From owner-ipng Mon Apr 1 09:55:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12563; Mon, 1 Apr 96 09:55:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12557; Mon, 1 Apr 96 09:55:06 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15748; Mon, 1 Apr 1996 09:53:00 -0800 Received: by mercury.Sun.COM (Sun.COM) id JAA23821; Mon, 1 Apr 1996 09:53:00 -0800 Received: from sunoco.nswc.navy.mil by relay2.nswc.navy.mil (4.1/SMI-4.1) id AA12172; Mon, 1 Apr 96 12:52:52 EST Received: from mobygrape.nswc.navy.mil by sunoco.nswc.navy.mil (SMI-8.6/SMI-SVR4) id MAA06193; Mon, 1 Apr 1996 12:52:43 -0500 Received: by mobygrape.nswc.navy.mil (SMI-8.6/SMI-SVR4) id MAA14599; Mon, 1 Apr 1996 12:52:43 -0500 Date: Mon, 1 Apr 1996 12:52:43 -0500 From: dmarlow@relay.nswc.navy.mil (Dave Marlow x1675) Message-Id: <199604011752.MAA14599@mobygrape.nswc.navy.mil> To: ipng@sunroof.eng.sun.com Subject: (IPng 1577) Multihoming Support in IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have read through Mike and Matt's Multihoming Support in IPv6 (draft-shand-ipv6-multi-homing-00.txt). I think that this is a good overview of the host multihoming problem. I have the following points on the draft: 1. The draft covers host multihoming for UNICAST transfer but never explicitly states this. Unicast transfer is the important case where additional mechanisms appear to be needed. The draft needs to explicitly state that it covers issues related to unicast transfer. An alternative is to be explicit about the current text being for unicast and to add a section or an appendix to cover the multicast issues. I have a few comments on multicast transfer with multihomed hosts, but I do not see multicast as a primary driver for this work. 2. In section 2.3 (High Resilience Multiple Interfaces) there is a list of ten requirements for host multihoming where each host has multiple interfaces which are functionally equivalent. One additional requirement that should be added is for a host originating multicast packets to identify the interface that each packet is originated on. This is currently assumed by all multicast routing protocols to ensure that multicast routers can construct the proper tree. 3. I think that an explicit goal should be added to the list of section 2.3 for unicast host multihoming to support both TCP and UDP transfers. Unicast RSVP/Integrated Services operations should also be supported. 4. One issue that I did not see covered in section 3 (Some possible solutions) were DNS impacts. I am not sure whether any extensions are required to DNS itself to cover host multihoming, but it seems possible that hosts may need to treat information from a DNS server differently (i.e. duplicate DNS responses). 5. There does not appear to be a need for any mechanisms, beyond those of RFC 1112, to support host multihoming, multicast transfer. Further work is needed to verify this. Section 4 of the internet draft (Selecting the output interface) is an important issue for multicast transfer; however, the multicast transfer has a different set of considerations than what is covered. While there may not be a need for additional mechanisms, consistent operation by a group of multihomed hosts using multicast transfer is needed and this might be a subject for an informational document. The goals for host multihoming's multicast capability should be to ensure that UDP multicast transfer is supported along with multicast RSVP/Integrated Services operations. Concluding remarks: I think that the current ID, with some modifications to cover the identified issues, meets its objectives of providing a taxonomy for host multihoming and a discussion of the issues. I would like to see further work on the Type 3 case (High Resilience Multiple Interfaces). Going over section 3 (Possible solutions) the anycast address and EID like alternatives appear to meet the need for unicast host multihoming. Given that anycast addresses are already being developed within the IPv6 effort it would seem that this approach should be looked at first. 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 Tue Apr 2 14:50:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13454; Tue, 2 Apr 96 14:50:25 PST Received: from caribe.eng.sun.com (caribe-86) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13448; Tue, 2 Apr 96 14:50:09 PST Received: from kandinsky (kandinsky [129.146.86.117]) by caribe.eng.sun.com (8.7.1/8.7.1) with SMTP id OAA06298 for ; Tue, 2 Apr 1996 14:46:47 -0800 (PST) Date: Tue, 2 Apr 1996 14:48:14 -0800 (PST) From: Bob Gilligan Reply-To: Bob Gilligan Subject: (IPng 1578) IPv6 API spec issues To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As those of you present at the Los Angeles IETF meeting know, discussion of the API spec was included on the agenda for the IPng working group meeting, but we did not have time to get to it. So instead, a group of people interested in the API spec got together in an informal meeting. Dan Harrington took excellent notes, which are included below. Much of the discussion centered on the proposals for dealing with source routing and sending/receiving interface specification alternatives that had been discussed on the mailing list. The participants could not agree on the best way to accommodate either of these functions in the API. We did, however, come up with a strategy for making progress: delete the controversial sections and re-issue the document as the "Basic" API spec for IPv6. This approach will get down those parts of the API that are generally agreed to (and what are needed to get most IPv6 applications running), while leaving room for future I-Ds to specify more "advanced" features, like how to deal with source routes and sending/receiving interface, as we get more experience with those features in the protocol. We also discussed the hostname to address translation functions. Most people felt that, since Posix now has defined a general protocol independent function for this purpose, there was no need for us to define another. So we proposed simply deleting the definitions of hostname2addr() and addr2hostname() from the spec, further simplifying it. I think these changes and the others outlined below represent forward progress. If there is no objection, I will go ahead and re-issue the spec with the changes discussed below. Bob. ----- Begin Included Message ----- Date: Mon, 11 Mar 1996 11:08:44 -0500 From: Dan Harrington To: Bob.Gilligan@Eng, bound@zk3.dec.com, conta@zk3.dec.com, dan@lkg.dec.com, jgm+@cmu.edu, mccann@zk3.dec.com, narten@vnet.ibm.com, nordmark@Eng, paul@vix.com, rstevens@noao.edu, thomas@lkg.dec.com, tim@mentat.com Subject: Notes of BSD API Ad Hoc Meeting Cc: deering@parc.xerox.com, hinden@ipsilon.lkg.dec.com Notes from Ad Hoc meeting of BSD API interested parties, held Thursday, 7 March 1996 at 35th IETF in LA. Attending: Bob Gilligan, Tim Hartrick, Dan Harrington, Jack McCann, Matt Thomas, Paul Vixie, Thomas Narten, John Myers, Jim Bound, Alex Conta, Erik Nordmark, Richard Stevens (late) Agenda: Function naming Link Identifier Source Route Mechanisms Function Naming: It was generally agreed, after some discussion, that the POSIX style getconninfo/getaddrinfo is the preferred means of providing name<=>address resolution. Paul Vixie made the statement that "this seems like the good-network-citizen thing to do". It was also mentioned that Paul's BIND distribution contains a gethostbyname2() function, but this is not documented and its use should not be encouraged. The addr2ascii and ascii2addr routines will be renamed to net_ntoa and net_aton, to align more closely with existing V4 calls. Paul also suggested a system-wide switch to control the ordering of returned addresses when multiple records are retrieved from DNS, a file such as /etc/inet6conf. Link Identifier: [No explicit notes on this topic..dth] Source Route Mechanisms: This was a freewheeling discussion, with multiple parties taking different positions. Some preferred the current proposal, using an array of sockaddr structures to pass source route information from kernel to application (and vice versa). One alternative with a fair number of backers involved the use of sendmsg/recvmsg syscalls, with control structures being used to convey ancillary information. The question of sendmsg etc. being a POSIX standard was raised (not sure of answer). A point was also raised that this mechanism might provide a general solution to the issue of getting at IPV6 specific information (e.g. Path MTU information will be needed by IPV6 applications also, and Hop-by-Hop options may require a means of passing ancillary information). Finally, consensus by exhaustion was reached with a proposal to pare down the current BSD API draft to provide the basic set of services on which there is agreement (with modifications reflecting the earlier decisions re. function naming). It was felt that this would provide the necessary functionality for porting the vast majority of extant applications. The various proposals for dealing with source routing and associated issues would then be submitted as separate drafts and debated independently. This compromise allows the IPV6 world to move forward. In summary, the BASIC API spec will NOT provide a source route mechanism, will NOT specify the received interface, but WILL retain the multicast group join/drop mechanisms. [Note that I have cc'ed our working group chairs, in order to apprise them of our informal meeting and its results. If they think that this meeting was clandestine, I can't wait to see their faces when they learn of the secret cabal plotting to change the IPV6 header to interleave the source and destination addresses on nibble boundaries! dth] Mailing list: Bob.Gilligan@eng.sun.com jgm+@cmu.edu tim@mentat.com narten@vnet.ibm.com paul@vix.com nordmark@eng.sun.com rstevens@noao.edu conta@zk3.dec.com bound@zk3.dec.com mccann@zk3.dec.com thomas@lkg.dec.com dan@lkg.dec.com cc: hinden@ipsilon.com deering@parc.xerox.com ----- 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 Wed Apr 3 06:17:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13831; Wed, 3 Apr 96 06:17:33 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13825; Wed, 3 Apr 96 06:17:17 PST Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15633; Wed, 3 Apr 1996 06:15:11 -0800 Received: by mercury.Sun.COM (Sun.COM) id GAA26336; Wed, 3 Apr 1996 06:15:10 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13128; 3 Apr 96 9:14 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1579) I-D ACTION:draft-ietf-ipngwg-unicast-addr-fmt-04.txt Date: Wed, 03 Apr 96 09:14:39 -0500 Message-Id: <9604030914.aa13128@IETF.CNRI.Reston.VA.US> 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. Note: This revision reflects comments received during the last call period. Title : An IPv6 Provider-Based Unicast Address Format Author(s) : Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel Filename : draft-ietf-ipngwg-unicast-addr-fmt-04.txt Pages : 8 Date : 04/02/1996 This document defines an IPv6 provider-based unicast address format for use in the Internet. The address format defined in this document is consistent with the "IPv6 Addressing Architecture" [ARCH] and the "An Architecture for IPv6 Unicast Address Allocation" [ALLOC], and is intended to facilitate scalable Internet routing. The unicast address format defined in this document doesn't preclude the use of other unicast address formats. 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-unicast-addr-fmt-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-unicast-addr-fmt-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960403085902.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-addr-fmt-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-addr-fmt-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960403085902.I-D@CNRI.Reston.VA.US> --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 Sun Apr 7 14:27:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16065; Sun, 7 Apr 96 14:27:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16059; Sun, 7 Apr 96 14:26:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23439; Sun, 7 Apr 1996 14:24:42 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA08257; Sun, 7 Apr 1996 14:24:41 -0700 Received: (from ipng@localhost) by dune.silkroad.com (8.7.3/8.6.9) id RAA16599 for ipng@sunroof.Eng.Sun.COM; Sun, 7 Apr 1996 17:24:17 -0400 From: Tim Bass (IPNG WG) Message-Id: <199604072124.RAA16599@dune.silkroad.com> Subject: (IPng 1580) IPv6 Checksum Interest To: ipng@sunroof.eng.sun.com Date: Sun, 7 Apr 1996 17:24:17 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24 PGP2] 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. Forgive me for being behind on this issue. I understand that the IP header checksum will be omitted from IPv6. This, IMO, is a great forward step because of numerous issues including data encryption and address translation. I am interested in working with someone (or more people) that are familar with IPv6 to publish an ID on IP address translation in intermediate systems. The strawman paper that describes the basic idea can be found in ps format directly: http://dune.silkroad.com/ Under the bullet: Classless Route Aggregation in Network Systems (CRANES) If anyone is interested in working together on this, please drop me a email. Best Regards, Tim +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "... the fates of men are bonded | | The Silk Road Group, Ltd. | one to the other by the cement | | | of wisdom." | | http://www.silkroad.com/ | Milan Kundera | | | | +------------------------------------------------------------------------+ ------------------------------------------------------------------------------ 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 Apr 8 06:30:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16243; Mon, 8 Apr 96 06:30:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16237; Mon, 8 Apr 96 06:30:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28778; Mon, 8 Apr 1996 06:28:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA15634; Mon, 8 Apr 1996 06:28:25 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08644; 8 Apr 96 9:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1581) I-D ACTION:draft-ietf-ipngwg-pppext-ipv6cp-02.txt Date: Mon, 08 Apr 96 09:07:39 -0400 Message-Id: <9604080907.aa08644@IETF.CNRI.Reston.VA.US> 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 : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-pppext-ipv6cp-02.txt Pages : 11 Date : 04/05/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. 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-pppext-ipv6cp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-pppext-ipv6cp-02.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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960405153828.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-pppext-ipv6cp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960405153828.I-D@CNRI.Reston.VA.US> --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 Apr 8 08:47:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16316; Mon, 8 Apr 96 08:47:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16310; Mon, 8 Apr 96 08:46:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09674; Mon, 8 Apr 1996 08:44:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA10987; Mon, 8 Apr 1996 08:44:41 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA00152; Mon, 8 Apr 1996 08:43:56 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Apr 1996 07:47:27 -0800 To: mankin@isi.edu, sob@harvard.edu From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1582) Request to Advance "An IPv6 Provider-Based Unicast Address Format" Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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 : An IPv6 Provider-Based Unicast Address Format Author(s) : Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel Filename : draft-ietf-ipngwg-unicast-addr-fmt-04.txt Pages : 8 Date : 04/02/1996 The working group last call on this document ended on Friday April 5, 1996. No comments were received during the working group last call. 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 Mon Apr 8 14:26:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16639; Mon, 8 Apr 96 14:26:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16393; Mon, 8 Apr 96 10:37:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00104; Mon, 8 Apr 1996 10:35:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA14036; Mon, 8 Apr 1996 10:34:56 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14451; 8 Apr 96 12:47 EDT To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1583) Last Call: An IPv6 Provider-Based Unicast Address Format to Proposed Standard Date: Mon, 08 Apr 96 12:47:40 -0400 Message-Id: <9604081247.aa14451@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider "An IPv6 Provider-Based Unicast Address Format" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by April 22, 1996. ------------------------------------------------------------------------------ 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 Apr 10 22:50:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18822; Wed, 10 Apr 96 22:50:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18774; Wed, 10 Apr 96 19:47:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB18709; Wed, 10 Apr 1996 19:45:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA28948; Wed, 10 Apr 1996 19:45:17 -0700 Received: from sixgraph.teleconnect.net (ppp2.teleconnect.net [205.236.38.73]) by teleconnect.net (8.6.12/8.6.9) with SMTP id WAA20436 for ; Wed, 10 Apr 1996 22:45:42 -0400 Message-Id: <316C6420.7644@teleconnect.net> Date: Wed, 10 Apr 1996 21:45:04 -0400 From: Charlie Flynn Reply-To: cflynn@teleconnect.net Organization: VP Teleconnect Services Inc. X-Mailer: Mozilla 3.0B2 (Win16; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 1584) unsubscribe ipng Content-Type: multipart/mixed; boundary="------------4BF453994B4A" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------4BF453994B4A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe ipng --------------4BF453994B4A Content-Type: text/html; charset=us-ascii; name="ipngwg-charter.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipngwg-charter.html" IPNG (ipngwg) Charter

IPNG (ipngwg) Charter

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

Chair(s)

  • Bob Hinden <hinden@ipsilon.com>
  • Steve Deering <deering@parc.xerox.com>

IP: Next Generation Area Director(s):

  • Scott Bradner <sob@harvard.edu>
  • Allison Mankin <mankin@isi.edu>

Mailing List Information

  • General Discussion:ipng@sunroof.eng.sun.com
  • To Subscribe: majordomo@sunroof.eng.sun.com
    • In Body: subscribe ipng
  • Archive: ftp://parcftp.xerox.com/pub/ipng

Description of Working Group

Editor: Bob Hinden (hinden@eng.sun.com)

The next generation of the Internet Protocol (IPv6) is intended to support Internet traffic for many years into the future by providing enhancements over the capabilities of the existing IPv4 service. This working group will produce specifications for the core functionality of that service. The working group shall carry out the recommendations of the IPng Area Directors as outlined at the July 1994 IETF and in ``The Recommendation for the IP Next Generation Protocol,'' Internet-Draft, (draft-ipng-recommendation-00.txt), September 1994.

The working group shall use the following documents as the basis of its work:

Simple Internet Protocol Plus (SIPP) Specfication (128 bit version)

SIPP Addressing Architecture

An Architecture for IPv6 Unicast Address Allocation

Simple SIPP Transition (SST) Overview

SIPP Program Interfaces for BSD Systems

SIPP Security Architecture

SIPP Authentication Header

SDRP Routing Header for SIPP-16

IP Next Generation Overview

ICMP and IGMP extensions for SIPP

FTP Operation Over Big Address Records (FOOBAR)

DNS Extensions to support SIPP

Enhancements to be considered:

Large Packets: Consider extensions for support of datagrams which are larger than 64K.

Source Routing: The working group shall consider enhanced source routing capabilities for IPng.

Tunneling: Complete specification of IPng in IPng tunneling.

Address format and assignment plan: The working group shall review the details of address structure as specified in [SIPP-16] and shall repair any deficiencies with respect to current or near-term addressing requirements, assuming a fixed, 16-byte size. The specification shall provide a mechanism for supporting multiple additional formats, for possible enhancement to incorporate other popular addressing schemes.

Routing Structure: In completing the addressing details, the working group shall ensure that routing according to current, CIDR-like schemes can be supported comfortably.

Autoconfiguration: Coordinate with the IPng Address Autoconfiguration Working Group.

Transition: The working group shall coordinate with the related transition and conversion efforts (ngtrans, tacit, nosi, etc.) to ensure that the base specification provides the facilities required for the transition from IPv4.

Security: A set of base documents for IPng security shall be completed. This shall include algorithms for authentication and privacy carried as IPng extension headers and include an initial selection of required encryption and key management algorithms and a facility to support other optional algorithms. The working group should also examine IPng firewall issues and if necessary develop specific firewall frameworks.

Minimum MTU: Consider a larger minimum MTU.

Header Compression: Consider ways to abbreviate the IPng header in the contexts of native IPng, multiple IPng packets in a flow, and encapsulated IPng.

TCP/UDP: The IPng Working Group will specify the procedures for hosts to compute and verify TCP/UDP pseudo-headers. Any other changes to TCP beyond making TCP work with IPng are out of scope of the working group and should be dealt with by a TCPng Working Group.

The IPng Working Group will coordinate with other groups, including Mobile IP, IPng Address Autoconfiguration, OSPF, IS-IS, RIPv2, IDR, Security, Applications, Network Management, IP over ATM, etc.

Goals and Milestones

Done
Submit preliminary IPng core specifications, with required enhancements, as Internet-Drafts.
Done
Submit revised core IPng specifications as Internet-Drafts.
Done
Submit core IPng specifications to IESG for consideration as Proposed Standards.
Feb 95
Submit extended IPng specifications as Internet-Drafts.
Mar 95
Submit extended IPng specifications to IESG for consideration as Proposed Standards.
Jul 95
Submit revised specifications to IESG based on implementation experience for consideration as Draft Standards.
Oct 95
Submit revised IPng specifications as Internet-Drafts.
Dec 95
Submit final IPng specifications to IESG for consideration as Standards.

Current Internet-Drafts

Request for Comments

IETF Secretariat - Corporation for National Research Initiatives

Please send questions, comments, and/or suggestions to ietf-web@cnri.reston.va.us.

Return to working group directory.

Return to IETF home page. --------------4BF453994B4A-- ------------------------------------------------------------------------------ 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 Apr 12 06:36:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19720; Fri, 12 Apr 96 06:36:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19714; Fri, 12 Apr 96 06:36:24 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22797; Fri, 12 Apr 1996 06:34:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA10985; Fri, 12 Apr 1996 06:34:06 -0700 Received: from pferguso-pc.cisco.com (c1robo8.cisco.com [171.68.13.8]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id GAA17517 for ; Fri, 12 Apr 1996 06:32:59 -0700 Message-Id: <199604121332.GAA17517@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Apr 1996 09:34:03 -0400 To: ipng@sunroof.eng.sun.com From: Paul Ferguson Subject: (IPng 1585) And now, a message from our detractors... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please accept my apologies for contributing non-technical bits, but I thought some of you might be interested to know that the US DoJ is attempting to mandate that IPv6 protocol(s) contain a method to identify 'adult' users v. 'minor' users in an effort to satisfy the CDA (Communications Decency Act). You are now entering the 'Ludicrous Zone'. - paul [snip] >Date: Fri, 12 Apr 96 02:22 CDT >From: Cu Digest (tk0jut2@mvs.cso.niu.edu) >Subject: Cu Digest, #8.29, Apr 11, 1996 [snip] > >+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+ > THE NEW "I AM A CHILD" INTERNET PROTOCOL >+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+-=-+ > >There's a second way to answer the question of: "How do you know who >the children are?" > >Another option the DoJ appears to be pushing -- we'll know details >tomorrow -- is this idea of reprogramming every computer on the >worldwide Internet to run software that tags users as adults or >minors, so a server will know whether it can send out "indecent" >material. > >This shifts the burden of establishing age-identity from the content >provider to the business or school giving out the Internet account. > >It also would allow any unscrupulous net.lurker to troll for "I am a >child" tags and follow them back to the originating site -- not >exactly the best way to protect the children! > >I should have realized this DoJ strategy earlier. Last week when I was >arguing with Bruce Taylor, an architect of the CDA, we went 'round and >'round on the issue of children on the Net. He maintained that every >Internet user has to have an account somewhere, so the provider of >that account can tag the user as a minor or adult. > >I asked Taylor how his proposal was possible with the TCP/IP protocol >-- the nerve system the carries all the data flowing through the Net. >He replied that technical problems can be solved by technical people, >and wasn't there a new protocol being developed, anyway? Basically, >his position was: "Your side comes across to the court as saying that >it can be done but we won't do it. You're a bunch of geeks who want to >protect their porn and the court isn't going to buy it." > >The "new protocol" being developed is IP Version 6, which the DoJ >zoomed in on in cross-examination of one of our witnesses, Scott >Bradner from the Internet Engineering Task Force: > > 13 Q Would it be fair to say, to summarize what you've just > 14 said, that the IP Next Generation group is working on a new > 15 generation of the IP Protocol itself? > 16 A That is correct. > 17 Q Does it have -- does the IP Next Generation group have > 18 recommendations regarding a specific architecture of the > 19 packet traffic on the Internet, including the format of the > 20 packet? > >The DoJ is going to argue that IPv6 can include such an adult/minor >tag in each datagram. Chris Hansen, the head of the ACLU's legal team, >says: > > Olsen is going to push this tagging idea that the government has, > that you can imbed in your tag -- in your address -- an adult or > minor tag. They're going to suggest that the market will come into > existence that will make that tagging relevant. > >It's more like the *judicial penalties* will evolve to make the >tagging not just relevant, but mandatory! On the cypherpunks list, >Bill Frantz, a computer consultant, outlines one problem: > > One of the migration paths suggested for IPV4 to IPV6 migration is > to tunnel IPV4 packets within IPV6 packets. IPV4 packets do not > provide for an adult/minor tag, so until the transition to IPV6 is > fairly well along, this approach will be ineffective. > > If the people who are worried about minor's accessing smut want > something this century, they should go with PICS. > >A member of the IETF replies: > > Neither, for that matter, do IPv6 packets -- there is no provision > for them. Furthermore, were anyone to create an end to end header of > that sort, it would be eight bytes of wasted space in every packet > in the net, especially since the implementation of such a tag is a > technical impossibility as there is no way to force the originating > system to tell the truth. > >The "high-touch" argument against this is important as the high-tech >one. I just received the following mail from someone who would be >unable to continue his work if the DoJ's IPv6 scheme is implemented: > > We provide free anonymous access to the net to sexual abuse survivors. > We don't even know who they are, nor do we care - a lot of them are > hiding out from their perps, and to try and identify them would be a > tremendous breach of trust, as they are depending on us for their > anonymity, much as a reporter would protect their anonymous source. > > I also have been told by these folks themselves that some of them are > under the age of 18 - hell, I've had a few that tell me that they are > 13 or 14 years old, and that they are still at home, still being raped > by their perps. We provide an outlet for their frustrations, emptional > support, a community for them, people to talk to, and support for them > if they choose to report their abuse. None of this would be possible > if Taylor and friends had their way. > > Sure, we could trace each and every one of them back to their > providers, and find out who they are, but I'm not going to do it, and > I'm perfectly willing to go to jail to protect their identities. My > integrity is worth a whole hell of a lot more than any government law. > > [snip] ------------------------------------------------------------------------------ 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 Apr 12 16:32:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20176; Fri, 12 Apr 96 16:32:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20170; Fri, 12 Apr 96 16:31:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB16246; Fri, 12 Apr 1996 16:29:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA08101; Fri, 12 Apr 1996 16:29:32 -0700 Received: from localhost (roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) with SMTP id AAA15338 for ; Sat, 13 Apr 1996 00:29:23 +0100 Message-Id: <199604122329.AAA15338@oberon.di.fc.ul.pt> X-Authentication-Warning: oberon.di.fc.ul.pt: Host localhost didn't use HELO protocol X-Authentication-Warning: oberon.di.fc.ul.pt: roque owned process doing -bs To: ipng@sunroof.eng.sun.com Subject: (IPng 1586) pseudo header checksum From: roque@di.fc.ul.pt Reply-To: roque@di.fc.ul.pt Date: Sat, 13 Apr 1996 00:29:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The IPv6 header does not have a checksum to protect the fixed header fields not the options carried in the packet. This as known advantages in terms of packet processing in the router when compared with IPv4. To give a warranty of address correctness protocols carried in IPv6 datagrams need to construct it's checksum with the packet addresses. While for TCP and UDP implementations this posses minor problems only, since they are usually implemented at the same software level as the IP code, for other protocols this may be undesirable. The BSD API provides a method for protocol extensions from user level (raw sockets) that has been extensively used by IPv4 software. The usual operation of such a protocol daemon is to use the sendto call to a destination letting source address determination to the kernel witch has routing information to decide the best source address for a destination. My suggestion to the IPng WG is that a destination option be defined to protect the addresses and payload length of IPv6 datagrams. The big advantage is that daemons that use raw sockets don't have to do a bind for every send they wish to do*. Even if the node as only one interface it may have multiple addresses (and will in most cases), so the only way an app can be sure of the source address for it's packets it's to bind. (or use the sendif setsockopt and pass the source address in every send if it's semantics implies the choice of source address and not just the outgoing interface, but my reading from the current draft doesn't give that idea). Other advantage is that when a routing header is used, this option can provide hop by hop (src route hops) address integrity. * supposing they have that information. the choice of the correct source address requires, in some cases, knowledge of the routing topology. regards, Pedro. P.S: i apologize if this issue as allready been raised. ------------------------------------------------------------------------------ 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 Apr 15 09:16:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20965; Mon, 15 Apr 96 09:16:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20959; Mon, 15 Apr 96 09:16:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27606; Mon, 15 Apr 1996 09:14:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA19874; Mon, 15 Apr 1996 09:14:00 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA04298; Mon, 15 Apr 1996 12:09:33 -0400 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA09605; Mon, 15 Apr 1996 12:09:30 -0400 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id LAA05268; Mon, 15 Apr 1996 11:44:02 GMT Message-Id: <199604151144.LAA05268@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host LOCALHOST didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: roque@di.fc.ul.pt Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1587) Re: pseudo header checksum In-Reply-To: Your message of "Sat, 13 Apr 1996 00:29:15 +0200." <199604122329.AAA15338@oberon.di.fc.ul.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 1996 11:43:52 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To give a warranty of address correctness protocols carried in IPv6 datagrams > need to construct it's checksum with the packet addresses. While for TCP and > UDP implementations this posses minor problems only, since they are usually > implemented at the same software level as the IP code, for other protocols > this may be undesirable. The BSD API provides a method for protocol extensions > from user level (raw sockets) that has been extensively used by IPv4 software. True. > The usual operation of such a protocol daemon is to use the sendto call > to a destination letting source address determination to the kernel witch has > routing information to decide the best source address for a destination. > > My suggestion to the IPng WG is that a destination option be defined > to protect the addresses and payload length of IPv6 datagrams. It's not needed. > The big advantage is that daemons that use raw sockets don't have to do > a bind for every send they wish to do*. Even if the node as only one > interface it may have multiple addresses (and will in most cases), so the > only way an app can be sure of the source address for it's packets it's to > bind. (or use the sendif setsockopt and pass the source address in every send > if it's semantics implies the choice of source address and not just the > outgoing interface, but my reading from the current draft doesn't give that > idea). No! There does not need to be support in the IPv6 protocol itself for what you are proposing since what you have asked for can be done in an application daemon. This is an implementation issue and not a protocol issue. In our Digital UNIX prototype, the ICMPv6 checksum calculation is properly performed on raw sockets without needing any changes to the IPv6 protocol. There are a number of ways to do this without requiring an addition options to be defined. One method is to define a setsockopt() which tells the raw socket code to calculate a checksum (including/excluding the header checksum) and insert it at a certain offset in each outgoing packet. For instance, you could use something like: int offset = 2; setsockopt(fd, IPPROTO_RAW, RAWIP6_ADDCHECKSUM, &offset, sizeof(offset)); for doing the ICMPv6 checksum. Raw sockets (especially ICMPv6 sockets) will be addressed in Advanced BSD API for BSD 4.4 sockets draft and Jim Bound, Keith Sklower, and I are doing. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Apr 15 09:50:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21016; Mon, 15 Apr 96 09:50:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20906; Mon, 15 Apr 96 07:42:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15550; Mon, 15 Apr 1996 07:39:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA22707; Mon, 15 Apr 1996 07:39:47 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12636; 15 Apr 96 10:37 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1588) Protocol Action: Neighbor Discovery for IP Version 6 (IPv6) to Proposed Standard Date: Mon, 15 Apr 96 10:36:56 -0400 Message-Id: <9604151037.aa12636@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft "Neighbor Discovery for IP Version 6 (IPv6)" as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This specification defines the Neighbor Discovery protocol for Internet Protocol Version 6. Nodes (hosts and routers) use Neighbor Discovery to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid. Hosts also use Neighbor Discovery to find neighboring routers that are willing to forward packets on their behalf. Finally, nodes use the protocol to actively keep track of which neighbors are reachable and which are not, and to detect changed link-layer addresses. When a router or the path to a router fails, a host actively searches for functioning alternates. Working Group Summary This document was strongly supported by the Working Group. There was discussion about the applicability of this protocol to different media types during the IETF Last-Call. The wording in the document was clarified to address the issue. Protocol Quality This document was reviewed for the IESG by Scott Bradner and Allison Mankin. ------------------------------------------------------------------------------ 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 Apr 15 09:54:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21028; Mon, 15 Apr 96 09:54:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20923; Mon, 15 Apr 96 08:41:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22921; Mon, 15 Apr 1996 08:39:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA09607; Mon, 15 Apr 1996 08:39:29 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA29225 for ; Mon, 15 Apr 1996 08:39:28 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Apr 1996 08:39:35 -0700 To: ipng@sunroof.eng.sun.com From: The IESG (by way of hinden@ipsilon.com (Bob Hinden)) Subject: (IPng 1589) Protocol Action: IPv6 Stateless Address Autoconfiguration to Proposed Standard Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft "IPv6 Stateless Address Autoconfiguration" as a Proposed Standard. This document is the product of the Address Autoconfiguration Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless autoconfiguration requires no manual configuration of hosts or additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server. This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. Working Group Summary There were no problems raised during last call for this proposal. Protocol Quality The proposed document was reviewed for the IESG by Scott Bradner and Allison Mankin. ------------------------------------------------------------------------------ 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 Apr 19 12:41:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23873; Fri, 19 Apr 96 12:41:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23867; Fri, 19 Apr 96 12:41:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27611; Fri, 19 Apr 1996 12:39:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA00245; Fri, 19 Apr 1996 12:38:46 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA05102; Fri, 19 Apr 1996 15:23:37 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05214; Fri, 19 Apr 1996 15:23:32 -0400 Message-Id: <9604191923.AA05214@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Cc: 6bone@isi.edu Subject: (IPng 1590) 6bone WWW Page Pointer Date: Fri, 19 Apr 96 15:23:31 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI... See the charter, requirements, mission, etc... at http://www-6bone.lbl.gov/6bone/ /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 Apr 19 12:56:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23915; Fri, 19 Apr 96 12:56:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23628; Fri, 19 Apr 96 01:47:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23801; Fri, 19 Apr 1996 01:45:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA05407; Fri, 19 Apr 1996 01:45:02 -0700 Received: by unidhp1.uni-c.dk (1.39.111.2/16.2) id AA121113671; Fri, 19 Apr 1996 10:47:51 +0200 Date: Fri, 19 Apr 1996 10:47:51 +0200 (METDST) From: "Gudrun R. Dalgeir" To: ipng@sunroof.eng.sun.com Subject: (IPng 1591) IPng documents Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please tell me from where I can copy the following documents, draft-ietf-ipngwg-addr-arch-03.txt draft-ietf-ipngwg-ipv6-spec-02.txt draft-ietf-ipngwg-icmp-02.txt draft-ietf-ngtrans-trans-mech-01.txt Regards ---------------- oo000oo ---------------------------------- Gudrun Dalgeir phone : (+) 45 35878532 UNI-C fax : (+) 45 35878890 Vermundsgade 5 e-mail : Gudrun.Dalgeir@uni-c.dk DK-2100 Kbh. O ----------------------------------------------------------- ------------------------------------------------------------------------------ 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 Apr 19 13:49:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23998; Fri, 19 Apr 96 13:49:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23992; Fri, 19 Apr 96 13:49:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06954; Fri, 19 Apr 1996 13:46:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA18637; Fri, 19 Apr 1996 13:46:13 -0700 Received: from pferguso-pc.cisco.com (c1robo8.cisco.com [171.68.13.8]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id NAA02973; Fri, 19 Apr 1996 13:44:26 -0700 Message-Id: <199604192044.NAA02973@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Apr 1996 16:45:29 -0400 To: "Gudrun R. Dalgeir" From: Paul Ferguson Subject: (IPng 1592) Re: IPng documents Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Try: http://www.internic.net or any appropriate mirror. - paul At 10:47 AM 4/19/96 +0200, Gudrun R. Dalgeir wrote: > >Please tell me from where I can copy the following documents, > >draft-ietf-ipngwg-addr-arch-03.txt >draft-ietf-ipngwg-ipv6-spec-02.txt >draft-ietf-ipngwg-icmp-02.txt >draft-ietf-ngtrans-trans-mech-01.txt > > >Regards > >---------------- oo000oo ---------------------------------- >Gudrun Dalgeir phone : (+) 45 35878532 >UNI-C fax : (+) 45 35878890 >Vermundsgade 5 e-mail : Gudrun.Dalgeir@uni-c.dk >DK-2100 Kbh. O >----------------------------------------------------------- > > >------------------------------------------------------------------------------ >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 > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s ------------------------------------------------------------------------------ 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 Apr 19 16:01:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24098; Fri, 19 Apr 96 16:01:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24092; Fri, 19 Apr 96 16:01:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28355; Fri, 19 Apr 1996 15:59:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA24012; Fri, 19 Apr 1996 15:59:09 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA17854; Fri, 19 Apr 1996 15:58:58 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Apr 1996 15:59:17 -0700 To: "Gudrun R. Dalgeir" From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1593) Re: IPng documents Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gudrun, >Please tell me from where I can copy the following documents, > >draft-ietf-ipngwg-addr-arch-03.txt >draft-ietf-ipngwg-ipv6-spec-02.txt >draft-ietf-ipngwg-icmp-02.txt >draft-ietf-ngtrans-trans-mech-01.txt These documents are now "Request for Comments" (RFC's). They can be found as ftp://ds.internic.net/rfc/rfc1884.txt ftp://ds.internic.net/rfc/rfc1883.txt ftp://ds.internic.net/rfc/rfc1885.txt ftp://ds.internic.net/rfc/rfc1933.txt A summary and pointers to the current IPng documents can be found at http://playground.sun.com/pub/ipng/html/ipng-main.html Regards, 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 Mon Apr 22 06:50:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25028; Mon, 22 Apr 96 06:50:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25022; Mon, 22 Apr 96 06:50:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19175; Mon, 22 Apr 1996 06:48:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA04018; Mon, 22 Apr 1996 06:48:01 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09347; 22 Apr 96 9:23 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1594) I-D ACTION:draft-ietf-ipngwg-bsd-api-05.txt Date: Mon, 22 Apr 96 09:23:03 -0400 Message-Id: <9604220923.aa09347@IETF.CNRI.Reston.VA.US> 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 Filename : draft-ietf-ipngwg-bsd-api-05.txt Pages : 25 Date : 04/19/1996 In order to implement the version 6 Internet Protocol (IPv6) [1] in an operating system based on Berkeley Unix (4.x BSD), changes must be made to the application program interface (API). TCP/IP applications written for BSD-based operating systems have in the past enjoyed a high degree of portability because most of the systems derived from BSD provide the same API, known informally as "the socket interface". We would like the same portability with IPv6. This memo presents a basic set of extensions to the BSD socket API to support IPv6. The changes include a new data structure to carry IPv6 addresses, new address conversion functions, and some new setsockopt() options. The extensions are designed to provide access to IPv6 features, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for new IPv6 features may be added at a later time. 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-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-api-05.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960419101857.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960419101857.I-D@CNRI.Reston.VA.US> --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 Apr 22 07:07:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25045; Mon, 22 Apr 96 07:07:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25039; Mon, 22 Apr 96 07:06:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20695; Mon, 22 Apr 1996 07:04:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA07627; Mon, 22 Apr 1996 07:04:22 -0700 Received: from felix.seas.gwu.edu (root@felix.seas.gwu.edu [128.164.9.3]) by franklin.seas.gwu.edu (8.7.1/8.7.1) with ESMTP id KAA02065 for ; Mon, 22 Apr 1996 10:04:21 -0400 (EDT) Received: from reto.seas.gwu.edu (reto@felix [128.164.9.3]) by felix.seas.gwu.edu (8.7.1/8.7.1) with SMTP id KAA17320 for ; Mon, 22 Apr 1996 10:04:16 -0400 (EDT) Message-Id: <199604221404.KAA17320@felix.seas.gwu.edu> X-Sender: reto@seas.gwu.edu X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Apr 1996 10:05:53 -0400 To: ipng@sunroof.eng.sun.com From: Reto Haeni Subject: (IPng 1595) Routing Header info against traffic analysis? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi As I was working through the IPng specifications, I realized that no options are implemented to prevent traffic analysis in IPsec. Could the Routing Header information been set up that the list of intermediate nodes changes when the system setting provide a list of alternative routing paths? An error condition could arise similar to the definition in the fragmentation header, if not all packets are received to complete reassembly of the message within 60 seconds (a long time but I think this would be a reasonable waiting time if you are concerned about traffic analysis). This would prevent most attempts to traffic analysis and complete the good IPsec spec. I am looking forward to your comments greetings Reto ------------------------------------------------------------------ at the George Washington University, Washington DC reto@seas.gwu.edu ------------------------------------------------------------------------------ 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 Apr 22 09:48:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25161; Mon, 22 Apr 96 09:48:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25155; Mon, 22 Apr 96 09:48:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06227; Mon, 22 Apr 1996 09:45:58 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA25465; Mon, 22 Apr 1996 09:45:49 -0700 From: Alain.Durand@imag.fr Received: from brahma.imag.fr (brahma.imag.fr [129.88.30.10]) by imag.imag.fr (8.6.11/8.6.9) with ESMTP id SAA03882 for ; Mon, 22 Apr 1996 18:45:45 +0200 Received: (from durand@localhost) by brahma.imag.fr (8.7/8.7) id SAA16243 for ipng@sunroof.Eng.Sun.COM; Mon, 22 Apr 1996 18:45:44 +0200 (MET DST) Message-Id: <9604221845.ZM16241@brahma.imag.fr> Date: Mon, 22 Apr 1996 18:45:43 +0200 X-Mailer: Z-Mail (3.2.1 10apr95) To: ipng@sunroof.eng.sun.com Subject: (IPng 1596) bsd-api-05 questions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've just read draft-ietf-ipngwg-bsd-api-05.txt, and I have a couple questions. 1) 5.1. Hostname to Address Translation getaddrinfo is defined by posix 1003.1g. Fine. But shouldn't the prototype of this function be stated in this draft? I have a hard time finding the posix doccument, and it's only referenced as DRAFT6.3 in the references. Any pointer where to get it? 2) 5.3. Address Conversion Functions The new functions to convert between binary and text forms of addresses are supposed to be protocol independent. Why should we have the keywork 'inet' in their names? I'd rather like to keep the previous names ascii2addr() and addr2ascii() instead of inet_pton() and inet_ntop(). - Alain Durand. -- ^_^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ U (* *) Alain DURAND | Preserve keyboards: | ( v ) I.M.A.G. | use completion. | /~~~\ Direction des Moyens Informatiques |----------------------------- <|=< BSD >= BP 53 38041 Grenoble Cedex 9 | E-Mail: Alain.Durand@imag.fr | \ / France | Phone: +33 76 63 57 03 | <~~< Postmaster@imag.fr | Fax: +33 76 51 49 64 ~ ~ ------------------------------------------------------------------------------ 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 Apr 22 11:25:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25215; Mon, 22 Apr 96 11:25:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25208; Mon, 22 Apr 96 11:25:11 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25547; Mon, 22 Apr 1996 11:22:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA04568; Mon, 22 Apr 1996 11:22:27 -0700 Received: from mailhub.advtech.uswest.com (mh16.advtech.uswest.com [130.13.16.7]) by uswat.advtech.uswest.com (8.7.5/8.7.3) with ESMTP id MAA07982; Mon, 22 Apr 1996 12:21:32 -0600 (MDT) Received: from yakima.advtech.uswest.com (yakima.advtech.uswest.com [130.13.21.147]) by mailhub.advtech.uswest.com (8.7.5/8.7.3) with SMTP id MAA19087; Mon, 22 Apr 1996 12:21:31 -0600 (MDT) Received: by yakima.advtech.uswest.com (advtech.uswest.com) id AA11806 (4.1/at-generic.8Nov93); Mon, 22 Apr 96 12:21:30 MDT From: Brian Field Message-Id: <9604221821.AA11806@yakima.advtech.uswest.com> Subject: (IPng 1597) Re: I-D ACTION:draft-ietf-ipngwg-bsd-api-05.txt To: Internet-Drafts@cnri.reston.va.us Date: Mon, 22 Apr 1996 12:21:29 -0600 (MDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9604220923.aa09347@IETF.CNRI.Reston.VA.US> from "Internet-Drafts@CNRI.Reston.VA.US" at Apr 22, 96 09:23:03 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Title : Basic Socket Interface Extensions for IPv6 > Author(s) : R. Gilligan, S. Thomson, J. Bound > Filename : draft-ietf-ipngwg-bsd-api-05.txt > Pages : 25 > Date : 04/19/1996 Some comments on the above draft. Two typos: On page 8, the reference to (non-existent) section 9 should instead be section 8. On page 9, the reference to section 6.3 should instead be section 5.4 Two general comments: There is no indication where the variable in6addr_any is defined. Presumably, it's in , since that's where in6addr_loopback is defined. Function getnameinfo () is said to replace addr2hostname(). addr2hostname() requires an the address type be specified as a parameter, while getnameinfo() does not. Should getnameinfo () also define an address family parameter or does it use some magic to figure the address family out on the fly? One question: In section 8.1, "IPv4 Applications Interoperating with IPv6 Nodes", it appears as if the obvious was left out. What's the problem with having IPv6 use IPv4 when talking to an IPv4 node (ala Solaris)? This way, IPv4 nodes do not need to change (as would be required to support suggestion #2) and would allow v6 nodes to communication with v4 nodes... (what am I missing??) 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 Mon Apr 22 11:48:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25232; Mon, 22 Apr 96 11:48:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25226; Mon, 22 Apr 96 11:48:22 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00527; Mon, 22 Apr 1996 11:45:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA12484; Mon, 22 Apr 1996 11:45:31 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA24970; Mon, 22 Apr 1996 14:24:10 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26839; Mon, 22 Apr 1996 14:24:04 -0400 Message-Id: <9604221824.AA26839@fwasted.zk3.dec.com> To: Alain.Durand@imag.fr Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1598) Re: bsd-api-05 questions In-Reply-To: Your message of "Mon, 22 Apr 96 18:45:43 +0200." <9604221845.ZM16241@brahma.imag.fr> Date: Mon, 22 Apr 96 14:24:04 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, >I've just read draft-ietf-ipngwg-bsd-api-05.txt, and I have a couple >questions. >1) 5.1. Hostname to Address Translation >getaddrinfo is defined by posix 1003.1g. Fine. But shouldn't the >prototype of this function be stated in this draft? >I have a hard time finding the posix doccument, and it's only >referenced as DRAFT6.3 in the references. Any pointer where to get >it? See attached ftp location. THis is IEEE Work hence it requires membership to participate. We have referenced the spec only at this time because if it changes we don't want to update the v6 IETF API spec each time until the draft reaches standard. Bob is on vacation this week and I am on semi vacation until Wednesday. If all can just copy this spec (attached) for now and tell us if that will work we would appreciated it. If not Bob, I, or someone will develop a man page type draft for getaddrinfo and make it an info RFC or something. >2) 5.3. Address Conversion Functions > >The new functions to convert between binary and text forms of >addresses are supposed to be protocol independent. >Why should we have the keywork 'inet' in their names? >I'd rather like to keep the previous names ascii2addr() and >addr2ascii() instead of inet_pton() and inet_ntop(). This spec is for the Internet? What besides TCP/IP runs on it that we should care about? This will also be the same functions in an upcoming release of BIND too. thanks /jim ---------------------------------------------- The postscript of P1003.1g/D6.3 (the current draft) is available on the IEEE SPASystem. It can be retrieved from there by anonymous ftp. To do so, connect via ftp to host stdsbbs.ieee.org and log in as "anonymous", giving your e-mail address as password. Then enter the following commands: quote site group p1003.1g quote site gpass want2see You will then be able to change to directory private/p1003.1g/d6.3 and retrieve the files that are there. --------------------------------------------------- ------------------------------------------------------------------------------ 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 Apr 22 12:10:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25261; Mon, 22 Apr 96 12:10:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25255; Mon, 22 Apr 96 12:09:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05330; Mon, 22 Apr 1996 12:07:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA19601; Mon, 22 Apr 1996 12:06:39 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id MAA12047; Mon, 22 Apr 1996 12:02:14 -0700 (PDT) Message-Id: <199604221902.MAA12047@aland.bbn.com> To: bound@zk3.dec.com Cc: Alain.Durand@imag.fr, ipng@sunroof.eng.sun.com Subject: (IPng 1599) Re: bsd-api-05 questions In-Reply-To: Your message of Mon, 22 Apr 96 14:24:04 -0400. <9604221824.AA26839@fwasted.zk3.dec.com> Date: Mon, 22 Apr 96 12:02:13 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >2) 5.3. Address Conversion Functions > >The new functions to convert between binary and text forms of >addresses are supposed to be protocol independent. >Why should we have the keywork 'inet' in their names? >I'd rather like to keep the previous names ascii2addr() and >addr2ascii() instead of inet_pton() and inet_ntop(). This spec is for the Internet? What besides TCP/IP runs on it that we should care about? This will also be the same functions in an upcoming release of BIND too. Just because we're an internet standards committee doesn't mean we have to ignore other uses of the technology. These are LIBRARY functions and so should be general where feasible. Furthermore, even in an IP implementation, one periodically has to convert to and from binary representations of Ethernet, ATM, FDDI, and other link level addresses (e.g. applications that print ARP tables). It would be nice if one library routine just did that for us nicely. 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 Mon Apr 22 12:31:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25289; Mon, 22 Apr 96 12:31:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25283; Mon, 22 Apr 96 12:31:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09614; Mon, 22 Apr 1996 12:29:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA26955; Mon, 22 Apr 1996 12:28:57 -0700 Received: (from lane@localhost) by watsun.cc.columbia.edu (8.7.5/8.7.3) id PAA13432; Mon, 22 Apr 1996 15:26:10 -0400 (EDT) Date: Mon, 22 Apr 1996 15:26:10 -0400 (EDT) From: David Lane Message-Id: <199604221926.PAA13432@watsun.cc.columbia.edu> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: bound@zk3.dec.com's message of Mon, 22 Apr 96 14:24:04 -0400 <9604221824.AA26839@fwasted.zk3.dec.com> Subject: (IPng 1600) Re: bsd-api-05 questions Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >2) 5.3. Address Conversion Functions > >The new functions to convert between binary and text forms of >addresses are supposed to be protocol independent. >Why should we have the keywork 'inet' in their names? >I'd rather like to keep the previous names ascii2addr() and >addr2ascii() instead of inet_pton() and inet_ntop(). This spec is for the Internet? What besides TCP/IP runs on it that we should care about? This will also be the same functions in an upcoming release of BIND too. thanks /jim Well, yes and no. The spec is being produced as part of the IPng work for the Internet, yes. However, it is not *just* a spec for the Internet. It is a spec for an API which is one of the more commonly used interfaces for any form of networking. There are products that use sockets to access the global public data network (ITU protocol suite, *not* TCP/IP), there are sockets interfaces to "Unix sockets" which are more like named pipes than anything else (and woe be unto them that break this!), and so on. As it currently exists, it cannot support IPv6, so the purpose of the work being done on this spec, as I understand it, is to make the BSD sockets interface *less* protocol dependent, not more so. David. ------------------------------------------------------------------------------ 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 Apr 22 16:15:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25504; Mon, 22 Apr 96 16:15:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25498; Mon, 22 Apr 96 16:14:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20117; Mon, 22 Apr 1996 16:12:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA04575; Mon, 22 Apr 1996 08:37:19 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id LAA17863; Mon, 22 Apr 1996 11:37:12 -0400 (EDT) Message-Id: <199604221537.LAA17863@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Reto Haeni Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1601) Re: Routing Header info against traffic analysis? In-Reply-To: Your message of "Mon, 22 Apr 1996 10:05:53 EDT." <199604221404.KAA17320@felix.seas.gwu.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 22 Apr 1996 11:37:07 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reto Haeni writes: > As I was working through the IPng specifications, I realized that > no options are implemented to prevent traffic analysis in IPsec. 1) This is material for the IPSEC mailing list, not for IPng. 2) You are correct. There is no provision for preventing traffic analysis. If you want to do it, send out dummy encrypted traffic. It isn't something that IPSec really needs to solve directly. .pm ------------------------------------------------------------------------------ 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 Apr 23 03:33:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25847; Tue, 23 Apr 96 03:33:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25841; Tue, 23 Apr 96 03:33:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16219; Tue, 23 Apr 1996 03:30:43 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA27154; Tue, 23 Apr 1996 03:30:42 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1602) Re: bsd-api-05 questions To: Alain.Durand@imag.fr Date: Tue, 23 Apr 1996 12:29:09 +0100 (BST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9604221845.ZM16241@brahma.imag.fr> from "Alain.Durand@imag.fr" at Apr 22, 96 06:45:43 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) 5.1. Hostname to Address Translation > > getaddrinfo is defined by posix 1003.1g. Fine. But shouldn't the > prototype of this function be stated in this draft? > I have a hard time finding the posix doccument, and it's only > referenced as DRAFT6.3 in the references. Any pointer where to get > it? We should define it too. Posix documents are expensive. Having an RFC that requires you spend a fortune on other documents to use it is counter productive to standards. At least define for IPv6 Alan ------------------------------------------------------------------------------ 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 Apr 23 06:21:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25933; Tue, 23 Apr 96 06:21:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25927; Tue, 23 Apr 96 06:20:57 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25426; Tue, 23 Apr 1996 06:18:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA29152; Tue, 23 Apr 1996 06:18:26 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11309; 23 Apr 96 8:59 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1603) I-D ACTION:draft-ietf-ipngwg-pmtuv6-02.txt Date: Tue, 23 Apr 96 08:59:22 -0400 Message-Id: <9604230859.aa11309@IETF.CNRI.Reston.VA.US> 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. Note: This revision reflects comments received during the last call period. Title : Path MTU Discovery for IP version 6 Author(s) : J. McCann, S. Deering, J. Mogul Filename : draft-ietf-ipngwg-pmtuv6-02.txt Pages : 16 Date : 04/22/1996 This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC-1191, which describes Path MTU Discovery for IP version 4. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-pmtuv6-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pmtuv6-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-pmtuv6-02.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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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: <19960422133124.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-pmtuv6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-pmtuv6-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960422133124.I-D@CNRI.Reston.VA.US> --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 Apr 23 06:30:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25957; Tue, 23 Apr 96 06:30:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25951; Tue, 23 Apr 96 06:30:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26070; Tue, 23 Apr 1996 06:28:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA01095; Tue, 23 Apr 1996 06:28:16 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA25464; Tue, 23 Apr 1996 09:17:17 -0400 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA13074; Tue, 23 Apr 1996 09:17:15 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id IAA13389; Tue, 23 Apr 1996 08:55:25 GMT Message-Id: <199604230855.IAA13389@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: ipng@sunroof.eng.sun.com Cc: iialan@iifeak.swan.ac.uk (Alan Cox), Alain.Durand@imag.fr, Brian Field Subject: (IPng 1604) Re: bsd-api-05 questions In-Reply-To: Your message of "Tue, 23 Apr 1996 12:29:09 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Apr 1996 08:55:15 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [This message addresses various points about the API draft that have been raised over the past few days.] > We should define it too. Posix documents are expensive. Having an RFC > that requires you spend a fortune on other documents to use it is counter > productive to standards. At least define for IPv6 It will be defined but in a separate draft. This is so that this draft can go ahead without having to keep in sync with the POSIX definition. The new draft will be keep is sync with the POSIX 1003.1g definition of getaddrinfo. > The new functions to convert between binary and text forms of > addresses are supposed to be protocol independent. > Why should we have the keywork 'inet' in their names? > I'd rather like to keep the previous names ascii2addr() and > addr2ascii() instead of inet_pton() and inet_ntop(). Why inet_* over net_*? Namespace issues. It is believed that there is a much more likely chance that net_* would conflict with existing code than would inet_* (since inet_* is already being used (inet_addr, inet_ntoa)). > Function getnameinfo () is said to replace addr2hostname(). addr2hostname() > requires an the address type be specified as a parameter, while > getnameinfo() does not. Should getnameinfo () also define an address family > parameter or does it use some magic to figure the address family out on the > fly? getnameinfo gets passed in a struct sockaddr * and can obtain the address family from the sockaddr. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Apr 23 08:56:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26099; Tue, 23 Apr 96 08:56:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26093; Tue, 23 Apr 96 08:56:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10921; Tue, 23 Apr 1996 08:53:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA08404; Tue, 23 Apr 1996 08:53:38 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA01423; Tue, 23 Apr 1996 08:53:31 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Apr 1996 08:53:55 -0700 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1605) WG Last Call: "IP Version 6 over PPP" Cc: hinden@Ipsilon.COM, deering@parc.xerox.com 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 : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-pppext-ipv6cp-02.txt Pages : 11 Date : 04/05/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 Tuesday May 7, 1996. 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 Apr 23 21:45:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26831; Tue, 23 Apr 96 21:45:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26825; Tue, 23 Apr 96 21:45:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25970; Tue, 23 Apr 1996 21:42:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA08424; Tue, 23 Apr 1996 21:42:49 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA18030; Wed, 24 Apr 1996 00:38:44 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27487; Wed, 24 Apr 1996 00:38:42 -0400 Message-Id: <9604240438.AA27487@fwasted.zk3.dec.com> To: Craig Partridge Cc: bound@zk3.dec.com, Alain.Durand@imag.fr, ipng@sunroof.eng.sun.com Subject: (IPng 1606) Re: bsd-api-05 questions In-Reply-To: Your message of "Mon, 22 Apr 96 12:02:13 PDT." <199604221902.MAA12047@aland.bbn.com> Date: Wed, 24 Apr 96 00:38:42 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >2) 5.3. Address Conversion Functions > >The new functions to convert between binary and text forms of >addresses are supposed to be protocol independent. >Why should we have the keywork 'inet' in their names? >I'd rather like to keep the previous names ascii2addr() and >addr2ascii() instead of inet_pton() and inet_ntop(). This spec is for the Internet? What besides TCP/IP runs on it that we should care about? This will also be the same functions in an upcoming release of BIND too. >Just because we're an internet standards committee doesn't mean we have >to ignore other uses of the technology. THe name inet_pton() or inet_ntop() does not do that. >These are LIBRARY functions and so should be general where feasible. Fine someone else can write a generic API spec. We will have several come out before Montreal like the Advanced API specs soon do handle multihoming, interfaces, sources routes, anycast, etc.. If you really want a generic library I encourage you to write the spec. >Furthermore, even in an IP implementation, one periodically has to convert >to and from binary representations of Ethernet, ATM, FDDI, and other link >level addresses (e.g. applications that print ARP tables). It would >be nice if one library routine just did that for us nicely. Fine write the spec. We are doing this to get IPv6 up and away so developers can start porting. The IETF don't do APIs so we are doing what is needed for v6. If you or anyone else wants more or can find a valid technical problem with the spec we are listening. NO change will be made. 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 Apr 23 21:50:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26845; Tue, 23 Apr 96 21:50:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26837; Tue, 23 Apr 96 21:50:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26172; Tue, 23 Apr 1996 21:47:59 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA09499; Tue, 23 Apr 1996 21:47:57 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA24882; Wed, 24 Apr 1996 00:43:26 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30356; Wed, 24 Apr 1996 00:43:21 -0400 Message-Id: <9604240443.AA30356@fwasted.zk3.dec.com> To: David Lane Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1607) Re: bsd-api-05 questions In-Reply-To: Your message of "Mon, 22 Apr 96 15:26:10 EDT." <199604221926.PAA13432@watsun.cc.columbia.edu> Date: Wed, 24 Apr 96 00:43:20 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David, In this spec all we care about are BSD API sockets for IPv6 and now only its BASIC functions. Thats all we care about. Do I care about more. Yes like WINSOCKETS and XTI and RPC (needs for multihoming or source routes). I see your point but this is not a generic API spec. No change forthcoming. Anyone now can do an Advanced API spec as an Info RFC. For example I am working on one with two other folks that will be ONLY for BSD (read UNIX type sockets) 4.4 and it won't care at all about BSD 4.3. The ISVs and Market and then the real API standards groups will build the standard API. 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 Apr 23 22:06:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26919; Tue, 23 Apr 96 22:06:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26913; Tue, 23 Apr 96 22:05:57 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27043; Tue, 23 Apr 1996 22:03:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA12696; Tue, 23 Apr 1996 22:03:25 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA25219; Wed, 24 Apr 1996 00:55:53 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA30893; Wed, 24 Apr 1996 00:55:53 -0400 Message-Id: <9604240455.AA30893@fwasted.zk3.dec.com> To: iialan@iifeak.swan.ac.uk (Alan Cox) Cc: Alain.Durand@imag.fr, ipng@sunroof.eng.sun.com Subject: (IPng 1608) Re: bsd-api-05 questions In-Reply-To: Your message of "Tue, 23 Apr 96 12:29:09 BST." Date: Wed, 24 Apr 96 00:55:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan, >> 1) 5.1. Hostname to Address Translation >> >> getaddrinfo is defined by posix 1003.1g. Fine. But shouldn't the >> prototype of this function be stated in this draft? >> I have a hard time finding the posix doccument, and it's only >> referenced as DRAFT6.3 in the references. Any pointer where to get >> it? > >We should define it too. Posix documents are expensive. Having an RFC >that requires you spend a fortune on other documents to use it is counter >productive to standards. At least define for IPv6 Offline as we built this version of the spec I fought for what your saying. What convinced me with my co-authors and other API wizards was that if we put it in this spec it will change for sure. We are trying to define a basic BSD Sockets IPv6 API spec to become INFO RFC. If we put the D6.3 state in their it will be obsolete as D6.3 evolves to D6.4. I agree that the methods of charging for these specs is not too cool. I am now on the D6.3 mailing list and an IEEE member. I am going to complain about this when I get time officially to the IEEE at least for APIs where they cross reference networking APIs for which the protocols and mechanisms underneath are done in the IETF. I don't know how far I will get but I will at least make noise. For now we have a pointer I sent out to D6.3 and Bob and I will talk before Montreal to come up with another means. I will also connect with the IEEE Standards Office. OK. Right now I am really maxed at work. I will make a point of this before Montreal. /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 Apr 24 03:04:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27105; Wed, 24 Apr 96 03:04:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27099; Wed, 24 Apr 96 03:04:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15211; Wed, 24 Apr 1996 03:02:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA28024; Wed, 24 Apr 1996 03:02:05 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1609) Re: bsd-api-05 questions To: bound@zk3.dec.com Date: Wed, 24 Apr 1996 12:00:04 +0100 (BST) Cc: Alain.Durand@imag.fr, ipng@sunroof.eng.sun.com In-Reply-To: <9604240455.AA30893@fwasted.zk3.dec.com> from "bound@zk3.dec.com" at Apr 24, 96 00:55:52 am Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Offline as we built this version of the spec I fought for what your > saying. What convinced me with my co-authors and other API wizards was > that if we put it in this spec it will change for sure. We are trying > to define a basic BSD Sockets IPv6 API spec to become INFO RFC. If we > put the D6.3 state in their it will be obsolete as D6.3 evolves to D6.4. This is a rather good point. Oh well. > APIs where they cross reference networking APIs for which the protocols > and mechanisms underneath are done in the IETF. I don't know how far I > will get but I will at least make noise. For now we have a pointer I > sent out to D6.3 and Bob and I will talk before Montreal to come up with > another means. I will also connect with the IEEE Standards Office. OK. > Right now I am really maxed at work. I will make a point of this before > Montreal. Best of luck with it Alan ------------------------------------------------------------------------------ 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 Apr 24 07:58:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27296; Wed, 24 Apr 96 07:58:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27290; Wed, 24 Apr 96 07:57:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06347; Wed, 24 Apr 1996 07:55:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA26103; Wed, 24 Apr 1996 07:55:17 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id HAA14842; Wed, 24 Apr 1996 07:51:11 -0700 (PDT) Message-Id: <199604241451.HAA14842@aland.bbn.com> To: bound@zk3.dec.com Cc: Craig Partridge , Alain.Durand@imag.fr, ipng@sunroof.eng.sun.com Subject: (IPng 1610) Re: bsd-api-05 questions In-Reply-To: Your message of Wed, 24 Apr 96 00:38:42 -0400. <9604240438.AA27487@fwasted.zk3.dec.com> Date: Wed, 24 Apr 96 07:51:10 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >These are LIBRARY functions and so should be general where feasible. Fine someone else can write a generic API spec. We will have several come out before Montreal like the Advanced API specs soon do handle multihoming, interfaces, sources routes, anycast, etc.. If you really want a generic library I encourage you to write the spec. I did -- I wrote the first addr2ascii() and ascii2addr() functions and explained how to use them. That work got borrowed for IPv6. What I understand from the current e-mail is you decided to screw the purpose of that work up. So I think the shoe is on the other foot. Unscrew the spec. 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 Apr 24 10:39:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27495; Wed, 24 Apr 96 10:39:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27489; Wed, 24 Apr 96 10:39:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01906; Wed, 24 Apr 1996 10:36:38 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA22642; Wed, 24 Apr 1996 10:34:44 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA00504; Wed, 24 Apr 1996 13:22:37 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03666; Wed, 24 Apr 1996 13:22:32 -0400 Message-Id: <9604241722.AA03666@fwasted.zk3.dec.com> To: Craig Partridge Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1611) Re: bsd-api-05 questions In-Reply-To: Your message of "Wed, 24 Apr 96 07:51:10 PDT." <199604241451.HAA14842@aland.bbn.com> Date: Wed, 24 Apr 96 13:22:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >These are LIBRARY functions and so should be general where feasible. Fine someone else can write a generic API spec. We will have several come out before Montreal like the Advanced API specs soon do handle multihoming, interfaces, sources routes, anycast, etc.. If you really want a generic library I encourage you to write the spec. >I did -- I wrote the first addr2ascii() and ascii2addr() functions and >explained how to use them. That work got borrowed for IPv6. What I >understand from the current e-mail is you decided to screw the purpose of >that work up. I know. The functions have not changed only the name. So your functions still apply. We don't like the name. And that had consensus. >So I think the shoe is on the other foot. Unscrew the spec. Maybe there is no issue here. The af argument still applies. The names have been changed. I assume your not wedded to the name? If so your the only one I know of? I personally don't care. But strong input who uses these felt inet_pton() and inet_ntop() were better library names, and more congruent with the BSD other library names. /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 Apr 24 10:48:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27524; Wed, 24 Apr 96 10:48:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27518; Wed, 24 Apr 96 10:47:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03537; Wed, 24 Apr 1996 10:45:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA00896; Wed, 24 Apr 1996 10:45:14 -0700 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA12884; Wed, 24 Apr 1996 10:44:40 -0700 Date: Wed, 24 Apr 1996 10:44:40 -0700 From: Ran Atkinson Message-Id: <199604241744.KAA12884@puli.cisco.com> To: craig@aland.bbn.com Subject: (IPng 1612) Re: bsd-api-05 questions In-Reply-To: <199604241451.HAA14842@aland.bbn.com> References: <9604240438.AA27487@fwasted.zk3.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199604241451.HAA14842@aland.bbn.com> Craig Partridge wrote: > > > >These are LIBRARY functions and so should be general where feasible. > > Fine someone else can write a generic API spec. We will have several > come out before Montreal like the Advanced API specs soon do handle > multihoming, interfaces, sources routes, anycast, etc.. If you really > want a generic library I encourage you to write the spec. > >I did -- I wrote the first addr2ascii() and ascii2addr() functions and >explained how to use them. That work got borrowed for IPv6. What I >understand from the current e-mail is you decided to screw the purpose of >that work up. > >So I think the shoe is on the other foot. Unscrew the spec. Craig is correct. The current draft is broken in ways that the earlier drafts were not. Fix the draft and remove the recent brokenness. 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 Wed Apr 24 11:02:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27617; Wed, 24 Apr 96 11:02:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27611; Wed, 24 Apr 96 11:02:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06213; Wed, 24 Apr 1996 10:59:43 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA07121; Wed, 24 Apr 1996 10:59:44 -0700 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id KAA11654; Wed, 24 Apr 1996 10:59:43 -0700 Date: Wed, 24 Apr 1996 10:59:43 -0700 From: Ran Atkinson Message-Id: <199604241759.KAA11654@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1613) Re: bsd-api-05 questions In-Reply-To: <9604241722.AA03666@fwasted.zk3.dec.com> References: <199604241451.HAA14842@aland.bbn.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <9604241722.AA03666@fwasted.zk3.dec.com> Jim wrote: >I know. The functions have not changed only the name. So your >functions still apply. We don't like the name. And that had ^^^^^^^^^^^^ >consensus. ^^^^^^^^^ Nonsense. >I personally don't care. Then I'm confused about why are you arguing so strongly about this. No one else seems to be as vocal as you are on this. The discussions on the list have mostly been in favour of the ascii2addr() and addr2ascii() names. I talked about this at some length with Bob Gilligan at LA and afterwards and he was happy to stay with the older names that Craig Partridge came up with. Craig's names have sufficient implementation experience now indicating they are fine. The argument that some others make about namespace conflicts is bogus because the inet_*() namespace isn't reserved as a block and so isn't any better protected against namespace conflicts. As to the IEEE, there is near zero probability of their standards being no-cost since they fund standards work with the income from standards sales. I agree this is unfortunate, but it seems very unlikely to change anytime soon. A real RFC that describes things in sufficient detail to build an implementation that has application portability will provide real value. If folks actually build that interface as per the RFC, it is very likely to be accepted by the IEEE POSIX.1 folks in the future. 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 Wed Apr 24 11:14:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27711; Wed, 24 Apr 96 11:14:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27705; Wed, 24 Apr 96 11:14:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08602; Wed, 24 Apr 1996 11:11:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA11504; Wed, 24 Apr 1996 11:10:20 -0700 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA22769; Wed, 24 Apr 96 13:13:57 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA15245; Wed, 24 Apr 96 13:11:56 CDT Date: Wed, 24 Apr 96 13:11:56 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9604241811.AA15245@anubis.network.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1614) modelling address space allocation - Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I confess that I haven't followed every detail of how the IPv6 address space is carved up, but I did get an impression of various agendas being pushed, and various theories being proposed. Did anyone actually try to build some models of how the IPv4 address space got allocated, how it grew and what chunks got assigned when, and then plugged the various IPv6 address-space-slicings into that to see how it worked, how well routes would have aggregated, and so on? Or cooked up algorithms for 'how to allocated IPv6 addresses' and then plugged the current IPv4 network into same, assuming some sort of optimality, and seen what happens? I'm interested in looking at such models. I confess, further, that watching back-biting about API details does not really make me jump up and scream 'WOW! What a bunch of awesome SCIENTISTS!' Andrew ------------------------------------------------------------------------------ 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 Apr 25 00:08:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28410; Thu, 25 Apr 96 00:08:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28404; Thu, 25 Apr 96 00:08:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11824; Thu, 25 Apr 1996 00:06:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA19732; Thu, 25 Apr 1996 00:06:05 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0uCJiG-000ZBXC; Wed, 24 Apr 96 22:35 PDT Message-Id: Date: Wed, 24 Apr 96 22:35 PDT From: Michael Gersten Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: ipng@sunroof.eng.sun.com Subject: (IPng 1615) Re: And now, a message from our detractors... Reply-To: michael@stb.info.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Re: Government trying to put an adult/minor flag in the IPv6 header: It's not a question of can it be done or not. It's just one bit in the header. And, on unix systems, you can check the real user id of the process that's doing the send or write call, and set it. But on other systems? On systems where the process sending packets out the internet does not know what process generated the data? Or what about data generated from a process that doesn't have a user associated with it -- think of a daemon process, or a server on another machine. Neither of these will have any idea what generated the original data. You lose this extra info the first time it gets redirected through a new host. Bad idea. (Insert image of an owner scolding a dog with a wagging tail). Michael -- Michael Gersten michael@stb.info.com http://www.stb.info.com/~michael NeXT Registered Developer (NeRD) # 3860 Without Prejudice, UCC 1-207 ** HIRE ME: http://www.stb.info.com/~michael/Work.html ------------------------------------------------------------------------------ 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 Apr 25 05:03:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28567; Thu, 25 Apr 96 05:03:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28561; Thu, 25 Apr 96 05:02:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25234; Thu, 25 Apr 1996 05:00:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA22273; Thu, 25 Apr 1996 05:00:21 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA24132; Thu, 25 Apr 1996 07:41:10 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21118; Thu, 25 Apr 1996 07:41:09 -0400 Message-Id: <9604251141.AA21118@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1616) Re: bsd-api-05 questions In-Reply-To: Your message of "Wed, 24 Apr 96 10:44:40 PDT." <199604241744.KAA12884@puli.cisco.com> Date: Thu, 25 Apr 96 07:41:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Craig is correct. The current draft is broken in ways that the earlier >drafts were not. Fix the draft and remove the recent brokenness. No. Please be more specific. Craig's point has been overuled. We have at least 10 hard core API folks on this list who do not support the name previously used. You and Craig are a voice of two not enough to cause a change and so far its ascetics and not technical input. Which makes it less relevant. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Apr 25 05:05:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28579; Thu, 25 Apr 96 05:05:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28573; Thu, 25 Apr 96 05:05:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25370; Thu, 25 Apr 1996 05:02:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA22750; Thu, 25 Apr 1996 05:02:55 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA13319; Thu, 25 Apr 1996 07:45:38 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA10194; Thu, 25 Apr 1996 07:45:29 -0400 Message-Id: <9604251145.AA10194@fwasted.zk3.dec.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, paul@vix.com Subject: (IPng 1617) Re: bsd-api-05 questions In-Reply-To: Your message of "Wed, 24 Apr 96 10:59:43 PDT." <199604241759.KAA11654@puli.cisco.com> Date: Thu, 25 Apr 96 07:45:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I know. The functions have not changed only the name. So your >>functions still apply. We don't like the name. And that had > ^^^^^^^^^^^^ >>consensus. > ^^^^^^^^^ > >Nonsense. > >>I personally don't care. >Then I'm confused about why are you arguing so strongly about this. >No one else seems to be as vocal as you are on this. We had a meeting at the L.A. IETF I am just carrying the message. There were over 10 people who support this. Please don't shoot the messenger. > The discussions on the list have mostly been in favour of the >ascii2addr() and addr2ascii() names. I talked about this at some length >with Bob Gilligan at LA and afterwards and he was happy to stay with the >older names that Craig Partridge came up with. Craig's names have >sufficient implementation experience now indicating they are fine. THats strange because Bob supports this change. The implementation will not change just the name. >The argument that some others make about namespace conflicts is >bogus because the inet_*() namespace isn't reserved as a block and so isn't >any better protected against namespace conflicts. Well lets see if anyone else agrees with you. Paul Vixie???? > As to the IEEE, there is near zero probability of their standards >being no-cost since they fund standards work with the income from standards >sales. I agree this is unfortunate, but it seems very unlikely to change >anytime soon. A real RFC that describes things in sufficient detail to >build an implementation that has application portability will provide real >value. If folks actually build that interface as per the RFC, it is very >likely to be accepted by the IEEE POSIX.1 folks in the future. I agree with you. But others do not. /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 Apr 25 05:16:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28607; Thu, 25 Apr 96 05:16:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28601; Thu, 25 Apr 96 05:15:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25836; Thu, 25 Apr 1996 05:13:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA24267; Thu, 25 Apr 1996 05:13:16 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA05653; Thu, 25 Apr 1996 08:00:47 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11854; Thu, 25 Apr 1996 08:00:44 -0400 Message-Id: <9604251200.AA11854@fwasted.zk3.dec.com> To: michael@stb.info.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1618) Re: And now, a message from our detractors... In-Reply-To: Your message of "Wed, 24 Apr 96 22:35:00 PDT." Date: Thu, 25 Apr 96 08:00:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't support this at all. For the first time in the IPng process I have a social view on this issue and am completely against any type of field that supports any censorship by my government of the Internet. Absolutely not is my input. If you don't want your children to play with lighters and the internet teach them not to don't ask us to make your job easier or cause me to have to buy bic lighters that are bogus. /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 Apr 25 07:58:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28737; Thu, 25 Apr 96 07:58:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28731; Thu, 25 Apr 96 07:58:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08743; Thu, 25 Apr 1996 07:55:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA28407; Thu, 25 Apr 1996 07:55:33 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id HAA16603; Thu, 25 Apr 1996 07:51:27 -0700 (PDT) Message-Id: <199604251451.HAA16603@aland.bbn.com> To: bound@zk3.dec.com Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 1619) Re: bsd-api-05 questions In-Reply-To: Your message of Thu, 25 Apr 96 07:41:08 -0400. <9604251141.AA21118@fwasted.zk3.dec.com> Date: Thu, 25 Apr 96 07:51:26 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You and Craig are a voice of two not enough to cause a change and so far its ascetics and not technical input. Which makes it less relevant. Jim: Excuse me. The change to inet* was entirely esthetics too. The problem with inet names is that it suggests the purpose of the routines is to do inet* stuff. It isn't -- they are to do general address conversion to and from printable formats. 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 Thu Apr 25 07:59:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28750; Thu, 25 Apr 96 07:59:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28743; Thu, 25 Apr 96 07:59:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08857; Thu, 25 Apr 1996 07:56:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA28738; Thu, 25 Apr 1996 07:56:45 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1620) Re: And now, a message from our detractors... To: michael@stb.info.com Date: Thu, 25 Apr 1996 16:52:56 +0100 (BST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Michael Gersten" at Apr 24, 96 10:35:00 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It's not a question of can it be done or not. It's just one bit in the header. Its a question of if it can be done or not. To start with we don't checksum our IPv6 headers. This bit would force header checksumming. > And, on unix systems, you can check the real user id of the process that's > doing the send or write call, and set it. But that process might not be the data originator, just a daemon. Suppose the data is pasted between two windows. How about multicast frames, tunnels etc ? Alan ------------------------------------------------------------------------------ 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 Apr 25 08:51:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28822; Thu, 25 Apr 96 08:51:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28816; Thu, 25 Apr 96 08:51:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14580; Thu, 25 Apr 1996 08:48:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA13674; Thu, 25 Apr 1996 08:48:48 -0700 From: bound@zk3.dec.com Received: from wasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA02649; Thu, 25 Apr 1996 11:35:27 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA04916; Thu, 25 Apr 1996 11:35:26 -0400 Message-Id: <9604251535.AA04916@fwasted.zk3.dec.com> To: Craig Partridge Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1621) Re: bsd-api-05 questions In-Reply-To: Your message of "Thu, 25 Apr 96 07:51:26 PDT." <199604251451.HAA16603@aland.bbn.com> Date: Thu, 25 Apr 96 11:35:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > Excuse me. The change to inet* was entirely esthetics too. > The problem with inet names is that it suggests the purpose of the >routines is to do inet* stuff. It isn't -- they are to do general address >conversion to and from printable formats. Yep. Thats true. But what else is there but inet* stuff? Will others who wanted this done please add your two cents? As Bob and I did not want this change in the spec? Thank You. I am just trying to get this spec to a last call and have a good chance it will succeed. Specifically Matt Thomas, Paul Vixie, Tim Hartick, Richard Stevens, and Francis DuPont please share your thoughts on this subject? Others??? I don't believe other protocols really matter though and inet* seems to be correct from that perspective. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Apr 25 09:05:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28864; Thu, 25 Apr 96 09:05:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28858; Thu, 25 Apr 96 09:04:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16648; Thu, 25 Apr 1996 09:02:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA18352; Thu, 25 Apr 1996 09:02:13 -0700 From: Victor.DIAS-FERNANDES@DG12.cec.be X400-Received: by mta sun1.iihe.ac.be in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Thu, 25 Apr 1996 15:39:08 +0200 X400-Received: by /PRMD=CEC/ADMD=RTT/C=BE/; Relayed; Thu, 25 Apr 1996 15:39:43 +0200 Date: Thu, 25 Apr 1996 15:39:43 +0200 X400-Originator: Victor.DIAS-FERNANDES@DG12.cec.be X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=CEC/ADMD=RTT/C=BE/;WIN2362-960425133943-242C] Original-Encoded-Information-Types: undefined X400-Content-Type: P2-1984 (2) Content-Identifier: Comments to: dra Alternate-Recipient: Allowed Message-Id: To: ipng@sunroof.eng.sun.com (Non Receipt Notification Requested) Subject: (IPng 1622) Comments to: draft-ietf-ipngwg-pmtuv6-02.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Page 12 and Page 13] >6. Security considerations > > This Path MTU Discovery mechanism makes possible two denial-of- > service attacks, both based on a malicious party sending false Packet > Too Big messages to a node. > > In the first attack, the false message indicates a PMTU much smaller > than reality. This should not entirely stop data flow, since the > victim node should never set its PMTU estimate below the IPv6 minimum > link MTU. It will, however, result in suboptimal performance. To minimize this type of attack the sending node could: 1- Check if the received Packet Too Big Message (PTBm) is really a response to a packed sent by the node, by checking the data returned in the PTBm. If not ignore the PTBm and continue using the actual PMTU. 2- Check if and acknowledgment for the supposed Too Big Packet was received. If yes ignore the PTBm. If not save the actual PTMU value and begin using the new PTMU value. If an acknowledgment arrives for the packet that was sent and that had originated the PTBm (proving the PTBm was false) reset the PTMU value to the old saved value (the save PTMU value can be cleared after a specified timeout if an acknowledgment is not received) [Page 4 and Page 5] >3. Protocol overview > > This memo describes a technique to dynamically discover the PMTU of a > path. The basic idea is that a source node initially assumes that > the PMTU of a path is the (known) MTU of the first hop in the path. > If any of the packets sent on that path are too large to be forwarded > by some node along the path, that node will discard them and return > ICMPv6 Packet Too Big messages [ICMPv6]. Upon receipt of such a > message, the source node reduces its assumed PMTU for the path based > on the MTU of the constricting hop as reported in the Packet Too Big > message. > > The Path MTU Discovery process ends when the node's estimate of the > PMTU is less than or equal to the actual PMTU. Note that several > iterations of the packet-sent/Packet-Too-Big-message-received cycle > may occur before the Path MTU Discovery process ends, as there may be > links with smaller MTUs further along the path. > > Alternatively, the node may elect to end the discovery process by > ceasing to send packets larger than the IPv6 minimum link MTU. > > The PMTU of a path may change over time, due to changes in the > routing topology. Reductions of the PMTU are detected by Packet Too > Big messages. To detect increases in a path's PMTU, a node > periodically increases its assumed PMTU. This will almost always > result in packets being discarded and Packet Too Big messages being > generated, because in most cases the PMTU of the path will not have > changed. Therefore, attempts to detect increases in a path's PMTU > should be done infrequently. > .../... To avoid the (eventually large) amount of iterations of "packet-sent/Packet-Too-Big-message-received" until the correct PMTU value is discovered a special packet could be defined to probe for the correct PMTU value for a given path (like a new ICMP Type message). This packet will be sent by the source note and addressed to the destination node. The sending node will put is PMTU value in the packet data and each forwarding node will check if the PMTU value is acceptable, if yes the packet is forwarded without data modification, if not the node changes the value to it's supported PMTU value and forwards the packet. The destination node will copy the PMTU value to another field in the packet, will write it's PMTU value in the original field and send the new packet to the sending node. The same process of PMTU value checking will be done in the returned packet. At reception by the sending node this node will know the correct PMTU values in both directions. If in the middle of the connection the PMTU value changes the node will receive a PTBm from one of the forwarding nodes and will check this PTBm as described above. If the node is forced to reduce the PMTU value in use to a questionable small value (lets say 50% of the PMTU value returned by the probe PTMU packet) the node could send a new probe PMTU packet to check this value, in case the node is under attack as described in [6. above]. After receiving the response to the new probe packet the node can decide to use the value returned in the new probe packet or the value returned in the PTBm. This type of packet will allow the sending node to seek for a new (bigger) PMTU value without losing data packets that will be dropped by the forwarding nodes due to _Too Big Packet_ for the supported PMTU in the forwarding nodes. [Page 5] >3. Protocol overview > > .../... > > Path MTU Discovery supports multicast as well as unicast > destinations. In the case of a multicast destination, copies of a > packet may traverse many different paths to many different nodes. > Each path may have a different PMTU, and a single multicast packet > may result in multiple Packet Too Big messages, each reporting a > different next-hop MTU. The minimum PMTU value across the set of > paths in use determines the size of subsequent packets sent to the > multicast destination. > > .../... This implies that the _slower connection_ (smaller PMTU) will impose its _speed_ to all the members of the multicast! This makes possible the same type of attack as describe in [6. above] or worst completely make the data useless in case the data is for time sensitive application, due to _Too Small Packets_ or/and fragmentation. To avoid this situation a minimum PMTU value to use (a configurable parameter for special services) could be imposed and all PMTU value smaller than this minimum value ignored. Note: PTBm will be received from the forwarding nodes in the path to the _slower nodes_ (smaller PMTU then the minimum PMTU value) what to do? Ignore them, filter the traffic to these paths for these types of services, force these nodes to not use the multicast address(????). Victor Dias Fernandes (victor.dias-fernandes@dg12.cec.be) ------------------------------------------------------------------------------ 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 Apr 25 09:13:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28886; Thu, 25 Apr 96 09:13:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28203; Wed, 24 Apr 96 19:57:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26144; Wed, 24 Apr 1996 19:55:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA18126; Wed, 24 Apr 1996 19:48:55 -0700 Received: by gw.home.vix.com id TAA16507; Wed, 24 Apr 1996 19:48:54 -0700 (PDT) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA25335; Wed, 24 Apr 1996 19:48:53 -0700 Date: Wed, 24 Apr 1996 19:48:53 -0700 Message-Id: <9604250248.AA25335@wisdom.home.vix.com> From: Paul Vixie To: ipng@sunroof.eng.sun.com Subject: (IPng 1623) I hope we don't go back to the ascii2addr() and addr2ascii() names Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As the maintainer of the BIND resolver, I can't put names like that in. My reasons are at least those which follow: 1. The chance of colliding with a user or system function is higher without a prefix like net_ or inet_ or ipv6_ or ip6_ or inet6_ or *something*. 2. Using "2" to mean "to" is not something we ought to do in public, and and that's the nicest thing I could think to say about it. 3. "ascii" isn't what you mean; printable is. Consider i8n, or even 8859. 4. "addr" isn't what you mean; Network Address is. Consider %#x or void*. I am the progenitor of the inet_pton() and inet_ntop() names, after a lengthy debate among the folks who had the ad-hoc API meeting in Los Angeles. We decided against net_ since every similar thing in the old BSD API was inet_. We decided against ip6_, inet6_, and ipv6_ since these functions would work perfectly for other versions of the Internet protocol, like IPv4. We decided against "a" for "ascii" in favour of "p" for "presentation"; similarly we used "n" for "network". Presentation and Network are from the ISO 7-layer cake. ("p" might stand for "printable" except that this is probably an input format as well.) If you don't like the names, could you consider #define'ing them in your code to be usable with the "2" names, while leaving the IETF to be in the public position of recommending something that fits more in the spirit of what came before, as well as what else might be in an application's symbol table? Hmmm. I meant this as a flame, and it came out as a plea for peace. I must be getting old. ------------------------------------------------------------------------------ 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 Apr 25 09:18:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28910; Thu, 25 Apr 96 09:18:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28904; Thu, 25 Apr 96 09:18:19 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18594; Thu, 25 Apr 1996 09:15:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA12148; Thu, 25 Apr 1996 08:44:21 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA12585 for ; Thu, 25 Apr 1996 08:44:13 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Apr 1996 08:44:40 -0700 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1624) Re: And now, a message from our detractors... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Re: Government trying to put an adult/minor flag in the IPv6 header: > This is, IMHO, a stupid idea. I would not support it. I would also argue that the government (in this case the US Government) does not have any jurisdiction here. 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 Apr 25 09:22:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28944; Thu, 25 Apr 96 09:22:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28780; Thu, 25 Apr 96 08:13:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10468; Thu, 25 Apr 1996 08:10:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA02214; Thu, 25 Apr 1996 08:08:12 -0700 Received: by gw.home.vix.com id IAA29527; Thu, 25 Apr 1996 08:07:44 -0700 (PDT) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA00899; Thu, 25 Apr 1996 08:07:44 -0700 Message-Id: <9604251507.AA00899@wisdom.home.vix.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1625) Re: bsd-api-05 questions In-Reply-To: Your message of "Thu, 25 Apr 1996 07:45:29 EDT." <9604251145.AA10194@fwasted.zk3.dec.com> Date: Thu, 25 Apr 1996 08:07:44 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >The argument that some others make about namespace conflicts is > >bogus because the inet_*() namespace isn't reserved as a block and so isn't > >any better protected against namespace conflicts. > > Well lets see if anyone else agrees with you. Paul Vixie???? I am pretty much the semaphore for that block, any more, for most vendors. ------------------------------------------------------------------------------ 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 Apr 25 09:26:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28985; Thu, 25 Apr 96 09:26:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28979; Thu, 25 Apr 96 09:25:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19741; Thu, 25 Apr 1996 09:23:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA26082; Thu, 25 Apr 1996 09:23:22 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id JAA16863; Thu, 25 Apr 1996 09:19:11 -0700 (PDT) Message-Id: <199604251619.JAA16863@aland.bbn.com> To: bound@zk3.dec.com Cc: Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1626) Re: bsd-api-05 questions In-Reply-To: Your message of Thu, 25 Apr 96 11:35:25 -0400. <9604251535.AA04916@fwasted.zk3.dec.com> Date: Thu, 25 Apr 96 09:19:10 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > Excuse me. The change to inet* was entirely esthetics too. > The problem with inet names is that it suggests the purpose of the >routines is to do inet* stuff. It isn't -- they are to do general address >conversion to and from printable formats. Yep. Thats true. But what else is there but inet* stuff? Ethernet addresses (last I looked, struct arpreq used a sockaddr to pass around the Ethernet address -- so there are Ethernet sockaddrs running around). IPv4 (one of the goals of the ascii2addr() routines was to say to folks -- use this from now on and your application will handle IPv6 when it comes). ATM addresses. (There are about 19 other AF_ types, though most aren't used). The basic idea is, given an AF, you can convert from ascii to a sockaddr or vice versa. 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 Thu Apr 25 09:47:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29103; Thu, 25 Apr 96 09:47:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29097; Thu, 25 Apr 96 09:47:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23313; Thu, 25 Apr 1996 09:44:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA03167; Thu, 25 Apr 1996 09:44:33 -0700 Received: from localhost.wrs.com by loire.wrs.com with SMTP id AA19915 (5.65c/IDA-1.4.4 for ); Thu, 25 Apr 1996 09:44:49 -0700 Message-Id: <199604251644.AA19915@loire.wrs.com> To: bound@zk3.dec.com Cc: Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1627) Re: bsd-api-05 questions Organization: Wind River Systems; Alameda, CA;USA Reply-To: gnn@wrs.com In-Reply-To: bound@zk3.dec.com's message of Thu, 25 Apr 96 11:35:25 EDT. Date: Thu, 25 Apr 96 09:44:48 -0700 From: George Neville-Neil Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com writes: >Will others who wanted this done please add your two cents? As Bob and >I did not want this change in the spec? Thank You. I am just trying to >get this spec to a last call and have a good chance it will succeed. > >Specifically Matt Thomas, Paul Vixie, Tim Hartick, Richard Stevens, and >Francis DuPont please share your thoughts on this subject? Others??? > >I don't believe other protocols really matter though and inet* seems to >be correct from that perspective. I have a comment, even though I'm not in the above list of intended commenters. Having looked at the draft I see that the inet_* calls all have an address family (af) parameter. Since the Address Family is specified in the call I think that the call should not have the word inet (or any other address family type name) in it. Since one would believe that the purpose of the af parameter is to allow for a generic interface, the name should be generic. Just my opinion. Later, 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 Thu Apr 25 11:28:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29263; Thu, 25 Apr 96 11:28:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29257; Thu, 25 Apr 96 11:27:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12540; Thu, 25 Apr 1996 11:25:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA16130; Thu, 25 Apr 1996 11:25:24 -0700 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 25 Apr 1996 14:22:45 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 25 Apr 1996 14:21:58 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 25 Apr 1996 14:21:00 -0400 Date: Thu, 25 Apr 1996 14:21:00 -0400 X400-Originator: /dd.id=1663884/g=vivek/i=v/s=kapil/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.398:25.03.96.18.21.58] X400-Content-Type: P2-1984 (2) Content-Identifier: re:(IPng 1624... From: "vivek (v.) kapil" Message-Id: <"15463 Thu Apr 25 14:22:10 1996"@bnr.ca> To: ipng@sunroof.eng.sun.com Subject: (IPng 1628) re: Adult/minor flag in the IPv6 header(was And now,... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message "(IPng 1624) Re: And now, a message from our detractors...", hinden@Ipsilon.com writes: >> >>Re: Government trying to put an adult/minor flag in the IPv6 header: >> > >This is, IMHO, a stupid idea. I would not support it. > >I would also argue that the government (in this case the US Government) >does not have any jurisdiction here. Why do you think it is a stupid idea? IMHO, I personally think there should be a way to identify who is on the Internet. The kind of material that is floating on the Net is offcourse not for kids' poor eyes. I also think there should be a way to mark the contents for its level of obscenity so that those contents can be barred to appear in front of those who do not wish to see them. Offcourse, whether the adult/minor flag be set within IPv6 or not is completely different issue. Folks have to agree first whether adult/minor flag should be legalized or not. Regards, Vivek Kapil vkapil@nortel.ca > >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 Apr 25 11:59:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29383; Thu, 25 Apr 96 11:59:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29376; Thu, 25 Apr 96 11:59:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17316; Thu, 25 Apr 1996 11:57:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA26563; Thu, 25 Apr 1996 11:56:59 -0700 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.12/8.6.11) with ESMTP id OAA10598; Thu, 25 Apr 1996 14:56:05 -0400 Message-Id: <199604251856.OAA10598@thumper.bellcore.com> To: "vivek (v.) kapil" Cc: ipng@sunroof.eng.sun.com, gja@thumper.bellcore.com Subject: (IPng 1629) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Your message of Thu, 25 Apr 1996 14:21:00 -0400. <"15463 Thu Apr 25 14:22:10 1996"@bnr.ca> Date: Thu, 25 Apr 1996 14:55:57 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>Re: Government trying to put an adult/minor flag in the IPv6 header: >>>> >>> >>>This is, IMHO, a stupid idea. I would not support it. >>> >>>I would also argue that the government (in this case the US Government) >>>does not have any jurisdiction here. >> >>Why do you think it is a stupid idea? IMHO, I personally think >>there should be a way to identify who is on the Internet. Thank you, Vivek, for carefully hijacking the thread with your reply. Whether a flag in IPv6 headers is stupid is rather orthogonal to whether identification should be possible on 'the Internet'. I recognise that some people find it easier to argue the generalities rather than the technical possibilities, but realize this mailing list is for the technical specs, not social engineering. gja ------------------------------------------------------------------------------ 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 Apr 25 12:09:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29405; Thu, 25 Apr 96 12:09:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29399; Thu, 25 Apr 96 12:09:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19042; Thu, 25 Apr 1996 12:07:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA29881; Thu, 25 Apr 1996 12:07:12 -0700 Received: from localhost.wrs.com by loire.wrs.com with SMTP id AA20664 (5.65c/IDA-1.4.4 for ); Thu, 25 Apr 1996 12:09:10 -0700 Message-Id: <199604251909.AA20664@loire.wrs.com> To: "vivek (v.) kapil" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1630) Re: Adult/minor flag in the IPv6 header(was And now,... Organization: Wind River Systems; Alameda, CA;USA Reply-To: gnn@wrs.com In-Reply-To: "vivek (v.) kapil"'s message of Thu, 25 Apr 96 14:21:00 EDT. Date: Thu, 25 Apr 96 12:09:09 -0700 From: George Neville-Neil Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A general note. I've been having a hard time deciding whether to reply to these sorts of mail, or not. But perhaps if I don't speak up now maybe I'll regret it. "vivek (v.) kapil" writes: > >Why do you think it is a stupid idea? IMHO, I personally think >there should be a way to identify who is on the Internet. The kind of >material that is floating on the Net is offcourse not for kids' >poor eyes. > It is stupid, or ridiculous IMHO for the following reasons: 1) It is a technical rabbit hole from which there is no return. Right now it's a bit, maybe someday it will be a whole set of options. Where do we stop? 2) The age of an adult differs from country to country, interpretation is not binary in this case be dependant on where the packet originated, this is a rather difficult problem since address allocation is not a country by country thing, but is relegated to ISPs. 3) There is little or no authentication in the current internet on who is what. I.e. "On the Internet no one knows you're a dog." There are many other reasons that I could list. Please, let's not make protocol design suffer from the same problems as governments, it's already tough enough to get a consensus. Later, 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 Thu Apr 25 12:22:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29421; Thu, 25 Apr 96 12:22:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29415; Thu, 25 Apr 96 12:22:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20677; Thu, 25 Apr 1996 12:19:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA03548; Thu, 25 Apr 1996 12:19:33 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id PAA27928; Thu, 25 Apr 1996 15:18:59 -0400 (EDT) Message-Id: <199604251918.PAA27928@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: "vivek (v.) kapil" , hinden@ipsilon.com Cc: ipng@sunroof.eng.sun.com, ietf@cnri.reston.va.us Subject: (IPng 1631) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Your message of "Thu, 25 Apr 1996 14:21:00 EDT." <"15463 Thu Apr 25 14:22:10 1996"@bnr.ca> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 25 Apr 1996 15:18:49 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "vivek (v.) kapil" writes: > hinden@Ipsilon.com writes: > >>Re: Government trying to put an adult/minor flag in the IPv6 header: > > > >This is, IMHO, a stupid idea. I would not support it. > >I would also argue that the government (in this case the US Government) > >does not have any jurisdiction here. > > Why do you think it is a stupid idea? IMHO, I personally think > there should be a way to identify who is on the Internet. The kind of > material that is floating on the Net is offcourse not for kids' > poor eyes. > > I also think there should be a way to mark the contents for its > level of obscenity so that those contents can be barred to appear > in front of those who do not wish to see them. Besides, having an Adult/Minor flag makes it much easier for technically astute pedophiles to find targets, and I think we should help them as much as we can, since there is so much discrimination against pedophiles that giving them a leg up now and then is probably required by some anti-discrimination law out there. Also, I think we should have a whole raft of new flags. I would propose the following tags: Subversive/Not Subversive according to The Government of Iran The Government of Saudi Arabia The Government of China The Government of Singapore The Government of Libya The Government of Kenya The Government of the U.S. Offensive/Not Offensive to All Christians Catholics Calvinists Lutherans Baptists All Muslims Shiite Muslims Sunni Muslims Hindus Sikhs Jews Nazis White Supremicists Black Supremicists Colorblind People People with one arm (left) People with one arm (right) Gays Homophobes Lesbian Separatists IETF members Contains/Does not contain data advocating potentially offensive ideas: Individualist ideas Ideas advocated by the Democratic Party Ideas advocated by the Republican Party Ideas advocated by the Communist Party Ideas advocated by cattle mutilators Ideas advocated by Hillary Clinton Ideas advocated by Ayn Rand Ideas advocating human rights Any ideas that require thinking (offensive to stupid people) Packet is being transmitted by Someone under the age of 18 Someone under the age of 12 A Jew A Hindu A person who is known to advocate ideas considered subversive by the government of Burkina Faso Etc. Etc. I suggest, before we deploy IPv6 too far and cannot make major technical changes, that we have to put in a mandatory end to end option, initially with space 256 bits (but extensible via a frequency coding mechanism), to be called the "naughty bits", to indicate the presence of any such offensive material in the packet. The IANA will assign these bits to any group or individual who can articulate a criterion by which he might be offended. All routers MUST drop any and all packets not containing the "naughty bits". > Folks have to agree first whether adult/minor flag should be > legalized or not. Legalized! Pshaw! I advocate the immediate establishment of an international convention requiring the death penalty for any person or piece of artificially intelligent software transmitting a packet without all (and I mean ALL!) defined "naughty bits" asserted. This will make it easy for people to be protected as you advocate: > I also think there should be a way to mark the contents for its > level of obscenity so that those contents can be barred to appear > in front of those who do not wish to see them. The advantage of my generalization of your scheme, however, is that it will permit the Government of Iran to permit data containing, say, suitably head-to-toe covered pictures of women to be transmitted to the country, but at the same time allow much less liberal governments to eliminate any such representational artwork, which, as you know, goes against the will of Allah, and also permit the pedonecrobestiophiles on the net to only allow packets containing pictures of young dead animals being buggered to pass through their firewall. The system in question is both necessary to permit the worldwide automated censorship regime we are all working hard to achieve and is technically feasible. I advocate the immediate formation of a working group to rapidly create a standard before its too late and more Iranian children are traumatized for life by seeing pictures of women without veils. Perry PS apologies to T.C. May for open theft of many of his ideas on this topic. ------------------------------------------------------------------------------ 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 Apr 25 12:53:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29517; Thu, 25 Apr 96 12:53:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29511; Thu, 25 Apr 96 12:53:11 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24915; Thu, 25 Apr 1996 12:50:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA12336; Thu, 25 Apr 1996 12:50:38 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id PAA09910; Thu, 25 Apr 1996 15:52:20 -0400 Received: from karma.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA17236; Thu, 25 Apr 96 15:50:34 EDT Date: Thu, 25 Apr 96 15:50:34 EDT Message-Id: <9604251950.AA17236@pobox.BayNetworks.com> Received: by karma.engeast (4.1/SMI-4.1) id AA03034; Thu, 25 Apr 96 15:49:41 EDT From: Mike Davis To: perry@piermont.com Cc: ipng@sunroof.eng.sun.com, ietf@cnri.reston.va.us Subject: (IPng 1632) Re: Adult/minor flag in the IPv6 header(was And now,... Reply-To: mdavis@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [proposal deleted] Perry, You are obviously forgetting that we are all individuals, and should not have to have our tastes lumped into large groups. Therefore, the IPv6 header should include a field with a bit for each human alive, now or in the projected lifetime of the protocol, which will indicate whether the given packet will offend that person. --mad ------------------------------------------------------------------------------ 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 Apr 25 12:55:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29538; Thu, 25 Apr 96 12:55:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29532; Thu, 25 Apr 96 12:55:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25257; Thu, 25 Apr 1996 12:52:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA12914; Thu, 25 Apr 1996 12:52:31 -0700 Received: (from pld@localhost) by cantor.math.luc.edu (8.6.12/8.6.12) id OAA19964 for ipng@sunroof.eng.sun.com; Thu, 25 Apr 1996 14:53:01 -0500 Date: Thu, 25 Apr 1996 14:53:01 -0500 From: Peter Dordal Message-Id: <199604251953.OAA19964@cantor.math.luc.edu> Subject: (IPng 1633) Re: And now, a message from our detractors... Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > pferguso@lint.cisco.com wrote > I thought some of you might be interested to know that the US DoJ > is attempting to mandate that IPv6 protocol(s) contain a method to > identify 'adult' users v. 'minor' users in an effort to satisfy the > CDA (Communications Decency Act). This makes about as much sense as having digitized-voice telephony packets carry age bits. It's the wrong protocol level. I am assuming that this issue does not yet need to be taken seriously, but here goes anyway. Strictly speaking, the issue isn't whether the bits can be included in some Destination Options field, but whether this can be done *securely*. Doing this at the source endpoint can never be entirely secure. Theoretically, age-id could be done securely by SLIP-type connection providers by having their routers add an age-id options header to every outbound packet, unless the user provides age-authentication data at the time of initial connection. Service providers for, say, K-12 schools could do this too. I don't think such a scheme is quite realistic; sites with internal routers (such as universities) would face all sorts of muddy issues. But I don't think this level of security is what most parents (if not the US government) are looking for, though. In which case a strong argument can be made that age identification should be attached (insecurely) to the application(/presentation/session) level. Browsers would be configurable to add under-18 flags *within the http protocol*. What would prevent a 16-year-old from using another browser? Well, service providers might *encourage* the use of local TCP/IP layers that accepted connections only from applications on a designated list. This list would presumably include only "safe" browsers. Eminently defeatable, but arguably Good Enough. At least such a model should forestall criticism that the IETF simply doesn't care about this. It also leaves the details up to the Configuring Adult, not to the government. ------------------------------------------------------------------------------ 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 Apr 25 13:15:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29579; Thu, 25 Apr 96 13:15:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29573; Thu, 25 Apr 96 13:15:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28380; Thu, 25 Apr 1996 13:12:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA18834; Thu, 25 Apr 1996 13:12:31 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id WAA23743; Thu, 25 Apr 1996 22:12:22 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id WAA13697; Thu, 25 Apr 1996 22:12:21 +0200 Message-Id: <199604252012.WAA13697@givry.inria.fr> From: Francis Dupont To: bound@zk3.dec.com Cc: Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1634) Re: bsd-api-05 questions In-Reply-To: Your message of Thu, 25 Apr 1996 11:35:25 EDT. <9604251535.AA04916@fwasted.zk3.dec.com> Date: Thu, 25 Apr 1996 22:12:08 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Specifically Matt Thomas, Paul Vixie, Tim Hartick, Richard Stevens, and Francis DuPont please share your thoughts on this subject? Others??? => Dupont please... I fully share the concern of my colleague and friend Alain Durand. getaddrinfo specs *must* be in the internet draft and I don't understand the move from ascii2addr/addr2ascii ugly names to even more ugly inet_pton/inet_ntop names... Another point, if we want to go to Posix style we must fix every details in order to avoid late changes, for instance reserved prefix names, etc... Francis.Dupont@inria.fr PS: What is a camel ? It is an horse designed by a committee! ------------------------------------------------------------------------------ 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 Apr 25 13:23:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29610; Thu, 25 Apr 96 13:23:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29585; Thu, 25 Apr 96 13:18:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28855; Thu, 25 Apr 1996 13:15:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA19919; Thu, 25 Apr 1996 13:15:55 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA09270; Thu, 25 Apr 1996 13:15:17 -0700 Date: Thu, 25 Apr 1996 13:15:17 -0700 (PDT) From: Karl Auerbach To: Mike Davis Cc: perry@piermont.com, ipng@sunroof.eng.sun.com, ietf@cnri.reston.va.us Subject: (IPng 1635) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: <9604251950.AA17236@pobox.BayNetworks.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You are obviously forgetting that we are all individuals, and should > not have to have our tastes lumped into large groups. Therefore, the > IPv6 header should include a field with a bit for each human alive, > now or in the projected lifetime of the protocol, which will indicate > whether the given packet will offend that person. What about our schitzophrenic population? They might need blocks of bits. To help prevent bit explosion, we could retain CIDR. (Hmmm, might this change things from "one person, one vote" to "each personality, one vote"? In that case I know individuals who could dominate whole towns.) --karl-- ------------------------------------------------------------------------------ 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 Apr 25 13:39:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29647; Thu, 25 Apr 96 13:39:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29641; Thu, 25 Apr 96 13:39:22 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02251; Thu, 25 Apr 1996 13:36:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA26350; Thu, 25 Apr 1996 13:36:48 -0700 Received: from munin.fnal.gov ("port 3274"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I3YPCI70XY001BG7@FNAL.FNAL.GOV>; Thu, 25 Apr 1996 15:36:41 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id PAA05409; Thu, 25 Apr 1996 15:36:05 -0500 (CDT) Date: Thu, 25 Apr 1996 15:36:04 -0500 From: Matt Crawford Subject: (IPng 1636) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: "25 Apr 1996 15:50:34 EDT." <"9604251950.AA17236"@pobox.BayNetworks.com> To: mdavis@baynetworks.com Cc: perry@piermont.com, ipng@sunroof.eng.sun.com, ietf@CNRI.RESTON.VA.US Message-Id: <199604252036.PAA05409@munin.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{ Therefore, the IPv6 header should include a field with a bit for > each human alive, now or in the projected lifetime of the protocol, Huh? I thought that was our addressing architecture!! :-) ------------------------------------------------------------------------------ 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 Apr 25 13:44:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29679; Thu, 25 Apr 96 13:44:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29661; Thu, 25 Apr 96 13:44:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03100; Thu, 25 Apr 1996 13:41:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA28020; Thu, 25 Apr 1996 13:41:44 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id QAA19328; Thu, 25 Apr 1996 16:43:36 -0400 (EDT) Date: Thu, 25 Apr 1996 16:43:36 -0400 (EDT) From: Scott Bradner Message-Id: <199604252043.QAA19328@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com, vkapil@bnr.ca Subject: (IPng 1637) Re: Adult/minor flag in the IPv6 header(was And now,... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why do you think it is a stupid idea? IMHO, I personally think > there should be a way to identify who is on the Internet. It would seem that you assume that whoever sets the "bit" will speak the truth - seems to me to be a rather big assumption Do we then add a religion field so that articles on space exploration do not get sent to people in the flat earth society, or a refoemed smoker bit so that pictures showing people smoking do not get a chance to offend, or a conservative bit to block Ted Kennedy? once you start down this path where do you stop. I'd say refuse the path. I think it is fine if a sender wants to flag things as potentially bothersum (with some granularity in the bother scales) so that a receiver (or receiver's parents) have the ability to control but the idea that a potential receiver should tell the world their reject filter seems to be a bit much - there is, among other things, a bit of a scaling issue. Scott ------------------------------------------------------------------------------ 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 Apr 25 14:51:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29818; Thu, 25 Apr 96 14:51:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29735; Thu, 25 Apr 96 14:10:14 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08166; Thu, 25 Apr 1996 14:07:42 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA06818; Thu, 25 Apr 1996 14:07:40 -0700 Received: (from bruen@localhost) by wizard.mit.edu (8.6.11/8.6.9) id RAA03447; Thu, 25 Apr 1996 17:06:49 -0400 Date: Thu, 25 Apr 1996 17:06:48 -0400 (EDT) From: bob bruen Reply-To: bruen@mit.edu To: Karl Auerbach Cc: Mike Davis , perry@piermont.com, ipng@sunroof.eng.sun.com, ietf@CNRI.Reston.VA.US Subject: (IPng 1638) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 25 Apr 1996, Karl Auerbach wrote: > What about our schitzophrenic population? They might need blocks > of bits. To help prevent bit explosion, we could retain CIDR. > (Hmmm, might this change things from "one person, one vote" to "each > personality, one vote"? In that case I know individuals who could dominate > whole towns.) Just to keep things on track, technically speaking schizophrenia is a failure of reality testing, multiple personalities are symptoms of hysteria. However, I not sure if that actually changes the discussion... ------------------------------------------------------------------------- Bob Bruen MIT Lab for Nuclear Science voice: 617.253.6065 77 Massachusetts Ave. fax: 617.258.6591 Cambridge MA 02139 http://www-lns.mit.edu/~bruen/index.html ---------------------------------------------------------------------------- ------------------------------------------------------------------------------ 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 Apr 25 14:52:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29830; Thu, 25 Apr 96 14:52:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29766; Thu, 25 Apr 96 14:26:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11735; Thu, 25 Apr 1996 14:23:59 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA11893; Thu, 25 Apr 1996 14:23:58 -0700 Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id RAA25748; Thu, 25 Apr 1996 17:22:01 -0400 Message-Id: <199604252122.RAA25748@black-ice.cc.vt.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: bruen@mit.edu Cc: Karl Auerbach , Mike Davis , perry@piermont.com, ipng@sunroof.eng.sun.com, ietf@CNRI.Reston.VA.US Subject: (IPng 1639) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Your message of "Thu, 25 Apr 1996 17:06:48 EDT." From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="===_-1_Thu_Apr_25_17:21:52_EDT_1996"; micalc=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 25 Apr 1996 17:21:54 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --===_-1_Thu_Apr_25_17:21:52_EDT_1996 Content-Type: text/plain; charset=us-ascii On Thu, 25 Apr 1996 17:06:48 EDT, bob bruen said: > Just to keep things on track, technically speaking schizophrenia is a > failure of reality testing, multiple personalities are symptoms of > hysteria. However, I not sure if that actually changes the discussion... RFC821 defines "temporary" and "permanent" errors for e-mail. We may need to investigate what the applicable equivalent here would be. What is the proper way to signal that a connection would have been acceptable now, except that you've only had 2 cups of coffee, have received 13 SNMP Alerts in the last 10 minutes, and left your Valium at home? /Valdis "Why did I leave myself a 'while you were out' note?" Kletnieks --===_-1_Thu_Apr_25_17:21:52_EDT_1996 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.1 iQCVAwUBMX/s79QBOOoptg9JAQFhZAP/fA3aIDw86ga6A+qr+KbFQVT74sjhwsYv 774R5jrhQANdXTNhJYOsyTsUGFSNmItNnRbDv/4mbePsImz5hp06Cww1A6GlcmdE jvYq3ZepduCK3UgRp6IYU7g/IqDXHoKbehTjrhzoCUZb5lJ/+R1DPjRJ78GkujVw npI53GBKSQA= =phrd -----END PGP MESSAGE----- --===_-1_Thu_Apr_25_17:21:52_EDT_1996-- ------------------------------------------------------------------------------ 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 Apr 25 14:53:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29842; Thu, 25 Apr 96 14:53:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29798; Thu, 25 Apr 96 14:48:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16615; Thu, 25 Apr 1996 14:46:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA18650; Thu, 25 Apr 1996 14:45:52 -0700 Received: from [163.185.164.95] by ohnasn07.houston.omnes.net (post.office MTA v1.9.3 ID# 0-12122) with SMTP id AAB6919; Thu, 25 Apr 1996 19:45:14 +0000 X-Sender: lodge@sndsn1.sedalia.sinet.slb.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Apr 1996 16:45:14 -0500 To: Karl Auerbach , Mike Davis From: lodge@houston.omnes.net (Mathew Lodge) Subject: (IPng 1640) Re: Adult/minor flag in the IPv6 header Cc: perry@piermont.com, ipng@sunroof.eng.sun.com, ietf@CNRI.Reston.VA.US Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 13:15 4/25/1996, Karl Auerbach wrote: >> You are obviously forgetting that we are all individuals, and should >> not have to have our tastes lumped into large groups. Therefore, the >> IPv6 header should include a field with a bit for each human alive, >> now or in the projected lifetime of the protocol, which will indicate >> whether the given packet will offend that person. > >What about our schitzophrenic population? They might need blocks >of bits. To help prevent bit explosion, we could retain CIDR. No, not CIDR -- there's lots of code available for implementing arbitrarily large sparse arrays. I say sparse arrays because I suspect that many packets will only be subversive to certain groups. But maybe I'm wrong -- perhaps we should run a simulation network with suitable representatives of each possibly offended group before considering the encoding strategy for the IPv6 flag field... Cheers, Mathew ------------------------------------------------------------------------------ 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 Apr 25 15:18:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29899; Thu, 25 Apr 96 15:18:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29893; Thu, 25 Apr 96 15:17:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22728; Thu, 25 Apr 1996 15:15:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA27404; Thu, 25 Apr 1996 15:15:06 -0700 Received: from drake.cnu.edu (drake.cnu.edu [137.155.12.210]) by morgan.cnu.edu (8.7.3/8.6.9) with ESMTP id SAA29398 for ; Thu, 25 Apr 1996 18:15:05 -0400 (EDT) Received: from localhost (patrick@localhost) by drake.cnu.edu (SMI-8.6/8.6.9) with SMTP id SAA24260 for ; Thu, 25 Apr 1996 18:15:04 -0400 X-Authentication-Warning: drake.cnu.edu: patrick owned process doing -bs Date: Thu, 25 Apr 1996 18:15:04 -0400 (EDT) From: "J. Patrick Narkinsky" To: ipng@sunroof.eng.sun.com Subject: (IPng 1641) Re: And now, a message from our detractors... In-Reply-To: <9604251200.AA11854@fwasted.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 My opinion is pretty straight forward -- putting a "Majority Field" in an IPV6 header makes no sense. None. Philosophical/Freedom/Religious questions aside, it should go in the TCP header or even in HTTP or something. This is a layer 7 issue, not layer 3. Patrick ------------------------------------------------------------ J. Patrick Narkinsky | | Computers are not intelligent. Sr. Systems Engineer | CNU Computer Center | They only think they are. (804)594-7180 | ------------------------------------------------------------ ------------------------------------------------------------------------------ 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 Apr 25 15:23:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29914; Thu, 25 Apr 96 15:23:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29908; Thu, 25 Apr 96 15:23:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23779; Thu, 25 Apr 1996 15:20:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA28994; Thu, 25 Apr 1996 15:20:35 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id SAA28359; Thu, 25 Apr 1996 18:20:07 -0400 (EDT) Message-Id: <199604252220.SAA28359@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Ari Ollikainen Cc: ietf@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 1642) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Your message of "Thu, 25 Apr 1996 14:45:05 PDT." <199604252142.AA09422@gatekeeper.sprintlabs.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 25 Apr 1996 18:20:02 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ari Ollikainen writes: > Apparently, France "...proposed on Wednesday that countries sign a > global convention setting out principles for regulating the Internet > and on-line services in areas such as data privacy and protection of > consumers and minors..." (Reuters) > > "...the convention should develop a "code of good conduct" > and a system for determining which country's rules apply to the new > services. > > ...France would raise the question at a meeting of the Group of Seven > rich countries in June in Lyon..." So, the question is, are we going to let a bunch of computer illiterates who can't even manage to do the jobs they were supposedly elected to do tell us what to do? 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 Thu Apr 25 15:27:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29930; Thu, 25 Apr 96 15:27:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29855; Thu, 25 Apr 96 14:56:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18012; Thu, 25 Apr 1996 14:53:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA20970; Thu, 25 Apr 1996 14:53:53 -0700 Received: from [199.2.53.28] by gatekeeper.sprintlabs.com with SMTP id AA09422 (5.67b/IDA-1.5 for ); Thu, 25 Apr 1996 14:42:46 -0700 Message-Id: <199604252142.AA09422@gatekeeper.sprintlabs.com> X-Sender: aollikai@gatekeeper Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Apr 1996 14:45:05 -0700 To: ietf@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com From: ari@sprintlabs.com (Ari Ollikainen) Subject: (IPng 1643) Re: Adult/minor flag in the IPv6 header(was And now,... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 17:06 4/25/96 -0400, bob bruen wrote: > > Just to keep things on track, technically speaking schizophrenia is a > failure of reality testing, multiple personalities are symptoms of > hysteria. However, I not sure if that actually changes the discussion... > No, it doesn't, but perhaps the intrusion of the real world will: Apparently, France "...proposed on Wednesday that countries sign a global convention setting out principles for regulating the Internet and on-line services in areas such as data privacy and protection of consumers and minors..." (Reuters) "...the convention should develop a "code of good conduct" and a system for determining which country's rules apply to the new services. ...France would raise the question at a meeting of the Group of Seven rich countries in June in Lyon..." _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 _/ _/ _/ _/ _/ Voice: 415 375 4265 FAX: 415 375 4490 ~RECOM Technologies 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 Thu Apr 25 15:40:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29994; Thu, 25 Apr 96 15:40:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29985; Thu, 25 Apr 96 15:40:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27564; Thu, 25 Apr 1996 15:37:52 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA05250; Thu, 25 Apr 1996 15:37:52 -0700 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/4.03) id AA07957; Thu, 25 Apr 1996 18:32:59 -0400 Date: Thu, 25 Apr 1996 18:32:59 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9604252232.AA07957@oxygen.house.gov> To: ipng@sunroof.eng.sun.com, sob@newdev.harvard.edu, vkapil@bnr.ca Subject: (IPng 1644) Re: Adult/minor flag in the IPv6 header(was And now,... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | From owner-ipng@sunroof.Eng.Sun.COM Thu Apr 25 16:49:01 1996 | From: Scott Bradner | Message-Id: <199604252043.QAA19328@newdev.harvard.edu> | Subject: (IPng 1637) Re: Adult/minor flag in the IPv6 header(was And now,... | | > Why do you think it is a stupid idea? IMHO, I personally think | > there should be a way to identify who is on the Internet. | | It would seem that you assume that whoever sets the "bit" | will speak the truth - seems to me to be a rather big assumption | [remarkably rational response, considering the basic problem, deleted] | idea that a potential receiver should tell the world their reject | filter seems to be a bit much - there is, among other things, a bit of a | scaling issue. To say nothing about putting a content tag at a layer way too low in the stack. I know that dynamic addressing is built into IPv6, but changing address-level information based on the age of the user? (I hope I understand just where they wanted to put this bit.) Have you all considered the possibility that you offended the network gods with all those April Fool RFCs? I really thought this was another one. Political ties like Communications Decency seem to be an appropriate hell for those with the tradition of the Internet. For your penance, you must explain technical issues to your Representative in Congress. John Schnizlein Planning Manager House Information Resources U. S. House of Representatives (I do technology, not policy.) ------------------------------------------------------------------------------ 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 Apr 25 16:34:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00381; Thu, 25 Apr 96 16:34:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00375; Thu, 25 Apr 96 16:34:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07271; Thu, 25 Apr 1996 16:31:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA23604; Thu, 25 Apr 1996 16:31:48 -0700 Received: from infobro.cais.com (infobro.cais.com [205.161.100.60]) by cais.cais.com (8.6.10/8.6.5) with SMTP id TAA01247; Thu, 25 Apr 1996 19:31:45 -0400 Received: by infobro.cais.com with Microsoft Mail id <01BB32DE.2B7C1020@infobro.cais.com>; Thu, 25 Apr 1996 19:34:07 -0400 Message-Id: <01BB32DE.2B7C1020@infobro.cais.com> From: "Eric D. Williams" To: "ipng@sunroof.Eng.Sun.COM" , "'J. Patrick Narkinsky'" Subject: (IPng 1645) Re: And now, a message from our detractors... Date: Thu, 25 Apr 1996 19:33:54 -0400 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 Absolutely, the IPv6 header is not the place. TCP (layer 4) is still = too low. However: IPv6 list is not even the place for this discussion the = application protocols (at servers and clients) are the entities that = must utilize this information, it is not a routing decision but a = presentation (6) or application (7) decision. The HTTP Browser vendors are already addressing this issue with the = introduction of the Kid Proof URL scanners eg. "Honey, don't let little = Johnny see the Buns 'R' Us page block out http://www.bunrus.com." Let the application guys deal with this stuff and let us get on with = letting as many people who want to receive these packets receive the = packets, as quickly as possible. Hotep, Eric PS if the kid can type, what's the big deal ?-) ---------- From: J. Patrick Narkinsky[SMTP:patrick@cnu.edu] Sent: Thursday, April 25, 1996 2:15 PM To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 1641) Re: And now, a message from our detractors...=20 My opinion is pretty straight forward -- putting a "Majority Field" in = an IPV6 header makes no sense. None. Philosophical/Freedom/Religious questions aside, it should go in the TCP header or even in HTTP or something.=20 This is a layer 7 issue, not layer 3. Patrick ------------------------------------------------------------ J. Patrick Narkinsky | | Computers are not intelligent. Sr. Systems Engineer | CNU Computer Center | They only think they are. (804)594-7180 | =20 ------------------------------------------------------------ -------------------------------------------------------------------------= ----- 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 Thu Apr 25 17:04:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00464; Thu, 25 Apr 96 17:04:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00332; Thu, 25 Apr 96 16:15:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03970; Thu, 25 Apr 1996 16:12:44 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA17643; Thu, 25 Apr 1996 16:12:06 -0700 Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25715 (mail destined for ipng@sunroof.eng.sun.com); Thu, 25 Apr 96 19:11:09 -0400 Received: by expresso.bunyip.com (NX5.67c/NX3.0S) id AA13000; Thu, 25 Apr 96 19:11:07 -0400 Message-Id: <9604252311.AA13000@expresso.bunyip.com> From: Peter Deutsch Date: Thu, 25 Apr 1996 19:11:05 -0400 In-Reply-To: bob bruen's message as of Apr 25, 17:06 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: bruen@mit.edu, Karl Auerbach Subject: (IPng 1646) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: Mike Davis , perry@piermont.com, ipng@sunroof.eng.sun.com, ietf@CNRI.Reston.VA.US Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [ You wrote: ] } On Thu, 25 Apr 1996, Karl Auerbach wrote: } > What about our schitzophrenic population? They might need blocks } > of bits. To help prevent bit explosion, we could retain CIDR. } > (Hmmm, might this change things from "one person, one vote" to "each } > personality, one vote"? In that case I know individuals who could dominate } > whole towns.) } } Just to keep things on track, technically speaking schizophrenia is a } failure of reality testing, multiple personalities are symptoms of } hysteria. However, I not sure if that actually changes the discussion... Well, for this list this is certainly an important distinction. If we're trying to deal with issues in failure testing, it would imply that any standards activity should go into the Operations Area. On the other hand, hysteria is obviously not a failure mode, but more of a question of controlling behaviour and would thus probably fall into the Security Area. Of course, identifying multiple personalities in the Internet environment is simply a Directory Service problem and obviously falls into the Applications Area, with the usual assistance from User Services (and I'd like to modestly submit that WHOIS++ beats X.500/LDAP in code shootouts where the personalities are split across multiple entities, but we can reserve such discussions for the new lists this is sure to spawn...) Of course, if all this new activity doesn't lead to a new protocol it's not worthy of the attention of this group, so I'd like to propose that where ever this ends up, we push for rapid standardization of a protocol to solve the communication problems between cooperating schizophrenic entities in an IP environment. Perhaps a suitable name for such a protocol would be "Splitting Yourself Between Internet Layers", or SYBIL. I think we can do something with this... In any event, finding a suitable home for the important (if somewhat unbelievable) original request must be the only reason it's being discussed at all. The poster missed the cutoff for April 1 RFCs by a good three weeks. - peterd -- ------------------------------------------------------------------------------ I think much of our difficulty lie in confusing implementation with architecture. Errors in implementation, although they may lead to spectacular failure, need not cause us to question our underlying assumptions. Errors in architecture tell us that essentially we do not know what we are doing. In such a case, there is little point in continuing until you sort out what it is you are trying to accomplish... ------------------------------------------------------------------------------ From owner-ipng@sunroof.eng.sun.com Thu Apr 25 16:55:03 1996 Return-Path: Received: from sunroof.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA19442; Thu, 25 Apr 1996 16:55:02 -0700 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00429; Thu, 25 Apr 96 16:57:34 PDT Date: Thu, 25 Apr 96 16:57:34 PDT Message-Id: <9604252357.AA00429@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com From: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Admin request Content-Length: 4486 X-Lines: 88 Status: RO From ietf-request@IETF.CNRI.Reston.VA.US Thu Apr 25 16:57:28 1996 Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00423; Thu, 25 Apr 96 16:57:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11060; Thu, 25 Apr 1996 16:54:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA00061; Thu, 25 Apr 1996 16:54:54 -0700 Received: by usa.net (SMI-8.6/SMI-SVR4) id RAA08026; Thu, 25 Apr 1996 17:54:56 -0600 Received: from unknown (127.0.0.1) by bob via smtp-relay (1.0) id smtp-cc39F316; Thu Apr 25 17:32:26 1996 Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28701; 25 Apr 96 19:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28657; 25 Apr 96 19:11 EDT Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa19213; 25 Apr 96 19:11 EDT Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25715 (mail destined for ietf@CNRI.Reston.VA.US); Thu, 25 Apr 96 19:11:09 -0400 Received: by expresso.bunyip.com (NX5.67c/NX3.0S) id AA13000; Thu, 25 Apr 96 19:11:07 -0400 Message-Id: <9604252311.AA13000@expresso.bunyip.com> Sender: ietf-request@IETF.CNRI.Reston.VA.US From: Peter Deutsch Date: Thu, 25 Apr 1996 19:11:05 -0400 In-Reply-To: bob bruen's message as of Apr 25, 17:06 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: bruen@mit.edu, Karl Auerbach Subject: Re: (IPng 1632) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: Mike Davis , perry@piermont.com, ipng@sunroof.eng.sun.com, ietf@CNRI.Reston.VA.US Source-Info: From (or Sender) name not authenticated. [ You wrote: ] } On Thu, 25 Apr 1996, Karl Auerbach wrote: } > What about our schitzophrenic population? They might need blocks } > of bits. To help prevent bit explosion, we could retain CIDR. } > (Hmmm, might this change things from "one person, one vote" to "each } > personality, one vote"? In that case I know individuals who could dominate } > whole towns.) } } Just to keep things on track, technically speaking schizophrenia is a } failure of reality testing, multiple personalities are symptoms of } hysteria. However, I not sure if that actually changes the discussion... Well, for this list this is certainly an important distinction. If we're trying to deal with issues in failure testing, it would imply that any standards activity should go into the Operations Area. On the other hand, hysteria is obviously not a failure mode, but more of a question of controlling behaviour and would thus probably fall into the Security Area. Of course, identifying multiple personalities in the Internet environment is simply a Directory Service problem and obviously falls into the Applications Area, with the usual assistance from User Services (and I'd like to modestly submit that WHOIS++ beats X.500/LDAP in code shootouts where the personalities are split across multiple entities, but we can reserve such discussions for the new lists this is sure to spawn...) Of course, if all this new activity doesn't lead to a new protocol it's not worthy of the attention of this group, so I'd like to propose that where ever this ends up, we push for rapid standardization of a protocol to solve the communication problems between cooperating schizophrenic entities in an IP environment. Perhaps a suitable name for such a protocol would be "Splitting Yourself Between Internet Layers", or SYBIL. I think we can do something with this... In any event, finding a suitable home for the important (if somewhat unbelievable) original request must be the only reason it's being discussed at all. The poster missed the cutoff for April 1 RFCs by a good three weeks. - peterd -- ------------------------------------------------------------------------------ I think much of our difficulty lie in confusing implementation with architecture. Errors in implementation, although they may lead to spectacular failure, need not cause us to question our underlying assumptions. Errors in architecture tell us that essentially we do not know what we are doing. In such a case, there is little point in continuing until you sort out what it is you are trying to accomplish... ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ 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 Apr 25 17:10:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00479; Thu, 25 Apr 96 17:10:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00430; Thu, 25 Apr 96 16:57:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11093; Thu, 25 Apr 1996 16:55:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA00082; Thu, 25 Apr 1996 16:54:59 -0700 Received: by moe.iris.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA1236; Thu, 25 Apr 96 19:57:19 -0700 Message-Id: <9604260257.AA1236@moe.iris.com> Received: from InterNotes with "Lotus Notes Mail Gateway for SMTP" id 6FE1DCFCB67839DC8525631700810D41; Thu, 25 Apr 96 19:56:52 To: "Perry E. Metzger" Cc: "Vivek (V.) Kapil" , Hinden , Ipng , Ietf From: Charlie Kaufman/Iris Date: 25 Apr 96 19:35:54 EDT Subject: (IPng 1647) Re: Adult/minor flag in the IPv6 header(was And now,... Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for your suggestion. I think it will go a long way toward satisfying all parties. I must object to one part though: >I suggest, before we deploy IPv6 too far and cannot make major >technical changes, that we have to put in a mandatory end to end >option, initially with space 256 bits (but extensible via a frequency >coding mechanism), to be called the "naughty bits", to indicate the >presence of any such offensive material in the packet. The IANA will >assign these bits to any group or individual who can articulate a >criterion by which he might be offended. All routers MUST drop any and >all packets not containing the "naughty bits". As I would have thought you would have learned by now based on the discussions of certificate contents, it is unacceptable to bit code information that might have legal significance (as this certainly would). Instead, the list of who might find this packet objectionable should be fully spelled out in text (and presumably translated to native languages by routers at international boundaries). Since this might necessitate an increase in the minimum packet size, nailing this down should be a matter of greatest urgency; it would seem only prudent to suspend all other work on IPv6 until it's done. --Charlie (charlie_kaufman@iris.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 Apr 25 17:20:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00492; Thu, 25 Apr 96 17:20:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00486; Thu, 25 Apr 96 17:20:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14621; Thu, 25 Apr 1996 17:17:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA05796; Thu, 25 Apr 1996 17:17:36 -0700 Received: (from ipng@localhost) by dune.silkroad.com (8.7.3/8.6.9) id UAA02126; Thu, 25 Apr 1996 20:16:55 -0400 From: Tim Bass (IPNG WG) Message-Id: <199604260016.UAA02126@dune.silkroad.com> Subject: (IPng 1648) Re: And now, a message from our detractors... To: hinden@Ipsilon.COM (Bob Hinden) Date: Thu, 25 Apr 1996 20:16:55 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Bob Hinden" at Apr 25, 96 08:44:40 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agreed. This discussion of an adult/minor flag in the IPv6 header seems a little *****, IMHO. (censored for children) Adult/Child flags should not be at the network layer for *sure* and maybe not, nada in the transport layer. Now; debating transport (TCP) vs. application inclusion has some merit (not much, IMHO, but some.... tiny bit of merit). Absolutely *nada* in the IPv6 header, is my small vote. Thanks, Tim ------------------------------------------------------------------------------ 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 Apr 25 20:05:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00654; Thu, 25 Apr 96 20:05:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00648; Thu, 25 Apr 96 20:05:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00432; Thu, 25 Apr 1996 20:02:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA10619; Thu, 25 Apr 1996 20:02:27 -0700 Received: from A119004.sat1.as.crl.com by A.crl.com with SMTP id AA25846 (5.65c/IDA-1.5 for ); Thu, 25 Apr 1996 20:01:18 -0700 Date: Thu, 25 Apr 1996 20:01:18 -0700 Message-Id: <2.2.16.19960425221336.23ef17c6@a.crl.com> X-Sender: trohling@a.crl.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: Ted Rohling Subject: (IPng 1649) Adult/minor flag in the IPv6 header(was And now,... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would propose a more fully functional mechanism that allows individuals to specify at the IP header level a mask of content information for the source and destination to use in order to successfully screen information. At a minimum at least 32 bits must be set aside to hold the following content indicators: Bit Position Content 31 Any image with Full frontal nudity (sexual content) 30 Any image with Pectoral nudity (sexual content) 29 Any image with Pelvic nudity (sexual content) 28 Any image with Anal nudity (sexual content) 27 Any image with Semi-nudity with heterosexual couples (sexual content) 26 Any image with Semi-nudity with homosexual couples (sexual content) 25 Any image with Semi-nudity with human and significant other(s) (sexual content) 24 Nudity restriction override (for cultures where this is accepted) 23 Non-moving picture with no nudity (sexual content) 22 Moving picture with no nudity (sexual content) 21 Sound of sexual activity 20 Live picture, live moving picture or live sound of sexual activity (does not require bits 25-31) 19 Sexually explicit text - using the seven forbidden words 18 Sexually explicit text - using other than the seven forbidden words 17 ASCII Text containing sexual inuendo (non-cute) 16 ASCII Text containing sexual inuendo (cute) 15 ASCII Text containing sexual inuendo (politically correct language) 14 HTML text containing sexual inuendo (non-cute) 13 HTML text containing sexual inuendo (cute) 12 HTML text containing sexual inuendo (politically correct language) (NOTE: HTML with images must also include relevant image or sound bits) (NOTE 2: Must also be used for fonts that include sexual images) 11 Politically insensitive content 10 Ethnically insensitive content (African descent) 09 Ethnically insensitive content (Castillian descent) 08 Ethnically insensitive content (Caucasian descent) 07 Ethnically insensitive content (Asian descent) 06 Ethnically insensitive content (Indiginous populations) 05 Religiously insensitive content (Christian) 04 Religiously insensitive content (Jew) 03 Religiously insensitive content (Moslem) 02 Religiously insensitive content (Asian religions) 01 Religiously insensitive content (Animists and others) 00 Not really worth reading at all -- just plain old drivel OOPS -- I'm probably going to need more than 32 bits. Do we have more room in the bit shifter to handle this? Tongue in cheek ;-) view of the problem. Adult/child flag is useless! We are certain to irrigate some other group as well with anything we do... why not try for a more successful package. I am prepared to put together a draft if anyone thinks this modality is useful. Let me know! Regards, Ted trohling@a.crl.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 Apr 25 20:28:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00680; Thu, 25 Apr 96 20:28:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00674; Thu, 25 Apr 96 20:28:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01933; Thu, 25 Apr 1996 20:25:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA14271; Thu, 25 Apr 1996 20:25:32 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id XAA20327; Thu, 25 Apr 1996 23:27:24 -0400 (EDT) Date: Thu, 25 Apr 1996 23:27:24 -0400 (EDT) From: Scott Bradner Message-Id: <199604260327.XAA20327@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com, trohling@a.crl.com Subject: (IPng 1650) Re: Adult/minor flag in the IPv6 header(was And now,... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we are kinda out of IPv6 scope here if people are interested in this sort of thing (dirty bits) take a look at the PICS work being done by the W3C and others Scott ------------------------------------------------------------------------------ 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 Apr 25 20:46:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00707; Thu, 25 Apr 96 20:46:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00700; Thu, 25 Apr 96 20:46:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03116; Thu, 25 Apr 1996 20:43:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA16934; Thu, 25 Apr 1996 20:43:32 -0700 Received: from orna.mentat.com ([192.88.122.155]) by mentat.com (4.1/SMI-4.1) id AA17975; Thu, 25 Apr 96 20:42:13 PDT Received: by orna.mentat.com (5.0/SMI-SVR4) id AA06256; Thu, 25 Apr 1996 20:42:12 +0800 Date: Thu, 25 Apr 1996 20:42:12 +0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <9604260342.AA06256@orna.mentat.com> To: bound@zk3.dec.com Subject: (IPng 1652) Re: bsd-api-05 question Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Craig, > > > Excuse me. The change to inet* was entirely esthetics too. > > > The problem with inet names is that it suggests the purpose of the > >routines is to do inet* stuff. It isn't -- they are to do general address > >conversion to and from printable formats. > > Yep. Thats true. But what else is there but inet* stuff? > > Will others who wanted this done please add your two cents? As Bob and > I did not want this change in the spec? Thank You. I am just trying to > get this spec to a last call and have a good chance it will succeed. > > Specifically Matt Thomas, Paul Vixie, Tim Hartick, Richard Stevens, and > Francis DuPont please share your thoughts on this subject? Others??? > > I don't believe other protocols really matter though and inet* seems to > be correct from that perspective. > > thanks > /jim > Since I do not have to write nor maintain resolver libraries (at least for the moment) I do not have a strong opinion about the names of the inet_ptoa/inet_atop alias addr2ascii/ascii2addr library calls. However, I generally agree with Paul Vixie about the aesthetics of the names. What I really want, however, is for this document to move forward so I can write some code using the parts of the document in which I have interest. If there is a militant minority (or possibly majority, hard to tell) which will not accept the change then fine. Let them have their day and lets get the document moving. Jeeze this is a sorry excuse for an ENGINEERING mailing list (at least over the last day or so). The porno-bit...(chuckle) They're kidding, right? Please tell me they're kidding. tim ------------------------------------------------------------------------------ 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 Apr 25 20:46:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00706; Thu, 25 Apr 96 20:46:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00694; Thu, 25 Apr 96 20:46:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03109; Thu, 25 Apr 1996 20:43:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA16926; Thu, 25 Apr 1996 20:43:28 -0700 Received: from pferguso-pc.cisco.com (c2robo9.cisco.com [171.68.13.41]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id UAA23704; Thu, 25 Apr 1996 20:42:20 -0700 Message-Id: <199604260342.UAA23704@lint.cisco.com> X-Sender: pferguso@lint.cisco.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Apr 1996 23:43:20 -0400 To: bound@zk3.dec.com From: Paul Ferguson Subject: (IPng 1651) Re: And now, a message from our detractors... Cc: michael@stb.info.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, you and I actually agree on something. Imagine that! :-) - paul At 08:00 AM 4/25/96 -0400, bound@zk3.dec.com wrote: >I don't support this at all. For the first time in the IPng process I >have a social view on this issue and am completely against any type of >field that supports any censorship by my government of the Internet. >Absolutely not is my input. If you don't want your children to play >with lighters and the internet teach them not to don't ask us to make >your job easier or cause me to have to buy bic lighters that are bogus. > >/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 > ------------------------------------------------------------------------------ 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 Apr 25 20:54:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00724; Thu, 25 Apr 96 20:54:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00718; Thu, 25 Apr 96 20:54:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03777; Thu, 25 Apr 1996 20:51:59 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA18488; Thu, 25 Apr 1996 20:51:59 -0700 Received: from pferguso-pc.cisco.com (c2robo9.cisco.com [171.68.13.41]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id UAA24633; Thu, 25 Apr 1996 20:50:53 -0700 Message-Id: <199604260350.UAA24633@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Apr 1996 23:51:54 -0400 To: "vivek (v.) kapil" From: Paul Ferguson Subject: (IPng 1653) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please, folks -- lets NOT start religious/political discussions on this list. Take it to com-priv. Please. - paul At 02:21 PM 4/25/96 -0400, vivek (v.) kapil wrote: > > >In message "(IPng 1624) Re: And now, a message from our detractors...", >hinden@Ipsilon.com writes: > >>> >>>Re: Government trying to put an adult/minor flag in the IPv6 header: >>> >> >>This is, IMHO, a stupid idea. I would not support it. >> >>I would also argue that the government (in this case the US Government) >>does not have any jurisdiction here. > >Why do you think it is a stupid idea? IMHO, I personally think >there should be a way to identify who is on the Internet. The kind of >material that is floating on the Net is offcourse not for kids' >poor eyes. > >I also think there should be a way to mark the contents for its >level of obscenity so that those contents can be barred to appear >in front of those who do not wish to see them. > >Offcourse, whether the adult/minor flag be set within IPv6 or not >is completely different issue. Folks have to agree first whether >adult/minor flag should be legalized or not. > >Regards, > >Vivek Kapil >vkapil@nortel.ca > >> >>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 > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso@cisco.com c i s c o S y s t e m s ------------------------------------------------------------------------------ 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 Apr 25 21:41:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00830; Thu, 25 Apr 96 21:41:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00824; Thu, 25 Apr 96 21:41:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06912; Thu, 25 Apr 1996 21:38:59 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA22919; Thu, 25 Apr 1996 21:38:57 -0700 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA21691; Thu, 25 Apr 96 23:02:47 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA14374; Thu, 25 Apr 96 23:00:45 CDT Date: Thu, 25 Apr 96 23:00:45 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9604260400.AA14374@anubis.network.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1654) Re: And now, a message from our detractors... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually, there is (sort of) precedent for this sort of thing. The IPSO work could be trivially modified to tag data originating from certain classes of sites as adult content, or whatever, and ISPs wishing to provide filtering could do IPSO processing (that's IP Security Options). I suspect I could throw together a quick document on how to appropriately tag your datagrams (for content providors) and how to check data content, using the existing IPSO technology. The easiest thing would be to simply tag 'adult content' as Top Secret. It even interoperates with existing IP stacks (which I think mostly ignore BSOs, Basic Security Options). Note that I absolutely do not support this sort of idiotic legislation. and think it's a bad idea all around, I am merely rebutting remarks about how it's a weird and wonderful and impossible technology. Andrew ------------------------------------------------------------------------------ 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 Apr 25 21:47:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00870; Thu, 25 Apr 96 21:47:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00864; Thu, 25 Apr 96 21:47:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07286; Thu, 25 Apr 1996 21:45:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA23789; Thu, 25 Apr 1996 21:45:02 -0700 Received: from pferguso-pc.cisco.com (c2robo9.cisco.com [171.68.13.41]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id VAA00408; Thu, 25 Apr 1996 21:43:23 -0700 Message-Id: <199604260443.VAA00408@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Apr 1996 00:44:24 -0400 To: Scott Bradner From: Paul Ferguson Subject: (IPng 1655) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: ipng@sunroof.eng.sun.com, vkapil@bnr.ca Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:43 PM 4/25/96 -0400, Scott Bradner wrote: > >once you start down this path where do you stop. I'd say refuse the path. > Yes indeed. Please do not allow politics and religion to drive technology. When this is allowed to occur, we're all big losers. :-/ - paul ------------------------------------------------------------------------------ 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 Apr 25 21:59:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00971; Thu, 25 Apr 96 21:59:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00965; Thu, 25 Apr 96 21:59:40 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07930; Thu, 25 Apr 1996 21:57:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA25331; Thu, 25 Apr 1996 21:57:07 -0700 Received: from pferguso-pc.cisco.com (c2robo9.cisco.com [171.68.13.41]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id VAA01682; Thu, 25 Apr 1996 21:55:27 -0700 Message-Id: <199604260455.VAA01682@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Apr 1996 00:56:29 -0400 To: perry@piermont.com From: Paul Ferguson Subject: (IPng 1656) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: Ari Ollikainen , ietf@cnri.reston.va.us, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:20 PM 4/25/96 -0400, Perry E. Metzger wrote: > >So, the question is, are we going to let a bunch of computer >illiterates who can't even manage to do the jobs they were supposedly >elected to do tell us what to do? > Of course not, Perry. - paul ------------------------------------------------------------------------------ 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 Apr 25 22:57:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01267; Thu, 25 Apr 96 22:57:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01261; Thu, 25 Apr 96 22:57:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13020; Thu, 25 Apr 1996 22:54:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA02553; Thu, 25 Apr 1996 22:54:39 -0700 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA28471; Fri, 26 Apr 1996 01:49:56 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22756; Fri, 26 Apr 1996 01:49:54 -0400 Message-Id: <9604260549.AA22756@fwasted.zk3.dec.com> To: Paul Ferguson Cc: Scott Bradner , ipng@sunroof.eng.sun.com, vkapil@bnr.ca, bound@zk3.dec.com Subject: (IPng 1657) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Your message of "Fri, 26 Apr 96 00:44:24 EDT." <199604260443.VAA00408@lint.cisco.com> Date: Fri, 26 Apr 96 01:49:53 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this discussion belongs elsewhere too. If someone has a proposal for a new bit to be defined then they should provide some kind of technical proposal with justification and what it does to support some paradigm. It seems from the mail also any such request has to be verified in fact it belongs at the network layer. Until such time I am not sure this is a good use of our time. Sorry if my social comment started this it was not my intent. I don't think any entity should come in and tell us in a WG (unless its part of us in the IETF like IESG, IAB, another WG, etc) put this bit in because they are such and such an entity. They need to do the same thing any of us mortals would have to do to get new functionality in a spec and work with the WG. /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 Apr 26 01:15:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01385; Fri, 26 Apr 96 01:15:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01379; Fri, 26 Apr 96 01:15:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22287; Fri, 26 Apr 1996 01:13:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA22179; Fri, 26 Apr 1996 01:13:01 -0700 Received: by gw.home.vix.com id BAA00304; Fri, 26 Apr 1996 01:12:54 -0700 (PDT) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA01816; Fri, 26 Apr 1996 01:12:48 -0700 Date: Fri, 26 Apr 1996 01:12:48 -0700 Message-Id: <9604260812.AA01816@wisdom.home.vix.com> From: Paul Vixie To: ipng@sunroof.eng.sun.com Subject: (IPng 1658) Re: bsd-api-05 questions Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The basic idea is, given an AF, you can convert from ascii to a sockaddr >or vice versa. > >Craig May I suggest, then: int sockaddr_parse(const char *text, int af, struct sockaddr *addr); int sockaddr_format(struct sockaddr addr, char *text, int textsize); This assumes 4.4BSDish sockaddr's that have an sa_len and sa_family, and will require adjustment given that not all systems have those and the API spec seems not to want to require all systems to have those. What's important is that the names indicate precisely what is going on. You are dealing with sockaddrs, not addrs. You are parsing and formatting. Both functions should be able to return -1 and set errno to something. I don't think this is the right thing to do; inet_ntop() and inet_pton() are a reasonable approximation of the right answer, and as this is the IETF, we only need to define behaviour for Internet (the I in IETF, right?) protocols. If vendors want to expand these functions, more power to them. The API spec assumes that you have an AF_INET and an AF_INET6 (or whatever), it does not and must not assume that you have AF_ETHER or AF_DATAKIT or whatever else might actually exist out there in the world. If we're going to define it for more address families, then we need to do THAT right, which means: say which families, say what the presentation format is for each family, and give enough syntax rules so that a "-1" return from sockaddr_parse() will be portable from system to system. I think that leads us well outside of (a) our actual goal set and (b) the solution space which has been delegated to us. Therefore this proposal is actually a reduction to absurdity, please do not take it seriously. My earlier message that started as a flame and finished as a plea for peace is my actual proposal on this subject. The message you are reading right now represents the flame that I wanted to send earlier. ------------------------------------------------------------------------------ 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 Apr 26 01:23:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01401; Fri, 26 Apr 96 01:23:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01395; Fri, 26 Apr 96 01:23:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22664; Fri, 26 Apr 1996 01:21:06 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA23232; Fri, 26 Apr 1996 01:21:05 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Apr 1996 09:20:25 +0100 To: ipng@sunroof.eng.sun.com Subject: (IPng 1659) Re: And now, a message from our detractors... In-Reply-To: Your message of "Thu, 25 Apr 1996 18:15:04 EDT." Date: Fri, 26 Apr 1996 09:20:23 +0100 Message-Id: <979.830506823@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >My opinion is pretty straight forward -- putting a "Majority Field" in an >IPV6 header makes no sense. here are 2 trivial (but correct) arguments against it being a generic packet level field: 1. "majority" is differnt in different countries - do you want ALL US packets banned from the rest of the world? [corrolary - some countries have NO censorship - do you want to do NO business with them?] 2. by analogy (most lawyers understand clear anaologies, even if most lawyers give most people an allergy) Do you want a marker on the front of all letters that says effectively "open me oh spotty adolescant, for i contain dubious material" the right solution is to encrypt EVERYTHING using unbreakable, but published algorithms, and only give the keys to the rightful and mature receivers (i.e. not the FBI or any other national, or unaccountable organisation). one way to defeat this idiotic proposal would be for ISOC or someone to employ a good lawyer who knows about laws of evidence in international law as i am sure that this sort of proposal is totally broken even by their weird and wonderful ways jon ------------------------------------------------------------------------------ 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 Apr 26 02:55:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01490; Fri, 26 Apr 96 02:55:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01484; Fri, 26 Apr 96 02:54:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26739; Fri, 26 Apr 1996 02:52:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id CAA02974; Fri, 26 Apr 1996 02:52:24 -0700 Received: from safeway.london.sco.COM by scol.london.sco.COM id aa00458; 26 Apr 96 9:13 GMT X-Uri: X-Face: "Ht#9&2KEo;v0Jn!m[7V}D}F5>{KUiNw Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 1660) Re: bsd-api-05 questions In-Reply-To: Your message of "Thu, 25 Apr 1996 09:19:10 MST." <199604251619.JAA16863@aland.bbn.com> Date: Fri, 26 Apr 1996 09:14:05 +0000 Message-Id: <26734.830510045@sco.COM> From: Harvey Thompson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig Partridge wrote: > [about inet_pton() inet_ntop() (was ascii2addr() addr2ascii)] > > The basic idea is, given an AF, you can convert from ascii to a sockaddr > or vice versa. The draft does say that only AF_INET and AF_INET6 are supported, and therefore are simply extensions over the already existing BSD inet_* interfaces -- do we really want a more generic interface? If we do [dons flame proof hat] how about including a more generic word instead of inet, like "af"? af_pton(), af_ntop() When I read the standard it wasn't obvious what the "p" stood for, although of course inet_ntoa() already exists so "a" couldn't be used. Also note that there are ether_ntoa() and ether_aton() functions (well there are on my system (SCO 3.2v5, which has BSD4.3-BSD4.4-ish networking)). But there don't seem to be any others like fddi_ntoa(), atm_aton(), carrier_pidgeon_aton()... In conclusion, as the draft stands I think it makes sense, unless we want to get carried away and support other address families, which would be nice, but is that what we're trying to do? This is *ip*ng right? Perhaps somebody ought to address [sic] this in another draft. --HarveyT ------------------------------------------------------------------------------ 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 Apr 26 06:25:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01598; Fri, 26 Apr 96 06:25:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01592; Fri, 26 Apr 96 06:24:53 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07467; Fri, 26 Apr 1996 06:22:20 -0700 Received: by Sun.COM (sun-barr.Sun.COM) id AA03454; Fri, 26 Apr 96 06:22:18 PDT Received: (from george@localhost) by southstation.mvp.com (8.6.11/8.6.6) id GAA06775 for ipng@sunroof.eng.sun.com; Fri, 26 Apr 1996 06:02:30 -0700 Date: Fri, 26 Apr 1996 06:02:30 -0700 From: George Mitchell Message-Id: <199604261302.GAA06775@southstation.mvp.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1661) Politics and IPv6 Header Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's nice to see a little levity on this mailing list from time to time, and it's even nicer to have an issue upon which so many of us can agree. Nevertheless, we owe it to ourselves not to give the politicians any ammunition they can use to portray the designers of the Internet proto- cols as being insensitive, unresponsive techno-nerds who don't want any- one else playing in their sandbox. In particular, derogatory messages about politicians may come back to haunt us. Let's concentrate on finding the best way to explain to non-technical people exactly *why* this is a presentation level issue, rather than a transport level issue -- bearing in mind that most people won't under- stand this assertion when it is phrased in this concise way. -- George Mitchell (george@mvp.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 Apr 26 06:40:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01618; Fri, 26 Apr 96 06:40:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01612; Fri, 26 Apr 96 06:40:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08705; Fri, 26 Apr 1996 06:37:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA03134; Fri, 26 Apr 1996 06:37:55 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id JAA00985; Fri, 26 Apr 1996 09:37:42 -0400 (EDT) Message-Id: <199604261337.JAA00985@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: francis@cactus.slab.ntt.jp (Paul Francis) Cc: ietf@cnri.reston.va.us, ipng@sunroof.eng.sun.com Subject: (IPng 1662) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Your message of "Fri, 26 Apr 1996 14:22:44 +0200." <9604260522.AA07297@cactus.slab.ntt.jp> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 26 Apr 1996 09:37:37 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul Francis writes: > Perhaps what is warrented is that the people > with the most official sounding titles in the > IETF/IAB draft a letter to whatever politicians > are proposing doing this to IPv6, No politicians have proposed it seriously enough yet to make such action warranted. Yet. 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 Apr 26 06:48:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01642; Fri, 26 Apr 96 06:48:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01636; Fri, 26 Apr 96 06:48:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09168; Fri, 26 Apr 1996 06:45:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA05091; Fri, 26 Apr 1996 06:45:26 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id JAA00998; Fri, 26 Apr 1996 09:45:22 -0400 (EDT) Message-Id: <199604261345.JAA00998@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: amolitor@anubis.network.com (Andrew Molitor) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1663) Re: And now, a message from our detractors... In-Reply-To: Your message of "Thu, 25 Apr 1996 23:00:45 CDT." <9604260400.AA14374@anubis.network.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 26 Apr 1996 09:45:21 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew Molitor writes: > Actually, there is (sort of) precedent for this sort of thing. The > IPSO work could be trivially modified to tag data originating from certain > classes of sites as adult content, or whatever, and ISPs wishing to provide > filtering could do IPSO processing (that's IP Security Options). > > I suspect I could throw together a quick document on how to > appropriately tag your datagrams (for content providors) and how to check > data content, using the existing IPSO technology. The easiest thing would be > to simply tag 'adult content' as Top Secret. It even interoperates with > existing IP stacks (which I think mostly ignore BSOs, Basic Security > Options). > > Note that I absolutely do not support this sort of idiotic > legislation. and think it's a bad idea all around, I am merely rebutting > remarks about how it's a weird and wonderful and impossible technology. The problem, Mr. Molitor, is not that we do not know how to stuff bits into packet headers to indicate things. The problem is that there is no way to objectively state what is offensive. I realize that this comment on my part sounds suspiciously political rather than technical, but it is objectively true regardless. The only way to do this would be to set the standards for tagging at the moral standards of the most restrictive location on the planet, in which case, as I've noted, representational art of any sort, including photographs of pine trees, would be considered sacrilegious and highly offensive. Yes, this is possible, but it also eliminates any capacity to get work done whatsoever. The time has come for the politicians to grow up, not for us to dumb ourselves down. It isn't the world they grew up in, and they can't turn back the clock without destroying the world. 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 Apr 26 08:30:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01784; Fri, 26 Apr 96 08:30:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01778; Fri, 26 Apr 96 08:30:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22285; Fri, 26 Apr 1996 08:27:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA01510; Fri, 26 Apr 1996 08:27:49 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1664) Re: Adult/minor flag in the IPv6 header(was And now,... To: vkapil@bnr.ca (vivek) Date: Fri, 26 Apr 1996 17:25:10 +0100 (BST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <"15463 Thu Apr 25 14:22:10 1996"@bnr.ca> from "vivek" at Apr 25, 96 02:21:00 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Why do you think it is a stupid idea? IMHO, I personally think > there should be a way to identify who is on the Internet. The kind of > material that is floating on the Net is offcourse not for kids' > poor eyes. Im sorry but identification of people isnt practical because nobody will let people ship encryption technology freely. > is completely different issue. Folks have to agree first whether > adult/minor flag should be legalized or not. In what Jurisdiction.. ------------------------------------------------------------------------------ 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 Apr 26 09:04:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01868; Fri, 26 Apr 96 09:04:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00430; Thu, 25 Apr 96 16:57:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11093; Thu, 25 Apr 1996 16:55:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA00082; Thu, 25 Apr 1996 16:54:59 -0700 Received: by moe.iris.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA1236; Thu, 25 Apr 96 19:57:19 -0700 Message-Id: <9604260257.AA1236@moe.iris.com> Received: from InterNotes with "Lotus Notes Mail Gateway for SMTP" id 6FE1DCFCB67839DC8525631700810D41; Thu, 25 Apr 96 19:56:52 To: "Perry E. Metzger" Cc: "Vivek (V.) Kapil" , Hinden , Ipng , Ietf From: Charlie Kaufman/Iris Date: 25 Apr 96 19:35:54 EDT Subject: (IPng 1665) Re: Adult/minor flag in the IPv6 header(was And now,... Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for your suggestion. I think it will go a long way toward satisfying all parties. I must object to one part though: >I suggest, before we deploy IPv6 too far and cannot make major >technical changes, that we have to put in a mandatory end to end >option, initially with space 256 bits (but extensible via a frequency >coding mechanism), to be called the "naughty bits", to indicate the >presence of any such offensive material in the packet. The IANA will >assign these bits to any group or individual who can articulate a >criterion by which he might be offended. All routers MUST drop any and >all packets not containing the "naughty bits". As I would have thought you would have learned by now based on the discussions of certificate contents, it is unacceptable to bit code information that might have legal significance (as this certainly would). Instead, the list of who might find this packet objectionable should be fully spelled out in text (and presumably translated to native languages by routers at international boundaries). Since this might necessitate an increase in the minimum packet size, nailing this down should be a matter of greatest urgency; it would seem only prudent to suspend all other work on IPv6 until it's done. --Charlie (charlie_kaufman@iris.com) From owner-ipng@sunroof.eng.sun.com Thu Apr 25 22:23:30 1996 Return-Path: Received: from sunroof.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA15006; Thu, 25 Apr 1996 22:23:30 -0700 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01106; Thu, 25 Apr 96 22:26:04 PDT Date: Thu, 25 Apr 96 22:26:04 PDT Message-Id: <9604260526.AA01106@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com From: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from [francis@cactus.slab.ntt.jp (Paul Francis)] Content-Length: 2002 X-Lines: 52 Status: RO From francis@cactus.slab.ntt.jp Thu Apr 25 22:25:48 1996 Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01100; Thu, 25 Apr 96 22:25:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10815; Thu, 25 Apr 1996 22:23:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA28667; Thu, 25 Apr 1996 22:23:13 -0700 Received: by cactus.slab.ntt.jp (4.1/core*slab.mx8+) id AA07297; Fri, 26 Apr 96 14:22:44 JST Date: Fri, 26 Apr 96 14:22:44 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9604260522.AA07297@cactus.slab.ntt.jp> To: perry@piermont.com, pferguso@cisco.com Subject: Re: (IPng 1642) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: ari@sprintlabs.com, ietf@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com > >So, the question is, are we going to let a bunch of computer >illiterates who can't even manage to do the jobs they were supposedly >elected to do tell us what to do? > I must say I really hesitate to get into this discussion, but.... While it is all a lot of great fun to make pokes at politicians and their technical (or any another) ignorance, as far as a lot of them are concerned, and as far as a lot of voters are concerned, one of the jobs that they in fact were elected to do is to see content filtering become a reality on the internet. Perhaps what is warrented is that the people with the most official sounding titles in the IETF/IAB draft a letter to whatever politicians are proposing doing this to IPv6, and inform them, in judgement-free and non-condescending tones, that IPv6 is, for technical reasons, not the appropriate place to put such functionality. They could additionally be told what activities are ongoing in IETF and other places to do content filtering. PF ps. By the way, after looking back over my thesis, I find that it would have been easy to add content filtering to Pip. Are you reading this Newt? ------------------------------------------------------------------------------ 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 Apr 26 09:18:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01889; Fri, 26 Apr 96 09:18:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01883; Fri, 26 Apr 96 09:18:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01105; Fri, 26 Apr 1996 09:15:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA17500; Fri, 26 Apr 1996 09:15:30 -0700 Received: (konczal@localhost) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) id MAA00080; Fri, 26 Apr 1996 12:11:12 -0400 Date: Fri, 26 Apr 1996 12:11:12 -0400 Message-Id: <199604261611.MAA00080@csmes.ncsl.nist.gov> From: Joe Konczal To: harveyt@sco.COM Cc: craig@aland.bbn.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <26734.830510045@sco.COM> (message from Harvey Thompson on Fri, 26 Apr 1996 09:14:05 +0000) Subject: (IPng 1666) Re: bsd-api-05 questions Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "HT" == Harvey Thompson writes: HT> Craig Partridge wrote: >> [about inet_pton() inet_ntop() (was ascii2addr() addr2ascii)] >> >> The basic idea is, given an AF, you can convert from ascii to a >> sockaddr or vice versa. HT> The draft does say that only AF_INET and AF_INET6 are HT> supported, and therefore are simply extensions over the HT> already existing BSD inet_* interfaces -- do we really want a HT> more generic interface? ... No, the draft says, in section 2, that the functions convert AF_INET and AF_INET6 addresses, and *can be extended* to other address families as well. HT> If we do [dons flame proof hat] how HT> about including a more generic word instead of inet, like HT> "af"? HT> af_pton(), af_ntop() Good idea. It would seem wierd to use something like puts (inet_ntop (AF_ISO, &siso, siso.siso_len, NULL)); to display an OSI address. HT> When I read the standard it wasn't obvious what the "p" stood HT> for, although of course inet_ntoa() already exists so "a" HT> couldn't be used. I was going to suggest af_aton() and af_ntoa(). HT> Also note that there are ether_ntoa() and ether_aton() HT> functions (well there are on my system (SCO 3.2v5, which has HT> BSD4.3-BSD4.4-ish networking)). But there don't seem to be HT> any others like fddi_ntoa(), atm_aton(), HT> carrier_pidgeon_aton()... HT> In conclusion, as the draft stands I think it makes sense, HT> unless we want to get carried away and support other address HT> families, which would be nice, but is that what we're trying HT> to do? This is *ip*ng right? If this is ip*ng*, then why don't we limit the functions to inet6_pton() and inet6_ntop(), since IPv4 already has inet_ntoa() and inet_addr()? 8^{) Making it easy for *somebody else* to seamlessly integrate support for different address families into a function designed to extend a generic API (the BSD [not-just-IP] Socket Interface) is not unreasonable, especially when it requires only a small additional effort. HT> Perhaps somebody ought to address [sic] this in another draft. HT> --HarveyT HT> ------------------------------------------------------------------------------ HT> IETF IPng Mailing List FTP archive: HT> ftp.parc.xerox.com:/pub/ipng IPng Home Page: HT> http://playground.sun.com/ipng Direct all administrative HT> requests to majordomo@sunroof.eng.sun.com -- Joe Konczal Phone: (301) 975-3285 National Institute of Standards and Technology Fax: (301) 948-0279 Building 820, Room 410 Gaithersburg, MD 20899 USA ------------------------------------------------------------------------------ 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 Apr 26 09:27:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01912; Fri, 26 Apr 96 09:27:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01906; Fri, 26 Apr 96 09:27:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02861; Fri, 26 Apr 1996 09:25:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA20950; Fri, 26 Apr 1996 09:25:00 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id JAA18927; Fri, 26 Apr 1996 09:23:02 -0700 (PDT) Message-Id: <199604261623.JAA18927@aland.bbn.com> To: Paul Vixie Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1667) Re: bsd-api-05 questions In-Reply-To: Your message of Fri, 26 Apr 96 01:12:48 -0700. <9604260812.AA01816@wisdom.home.vix.com> Date: Fri, 26 Apr 96 09:23:02 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The basic idea is, given an AF, you can convert from ascii to a sockaddr >or vice versa. > >Craig May I suggest, then: int sockaddr_parse(const char *text, int af, struct sockaddr *addr); int sockaddr_format(struct sockaddr addr, char *text, int textsize); This assumes 4.4BSDish sockaddr's that have an sa_len and sa_family, and will require adjustment given that not all systems have those and the API spec seems not to want to require all systems to have those. Fair enough. Except I'd prefer sockaddr2ascii() and ascii2sockaddr() or sa2ascii() or ascii2sa(). The point is that this is converting to and from ascii strings -- which parse and format just don't connote for me. I don't think this is the right thing to do; inet_ntop() and inet_pton() are a reasonable approximation of the right answer, and as this is the IETF , we only need to define behaviour for Internet (the I in IETF, right?) This I is Internet sillyness is becoming a problem. It is encouraging small mindedness. Since we're so concerned with the Internet does that mean we can't use Ethernets, etc? Of course not, but that seems to be what the rest of your note says and it is patently silly. The Internet works because IP runs over a bunch of MAC layer protocols -- and it means we Internet folk periodically have to cope with those addresses. We might as well make it easier in the programming interfaces to support those MAC addresses. Furthermore, for defining how things work for AF_XXX. Do the ones you know and leave the rest for a later revision. At least it starts us down the right track. 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 Apr 26 10:36:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02040; Fri, 26 Apr 96 10:36:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02034; Fri, 26 Apr 96 10:36:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15754; Fri, 26 Apr 1996 10:33:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA17441; Fri, 26 Apr 1996 10:33:30 -0700 Received: (from ipng@localhost) by dune.silkroad.com (8.7.3/8.6.9) id NAA03622; Fri, 26 Apr 1996 13:31:00 -0400 From: Tim Bass (IPNG WG) Message-Id: <199604261731.NAA03622@dune.silkroad.com> Subject: (IPng 1668) Re: Adult/minor flag in the IPv6 header(was And To: Charlie_Kaufman/Iris.IRIS@iris.com (Charlie Kaufman/Iris) Date: Fri, 26 Apr 1996 13:30:59 -0400 (EDT) Cc: perry@piermont.com, Vkapil@Bnr.Ca, Hinden@Ipsilon.Com, Ipng@sunroof.eng.sun.com, Ietf@Cnri.Reston.Va.Us In-Reply-To: <9604260257.AA1236@moe.iris.com> from "Charlie Kaufman/Iris" at Apr 25, 96 07:35:54 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk charlie_kaufman@iris.com continues: > presumably translated to native languages by routers at international > boundaries). Since this might necessitate an increase in the minimum packet > size, nailing this down should be a matter of greatest urgency; it would seem > only prudent to suspend all other work on IPv6 until it's done. > > --Charlie For the record, Charlie: Adult Content flags DO NOT belong in the Network Layer. This WG is a Network Layer group. IPv6 is a Network Layer Protocol. Adult Content flags are Higher Layer protocol issues, for example HTTP, FTP and NNTP application protocols; which has nothing to do with the Network Layer (period). Please do not hijack the IPv6 WG for individual agenda issues that are important, but belong elsewhere. The members of the IPv6 WG, *are indeed sensitive* to adult content themes; but also realize that the issue is not an IPv6 issue. Similar to "World Peace", "End to All Hunger", and a general "Better Place for You and Me" themes; "Adult Content" issues are important, but DO NOT belong in the IPv6 IETF WG. I suggest you call Netscape Communications, BTW. They announced a $4M USD profit this week and sell application protocol layer products. Best Regards, Tim ------------------------------------------------------------------------------ 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 Apr 26 11:24:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02070; Fri, 26 Apr 96 11:24:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02064; Fri, 26 Apr 96 11:23:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24844; Fri, 26 Apr 1996 11:21:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA09721; Fri, 26 Apr 1996 11:21:17 -0700 Received: by gw.home.vix.com id LAA09220; Fri, 26 Apr 1996 11:21:05 -0700 (PDT) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA02246; Fri, 26 Apr 1996 11:21:05 -0700 Message-Id: <9604261821.AA02246@wisdom.home.vix.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1669) Re: bsd-api-05 questions In-Reply-To: Your message of "Fri, 26 Apr 1996 09:23:02 PDT." <199604261623.JAA18927@aland.bbn.com> Date: Fri, 26 Apr 1996 11:21:05 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [paul] > int sockaddr_parse(const char *text, int af, struct sockaddr *addr); > int sockaddr_format(struct sockaddr addr, char *text, int textsize); [craig] > Fair enough. Except I'd prefer sockaddr2ascii() and ascii2sockaddr() > or sa2ascii() or ascii2sa(). The point is that this is converting to > and from ascii strings -- which parse and format just don't connote for > me. Let me say again what I said a few days ago. 1. You don't mean ascii. You mean presentation. There are parts of the world whose C compilers, and this is a C API, do not care one whit about ASCII. So 'A' won't always be equal to (char)65, and '0' will not always be equal to 48. 2. I will not debase myself in front of the vendors who import BIND into their systems by shipping code with a public interface that has "2" in the name as a way to separate words and mean "to". I can't even take this possibility seriously enough to discuss it or negotiate. It may well be that the IPv6 development API does not have to be similar to the vendor and application-writer's API. I would not like to see this happen and I think Rich Stevens would agree with me here since he would no doubt rather write one book for both sets of programmers. If you are totally opposed to inet_ntop() and inet_pton(), and you are taking my above tongue-in-cheek examples as a real proposal, then I still think we need a mumble_ prefix and "sa2" won't do it. "sa_" won't do it. "sock_" would do it, but "sockaddr_" is really the right answer here if we're trying to avoid symbol table collisions with the application. We could change "parse" to "input" and change "format" to "output" if that would make you more comfortable. As of this instant, BIND will follow the API -- inet_ntop() and inet_pton() are nonideal for the industry but they are perfect for what I, and what we as a working group, are trying to accomplish. > > ... > I think we understand each other. _You_ may care whether the same API will work for Appletalk names, but _I_ do not. No reason to argue about it; we can just agree to disagree, and move on. ------------------------------------------------------------------------------ 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 Apr 26 11:54:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02138; Fri, 26 Apr 96 11:54:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02132; Fri, 26 Apr 96 11:53:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00079; Fri, 26 Apr 1996 11:51:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA21269; Fri, 26 Apr 1996 11:51:07 -0700 Received: from drax.isi.edu by drax.isi.edu (5.65c/5.61+local-20) id ; Fri, 26 Apr 1996 11:50:46 -0700 To: "J. Patrick Narkinsky" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1670) Re: And now, a message from our detractors... In-Reply-To: Your message of "Thu, 25 Apr 1996 18:15:04 EDT." Date: Fri, 26 Apr 96 11:50:46 PDT Message-Id: <25678.830544646@drax.isi.edu> From: Craig Milo Rogers Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >My opinion is pretty straight forward -- putting a "Majority Field" in an >IPV6 header makes no sense. None. Philosophical/Freedom/Religious >questions aside, it should go in the TCP header or even in HTTP or >something. > >This is a layer 7 issue, not layer 3. Philosophical/Freedom/Religious issues aside, I feel compelled to debate the technical merits of carrying the adult/minor information in an IPv6 header. My reasoning is as follows: What we are actually debating here is a security control issue. We are proposing to divide our lowest existing security level into at least two distinct levels: minor and adult. The minor/adult content distinction originates in the application data being transmitted, and the IP packets are tagged accordingly, as would any other security level tags be applied to the IP packets involved. Thus, it is both a layer 7 and a layer 3 issue. This matter should be refered immediately to a subcommittee in the IP Security working group (IPSEC) for appropriate handling and disposition. The usual security trust rules should apply to processing the minor/adult security distinction. The underlying principle must be that only provable adults should have access to material that might contain adult content. Since we cannot rely on security labels granted by a system that is not multilevel secure, unless the entire originating system is physically secured, it should be obvious that the use of Ms. Windows in public is childish, in this context, while using VMS and some Unix systems is a more mature, adult-level activity. As an investment aside, look for greatly increased growth in companies that sell child-proof locks for PC and Mac keyboards. For liability reasons, we should also expect to see "shrink-wrapped" software to be replaced by the new child-proof twist-cap CDROM case by the end of the year. It is also important to note that security labeling alone is insufficient to prevent inappropriate access to restricted-access material in a shared-media network environment. Since cable-based and radio-based Internet connections are assumed to be significant access methods tying home and mobile users to the ubiquitous Internet of the near future, it follows that sufficiently strong encryption must be a mandatory profile feature for all general-purpose Internet implementations that might be used by adults. Personally, I recommend encoding all application fields using ASN.1, as it seems to obscure the underlying data to a remarkable degree. Craig Milo Rogers ------------------------------------------------------------------------------ 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 Apr 26 12:44:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02496; Fri, 26 Apr 96 12:44:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02490; Fri, 26 Apr 96 12:44:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07889; Fri, 26 Apr 1996 12:42:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA06891; Fri, 26 Apr 1996 12:42:02 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA20334; Fri, 26 Apr 1996 15:28:39 -0400 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA01569; Fri, 26 Apr 1996 15:28:38 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id PAA27571; Fri, 26 Apr 1996 15:08:18 GMT Message-Id: <199604261508.PAA27571@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Joe Konczal Cc: harveyt@sco.com, craig@aland.bbn.com, bound@zk3.dec.com, vixie@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1671) Re: bsd-api-05 questions In-Reply-To: Your message of "Fri, 26 Apr 1996 12:11:12 -0400." <199604261611.MAA00080@csmes.ncsl.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Apr 1996 15:08:15 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In <199604261611.MAA00080@csmes.ncsl.nist.gov>, Joe Kanczal wrote: > No, the draft says, in section 2, that the functions convert AF_INET > and AF_INET6 addresses, and *can be extended* to other address > families as well. Note the phrase *can be extended*. It's not must nor even should. > puts (inet_ntop (AF_ISO, &siso, siso.siso_len, NULL)); > > to display an OSI address. What about when you do puts (af_ntop (AF_ISO, &siso, siso.siso_len, NULL)); and af_ntop returns NULL since AF_ISO isn't supported? Does this means that when Digital ships these routines that it must make sure it works with AF_OSI, AF_DECnet, AF_DLI, AF_LAT, AF_X25, and AF_LINK as well? If it doesn't, there will be problem reports filed saying that the function is broken since it doesn't deal with my AF_foo address family. The inet_ntop and inet_pton clearly state the scope of these function is for Internet sockaddrs. Now if other address families happen to be supported, great. But that possibility on most systems is unlikely. If vendors want to use these functions for generic use, they can always do a #define af_ntop inet_ntop #define af_pton inet_pton and document the af_* routines (or defined the inet_* in the form of af_*). Using any other prefix other inet_ is going to set the wrong expectations. These functions will only wort on AF_INET and AF_INET6 in the majority of implementations. Giving them names that imply they do handle (as opposed to can handle) a wider scope of address families will cause grief for any vendor who ships IPv6. > HT> When I read the standard it wasn't obvious what the "p" stood > HT> for, although of course inet_ntoa() already exists so "a" > HT> couldn't be used. > > I was going to suggest af_aton() and af_ntoa(). See above. > > If this is ip*ng*, then why don't we limit the functions to > inet6_pton() and inet6_ntop(), since IPv4 already has inet_ntoa() and > inet_addr()? 8^{) Less conditional code. But then you knew that. > Making it easy for *somebody else* to seamlessly integrate support for > different address families into a function designed to extend a > generic API (the BSD [not-just-IP] Socket Interface) is not > unreasonable, especially when it requires only a small additional > effort. I guess this all comes to a view on the problem. Those of us who will provide these functions want to see the scope of these function as limited as possible. Those who want to actually use these function want the scope to be as wide as possible. I don't think that these two worldviews have any middle ground. Leave the ^%$% names alone and advance the draft. If you really want a generic function, get POSIX or X/Open to do it. We've defined inet_ntop and inet_pton so they can be mapped to generic functions or they can be the generic functions themselves and that should be sufficient. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 26 14:44:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02746; Fri, 26 Apr 96 14:44:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02740; Fri, 26 Apr 96 14:43:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26018; Fri, 26 Apr 1996 14:41:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA12736; Fri, 26 Apr 1996 14:41:21 -0700 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA21013; Fri, 26 Apr 1996 14:41:20 -0700 Date: Fri, 26 Apr 1996 14:41:20 -0700 From: Ran Atkinson Message-Id: <199604262141.OAA21013@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1672) Re: bsd-api-05 questions In-Reply-To: <199604261508.PAA27571@whydos.lkg.dec.com> References: <199604261611.MAA00080@csmes.ncsl.nist.gov> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199604261508.PAA27571@whydos.lkg.dec.com> Matt wrote: >Does this means that when Digital ships these routines that it >must make sure it works with AF_OSI, AF_DECnet, AF_DLI, AF_LAT, >AF_X25, and AF_LINK as well? It is up to each vendor to decide what it will choose to implement. This is each vendor's business decision only. No one has ever suggested otherwise. POSIX is the standards body for Sockets APIs so the IETF spec isn't a standard. The RFC is describing something so that we can all get on the same page and make it easier to achieve source-code portability for IPv6-capable applications. So arguments about this RFC mandating anything on vendors are really not well founded since it is clear that no mandating is happening nor can it happen in this context. >If it doesn't, there will be problem >reports filed saying that the function is broken since it doesn't >deal with my AF_foo address family. Any vendor has a choice of dealing with these as either feature requests or as bugs. >I guess this all comes to a view on the problem. Those of us who will ^^^^^ >provide these functions want to see the scope of these function as >limited as possible. Those who want to actually use these function want >the scope to be as wide as possible. I don't think that these two >worldviews have any middle ground. Please limit the scope of your claim. You certainly are NOT speaking for all of the implementers, but instead for yourself (and conceivably for some others as well). A number of the implementers either have or are working to implement support for most/all address families. Several of these plan to give their code away. In any event, this is not a great deal of code to implement. I would gently suggest that there is plenty of room for middle ground. The functions shouldn't try to work on address families not present on the system (e.g. XNS if one doesn't support XNS) but it is QUITE reasonable to achieve support for address families supported on the platform. >Leave the ^%$% names alone and advance the draft. If you really want >a generic function, get POSIX or X/Open to do it. We've defined inet_ntop >and inet_pton so they can be mapped to generic functions or they can be >the generic functions themselves and that should be sufficient. Would it make things easier for the vendors desiring to limit the scope if a freely distributable implementation of the functions existed that they could just take and use ?? It is almost certainly the case that POSIX will just take whatever gets deployed into IEEE 1003.1 (future version). X/OPEN will probably do whatever the vendor firms who are members of X/OPEN decide amongst themselves. In practice, neither of those is very open to individual participation or free software implementers (based on my being an IEEE member and being on the ballot group of various 1003.x standards). I've been involved in IEEE 1003 since the late 1980s, so I'm hardly inexperienced or uninformed here. Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Apr 26 15:29:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02873; Fri, 26 Apr 96 15:29:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02857; Fri, 26 Apr 96 15:26:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02751; Fri, 26 Apr 1996 15:23:42 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA24718; Fri, 26 Apr 1996 15:23:42 -0700 Received: from [128.89.30.9] (ARA9.BBN.COM [128.89.30.9]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id SAA12646; Fri, 26 Apr 1996 18:25:00 -0400 (EDT) Date: Fri, 26 Apr 1996 18:25:00 -0400 (EDT) X-Sender: lyman@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Paul Francis From: lyman@bbn.com (Lyman Chapin) Subject: (IPng 1673) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: perry@piermont.com, pferguso@cisco.com, ari@sprintlabs.com, ietf@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:22 AM 4/26/96, Paul Francis wrote: >> >>So, the question is, are we going to let a bunch of computer >>illiterates who can't even manage to do the jobs they were supposedly >>elected to do tell us what to do? >> > > >I must say I really hesitate to get into >this discussion, but.... Paul, Historical precedent suggests that a much more effective practical solution to this problem would be to launch a New Work Item in ISO/IEC to add Objectionable Content Filtering to CLNP. Government agencies around the world would be delighted to see this important matter being taken up by the "real" International Standards body, and would surely shift their attention to that arena. IP and the Internet, with the bozo spotlight elsewhere, could then get on with life. - Lyman > >While it is all a lot of great fun to make >pokes at politicians and their technical >(or any another) ignorance, as far as a lot >of them are concerned, and as far as a lot >of voters are concerned, one of the jobs >that they in fact were elected to do is to >see content filtering become a reality on >the internet. > >Perhaps what is warrented is that the people >with the most official sounding titles in the >IETF/IAB draft a letter to whatever politicians >are proposing doing this to IPv6, and inform them, >in judgement-free and non-condescending tones, that >IPv6 is, for technical reasons, not the appropriate >place to put such functionality. They could >additionally be told what activities are ongoing >in IETF and other places to do content filtering. > >PF > >ps. By the way, after looking back over my thesis, >I find that it would have been easy to add content >filtering to Pip. Are you reading this Newt? ------------------------------------------------------------------------------ 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 Apr 26 20:22:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03043; Fri, 26 Apr 96 20:22:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03037; Fri, 26 Apr 96 20:22:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00042; Fri, 26 Apr 1996 20:19:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA11524; Fri, 26 Apr 1996 20:19:26 -0700 Received: from primenet.com (root@usr3.primenet.com [198.68.32.13]) by mailhost1.primenet.com (8.7.3/8.7.1) with ESMTP id UAA18403 for ; Fri, 26 Apr 1996 20:19:25 -0700 (MST) Received: (from bwilmes@localhost) by primenet.com (8.7.3/8.7.3) id UAA11696; Fri, 26 Apr 1996 20:19:25 -0700 (MST) Date: Fri, 26 Apr 1996 20:19:25 -0700 (MST) From: Bob Wilmes To: ipng@sunroof.eng.sun.com Subject: (IPng 1674) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: <9604260549.AA22756@fwasted.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 Although you may personally belief in the grand tradition of laissez-faire network content on the Internet, I believe it would be a very wise decision for this group to atleast consider the potential mechanisms for accomplishing some form of voluntary mechanism for declarative content. Politicians all over the globe are going to use this issue to press for control, and whether you personally denounce such self censorship, you can look at the Motion Picture Industry Association rating system to atleast understand the common thread in popular society by many for such a system. You that sell networking equipment and services also have to realize that Fortune 500 company executives are today, very interested in tracking employee use of their Intranet/Internet connections, for the explicit purpose of terminating employees for browsing sexually suggestive web sites or newsgroup. This issue is going to keep growing, and this group should look at proactively developing a content lock mechanism, sort of a software "V" chip. ------------------------------------------------------------------------------ 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 Apr 26 21:45:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03084; Fri, 26 Apr 96 21:45:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03078; Fri, 26 Apr 96 21:45:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03496; Fri, 26 Apr 1996 21:42:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA17732; Fri, 26 Apr 1996 21:42:13 -0700 Received: (from mclay@localhost) by locutus.weareb.org (8.7.4/8.7.4) id XAA19094; Fri, 26 Apr 1996 23:43:16 -0500 (CDT) From: Michael Clay Message-Id: <199604270443.XAA19094@locutus.weareb.org> Subject: (IPng 1675) Re: Adult/minor flag in the IPv6 header(was And now,... To: ipng@sunroof.eng.sun.com Date: Fri, 26 Apr 1996 23:43:15 -0500 (CDT) In-Reply-To: from "Bob Wilmes" at Apr 26, 1996 08:19:25 PM X-Mailer: ELM [version 2.5 PL0a9] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Although you may personally belief in the grand tradition of laissez-faire > network content on the Internet, I believe it would be a very wise > decision for this group to atleast consider the potential mechanisms > for accomplishing some form of voluntary mechanism for declarative > content. [snip] Uhm... we have considered it. Take a look at the last 50-100 posts to this thread. In fact it is so blatantly absurd that most people on this list probably broke out in laughter when the idea was first presented. Anyone with any understanding of what IPv6 really is knows that the idea of a 'kid-bit' in the IP and/or lower layers is a brain-damaged idea. Just imagine, as a little thought exercise, of encoding this at the Link layer. You could then sign an affidavit when you bought your Adults-Only ethernet card for your PC stating that no children would be using a PC containing that card. I hope you are cringing at the very thought of such a thing. Encoding maturity info into IPv6 is no more sane. Lets look at both sides of the coin: 1) You dont like censorship and/or want to take resposiblity for what your child is exposed to in the world. This is the easy issue. Simply dont add the 'kid-bit'. Most people following this line of thinking would use PICS (or a similar protocol), if anything. 2) You wish to let your child roam free on the net without fear that he or she will be exposed to objectionable materials. I would argue that IPv6 is still the wrong place for this. There are so many ways to circumvent a 'kid-bit' that makes this whole concept leak like a sieve. i.e. Tunnels, Lack Of Accountablity on the remote site, etc, etc. In addition, what about IPv4? It is not going away, and cannot go away. This whole scheme breaks when you have to talk to an IPv4 host. BOOM!!! no more protected kiddies, and all of the 'evil' stuff gets archived on IPv4 hosts in foreign countries where no laws prevent such things. Gee, now what? How about using the software that ALREADY exists for limiting access to the net? (See PICS) These packages can both a) only block sites on a (modifiable) 'bad-site' list and b) only allow sites on an (also modifiable) pre-approved list. In addition, with PICS, the site-list can be maintained by the appropriate religious or political (or whatever) group of your choice. This is good, because I would not want someone else's religious or political standards being crammed down my throat involuntarily. Rant-mode off, Mike Clay -- ------------------+----------------------------------------------------------- Michael Clay | One does not seriously attack the expertise of a scientist mclay@weareb.org | using the undefined phrase 'butt-head'. -- Judge J. Baird ------------------+----------------------------------------------------------- ------------------------------------------------------------------------------ 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 Apr 27 05:47:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03318; Sat, 27 Apr 96 05:47:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03312; Sat, 27 Apr 96 05:46:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17024; Sat, 27 Apr 1996 05:44:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA09781; Sat, 27 Apr 1996 05:44:24 -0700 Received: from pferguso-pc.cisco.com (c1robo2.cisco.com [171.68.13.2]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id FAA26657; Sat, 27 Apr 1996 05:42:49 -0700 Message-Id: <199604271242.FAA26657@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Apr 1996 08:43:50 -0400 To: Bob Wilmes From: Paul Ferguson Subject: (IPng 1676) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:19 PM 4/26/96 -0700, Bob Wilmes wrote: > >Although you may personally belief in the grand tradition of laissez-faire >network content on the Internet, I believe it would be a very wise >decision for this group to atleast consider the potential mechanisms >for accomplishing some form of voluntary mechanism for declarative >content. > I think conventional wisdom dictates that this doesn't belong at the network layer. The OSI 8-Layer Reference Model +---------------+ | Politics | <----- You are here. +---------------+ | Application | +---------------+ | Presentation | +---------------+ | Session | +---------------+ | Transport | +---------------+ | Network | +---------------+ | Data Link | +---------------+ | Physical | +---------------+ Humor aside, this is not a network layer problem. - paul ------------------------------------------------------------------------------ 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 Apr 27 10:17:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03396; Sat, 27 Apr 96 10:17:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03390; Sat, 27 Apr 96 10:17:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23003; Sat, 27 Apr 1996 10:14:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA25153; Sat, 27 Apr 1996 10:14:51 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id NAA04161; Sat, 27 Apr 1996 13:14:46 -0400 (EDT) Message-Id: <199604271714.NAA04161@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Bob Wilmes Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1677) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Your message of "Fri, 26 Apr 1996 20:19:25 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 27 Apr 1996 13:14:46 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Wilmes writes: > Although you may personally belief in the grand tradition of laissez-faire > network content on the Internet, I believe it would be a very wise > decision for this group to atleast consider the potential mechanisms > for accomplishing some form of voluntary mechanism for declarative > content. As I have indicated, no such mechanism is possible, not because we do not know how to set bits on datagrams or file headers, but because there is not even a remotely uniform standard of what is offensive. > Politicians all over the globe are going to use this issue to press > for control, Let them. It is not our responsibility when they pass laws like that. It is theirs. Once they have passed their little snivling laws, let them cut off the global internet, which will someday soon encompass all telecommunications, and see how long their economy survives. The U.S. is no exception here -- the United States doesn't run the world any more, and in any case can hardly afford to destroy its most vital and vibrant industrial sector. If they choose to anyway, well, thats not the problem of the rest of the world. The Europeans aren't nearly as hung up about seeing penises or whatever. If you think I'm being political here, I must admit that I am. When people want to cut off their own access to material through the use of mechanisms like Surf Watch, thats perfectly fine. If a parent wants to buy internet service that is filtered to make sure that Junior gets only access to pictures of Bambi and never learns about gays or whatever, thats fine. When people suggest imposing expensive and grotesque responsibilities on third parties to mark their own casual remarks as being potentially offensive (perhaps because in their random comments on rec.arts.cinema they note that they went to the movies last week with the lover they aren't married to, which is highly offensive even today in much of the bible belt of the U.S.), I get militant. Yes, I'm political. Sue me. I will not go around padding the corners of the sharp edges of all the information I produce. I'm not going to take time at the end of every mail message I post to the net to remember if I used the word "fuck", or mentioned something that could be offensive to the government of Namibia, or whatever. It is not my responsibility to do so, and I'm not joking when I say I'll do my utmost to block any such stupidity. When I read the requirements documents for IPng, I see no mention of the requirement that the new network infrastructure must stop fifteen year olds from reading about sex, or stop Chinese dissidents from communicating (which is, of course, ultimately what the main use of any such technology will be.) > You that sell networking equipment and services also have to realize > that Fortune 500 company executives are today, very interested in tracking > employee use of their Intranet/Internet connections, for the explicit > purpose of terminating employees for browsing sexually suggestive > web sites or newsgroup. I don't see that we have to help unreasonable people in their quest to be unreasonable. I don't even care to mention that tagging is useless and ineffective and that using it in the method you describe is not going to do a whit of good in a future secure encrypted network. Far deeper than that is the point that the whole thing is not our problem. Any company that cares so much about what its employees are reading that they are going to spend large resources checking all the incoming bits to make sure that none of them are naughty can spend those resources on its own. I am not concerned about the internet being "stopped" by regulation because soon there isn't going to be another phone network or TV transmission infrastructure or anything else other than the internet. When that happens, not if, the companies that want to cut themselves off from the global communications infrastructure because they are scared that someone out there in the mailroom might be looking at pictures of naked women or someone getting a blow job are welcome to do so. They will reap the harvest of their foolishness. Meanwhile, the rest of us have real work to do. Wasting time on this foolishness is, yes, foolish. The fools who lie awake at night scared that someone out there might be looking at pictures of people having sex or that someone might be reading the truth about Tiananmen Square will continue on without us having to help them in their quest to rid the world of pictures of nipple tissue or unpleasant reporting. > This issue is going to keep growing, Let it. > and this group should look at proactively developing a content lock > mechanism, sort of a software "V" chip. Over my rotting corpse. If the congress wants to legislate something, let them. It isn't our responsibility to aid and abet, however. 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 Sat Apr 27 11:14:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03449; Sat, 27 Apr 96 11:14:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03443; Sat, 27 Apr 96 11:14:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24816; Sat, 27 Apr 1996 11:12:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA09807; Sat, 27 Apr 1996 11:12:04 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id LAA29689; Sat, 27 Apr 1996 11:11:00 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA12680; Sat, 27 Apr 96 11:09:38 MST; for ipng@sunroof.eng.sun.com Message-Id: <9604271809.AA12680@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Sat, 27 Apr 1996 11:09:37 -0700 Reply-To: 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: bound@zk3.dec.com, Craig Partridge Subject: (IPng 1678) Re: bsd-api-05 questions Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Apr 25, 11:35am you write:] > > Specifically Matt Thomas, Paul Vixie, Tim Hartick, Richard Stevens, and > Francis DuPont please share your thoughts on this subject? Others??? You really sure you want my comments :-) OK, I think the -05 spec is flawed, and I have said so numerous times over the past two weeks on the smaller mailing list (the people involved in the LA meeting concerning the draft). Here are my complaints. - I wrote what may be the first implementation of the Posix getaddrinfo() function 2-3 weeks ago along with the corresponding getnameinfo() function (Posix forgot to specify the reverse translation). In writing this I found that the removal of hostname2addr() and addr2hostname() from the draft was wrong. I have no way in getaddrinfo() of forcing an IPv6 DNS query. Paul Vixie made one or two proposals, but I think the concensus was that people didn't like his gethostname2() function, and the DNS working group was going to come out with something later in the year. People also said that it doesn't matter that these two functions were taken out of the draft, because everyone should be using getaddrinfo() instead. I don't agree. I think it should be possible to write a portable implementation of getaddrinfo() that does not have to do explicit DNS queries (i.e., it should not have to call the res_XXX() functions). - I also think the IETF spec should define getaddrinfo() and getnameinfo(). Posix specs are too hard to obtain and they will probably never be online. I volunteered to write this portion of the spec myself (starting with Keith Sklower's now-expired-getconninfo() draft, Keith sent me this nroff input) but no one wanted this done. Given the current status of the Posix 1003.1g draft, I really doubt there will be any changes to this function before the final standard is complete. - I do not care about the names, ascii2addr() versus inet_pton(), versus net_pton(), but agree with Craig that we should stay as protocol independent as possible. Craig: I think they changed from "ascii" to "p" (which stands for "presentation", not "printable") to avoid any dependence on ASCII format. They then chose the the inet_XXXX names to be similar to the existing inet_aton() and inet_ntoa(). I do want the sockets API spec done soon, as I want to start writing code that I know will be portable between the various implementations that are starting to be available, but I also think it needs to be done right. I think what is there is 98% complete, but it shouldn't take more than a week or two to finish it right. 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 Sat Apr 27 15:23:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03609; Sat, 27 Apr 96 15:23:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03603; Sat, 27 Apr 96 15:23:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02432; Sat, 27 Apr 1996 15:20:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA25108; Sat, 27 Apr 1996 15:20:53 -0700 Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.7.5/1.169) with SMTP id SAA03455; Sat, 27 Apr 1996 18:19:27 -0400 (EDT) X-Sender: kgk@ott.hookup.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Apr 1996 18:19:38 -0400 To: lyman@bbn.com (Lyman Chapin), Paul Francis , sc6ietf@dl.ac.uk, j.houldsworth@ste0426.wins.icl.co.uk, pag@mci.org.uk From: kgk@hookup.net (Keith G Knightson) Subject: (IPng 1679) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: perry@piermont.com, pferguso@cisco.com, ari@sprintlabs.com, ietf@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Lyman, I must say I was surpised to see what you wrote. Up to now I always regarded you as a person of some integrity. Shows how wrong one can be I suppose. Certainly bodes well for collaboration effort... >From bozo Keith > >Paul, > >Historical precedent suggests that a much more effective practical >solution to this problem would be to launch a New Work Item in ISO/IEC >to add Objectionable Content Filtering to CLNP. Government agencies >around the world would be delighted to see this important matter being >taken up by the "real" International Standards body, and would surely >shift their attention to that arena. IP and the Internet, with the >bozo spotlight elsewhere, could then get on with life. > >- Lyman > ------------------------------------------------------------------------------ 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 Apr 28 09:00:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03822; Sun, 28 Apr 96 09:00:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03816; Sun, 28 Apr 96 09:00:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01008; Sun, 28 Apr 1996 08:58:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA11061; Sun, 28 Apr 1996 08:58:05 -0700 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA02810; Sun, 28 Apr 1996 11:51:22 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31254; Sun, 28 Apr 1996 11:51:13 -0400 Message-Id: <9604281551.AA31254@fwasted.zk3.dec.com> To: Michael Clay Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1680) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: Your message of "Fri, 26 Apr 96 23:43:15 CDT." <199604270443.XAA19094@locutus.weareb.org> Date: Sun, 28 Apr 96 11:51:12 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can we please let this continue in the PICS or as Lyman suggested take it to JTC1 or whatever. If someone has a technical proposal for the IPng WG develop a draft and send it in and maybe if its deemed important it will be an agenda item at Montreal. This is eating up precious time before Montreal for real work we have to do. Someone build a draft or go somewhere else and discuss this as its not relative to any of the specs we are working on or implementing at present. Maybe this should go to IPSEC. Geezz Thomas Jefferson and James Madison must be turning in their graves and all the dead soldiers who fought for the basic freedoms supposedly the U.S. is founded upon. In the U.S. think about the up coming Memorial day and what it means and then go back and think about this extra bit. Whats more important that an entity can watch its employees or the precedence a bit can set in the system. These are my views and do not reflect my employers or anyone I associate with. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Apr 29 06:01:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04742; Mon, 29 Apr 96 06:01:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04736; Mon, 29 Apr 96 06:01:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13620; Mon, 29 Apr 1996 05:58:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA23522; Mon, 29 Apr 1996 05:58:21 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1681) Re: bsd-api-05 questions To: rja@cisco.com (Ran Atkinson) Date: Mon, 29 Apr 1996 14:56:31 +0100 (BST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199604262141.OAA21013@puli.cisco.com> from "Ran Atkinson" at Apr 26, 96 02:41:20 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > POSIX is the standards body for Sockets APIs so the IETF spec isn't a > standard. That depends on what is implemented by whom. The BSD socket API for IPv6 certainly doesnt need to explore higher level stuff nor generic issues, it just needs to work. > Would it make things easier for the vendors desiring to limit the > scope if a freely distributable implementation of the functions existed > that they could just take and use ?? For the Linux world yes. For the free BSD systems I am sure also. Even for people who don't implement it a code reference always helps. Alan ------------------------------------------------------------------------------ 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 Apr 29 07:20:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04859; Mon, 29 Apr 96 07:20:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04853; Mon, 29 Apr 96 07:19:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20189; Mon, 29 Apr 1996 07:17:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA14039; Mon, 29 Apr 1996 07:17:13 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id HAA23866; Mon, 29 Apr 1996 07:17:12 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA00697; Mon, 29 Apr 96 07:17:11 MST; for ipng@sunroof.eng.sun.com Message-Id: <9604291417.AA00697@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Mon, 29 Apr 1996 07:17:11 -0700 Reply-To: 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: iialan@iifeak.swan.ac.uk (Alan Cox), rja@cisco.com (Ran Atkinson) Subject: (IPng 1682) Re: bsd-api-05 questions Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Apr 29, 2:56pm you write:] > > POSIX is the standards body for Sockets APIs so the IETF spec isn't a > > standard. > > That depends on what is implemented by whom. The BSD socket API for IPv6 > certainly doesnt need to explore higher level stuff nor generic issues, it > just needs to work. Posix 1003.1g says nothing about IPv6, as there is no "existing practice". Therefore what the IETF does with the sockets API will become the existing practice. So whenever Posix gets back to updating 1003.1g with IPv6, what the IETF does now will become the standard. Also, given how long 1003.1g has taken to get where it is today, and it's still not done, can you guess when and if they'll ever get back to standardizing the IPv6 sockets API ... 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 Apr 29 07:58:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04890; Mon, 29 Apr 96 07:58:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04884; Mon, 29 Apr 96 07:58:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23728; Mon, 29 Apr 1996 07:55:43 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA23782; Mon, 29 Apr 1996 07:55:42 -0700 Received: from localhost (day@localhost) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id KAA11642 for ; Mon, 29 Apr 1996 10:58:44 -0400 (EDT) Message-Id: <199604291458.KAA11642@zafu.bbn.com> X-Authentication-Warning: zafu.bbn.com: Host day@localhost didn't use HELO protocol From: "John Day" Subject: (IPng 1683) Adult/minor flag To: ipng@sunroof.eng.sun.com Date: Mon, 29 Apr 96 10:55:40 EST Mail-System-Version: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Guys, This discussion has truly become absurd, but it was interesting to watch the responses. I must say that I was dismayed though by two things in this discussion: First, how long it took before someone pointed out that this is entirely the wrong layer to consider such a thing, and 2) the apparent lack of belief in the datagram/connectionless model exhibited by the ipv6 group. I begin to wonder whether this group deep down believes in a connection model. It is a fundamental premise of IP that each IP packet is independent of every other IP packet. Therefore, one would assume that one would only be required to set the "naughty" bits on those IP packets when considered independent of all other IP packets contain the offensive material. Now consider a gif file of your favorite raunchy pic, when the file is broken up into IP packets which ones are the offensive ones? Only set the "naughty" bit on those. Clearly compression might cause more packets to have their bits set. Take care, John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Apr 29 08:23:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04941; Mon, 29 Apr 96 08:23:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04935; Mon, 29 Apr 96 08:23:04 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26542; Mon, 29 Apr 1996 08:20:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA01380; Mon, 29 Apr 1996 08:20:27 -0700 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA28188; Mon, 29 Apr 1996 11:02:36 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24069; Mon, 29 Apr 1996 11:02:30 -0400 Message-Id: <9604291502.AA24069@fwasted.zk3.dec.com> To: Richard Stevens Cc: iialan@iifeak.swan.ac.uk (Alan Cox), rja@cisco.com (Ran Atkinson), ipng@sunroof.eng.sun.com Subject: (IPng 1684) Re: bsd-api-05 questions In-Reply-To: Your message of "Mon, 29 Apr 96 07:17:11 PDT." <9604291417.AA00697@gemini.tuc.noao.edu> Date: Mon, 29 Apr 96 11:02:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, This is a good point. By the time POSIX get done I will have deployed the API and an IPv6 stack. So how about writing up getaddrinfo() and getnameinfo() and passsing it by us. Could you do this? If Bob or I do it it will not get done for another month! We are both maxed on our day jobs and were hoping this last draft will fly. You can send to Bob and I to edit and flush out and Keith too if that is appropriate first. Also on DNS lib API. I am assuming I will use Paul Vixie's gethostbyname2() which will support an AF parameter. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Apr 29 09:17:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05041; Mon, 29 Apr 96 09:17:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05035; Mon, 29 Apr 96 09:17:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04418; Mon, 29 Apr 1996 09:14:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA20162; Mon, 29 Apr 1996 09:14:47 -0700 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/4.03) id AA42434; Mon, 29 Apr 1996 12:09:36 -0400 Date: Mon, 29 Apr 1996 12:09:36 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9604291609.AA42434@oxygen.house.gov> To: Day@bbn.com, ipng@sunroof.eng.sun.com Subject: (IPng 1685) Re: Adult/minor flag Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ... I must say that I was dismayed though by two things in > this discussion: First, how long it took before someone pointed out > that this is entirely the wrong layer to consider such a thing, ... I, for one actually thought it was an April Fool, like the flood of RFCs. Instead of posting here, I sent private comments to appropriate people. Since I read this source for technical information (I get all the politics I can handle at work :-), I prefer to keep this discussion off IPng. Summary: sombody who does not know better suggested the new IP could solve the Communication Decency "problem". We should not take the bait. My suggestion (delivered with humorous intent) was serious: Educate your Representative as the only reliable way to deal with these issues. The recent creation of the Internet Caucus suggests this effort is not futile. -- John ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Apr 29 10:25:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05222; Mon, 29 Apr 96 10:25:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03125; Fri, 26 Apr 96 23:23:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07466; Fri, 26 Apr 1996 23:21:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA24879; Fri, 26 Apr 1996 23:21:15 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA11847; Fri, 26 Apr 1996 23:19:41 -0700 Date: Fri, 26 Apr 1996 23:19:41 -0700 (PDT) From: Karl Auerbach To: Michael Clay Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1686) Re: Adult/minor flag in the IPv6 header(was And now,... In-Reply-To: <199604270443.XAA19094@locutus.weareb.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > a) only block sites on a (modifiable) 'bad-site' list and And to make the situation evern more absurd, if you were to label my site as "bad-site" I could bring a legal action for defamation and possibly even win. Sigh. --karl-- ------------------------------------------------------------------------------ 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 Apr 29 11:14:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05348; Mon, 29 Apr 96 11:14:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03784; Sun, 28 Apr 96 07:41:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29497; Sun, 28 Apr 1996 07:38:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA07372; Sun, 28 Apr 1996 07:38:25 -0700 Received: from jcurran-ppp.near.net by poblano.bbnplanet.com id aa08438; 28 Apr 96 10:38 EDT X-Sender: jcurran@198.114.157.116 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Phone: (617) 873-4398 Usmail: 150 CambridgePark Drive, Cambridge, MA, 02140 Date: Sun, 28 Apr 1996 10:38:25 -0400 To: ipng@sunroof.eng.sun.com From: John Curran Subject: (IPng 1687) Re: Adult/minor flag in the IPv6 header(was And now,... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While the ability to distinguish content types is important, it definitely belongs far above the network layer and there's already quite a few folks working on making content-tagging happen on the Internet [Surfwatch, et. al.]. If we should get a formal request to add an adult/minor flag to IP, then a reply along the lines suggested by Paul Francis (IPv6 is the wrong place, look to these other initiatives) seems in order. /John From owner-ipng@sunroof.eng.sun.com Mon Apr 29 06:43:04 1996 Return-Path: Received: from sunroof.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA05372; Mon, 29 Apr 1996 06:43:04 -0700 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04816; Mon, 29 Apr 96 06:45:39 PDT Date: Mon, 29 Apr 96 06:45:39 PDT Message-Id: <9604291345.AA04816@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com From: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from [Robert Moskowitz ] Content-Length: 1747 X-Lines: 39 Status: RO From rgm3@chrysler.com Mon Apr 29 06:45:23 1996 Return-Path: Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04810; Mon, 29 Apr 96 06:45:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16970; Mon, 29 Apr 1996 06:42:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA05782; Mon, 29 Apr 1996 06:42:45 -0700 Received: by pilotx.firewall.is.chrysler.com; id JAA04543; Mon, 29 Apr 1996 09:42:45 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma004537; Mon, 29 Apr 96 09:42:25 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id JAA12112; Mon, 29 Apr 1996 09:44:57 -0400 (EDT) Message-Id: <2.2.32.19960429134108.00b8e108@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Apr 1996 09:41:08 -0400 To: Bob Wilmes , ipng@sunroof.eng.sun.com From: Robert Moskowitz Subject: Re: (IPng 1674) Re: Adult/minor flag in the IPv6 header(was And now,... At 08:19 PM 4/26/96 -0700, Bob Wilmes wrote: > >You that sell networking equipment and services also have to realize >that Fortune 500 company executives are today, very interested in tracking >employee use of their Intranet/Internet connections, for the explicit >purpose of terminating employees for browsing sexually suggestive >web sites or newsgroup. This is so easy to handle at the firewall with the proxy server. Our execs already know this, and others do too. Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ 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 Apr 29 11:14:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05355; Mon, 29 Apr 96 11:14:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04810; Mon, 29 Apr 96 06:45:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16970; Mon, 29 Apr 1996 06:42:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA05782; Mon, 29 Apr 1996 06:42:45 -0700 Received: by pilotx.firewall.is.chrysler.com; id JAA04543; Mon, 29 Apr 1996 09:42:45 -0400 Received: from clhubgw1-le0.is.chrysler.com(172.29.128.203) by pilotx.is.chrysler.com via smap (g3.0.1) id sma004537; Mon, 29 Apr 96 09:42:25 -0400 Received: from rgm3 by clhubgw1-nf0.is.chrysler.com (8.7.5/SMI-4.1) id JAA12112; Mon, 29 Apr 1996 09:44:57 -0400 (EDT) Message-Id: <2.2.32.19960429134108.00b8e108@pop3hub.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Apr 1996 09:41:08 -0400 To: Bob Wilmes , ipng@sunroof.eng.sun.com From: Robert Moskowitz Subject: (IPng 1688) Re: Adult/minor flag in the IPv6 header(was And now,... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:19 PM 4/26/96 -0700, Bob Wilmes wrote: > >You that sell networking equipment and services also have to realize >that Fortune 500 company executives are today, very interested in tracking >employee use of their Intranet/Internet connections, for the explicit >purpose of terminating employees for browsing sexually suggestive >web sites or newsgroup. This is so easy to handle at the firewall with the proxy server. Our execs already know this, and others do too. Robert Moskowitz Chrysler Corporation (810) 758-8212 ------------------------------------------------------------------------------ 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 Apr 29 15:07:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05801; Mon, 29 Apr 96 15:07:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05795; Mon, 29 Apr 96 15:06:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07664; Mon, 29 Apr 1996 15:04:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA28387; Mon, 29 Apr 1996 15:04:19 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3679; Mon, 29 Apr 96 18:03:20 EDT Received: by RTP (XAGENTA 4.0) id 0421; Mon, 29 Apr 1996 18:03:56 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19233; Mon, 29 Apr 1996 18:03:43 -0400 Message-Id: <9604292203.AA19233@cichlid.raleigh.ibm.com> To: Richard Stevens Cc: bound@zk3.dec.com, Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1689) Re: bsd-api-05 questions In-Reply-To: Your message of "Sat, 27 Apr 1996 11:09:37 PDT." <9604271809.AA12680@gemini.tuc.noao.edu> Date: Mon, 29 Apr 1996 18:03:43 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Stevens writes: >OK, I think the -05 spec is flawed, and I have said so numerous times over >the past two weeks on the smaller mailing list (the people involved in the >LA meeting concerning the draft). Here are my complaints. I agree with Rich on all three of these points. His concerns need to be addressed. On a more mundane level: I'm not sure we have the Flow Label stuff quite right yet. > - Changed the sin6_flowlabel field to sin6_flowinfo to accommodate > the addition of the priority field to the IPv6 header. > struct sockaddr_in6 { > u_int16m_t sin6_family; /* AF_INET6 */ > u_int16m_t sin6_port; /* Transport layer port # */ > u_int32m_t sin6_flowinfo; /* IPv6 flow information */ > struct in6_addr sin6_addr; /* IPv6 address */ > }; This spec defines flowinfo as a 32 bit number. It is in fact a 24-bit Flow Label and a 4-bit priority (leaving 4 bits unused). The spec suggests that one extract these values via such operations as: > recvfrom(s, buf, buflen, flags, (struct sockaddr *) &sin6, &fromlen); > . . . > received_flowlabel = sin6.sin6_flowinfo & IPV6_FLOWINFO_FLOWLABEL; > received_priority = sin6.sin6_flowinfo & IPV6_FLOWINFO_PRIORITY; Yuck. Note that after the above the Flow Label is not even right-justified. Is this what we really want? Are we assuming that the system call that generates Flow Labels will return them in a non-right justified format? Or that the programmer will remember to do some bit shifting? I think we can do better. Why not have flowinfo be a structure so that the individual fields can be accessed via assignment statements? I think it makes more sense to be able to say something like: struct flowinfo { u_int32m_t reserved:4; u_int32m_t flowlabel:24; u_int32m_t priority:4; } flowinfo; #define sin6_priority flowinfo.priority #define sin6_flowlabel flowinfo.flowlabel ... sin6.sin6_priority = 5 sin6.sin6_flowinfo = XXX; I find this preferable to having to use explicit masking and/or shifts to get the desired values into the correct bit positions. Also, the current list of symbolic constants for priorities seems incomplete or misleading: > IPV6_PRIORITY_UNCHARACTERIZED > IPV6_PRIORITY_FILLER > IPV6_PRIORITY_UNATTENDED > IPV6_PRIORITY_RESERVED1 > IPV6_PRIORITY_BULK > IPV6_PRIORITY_RESERVED2 > IPV6_PRIORITY_INTERACTIVE > IPV6_PRIORITY_CONTROL > IPV6_PRIORITY_8 > IPV6_PRIORITY_9 > IPV6_PRIORITY_10 > IPV6_PRIORITY_11 > IPV6_PRIORITY_12 > IPV6_PRIORITY_13 > IPV6_PRIORITY_14 > IPV6_PRIORITY_15 First, the symbolic names don't distinguish between flow-controlled and non-flow controlled traffic. I'd suggest calling the first 7 something like IPV6_FCPRIO_UNCHARACTERIZED (using "FCPRIO" to denote flow-controlled priority). (Hopefully someone else can think of a better acronym.) Second, at the very least, priorities 8-15 should be given symbolic names via something like: IPV6_NFCPRIO_LOWEST .... IPV6_NFCPRIO_HIGHEST and maybe also defining a IPV6_NFCPRIO_DEFAULT (or average??) to be the middle value. Regarding inet_ntop() and inet_pton(), the spec doesn't say whether or not the address pointer "void *ap" needs to be aligned on any particular boundary (e.g., 64 bit). The spec should probably say something about this. >Inet_pton() returns the length of the address in octets if the >conversion succeeds, and -1 otherwise. The function does not modify >the buffer pointed to by ap if the conversion fails. Is there any particular reason why the function doesn't modify the buffer if the function fails? Is this just a backwards compatability thing? Since this is a *NEW* function being defined, what are we being compatable with? > char *inet_ntop( > int af, > const void *ap, > size_t len, > char *cp); >The len field specifies the length in octets of the address pointed to >by ap. This must be 4 if af is AF_INET, or 16 if af is AF_INET6. The >cp argument points to a buffer that the function can use to store the >text string. If the cp argument is NULL, the function uses its own >private static buffer. If the application specifies a non-NULL cp >argument, the buffer must be large enough to hold the text >representation of the address, including the terminating null octet. I'm confused by the len field. The spec says that it is the length of *ap, but the argument seems redundant to me given that af already determines the address. Why is it needed? 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 Apr 29 18:50:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05957; Mon, 29 Apr 96 18:50:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05941; Mon, 29 Apr 96 18:46:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10319; Mon, 29 Apr 1996 18:44:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA26120; Mon, 29 Apr 1996 18:44:00 -0700 Received: by cactus.slab.ntt.jp (4.1/core*slab.mx8+) id AA02224; Tue, 30 Apr 96 10:43:01 JST Date: Tue, 30 Apr 96 10:43:01 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9604300143.AA02224@cactus.slab.ntt.jp> To: francis@hookup.net, j.houldsworth@ste0426.wins.icl.co.uk, kgk@hookup.net, lyman@bbn.com, pag@mci.org.uk, sc6ietf@dl.ac.uk Subject: (IPng 1690) Re: Adult/minor flag in the IPv6 header(was And now,... Cc: ari@sprintlabs.com, ietf@CNRI.Reston.VA.US, ipng@sunroof.eng.sun.com, perry@piermont.com, pferguso@cisco.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I must say I was surpised to see what you wrote. .... > > From bozo Keith > Surely you realize that Lyman was joking?.... (It is so hard to do dry humor on the internet. If you add a smiley face, it is no longer dry.) PF ------------------------------------------------------------------------------ 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 Apr 29 23:58:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06161; Mon, 29 Apr 96 23:58:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06155; Mon, 29 Apr 96 23:58:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01694; Mon, 29 Apr 1996 23:55:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA08041; Mon, 29 Apr 1996 23:55:31 -0700 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA07300; Tue, 30 Apr 1996 02:49:06 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19105; Tue, 30 Apr 1996 02:49:03 -0400 Message-Id: <9604300649.AA19105@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: Richard Stevens , bound@zk3.dec.com, Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1691) Re: bsd-api-05 questions In-Reply-To: Your message of "Mon, 29 Apr 96 18:03:43 -0300." <9604292203.AA19233@cichlid.raleigh.ibm.com> Date: Tue, 30 Apr 96 02:49:02 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'm not sure we have the Flow Label stuff quite right yet. > >> - Changed the sin6_flowlabel field to sin6_flowinfo to accommodate >> the addition of the priority field to the IPv6 header. > >> struct sockaddr_in6 { >> u_int16m_t sin6_family; /* AF_INET6 */ >> u_int16m_t sin6_port; /* Transport layer port # */ >> u_int32m_t sin6_flowinfo; /* IPv6 flow information */ >> struct in6_addr sin6_addr; /* IPv6 address */ >> }; >This spec defines flowinfo as a 32 bit number. It is in fact a 24-bit >Flow Label and a 4-bit priority (leaving 4 bits unused). The spec >suggests that one extract these values via such operations as: >> recvfrom(s, buf, buflen, flags, (struct sockaddr *) &sin6, &fromlen); >> . . . >> received_flowlabel = sin6.sin6_flowinfo & IPV6_FLOWINFO_FLOWLABEL; >> received_priority = sin6.sin6_flowinfo & IPV6_FLOWINFO_PRIORITY; > >Yuck. Note that after the above the Flow Label is not even >right-justified. Is this what we really want? Are we assuming that >the system call that generates Flow Labels will return them in a >non-right justified format? Or that the programmer will remember to do >some bit shifting? I think we can do better. Why not have flowinfo be >a structure so that the individual fields can be accessed via >assignment statements? I think it makes more sense to be able to say >something like: > > struct flowinfo { > u_int32m_t reserved:4; > u_int32m_t flowlabel:24; > u_int32m_t priority:4; > } flowinfo; > #define sin6_priority flowinfo.priority > #define sin6_flowlabel flowinfo.flowlabel > ... > sin6.sin6_priority = 5 > sin6.sin6_flowinfo = XXX; >I find this preferable to having to use explicit masking and/or shifts >to get the desired values into the correct bit positions. The flow label is not justified its just a mask of bits. The AND operator just masks the priority values to zero so all your left with for the flow are the bits that are on. This is the style and convention of most systems and we worked hard to not change the style as our strategy for the programmer that programs apps today via sockets on UNIX type systems. This spec was never meant for other systems. I know this is an issue for other systems but the title of our spec I think is pretty clear and not biased as its says BSD Sockets. Your free to implement the style you want but its not as efficient adding the overhead of structures to the code in my opinion. This is an old argument and not a major issue but a style issue. Technically there is no gain from what you propose and the justification is not an issue. Also what you propose makes building macros more difficult. And I am not a fan of macros but again thats convention too. >Also, the current list of symbolic constants for priorities seems >incomplete or misleading: >> IPV6_PRIORITY_UNCHARACTERIZED >> IPV6_PRIORITY_FILLER >> IPV6_PRIORITY_UNATTENDED >> IPV6_PRIORITY_RESERVED1 >> IPV6_PRIORITY_BULK >> IPV6_PRIORITY_RESERVED2 >> IPV6_PRIORITY_INTERACTIVE >> IPV6_PRIORITY_CONTROL >> IPV6_PRIORITY_8 >> IPV6_PRIORITY_9 >> IPV6_PRIORITY_10 >> IPV6_PRIORITY_11 >> IPV6_PRIORITY_12 >> IPV6_PRIORITY_13 >> IPV6_PRIORITY_14 >> IPV6_PRIORITY_15 > >First, the symbolic names don't distinguish between flow-controlled >and non-flow controlled traffic. I'd suggest calling the first 7 >something like IPV6_FCPRIO_UNCHARACTERIZED (using "FCPRIO" to denote >flow-controlled priority). (Hopefully someone else can think of a >better acronym.) Second, at the very least, priorities 8-15 should be >given symbolic names via something like: > >IPV6_NFCPRIO_LOWEST >.... >IPV6_NFCPRIO_HIGHEST >and maybe also defining a IPV6_NFCPRIO_DEFAULT (or average??) to be >the middle value. The priority field is for "congestion-controlled traffic" and "non-congestion-controlled traffic" not "flow" anything. These are two different concepts. We can make this clearer but I do not consider this to be a big issue ---> show stopper. >Regarding inet_ntop() and inet_pton(), the spec doesn't say whether or >not the address pointer "void *ap" needs to be aligned on any >particular boundary (e.g., 64 bit). The spec should probably say >something about this. There is no boundary issue its just a pointer to a buffer that holds the address. Its an address determined by the size of your registers pointing to a buffer. I think this to be common knowledge. >>Inet_pton() returns the length of the address in octets if the >>conversion succeeds, and -1 otherwise. The function does not modify >>the buffer pointed to by ap if the conversion fails. >Is there any particular reason why the function doesn't modify the >buffer if the function fails? Is this just a backwards compatability >thing? Since this is a *NEW* function being defined, what are we being >compatable with? The last step in the library routine would be to load the buffer why do that if the conversion fails? Other than that there is no reason to save the buffer it simply should not be destroyed. >> char *inet_ntop( >> int af, >> const void *ap, >> size_t len, >> char *cp); > >>The len field specifies the length in octets of the address pointed to >>by ap. This must be 4 if af is AF_INET, or 16 if af is AF_INET6. The >>cp argument points to a buffer that the function can use to store the >>text string. If the cp argument is NULL, the function uses its own >>private static buffer. If the application specifies a non-NULL cp >>argument, the buffer must be large enough to hold the text >>representation of the address, including the terminating null octet. >I'm confused by the len field. The spec says that it is the length of >*ap, but the argument seems redundant to me given that af already >determines the address. Why is it needed? This is left over from af == AF_ISO which can be a varible length address size, and the appendix of believeing we have to still keep track of variable thingees from non IPv6/IPv4 af's. I agree it is not needed for IPv4 or IPv6 and excess baggage. But if people want to use this for other af types they may need the length. But then again even CLNP suggestes 20 bytes and thats it. This gets back into the discussion of do we build universal library functions into this API spec? I say no as its for IPv6 developers to use and transition from IPv4 to IPv6. But is the extra field that painful? I don't think so. But it does look weird I agree. Also this is why the FOOBAR spec needs to be re-written before I will change my ftp to support the prt and pasv commands in that manner. 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 Apr 30 05:29:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06339; Tue, 30 Apr 96 05:29:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06333; Tue, 30 Apr 96 05:29:14 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20949; Tue, 30 Apr 1996 05:26:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA22556; Tue, 30 Apr 1996 05:26:34 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1690; Tue, 30 Apr 96 08:25:35 EDT Received: by RTP (XAGENTA 4.0) id 0515; Tue, 30 Apr 1996 08:26:22 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20468; Tue, 30 Apr 1996 08:26:16 -0400 Message-Id: <9604301226.AA20468@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: Richard Stevens , Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1692) Re: bsd-api-05 questions In-Reply-To: Your message of "Tue, 30 Apr 1996 02:49:02 EDT." <9604300649.AA19105@fwasted.zk3.dec.com> Date: Tue, 30 Apr 1996 08:26:15 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com writes: >The flow label is not justified its just a mask of bits. The AND >operator just masks the priority values to zero so all your left with >for the flow are the bits that are on. This is the style and convention >of most systems and we worked hard to not change the style as our >strategy for the programmer that programs apps today via sockets on UNIX >type systems. This is OK if the value you are extracting is a single bit and you just want to know if the bit is cleared or set. But if the value is a multi-bit field, you need to treat the bits as a unit, and you want the data structures to allow easy access to the unit. If I understand the current spec, if I want to set the flowid and priority for a socket, I'd have to do something like: flow = syscall_to_give_me_a_flow_id(); sin6.sin6_flowinfo = 0; /* clear all the bits */ sin6.sin6_flowinfo |= (flow << BITS_TO_SHIFT); /* set just the flow label */ sin6.sin6_flowinfo |= IPV6_PRIORITY_INTERACTIVE; >From a programming perspective, I think it's a lot cleaner to have separate fields that can be access independent of each other. As defined now, if you want to set one field (e.g. Flow Label) you have to be careful not to clobber the bits you shouldn't be changing (e.g., Priority) whenever doing an assingment. An impossible task? Of course not. But I think having separate fields is more convenient and less error-prone. Likewise, if I want to print out the flow id, I have to do something like: printf ( ... , sin6.sin6_flowinfo >> BITS_TO_SHIFT); The current draft seems to imply that folks will not need to right-shift the sin6_flowinfo bits before using them. There is always a potential for problems when you use more bits than are necessary to define a quantity. What are the semantics when some of the "extra" bits are set? What will the system do? Better to just define things so such cases can't arise. >This spec was never meant for other systems. My comments have nothing to do with other systems. I'm looking at this purely from the perspective of minimizing programming errors. >Your free to implement the style you want but its not as efficient >adding the overhead of structures to the code in my opinion. Efficiency is not a factor in my comments. The kinds of overhead we're talking about here are insignificant in the overall scheme of things. >This is an >old argument and not a major issue but a style issue. IMO, style issues are important, especially when when we are talking about APIs. >Technically >there is no gain from what you propose and the justification is not an >issue. Is reduced likelyhood of programming errors not technical? >Also what you propose makes building macros more difficult. Can you please be more specific? >The priority field is for "congestion-controlled traffic" and >"non-congestion-controlled traffic" not "flow" anything. Agreed. > These are two >different concepts. We can make this clearer but I do not consider this >to be a big issue ---> show stopper. My concern is that as currently written, the first 8 priority values have nice sounding names that programmers can identify with (e.g, IPV6_PRIORITY_INTERACTIVE), but the last 8 values are just numbers, and that there is not distinction (in name) between the first 8 and last 8 priorities. I suspect that naive programmers (i.e., the masses) will pick the ones based on name. We'll have fewer errors if its more clear which priorities go with which type of traffic. >>Regarding inet_ntop() and inet_pton(), the spec doesn't say whether or >>not the address pointer "void *ap" needs to be aligned on any >>particular boundary (e.g., 64 bit). The spec should probably say >>something about this. >There is no boundary issue its just a pointer to a buffer that holds the >address. Its an address determined by the size of your registers >pointing to a buffer. I think this to be common knowledge. The spec makes it clear in various places that IPv6 addresses are aligned on 64 bit boundaries for efficiency reasons. Your response seems to be telling me that if the IPv6 address passed to inet* is not on a 64-bit boundary, your library routine won't dump core. Did I get this right? >>>Inet_pton() returns the length of the address in octets if the >>>conversion succeeds, and -1 otherwise. The function does not modify >>>the buffer pointed to by ap if the conversion fails. >>Is there any particular reason why the function doesn't modify the >>buffer if the function fails? Is this just a backwards compatability >>thing? Since this is a *NEW* function being defined, what are we being >>compatable with? >The last step in the library routine would be to load the buffer why do >that if the conversion fails? Other than that there is no reason to >save the buffer it simply should not be destroyed. Your response is telling me that I can't do the coversion in place. I have to use a temporary variable and then copy the result after I'm done. Not a big deal, but I'm somewhat surprised that such a requirement is spelled out in this spec. >>I'm confused by the len field. The spec says that it is the length of >>*ap, but the argument seems redundant to me given that af already >>determines the address. Why is it needed? >This is left over from af == AF_ISO which can be a varible length address >size, and the appendix of believeing we have to still keep track of >variable thingees from non IPv6/IPv4 af's. I agree it is not needed for >IPv4 or IPv6 and excess baggage. OK. I agree then that it should be there, since I think this routine should be useable with all sockaddr types. 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 Apr 30 07:58:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06381; Tue, 30 Apr 96 07:58:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06375; Tue, 30 Apr 96 07:58:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04550; Tue, 30 Apr 1996 07:56:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA01756; Tue, 30 Apr 1996 07:56:03 -0700 Received: (from mclay@localhost) by locutus.weareb.org (8.7.4/8.7.4) id JAA08159 for ipng@sunroof.eng.sun.com; Tue, 30 Apr 1996 09:56:29 -0500 (CDT) From: Michael Clay Message-Id: <199604301456.JAA08159@locutus.weareb.org> Subject: (IPng 1693) Re: bsd-api-05 questions To: ipng@sunroof.eng.sun.com (IPv6) Date: Tue, 30 Apr 1996 09:56:27 -0500 (CDT) X-Mailer: ELM [version 2.5 PL0a9] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just my $0.02. As a systems programmer, I really prefer the suggested: > struct flowinfo { > u_int32m_t reserved:4; > u_int32m_t flowlabel:24; > u_int32m_t priority:4; > } flowinfo; > #define sin6_priority flowinfo.priority > #define sin6_flowlabel flowinfo.flowlabel Ive have seen and used this construct in many places, and it makes for easy to read, easy to understand code. (If one writes for maintainability.) Allowing for gender may make this whole thing a slightly more complicated, though. Maybe something like: union flowinfo { struct { u_int32m_t reserved:4; u_int32m_t priority:4; u_int32m_t flowlabel:24; } flowdata; u_int32m_t flowinfo; } un; #define sin6_priority un.flowdata.priority #define sin6_flowlabel un.flowdata.flowlabel #define sin6_flowinfo un.flowinfo This way, sin6_flowinfo can be passed to and from htonl() and ntohl() to acheive network byte order per the API spec. - Mike Clay -- ------------------+----------------------------------------------------------- Michael Clay | "Maybe you should call the Internet and talk to their mclay@weareb.org | tech support people." -- AOL Customer Service ------------------+----------------------------------------------------------- ------------------------------------------------------------------------------ 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 Apr 30 08:02:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06394; Tue, 30 Apr 96 08:02:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06388; Tue, 30 Apr 96 08:02:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05022; Tue, 30 Apr 1996 07:59:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA03023; Tue, 30 Apr 1996 07:59:54 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1694) Re: bsd-api-05 questions To: narten@VNET.IBM.COM (Thomas Narten) Date: Tue, 30 Apr 1996 16:54:09 +0100 (BST) Cc: bound@zk3.dec.com, rstevens@noao.edu, craig@aland.bbn.com, ipng@sunroof.eng.sun.com In-Reply-To: <9604301226.AA20468@cichlid.raleigh.ibm.com> from "Thomas Narten" at Apr 30, 96 08:26:15 am Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > flow = syscall_to_give_me_a_flow_id(); > sin6.sin6_flowinfo = 0; /* clear all the bits */ > sin6.sin6_flowinfo |= (flow << BITS_TO_SHIFT); /* set just the flow label */ > sin6.sin6_flowinfo |= IPV6_PRIORITY_INTERACTIVE; What assumptions about endianism do we make with "give me a flow id" ? Alan ------------------------------------------------------------------------------ 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 Apr 30 08:29:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06428; Tue, 30 Apr 96 08:29:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06422; Tue, 30 Apr 96 08:29:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08896; Tue, 30 Apr 1996 08:26:52 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA12428; Tue, 30 Apr 1996 08:26:50 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA11862; Tue, 30 Apr 1996 08:26:42 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1381244466==_============" Date: Tue, 30 Apr 1996 08:27:10 -0700 To: ipng@sunroof.eng.sun.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1695) IPng March Meeting Minutes Cc: minutes@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --============_-1381244466==_============ Content-Type: text/plain; charset="us-ascii" Attached are the minutes from the March IETF Meeting in LA. Please send any corrections to me and I will send in an update. Bob --============_-1381244466==_============ Content-Type: text/plain; name="IPng-Meeting.March96"; charset="us-ascii" Content-Disposition: attachment; filename="IPng-Meeting.March96" IPng Working Group Meeting March 1996 Los Angles IETF Steve Deering / Xerox PARC, Co-Chair Robert Hinden / Ipsilon Networks, Co-Chair Meeting Minutes were taken and produced by Robert Hinden. ------------------------------------------------- Steve Deering opened the meeting. Bob Hinden agreed to take the minutes. The agenda was reviewed and the following items were agreed to be discussed: Introductions / Steve Deering W.G. Document Status / Bob Hinden University of New Hampshire Bakeoff Report / Jim Bound Spec. changes from UNH Experience / Steve Deering DHCPv6 Issues / Ralph Droms Host Anycasting Support / Jim Bound Multihomed Hosts / Mike Shand Link Local Address and Interface ID's / KRE Payload Header / KRE Header Compression for IPv6 / Mikael Degermark Tunneling Spec / Alex Conta Unicast address Formats / Bob Hinden Swap Source & Destination Address in IPv6 Header / Mike Carlton PMTU Spec / Jim McCanne BSD API Issues / Bob Gilligan UDP + TCP/MSS vs. JumboGrams / Dave Borman Host Handling of Router Header Max Autoconfig Token size? Correct ::127.0.0.1 in Transition Mechanism Specification IPv6 over PPP / Dimitry Haskin =================================================================== Monday =================================================================== Document Status / Bob Hinden Since the last IETF meeting the following IPv6 RFC's were published as Proposed Standards: o Internet Protocol, Version 6 (IPv6) Specification IP Version 6 Addressing Architecture o Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification o DNS Extensions to support IP version 6 The following document was published as Informational RFC: o An Architecture for IPv6 Unicast Address Allocation The following document was published as experimental RFC: o OSI NSAPs and IPv6 o IPv6 Testing Address Allocation The following documents have completed IETF last call and the IESG is considering for evaluation to Proposed Standard: o Neighbor Discovery for IP Version 6 (IPv6) o A Method for the Transmission of IPv6 Packets over Ethernet Networks o A Method for the Transmission of IPv6 Packets over FDDI Networks The IESG returned the following document to the working group: o An IPv6 Provider-Based Unicast Address Format [Editors Note: This document was discussed later in this meeting] The following documents are ready to be sent to the IESG: o A Method for the Transmission of IPv6 Packets over Token Ring Networks The following documents are almost ready for IPng working group last call: o Path MTU Discovery for IP version 6 o Generic Packet Tunneling in IPv6 Specification o IPv6 Program Interfaces for BSD Systems ------------- UNH Bakeoff / Jim Bound Jim Bound gave a report on the UNH IPv6 Bakeoff. Router implementations were tested from Ipsilon Networks and Bay Networks. Host implementations were tested from Sun Microsystems, Mentat, FTP Software, WIDE Consortia, HP, Digital, and INRIA. Most of the base spec was tested as well as Neighbor Discovery and Auto Address Configuration. The testing went well. The group is planning another test in late June. ------------- Specification Changes/Issues arising from UNH Bakeoff / Steve Deering o When processing routing header, If packet too big for next hop MTU, send ICMP packet "Pkt too big" to source Do NOT Fragment o On reception of option with wrong alignment, send ICMP parameter problem. Discussion about how to move changes forward. Scott Bradner (AD) said a new ID should be published, then ask IESG to publish an informational RFC. o In ND specifcation, clarify purpose and effect of the on-line flag. This is a mechanism which requires that all hosts send to routers to reach all destinations. Erik Nordmark noted that the text describing this topic was clarified in the current version of the ND Internet Draft. o Does a redirect for a packet with non-zero flow ID apply to only that flow or for all packets to same destination? Deering suggested that it should apply to all packets to that destination. Redirection of flows should be done with flow setup protocol (e.g., RSVP). Group agreed to make the IPv6 redirect flow insensitive. Dennis Fergusion noted that a flow redirect would also need to redirect source, destination, flow ID, not just destination. o Discussion on should a host accept new connections on a "depreciated" address. Group concluded that a host should accept new connections on a "depreciated" address. The AddrConf spec should be clarified. ------------ DHCPv6 Issues / Ralph Droms Authentication/Verification in DHCPv6 Background Want to authenticate clients and servers and verify contents unmodified. DHCP uses "relay agents" that retransmit messages between client and off-link server. DHCPv4 uses "giaddr' and "hops" fields, which are changed by the relay agent. Proposed Solutions Uses IPSEC and tunnels between relay agents and servers. Client discovers relay agents, inserts "giaddr" and uses IPSEC Skip "giaddr" and "hops" in verification computations with IPSEC or DHCP specific mechanism. Use IPSEC with separate associations between client/relay agent and relay agent/server. Defer authentication; encrypt response. Discussion about preferences of each proposed solutions. No clear preference from working group. Multiple Addresses and DCHCPv6 in IPv6 Are multiple addresses per interface a good idea for IPv6: Yes Should multiple addresses be delivered "on demand"? Service want its own address, doesn't know it until server starts. Long varied discussion about pro's/cons. Straw poll leaning that this is a good idea. Will applications want to specify the characteristics of the addresses they request? Site Local / Global Life Time Multi-homed Discussion....... No concensus on this. How will applications specify these addresses? Should DHCP be charged with specificaton and delivery of multiple addresses? DHCPv6 will be discussed tomorrow evening DHCP session. -------------- Bob Gilligan, NGTrans co-chair offered to let the IPng working group use the second half its session on Tuesday to complete more action items. The chairs accepted his offer. An additional session was scheduled Tuesday at 4:30pm at the end of the NGTRANS session. =================================================================== Tuesday =================================================================== Multihomed Hosts Draft tries to enumerate what multihoming means. Are there issues not described. Lists issues. Author wants people to read draft and have discussion on list and discuss at next IETF meeting. Suggestion to change title to "Multihomed Hosts". ---------- Payload Header KRE's proposal to support multipayload fields in single packet. Proposal to require implementation of this options. Three advantages: Put a number of small packets in one large one, 2) Makes better use of jumbograms, could be useful for better alignment in supercomputers. 3) Align TCP header on 8 byte boundary. Choice to to require it or to throw out the option. Meeting in Washington, DC concluded this was not worth doing. Discussion on pros/cons. Would put burden on receiver. Not at all clear how sender would like this to be used. Also, large issue for implementations of firewalls. Firewall would need to look inside to see if there were other headers. Group decided to not pursue. ------ IPv6 over PPP / Dimitry Haskin Draft proposal for a new PPP network control protocol to negotiate IP version 6 datagram transmission and configureation options. Current draft is draft-ietf-ipngwg-pppext-ipv6cp-01.txt. Draft was developed because IPv6 datagram use different protocol ID another data links and has different options than IPv4. Options are interface token used to form IPv6 link-local address as well as in global address autoconfiguration. Generated similar to Magic Number procedure. Also includes an option for IPv6 compression protocol. Draft was reviewed by PPP group. IPng needs to approve to move forward. Interface token 8 8 32 bits +------+--------+-----------------------------------------+ | Type | Length| Interface-Token | +------+--------+-----------------------------------------+ Link local address of PPP interfaces 8 70 bits 48 bits +------------+---------------------+----------------------+ | 1111111010 | 0 | Interface-Token | +------------+---------------------+----------------------+ Discussion about necessity of special PPP compression for IPv6 because there is already a general PPP compression algorithm which is not protocol specific. Discussion about reducing the size of the interface token. Would make compressions better if there was more zeros in the address. Suggestion for 8 bit interface token. Also, would allow more subnet space to create local address hierarchy in dialup service providers Suggestion for 32bits. Discussion about using smaller token. Group agreed to use 32bit tokens. Document will be revised. Chairs will do a working group last call when new ID is published. =================================================================== Wednesday =================================================================== Unicast Address Formats / Bob Hinden The IESG returned the "An IPv6 Provider-Based Unicast Address Format" to the working group. The issues dealt with the use of fixed length fields in the middle of the address. A new draft has been issued with attempts to resolve this issue. It defines the format for this address type to be: 3 5 n 56-n 64 bits +---+------------+------------+--------------+------------------+ |010| RegistryID | ProviderID | SubscriberID | Intra-Subscriber | +---+------------+------------+--------------+------------------+ In this version of the document the RegistryID uses a 5 bits and the Provider ID and Subscriber ID fields together use 56 bits. Individual subscribers are always guaranteed 64 bits of local address independent of which provider they use to insure operation with addr conf and to allow renumbering. The working group agreed to do a working group last call on this document and then to advance it to the IESG for proposed standard at the completion of the working group last call. --------- PMTU Specification Author reviewed changes from previous version. These included: o Add terminology section o Clarify definition of path o Local representation of path (implementation specific) o Applies to Multicast o Processing routing header o PMTU for directly connected node o Note about PTB message with MTU < 576 bytes o Appendix on changes from RFC-1191 o Add Jeff Mogul as an author o Remove references to "routes" Working group agreed to do a working group last call on this document. ----------------- Header Compression for IPv6 / Mikael Degermark Why Header Compressions: On low speed links want good interactive response time. Want to be able to support realtime audio. Goals to compress IPv6 (and IPv4), TCP, and UDP Headers. No setup is required in this proposal and it works over simplex links. The goal to support realtime audio for low speed links. Results: Reduces IPv6/UDP headers to 8.7% of size, 48 bytes to 4 bytes. Swedish Institute of Computer Science (SICS) has a prototype implementation running. Compressor is about 400 lines of C code. Decompressor is 300 lines of C code. Basic idea is to send a full header with a CID (compression ID) occasionally. Subsequent compressed headers carry the CID and fields that are different from the fields in the full header. TCP uses RFC1144 header. New formats for non-TCP flows. Adds generation field to identify when compression state is obsolete. Supports different formats depending on how much information is carried. Goal is to use the smallest possible. Handles compression of IPv6 subheaders. Includes rules for how to handle extension headers. Includes four different ways to classify how an individual field will change. Includes NOCHANGE: Never changes. DELTA: Changes in predictable way. Send difference. RANDOM: Can not predict, must be included INFERRED: Can deduce from other fields. Example of link level field. Showed examples of different cases are extended. Full Headers: Don't want to increase the size of a full header when maximum MTU is being used. Utilizes fact that header length field can be inferred. Uses the length field in IPv6 [and transport] header. Assumes that link layer provides the length of the packet. Also assumes that link layer delivers packets in the order that they are sent. Interesting issue of how to deal with packet loss. What happens if full header (which would have changed compresisons state) is lost. Must be able to detect this incorrect decompression and reestablish compressions state. For TCP many fields use delta encoding (tcp segements, etc.). If lost, then TCP sequence fields will be off. TCP checksum will catch these packets. Compressor looks for TCP retransmits then sends full header. Uses softstate for non-TCP packets. Periodically sends full header refreshes. Then does exponential backoffs to reduce the number of full headers sent. This is where generation field is used to establish new compressions state. Cost of sending full headers periodically only increases the average size of packets sent by 1.4 bits. This scheme can also be used for multicast and non-point to point links. Authors have not specified how which packets should use specific compressions state. Includes guidelines, but has not specified exactly. There is a tradeoff with how much compressions is done and implementation complexity. Need a way to tell these different headers apart. Could either get new link layer identifier (e.g., ethertype) or use different values in the version field. Group will discuss the merits on the ipng mailing list. SICS plans to make code available for the header compression implementation. ------------ Tunneling / Alex Conta New draft which includes changes agreed at previous meeting. Also added new section which discusses the dangers of recursive encapsulation. Other clarifications of document. Risk factors in Recursive encapsulation Type of tunnel Type of route to exit point: Type of Tunnel Inner tunnel with identical exit points, can be Fixed-exit pints (different entry points) Free-Exit inner tunnels (different entry points) Type of Route Route to a specific destination node / minimum risk Route to a specific prefix-net / min risk Route to an unspecified destination / Default route Default tunnel / Max risk! Discussion about necessity of need for tunnels in tunnels with same exit point. Desire to show some evidence in practice that there is a real problem to be solved. [Editor's note: cisco systems has similar mechanism in their proprietary tunneling protocol. It would be useful to find out how effective/necessary it has been.] Suggestion to include mechanism once in a while (one out of n packets). Group agreed to continue discussion on mailing list. ------------------ Proposal to Reorder Addresses in IPv6 Header / Mike Carlton Might be performance gain when forwarding packets if destination address is before source address. Presented example of how it affects cache in generic machine. Must check next header, hop limit, flow label. Write new hop limit. Validate source address. Use destination or flow label to search route cache. Upper part of source to determine address type Upper part or all of source to route multicast packets. Reordering will improve cache performance. Assumes FP is no more than 10 bits. Cache miss to 10-50 or more processor cycles. Long involved discussion. After long discussion, a straw poll was taken and the working group decided to leave the header order the way it was. This decision was reopened at the end of the session. After another long discussion the group could not make a decision and directed the working group chairs to discuss the issue and make a decision. That was done and the text of the message to the working group documenting this is included here: To: ipng@sunroof.Eng.Sun.COM Cc: hinden@ipsilon.com, deering@parc.xerox.com Subject: (IPng 1539) order of addresses in IPv6 header Date: Mon, 11 Mar 1996 18:39:33 PST From: Steve Deering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Background: If you attended Wednesday's ipngwg meeting in LA, or if you listened to it over the MBone, you will know that we had a lively discussion about possibly swapping the order of the Source Address and Destination Address fields in the IPv6 header. Several folks argued that changing the address order would allow for faster software forwarding of IPv6 packets in particular implementations (e.g., for particular cache line sizes), and for those implementations where it didn't help, it also didn't hurt to change the order. The potential (but unproven) performance benefit had to be weighed against the less tangible costs of making such a fundamental change at this late state in the process, such as confusion in the implementor community, further delay in progressing the specs, and possible negative "PR" consequences. A poll of the meeting attendees showed no strong consensus one way or the other, but a modest majority were in favor of leaving the order as is. So in my role as chair of the meeting (and co-chair of the WG), I made a snap "ruling" to leave the address order as is. After doing so, I had serious second thoughts. I concluded that I had let non-technical concerns override my best technical judgement (given the information at hand, admittedly incomplete), and that that was inappropriate for the IETF. So at the end of the WG meeting, I said I wanted to change my "ruling" and swap the two address fields. Then things got really animated, and much more vigorous arguments were made for leaving the address order as is. Finally, I conducted another poll, and this time the number in favor and the number opposed to swapping the address were approximately equal (!), with many abstentions. In the face of this clear lack of consensus, the two co-chairs were delegated to make a decision and announce it to the mailing list. Decision by Deering and Hinden: *** The order of the addresses in the IPv6 header stays as is. *** *** That is, source address first, destination address second. *** Rationale: (1) Swapping the addresses would not be "harmless", performance-wise, in all circumstances, contrary to what I claimed in the meeting. As Tracy Mallory pointed out, for packets with non-zero flow labels, moving the source address after the destination address would force the router to look further into the header than would otherwise be necessary. Thus, on those architectures that benefit from not having to read the whole header, flow-based traffic would be penalized by a change of address order. (2) As Christian Huitema pointed out, necessary improvements in congestion handling for non-flow-based traffic, such as fair queueing or a statistical approximation of fair queueing, are likely to require examination of the full source address of every forwarded packet anyway, in which case moving the source address to the end buys nothing, and defeats the possible gain described in the next point... (3) Assuming adoption of the proposed unicast addressing plan in which the low-order 64-bits of an IPv6 unicast address are used only for intra-site purposes, all inter-site forwarding can be done without looking at the last 64 bits of the destination address. Thus if we leave the address order as-is, we can still exploit the benefit of not fetching the trailing 64 bits of the header for inter-site routing, where the highest throughputs are going to be needed. Note: Mike Carlton, who initiated the discussion of swapping the addresses in his presentation on cache effects on IPv6 header processing, agrees with this analysis and has withdrawn his request to change the address order. -------- Unique Interface ID's / KRE Proposal to change link link layer address to: +--------+------+----------------------+-----------------+ | Prefix | IID | anything | Interface Token | +--------+------+----------------------+-----------------+ |----32 bits----| "IID" is long term constant identifier of the interface, unique within the node. Notes: Optional: Nodes not required to use these fields. For Non-Participants Minor change to ND discovery procedures For Participants Generate modified LL-ADDR Modified DAD Need to be able to detect DAD from another local interface (same node) Modify Draft DAD NS Reply (NA) There was a general concensus to pursue this proposal. ========================================================================= ========================================================================= --============_-1381244466==_============-- ------------------------------------------------------------------------------ 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 Apr 30 09:03:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06449; Tue, 30 Apr 96 09:03:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06443; Tue, 30 Apr 96 09:03:45 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14666; Tue, 30 Apr 1996 09:01:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA24723; Tue, 30 Apr 1996 09:00:49 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id MAA05458; Tue, 30 Apr 1996 12:00:38 -0400 Date: Tue, 30 Apr 1996 12:00:38 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9604301200.ZM5456@seawind.bellcore.com> In-Reply-To: "Thomas Narten" "(IPng 1689) Re: bsd-api-05 questions" (Apr 29, 6:03pm) References: <9604292203.AA19233@cichlid.raleigh.ibm.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: "Thomas Narten" Subject: (IPng 1696) Re: bsd-api-05 questions 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 On Apr 29, 6:03pm, Thomas Narten wrote: > Yuck. Note that after the above the Flow Label is not even > right-justified. Is this what we really want? Are we assuming that > the system call that generates Flow Labels will return them in a > non-right justified format? Or that the programmer will remember to do > some bit shifting? A flow label is a random number. When making up the number, it is sufficient to do something like: my_flow = (random()&FLOW_MASK)|PRIORITY_XX|VERSION_6 were the FLOW_MASK and PRIORITY_XX constant definitions take care of the local indianness. No shift, no byte reversal. Why make it any more complex than necessary ? -- 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 Tue Apr 30 09:22:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06468; Tue, 30 Apr 96 09:22:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06462; Tue, 30 Apr 96 09:22:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18008; Tue, 30 Apr 1996 09:19:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA01957; Tue, 30 Apr 1996 09:19:23 -0700 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA21127; Tue, 30 Apr 1996 12:09:14 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03394; Tue, 30 Apr 1996 12:09:12 -0400 Message-Id: <9604301609.AA03394@fwasted.zk3.dec.com> To: "Thomas Narten" Cc: bound@zk3.dec.com, Richard Stevens , Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1697) Re: bsd-api-05 questions In-Reply-To: Your message of "Tue, 30 Apr 96 08:26:15 -0300." <9604301226.AA20468@cichlid.raleigh.ibm.com> Date: Tue, 30 Apr 96 12:09:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>The flow label is not justified its just a mask of bits. The AND >>operator just masks the priority values to zero so all your left with >>for the flow are the bits that are on. This is the style and convention >>of most systems and we worked hard to not change the style as our >>strategy for the programmer that programs apps today via sockets on UNIX >>type systems. > >This is OK if the value you are extracting is a single bit and you >just want to know if the bit is cleared or set. But if the value is a >multi-bit field, you need to treat the bits as a unit, and you want >the data structures to allow easy access to the unit. If I understand >the current spec, if I want to set the flowid and priority for a >socket, I'd have to do something like: > flow = syscall_to_give_me_a_flow_id(); > sin6.sin6_flowinfo = 0; /* clear all the bits */ > sin6.sin6_flowinfo |= (flow << BITS_TO_SHIFT); /* set just the flow label */ > sin6.sin6_flowinfo |= IPV6_PRIORITY_INTERACTIVE; Yep. >From a programming perspective, I think it's a lot cleaner to have >separate fields that can be access independent of each other. As >defined now, if you want to set one field (e.g. Flow Label) you have >to be careful not to clobber the bits you shouldn't be changing (e.g., >Priority) whenever doing an assingment. An impossible task? Of course >not. But I think having separate fields is more convenient and less >error-prone. Well less error prone is subjective and not concrete at all. Another view is the way we have it specified now does not require the programmer to have to keep tack of yet another structure and they should be competent to use bit shifting to reduce the use of structures which is one of the benefits of working with the C programming language who want to maintain the "efficiency style" of assembly language. I agree that for the Jr. Programmer or one who does not write a lot of code (or never has) then using structure.field is more understandable, but its my impression that that type of programmer does not have precedence over the more experienced as we define the style. I will consult with Bob offline and bring your point up as we review the next version of the spec. >>Your free to implement the style you want but its not as efficient >>adding the overhead of structures to the code in my opinion. >Efficiency is not a factor in my comments. The kinds of overhead we're >talking about here are insignificant in the overall scheme of things. I don't agree. Anywhere I can avoid clutter here and an extra packet here or there is always a win. Removing clutter over the years reduces maintainence. The way its defined now is less lines of code in the include file and for the structure sockaddr. The more we put in the more it is for some engineering manager to maintain tomorrow. C permits this tight coding style and it is a benefit of the language. The spec uses this benefit. >>This is an >>old argument and not a major issue but a style issue. > >IMO, style issues are important, especially when when we are talking >about APIs. I agree and existing practice style has precedence over any new styles suggested unless an order of magnitude of gain is obtained. >>Technically >>there is no gain from what you propose and the justification is not an >>issue. >Is reduced likelyhood of programming errors not technical? I don't believe it will reduce programming errors. If an engineer does not know how to use bit shift operators in C correctly and will create errors I don't want them on my development team. I think its an engineering issue for sure, I just don't find your argument real strong. So its fair you bring it up. But, nothing in the draft in this space is technically broken or will not work. >>Also what you propose makes building macros more difficult. >Can you please be more specific? Adding nested structures to a structure without good reasons causes another level of indirection and #defines to use the field in a macro. Macros are already abused and difficult to read/maintain. Adding a structure to the flowinfo structure member just complicates using it and I don't agree with your assumptions on the gain from programmer errors being increased. The proof is that we have over 15 implementations today that interoperate and no implementor has complained at all about the style and we have all implemented it fine. Again I don't find this to be a show stopper and I don't see the point of this being implemented in yet another manner for the potential that it will reduce programming errors. >> These are two >>different concepts. We can make this clearer but I do not consider this >>to be a big issue ---> show stopper. > >My concern is that as currently written, the first 8 priority values >have nice sounding names that programmers can identify with (e.g, >IPV6_PRIORITY_INTERACTIVE), but the last 8 values are just numbers, >and that there is not distinction (in name) between the first 8 and >last 8 priorities. I suspect that naive programmers (i.e., the masses) >will pick the ones based on name. We'll have fewer errors if its more >clear which priorities go with which type of traffic. I just looked at my in.h and I agree it is confusing. I will discuss with Bob and suggest we fix this. >>>Regarding inet_ntop() and inet_pton(), the spec doesn't say whether or >>>not the address pointer "void *ap" needs to be aligned on any >>>particular boundary (e.g., 64 bit). The spec should probably say >>>something about this. > >>There is no boundary issue its just a pointer to a buffer that holds the >>address. Its an address determined by the size of your registers >>pointing to a buffer. I think this to be common knowledge. >The spec makes it clear in various places that IPv6 addresses are >aligned on 64 bit boundaries for efficiency reasons. Your response >seems to be telling me that if the IPv6 address passed to inet* is not >on a 64-bit boundary, your library routine won't dump core. Did I get >this right? What we make clear is that we tried to align the sockaddr structure on 64bits as we did the IPv6 Header fields and options. Your point is a different issue. The pointer *ap is just a location of the buffer and held in a register. Like this on an assumed 64bit machine where registers hold 64bit pointers: LA R2,buffer (place to put the address for the app) TRT R3,convrtn (conversion from n to p macro) MOV R2,R3+128 (move the address to the buffer for the app) So whether R2 or the buffer is aligned on a 64bit boundary is not relative. At the point where you move the data to R2 pointing to buffer as long as the displacement is 128 and not greater core will not be dumped and then only if you step on some privliged address space or until another part of the stack tries to use the over written memory location past 128. If R2 was null that would dump core too of course. This would work if R2 were a 16, 32, or 128 bit registers as thats just a function of the size of the pointer, but the buffer must be 128 bits. So there is no boundary alignment issue. >>>>Inet_pton() returns the length of the address in octets if the >>>>conversion succeeds, and -1 otherwise. The function does not modify >>>>the buffer pointed to by ap if the conversion fails. > >>>Is there any particular reason why the function doesn't modify the >>>buffer if the function fails? Is this just a backwards compatability >>>thing? Since this is a *NEW* function being defined, what are we being >>>compatable with? > >>The last step in the library routine would be to load the buffer why do >>that if the conversion fails? Other than that there is no reason to >>save the buffer it simply should not be destroyed. >Your response is telling me that I can't do the coversion in place. I >have to use a temporary variable and then copy the result after I'm >done. Not a big deal, but I'm somewhat surprised that such a >requirement is spelled out in this spec. Me too its not necessary I missed this and will consult with Bob. Even if the variable is dynamically allocated before or after the conversion it still does not matter. There might be some history here I have forgotten and I want to check OK. But I think that clarifying sentence should be removed now. 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 Apr 30 09:39:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06524; Tue, 30 Apr 96 09:39:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06518; Tue, 30 Apr 96 09:39:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21670; Tue, 30 Apr 1996 09:36:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA08954; Tue, 30 Apr 1996 09:36:30 -0700 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA19987; Tue, 30 Apr 1996 12:29:44 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06412; Tue, 30 Apr 1996 12:29:42 -0400 Message-Id: <9604301629.AA06412@fwasted.zk3.dec.com> To: iialan@iifeak.swan.ac.uk (Alan Cox) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1698) Re: bsd-api-05 questions In-Reply-To: Your message of "Tue, 30 Apr 96 16:54:09 BST." Date: Tue, 30 Apr 96 12:29:42 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> flow = syscall_to_give_me_a_flow_id(); >> sin6.sin6_flowinfo = 0; /* clear all the bits */ >> sin6.sin6_flowinfo |= (flow << BITS_TO_SHIFT); /* set just the flow label */ >> sin6.sin6_flowinfo |= IPV6_PRIORITY_INTERACTIVE; >What assumptions about endianism do we make with "give me a flow id" ? sin6.sin6_flowinfo is in network byte order so big endian. /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 Apr 30 10:06:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06669; Tue, 30 Apr 96 10:06:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06658; Tue, 30 Apr 96 10:06:33 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26557; Tue, 30 Apr 1996 10:03:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA19970; Tue, 30 Apr 1996 10:03:51 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2046; Tue, 30 Apr 96 13:02:50 EDT Received: by RTP (XAGENTA 4.0) id 0598; Tue, 30 Apr 1996 12:11:50 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20628; Tue, 30 Apr 1996 12:11:25 -0400 Message-Id: <9604301611.AA20628@cichlid.raleigh.ibm.com> To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1699) Re: bsd-api-05 questions In-Reply-To: Your message of "Tue, 30 Apr 1996 12:00:38 EDT." <9604301200.ZM5456@seawind.bellcore.com> Date: Tue, 30 Apr 1996 12:11:24 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk huitema@bellcore.com (Christian Huitema) writes: >A flow label is a random number. When making up the number, it is >sufficient to do something like: > my_flow = (random()&FLOW_MASK)|PRIORITY_XX|VERSION_6 Are things really this simple?. Two processes, both on the same machine, both talking to the same destination machine, shouldn't pick the same Flow Labels by accident. Having applications select their own random numbers doesn't prevent collisions. 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