From owner-ipng@sunroof.eng.sun.com Tue Nov 4 08:48:56 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA02774 for ipng-dist; Tue, 4 Nov 1997 08:45:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA02767 for ; Tue, 4 Nov 1997 08:45:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA22608 for ; Tue, 4 Nov 1997 08:45:35 -0800 Received: from santacruz.org (santacruz.org [207.86.120.165]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA07829 for ; Tue, 4 Nov 1997 08:45:21 -0800 (PST) Received: from localhost (jest@localhost) by santacruz.org (8.8.7/8.8.5) with SMTP id IAA28463 for ; Tue, 4 Nov 1997 08:51:30 -0800 Date: Tue, 4 Nov 1997 08:51:29 -0800 (PST) From: Gregory Taylor To: ipng@sunroof.eng.sun.com Subject: (IPng 4745) Serious problem regarding ip_fragment.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk I have been notified of a serious security hole regarding the ip_fragment.c code on the IPv4 platform... apparently, when exploited, it turns your screen white and causes you to reboot, I am currently in the process of trying to find this bug and post it on bugtraq.. but the biggest problem with this is that it works on ALL UNIX platforms.. not just linux and it could be a real pain to fix, any information on this could be very helpful. Also, if you have found a fix, or do know about this security hole, will it or has it been already patched in the IPv6 platform? Thank You, Gregory Taylor Owner Resourceful Network Solutions, Inc. (253) 475-1227 jest@santacruz.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 5 07:20:43 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA04125 for ipng-dist; Wed, 5 Nov 1997 07:17:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA04118 for ; Wed, 5 Nov 1997 07:17:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA12054 for ; Wed, 5 Nov 1997 07:17:25 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA14830 for ; Wed, 5 Nov 1997 07:16:57 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA27583; Wed, 5 Nov 1997 10:16:51 -0500 (EST) Message-Id: <199711051516.KAA27583@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4746) I-D ACTION:draft-ietf-ipngwg-addr-arch-v2-04.txt Date: Wed, 05 Nov 1997 10:16:50 -0500 Sender: owner-ipng@eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-04.txt Pages : 25 Date : 04-Nov-97 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v2-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971104145811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v2-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971104145811.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 5 08:40:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA04201 for ipng-dist; Wed, 5 Nov 1997 08:37:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA04194 for ; Wed, 5 Nov 1997 08:37:15 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA07140 for ; Wed, 5 Nov 1997 08:37:12 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA22224 for ; Wed, 5 Nov 1997 08:37:04 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id LAA23624; Wed, 5 Nov 1997 11:34:22 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA22918; Wed, 5 Nov 1997 11:34:23 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18566; Wed, 5 Nov 1997 11:34:19 -0500 Message-Id: <9711051634.AA18566@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4747) Re: Addr Conf Denial of Service and Interact with DHCPv6 In-Reply-To: Your message of "Wed, 24 Sep 1997 07:47:14 EDT." <9709241147.AA25441@wasted.zk3.dec.com> Date: Wed, 05 Nov 1997 11:34:19 -0500 From: Thomas Narten Sender: owner-ipng@eng.sun.com Precedence: bulk Jim, > Several issues and things to be resolved. > >5.5.3. Router Advertisement Processing > > On receipt of a valid Router Advertisement (as defined in > > [DISCOVERY]), a host copies the value of the advertisement's M bit > > into ManagedFlag. If the value of ManagedFlag changes from FALSE to > > TRUE, the host should invoke the stateful address autoconfiguration > > protocol, requesting address information. If the value of the > > ManagedFlag changes from TRUE to FALSE, the host should terminate the > > stateful address autoconfiguration protocol (i.e., stop requesting > > addresses and ignore subsequent responses to in-progress > > transactions). If the value of the flag stays unchanged, no special > > action takes place. In particular, a host MUST NOT reinvoke stateful > > address configuration if it is already participating in the stateful > > protocol as a result of an earlier advertisement. > I think we need words above that permit DHCPv6 to continue running if it > is being used for Dyanmic Updates to DNS (DDNS) via a DHCPv6 server. So > I object to the words that say "terminate" the stateful protocol. > I propose the following: > .................. If the value of the ManagedFlag changes from > TRUE to FALSE, the host MUST terminate the use of the stateful > address autoconfiguration protocol as a mechanism to obtain new > addresses or update existing address lifetimes. What should be done if RAs tell you not to use DHCP, but the DHCP server is sending you packets anyway? DHCP has a Reconfigure message, for instance. Is that to be ignored as well? How about something like: If the value of the ManagedFlag changes from TRUE to FALSE, the host MUST NOT initiate any new address-related actions through stateful autoconfiguration (including extending the lease of an address whose Lifetime is expiring). The host SHOULD complete any in-progress transactions and SHOULD respond to messages it receives through the stateless autoconfiguration protocol. A host MAY also return addresses, but may not request new ones. A couple of random thoughts: SHOULD/MUST language may not be quite right above, but the language *needs* to be very precise. There shouldn't be ambiguity in what a client does when it gets conflicting info from RAs or DHCP. I.e., it would be best of client behavior was always predictable. Also, would it make sense or be useful to add a message to DHCP so that the client can tell the server "I'm not suppposed to be using DHCP according to the managed bit", in which case the server can do something intelligent (like not retransmitting messages to it)? > If addr conf changes a stateless address the node still can use DHCPv6 > for example to update the DNS, so we don't want to say kill the stateful > protocol which MAY serve multiple purposes. Hmm. So you are saying clients may use DHCP to update the DNS rather than updating the DNS directly? And such a use of DHCP does not violate RAs telling you not to use DHCP? Allowing this sort of use of DHCP is going to lead to a lot of gray areas where its not entirely clear whether DHCP should be used, what features of DHCP should be used, etc. > Also if an address from > stateful valid-life becomes zero via addr conf, in the case of DHCPv6 I > would think we would want a DHCPv6 RELEASE to be sent to the DHCPv6 server > as one example, rather than the default to time out at the server as an > implementation choice. I think customers will want this done in an > orderly manner. In the above scenario, the system administrator has misconfigured things. I.e., RAs and DHCP sending out conflicting information about how to handle a specific address. I don't know that we should add more complexity to the client to try an "help" the server in such situations. There are likely lots of ways that a misconfiguration can cause things to end up in an undesirable state. Let's be careful about making the protocol more complex in attempting to cover these cases. > > An advertisement's O flag field is processed in an analogous manner. > > A host copies the value of the O flag into OtherConfigFlag. If the > > value of OtherConfigFlag changes from FALSE to TRUE, the host should > > invoke the stateful autoconfiguration protocol, requesting > > information (excluding addresses). If the value of the > > OtherConfigFlag changes from TRUE to FALSE, any activity related to > > stateful autoconfiguration for parameters other than addresses should > > be halted. If the value of the flag stays unchanged, no special > > action takes place. In particular, a host MUST NOT reinvoke stateful > > configuration if it is already participating in the stateful protocol > > as a result of an earlier advertisement. > This is a problem too. If the "M" flag is set it should imply the > client can accept OTHER configuration information as part of the DHCPv6 > exts specification. Like DNS processing or the POSIX TIMEZONE variable. > I propose the following: Does it really make sense to even have two separate flags (i.e., M and O)? These two flags were specified a long time back. Now that DHCP is actually being defined, I think it makes sense to ask whether two flags are really appropriate. For example, the server can easily control whether it hands out addresses or not just by not handing them out. It would simplify the client if it just used DHCP to get whatever parameters it thinks it needs, without having to distinguish between the two types of information. I don't recall the discussion/rational that lead to the definition of two flags. Is there still a compelling need for two flags? > ..... If the value of the OtherConfigFlag changes from TRUE to FALSE > any activity related to stateful autoconfiguration for paramters that > would alter the value of the link as defined in this specification > or Neighbor Discovery [ND-REF] MUST be halted. I'm not sure what "alter the value of the link" means in terms of specific DHCP options. What is the "value of a link"? > I think we need also to make it clear in this spec that: > 1. M bit means you don't get to receive link parameters like from > DHCPv6. I don't understand what you are asking here. My understanding is that if the M bit is *set*, a client is supposed to ask for address extensions. Is that not clear? Is that not what you think the behavior is (or should be)? > 2. O bit must be set for a node to get link parameters like from > DHCPv6. You mean both the M and O bit need to be set? Re: 0 Lifetime denial of service issue. I'll followup on this thread in another message. > > In those cases where a site requires the use of longer prefixes > > than can be accommodated by the interface identifier, stateful | > > autoconfiguration can be used. | > I think this should not be stated now per the new Addr Arch spec and use > of TLAs, SLAs, etc. and IPv6 over FOO using EUI 64. All prefixes should > not be greater than 64bits and should be the left most 64bits of an IPv6 > address. So I suggest we just delete the above from the text. > This will apply to both addr conf and stateful. I agree that the wording should be taken out. A larger question is whether there is consensus that we should definitively state that routing prefixes cannot be longer than 64 bits. IMO, such a statement shouldn't go in the ND/addrconf documents, but perhaps into the addressing architecture document, if it needs to be stated at all. > >5.6. Configuration Consistency > > It is possible for hosts to obtain address information using both > > stateless and stateful protocols since both may be enabled at the > > same time. It is also possible that the values of other > > configuration parameters such as MTU size and hop limit will be > > learned from both Router Advertisements and the stateful > > autoconfiguration protocol. If the same configuration information is > > provided by multiple sources, the value of this information should be > > information received from multiple sources is inconsistent. Hosts > > accept the union of all information received via the stateless and > > stateful protocols. If inconsistent information is learned from > > different sources, the most recently obtained values always have > > precedence over information learned earlier. > There is an issue here for addresses and lifetimes. If stateless and > stateful are in synch through system administration they could be using > the same prefixes. If stateful is in process and addresses are assigned > to the interface with lifetimes like: > 4c6e::12 valid=2 days preferred=1 day > Then addr conf says use stateless and: > 4c6e::12 valid=1 day preferred= 5 hours > We have an inconsistecy at the stateful server and I think we should > RELEASE the address when this happens via DHCPv6 from the client > node. IMO, we should keep things simple and not try to have clients straighten out misconfigurations. Case in point. Suppose the client does RELEASE the address. The RA M bit is saying use DHCP. But when will the client invoke DHCP again to request a new address? Since it RELEASED the address it had gotten, it won't do so when the lease expires (I'm assuming). So if the DHCP server is then configured to hand out different addresses, its not clear to me that the client will ever get the new addresses. There are lots of odd cases like this that will crop up when there are misconfigurations. I see it as mostly a lost cause to try to make sense of them. Do something simple and predictable. > But the words in addr conf in 5.5.3 do not permit me to send this > message. I don't see how 5.5.3 prohibits you from doing this. It only does so in the case where the M bit is off. Right? > Suggestion: > I think the fix is to permit releasing of addresses when a Router > Advertisement shuts off stateful (M-bit clear), and an address or > lifetime is altered via stateless that was last created or updated via > Stateful mechanisms. I'd be much more in favor of a MUST than a MAY above. You really want all clients to behave in a consistent manner. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 5 09:23:22 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA04250 for ipng-dist; Wed, 5 Nov 1997 09:20:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA04243 for ; Wed, 5 Nov 1997 09:20:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA19466 for ; Wed, 5 Nov 1997 09:19:59 -0800 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA12941 for ; Wed, 5 Nov 1997 09:17:24 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id MAA28640; Wed, 5 Nov 1997 12:17:19 -0500 Received: from sonoma.watson.ibm.com (sonoma.watson.ibm.com [9.2.24.94]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id MAA25104; Wed, 5 Nov 1997 12:17:18 -0500 Received: by sonoma.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA22968; Wed, 5 Nov 1997 12:17:14 -0500 Message-Id: <9711051717.AA22968@sonoma.watson.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: dina katabi Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4748) Anycast Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 05 Nov 1997 12:17:13 -0500 From: Vinod Peris Sender: owner-ipng@eng.sun.com Precedence: bulk Dina Katabi writes: > I am looking for detailed information about Anycast (Address > allocation, routing, possible applications ..) You can check out the following paper "Using Network Layer Anycast for Load Distribution on the Internet" by Basturk, et.al. You can obtain it from the following URL http://www.watson.ibm.com:8080/main-cgi-bin/search_paper.pl/entry_ids=8742 The paper looks at how the IP anycast service can be exploited by hosts connected to the Internet without significantly impacting the routing and protocol processing already in place. As a specific example it considers the use of anycast communication to distribute load among a set of mirror web sites. Hope this helps, --Vinod Peris -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 5 09:51:36 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA04302 for ipng-dist; Wed, 5 Nov 1997 09:48:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA04295 for ; Wed, 5 Nov 1997 09:48:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA28385 for ; Wed, 5 Nov 1997 09:47:54 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA27202 for ; Wed, 5 Nov 1997 09:46:41 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA12433; Wed, 5 Nov 1997 09:45:15 -0800 Message-Id: <3.0.3.32.19971105094455.0092dd00@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 05 Nov 1997 09:44:55 -0800 To: Jeffrey Burgan From: Bob Hinden Subject: (IPng 4749) Request to Advance IPv6 Addressing Documents Cc: narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following documents be published as indicated. The following document should be advanced to Proposed Standard: Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-04.txt Pages : 25 Date : 04-Nov-97 This document replaces RFC 1884 "IP Version 6 Addressing Architecture", that should become historic. The following document should be advanced to Proposed Standard: Title : An IPv6 Aggregatable Global Unicast Address Format Author(s) : R. Hinden, M. O'Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-02.txt Pages : 9 Date : 07/16/1997 This document replaces RFC 2073 "An IPv6 Provider-Based Unicast Address Format", that should become historic. The following document is to be advanced to Experimental: Title : IPv6 Testing Address Allocation Author(s) : R. Hinden, R. Fink, J. Postel Filename : draft-ietf-ipngwg-testv2-addralloc-01.txt Pages : 4 Date : 07/16/1997 This document replaces RFC 1897 "IPv6 Testing Address Allocation", that should become historic. The following document is to be advanced to Informational: Title : IPv6 Multicast Address Assignments Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-multicast-assgn-04.txt Pages : 8 Date : 07/16/1997 A working group last call for these documents was completed on August 13, 1997 and these documents were discussed at the Munich IETF IPng sessions. These drafts incorporates changes based on comments received during the w.g. last call and w.g. sessions. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 5 14:43:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA04655 for ipng-dist; Wed, 5 Nov 1997 14:39:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA04648 for ; Wed, 5 Nov 1997 14:39:22 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA07356 for ; Wed, 5 Nov 1997 14:39:16 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA26165 for ; Wed, 5 Nov 1997 14:39:11 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id QAA28271; Wed, 5 Nov 1997 16:31:29 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA29946; Wed, 5 Nov 1997 16:31:23 -0500 Message-Id: <9711052131.AA29946@wasted.zk3.dec.com> To: Thomas Narten Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4750) Re: Addr Conf Denial of Service and Interact with DHCPv6 In-Reply-To: Your message of "Wed, 05 Nov 1997 11:34:19 CDT." <9711051634.AA18566@cichlid.raleigh.ibm.com> Date: Wed, 05 Nov 1997 16:31:22 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Thomas, > >5.5.3. Router Advertisement Processing >> I propose the following: > >> .................. If the value of the ManagedFlag changes from >> TRUE to FALSE, the host MUST terminate the use of the stateful >> address autoconfiguration protocol as a mechanism to obtain new >> addresses or update existing address lifetimes. >What should be done if RAs tell you not to use DHCP, but the DHCP >server is sending you packets anyway? DHCP has a Reconfigure message, >for instance. Is that to be ignored as well? The only message you can get without causing it in DHCPv6 is the Reconfigure message to make this very clear. I think the client should "silently discard the packet". >How about something like: >If the value of the ManagedFlag changes from TRUE to FALSE, the host >MUST NOT initiate any new address-related actions through stateful >autoconfiguration (including extending the lease of an address whose >Lifetime is expiring). The host SHOULD complete any in-progress >transactions and SHOULD respond to messages it receives through the >stateless autoconfiguration protocol. A host MAY also return >addresses, but may not request new ones. This sounds good but the last part of the second sentence don't you mean "stateful autoconfiguration protocol"? >A couple of random thoughts: OK... >SHOULD/MUST language may not be quite right above, but the language >*needs* to be very precise. There shouldn't be ambiguity in what a >client does when it gets conflicting info from RAs or DHCP. I.e., it >would be best of client behavior was always predictable. I agree. >Also, would it make sense or be useful to add a message to DHCP so >that the client can tell the server "I'm not suppposed to be using >DHCP according to the managed bit", in which case the server can do >something intelligent (like not retransmitting messages to it)? Hmmm. Let me discuss this with my co-author OK. I can see the benefit maybe. I am not sure we want to stop retrasmission becuase it could be an update to the TCP KEEPALIVE parameter and we want that to happen and it has nothing to do with addresses. This was a key point in my input, DHCP is useful for things other than addresses and lifetimes. >> If addr conf changes a stateless address the node still can use DHCPv6 >> for example to update the DNS, so we don't want to say kill the stateful >> protocol which MAY serve multiple purposes. >Hmm. So you are saying clients may use DHCP to update the DNS rather >than updating the DNS directly? And such a use of DHCP does not >violate RAs telling you not to use DHCP? Allowing this sort of use of >DHCP is going to lead to a lot of gray areas where its not entirely >clear whether DHCP should be used, what features of DHCP should be >used, etc. Yes absolutely. This was also one of the options we wanted to make sure was clear to all as co-authors of Dynamic Updates to DNS from the very beginning. A client may do it or a server on behalf of a client. o I don't see the gray areas at all except for addresses. I think its pretty black and white. Of course I am a co-author on both specs and that may be why its very clear to me. Maybe if you could point out actual gray areas you have in mind I can maybe clear them up? >> Also if an address from >> stateful valid-life becomes zero via addr conf, in the case of DHCPv6 I >> would think we would want a DHCPv6 RELEASE to be sent to the DHCPv6 server >> as one example, rather than the default to time out at the server as an >> implementation choice. I think customers will want this done in an >> orderly manner. >In the above scenario, the system administrator has misconfigured >things. I.e., RAs and DHCP sending out conflicting information about >how to handle a specific address. I don't know that we should add more >complexity to the client to try an "help" the server in such >situations. There are likely lots of ways that a misconfiguration can >cause things to end up in an undesirable state. Let's be careful about >making the protocol more complex in attempting to cover these cases. I was not suggesting we add anything in the above. My statment above (">>") was just to reinforce the key point that DHCP per se should not be terminated lets say as a host daemon, but that it should stop using DHCP for addresses once an RA says M is not set. >> This is a problem too. If the "M" flag is set it should imply the >> client can accept OTHER configuration information as part of the DHCPv6 >> exts specification. Like DNS processing or the POSIX TIMEZONE variable. >> I propose the following: >Does it really make sense to even have two separate flags (i.e., M and >O)? These two flags were specified a long time back. Now that DHCP is >actually being defined, I think it makes sense to ask whether two >flags are really appropriate. For example, the server can easily >control whether it hands out addresses or not just by not handing them >out. It would simplify the client if it just used DHCP to get whatever >parameters it thinks it needs, without having to distinguish between >the two types of information. I agree. >I don't recall the discussion/rational that lead to the definition of >two flags. Is there still a compelling need for two flags? Well I have been around since the very first taxonomy proposed by Dave Katz and Sue Thomson. At the time the rationale was that we would need "other" configuration and had not really been down the path of DHCPv6. This happened later. So I don't think we need the "Other" flag. I also think what happened was we assumed that Addr Conf would cause DHCPv6 to execute (e.g. start thread, fork(), attach process), but that is really not the case anymore. There are some implementation issues I won't go into unless folks are interested, but thats why software engineers get paid the big bucks right. I would lov to see the "O" flag go away. I think its deprecated and will do nothing but cause problems now. >> ..... If the value of the OtherConfigFlag changes from TRUE to FALSE >> any activity related to stateful autoconfiguration for paramters that >> would alter the value of the link as defined in this specification >> or Neighbor Discovery [ND-REF] MUST be halted. >I'm not sure what "alter the value of the link" means in terms of >specific DHCP options. What is the "value of a link"? Bad choice of words on my part. I was thinking of TCP KEEPALIVE, TIMEZONE, etc... But this becomes moot if we ditch the "O" flag? >> I think we need also to make it clear in this spec that: > >> 1. M bit means you don't get to receive link parameters like from >> DHCPv6. >I don't understand what you are asking here. My understanding is that >if the M bit is *set*, a client is supposed to ask for address >extensions. Is that not clear? Is that not what you think the behavior >is (or should be)? Yes that is very clear. What I was concerned about is if the M bit was set and the O bit clear and the client received other configuration data it would have to reject it cause the O bit was not set. This is why just getting rid of the O bit would reduce a lot of complexity to implement the M bit. >> 2. O bit must be set for a node to get link parameters like from >> DHCPv6. >You mean both the M and O bit need to be set? Well just the O bit could have been set to use Stateful for other configuration data that are not addressees or lifetimes. >Re: 0 Lifetime denial of service issue. I'll followup on this thread >in another message. OK... >> > In those cases where a site requires the use of longer prefixes >> > than can be accommodated by the interface identifier, stateful | >> > autoconfiguration can be used. | > >> I think this should not be stated now per the new Addr Arch spec and use >> of TLAs, SLAs, etc. and IPv6 over FOO using EUI 64. All prefixes should >> not be greater than 64bits and should be the left most 64bits of an IPv6 >> address. So I suggest we just delete the above from the text. >> This will apply to both addr conf and stateful. >I agree that the wording should be taken out. Good. >A larger question is whether there is consensus that we should >definitively state that routing prefixes cannot be longer than 64 >bits. IMO, such a statement shouldn't go in the ND/addrconf documents, >but perhaps into the addressing architecture document, if it needs to >be stated at all. I agree. >> We have an inconsistecy at the stateful server and I think we should >> RELEASE the address when this happens via DHCPv6 from the client >> node. >IMO, we should keep things simple and not try to have clients >straighten out misconfigurations. Case in point. Suppose the client >does RELEASE the address. The RA M bit is saying use DHCP. But when >will the client invoke DHCP again to request a new address? Since it >RELEASED the address it had gotten, it won't do so when the lease >expires (I'm assuming). So if the DHCP server is then configured to >hand out different addresses, its not clear to me that the client will >ever get the new addresses. There are lots of odd cases like this that >will crop up when there are misconfigurations. I see it as mostly a >lost cause to try to make sense of them. Do something simple and >predictable. I agree. But the problem is that we have two states to maintain for addresses. I think I can work around that though on second thought. >> But the words in addr conf in 5.5.3 do not permit me to send this >> message. > >I don't see how 5.5.3 prohibits you from doing this. It only does so >in the case where the M bit is off. Right? RIght. But from this mail I am now thinking what "M" implies is whether you get your addresses from stateless or stateful only. Not whether stateless or stateful are daemons or processes on nodes. If we get rid of the O bit it is even more clear. >> Suggestion: >> I think the fix is to permit releasing of addresses when a Router >> Advertisement shuts off stateful (M-bit clear), and an address or >> lifetime is altered via stateless that was last created or updated via >> Stateful mechanisms. >I'd be much more in favor of a MUST than a MAY above. You really want >all clients to behave in a consistent manner. Thats fine with me but my wording above is wrong. It should say when an RA declares use of stateless instead of stateful by clearing the M bit then the node should release its stateful addresses, but not until all existing connections using those addresses have completed. Or something of that nature. Now when M is set though it can be the client is getting addresses from both stateless and stateful. In this case do we need to consider all the situations where there is a discrepancy. But as you said this will only happen on misconfigurations. The questions is do we have any work todo as spec writers to address those scenario's? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 7 07:05:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA06586 for ipng-dist; Fri, 7 Nov 1997 07:02:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA06576 for ; Fri, 7 Nov 1997 07:02:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA01183 for ; Fri, 7 Nov 1997 07:02:06 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA01859 for ; Fri, 7 Nov 1997 07:02:04 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA06395; Fri, 7 Nov 1997 10:01:58 -0500 (EST) Message-Id: <199711071501.KAA06395@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4752) I-D ACTION:draft-ietf-ipngwg-trans-tokenring-04.txt Date: Fri, 07 Nov 1997 10:01:58 -0500 Sender: owner-ipng@eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : T. Narten, M. Crawford, S. Thomas Filename : draft-ietf-ipngwg-trans-tokenring-04.txt Pages : 10 Date : 06-Nov-97 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. 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-trans-tokenring-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-tokenring-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971106151453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-tokenring-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971106151453.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 7 17:02:56 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA07256 for ipng-dist; Fri, 7 Nov 1997 16:59:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA07249 for ; Fri, 7 Nov 1997 16:59:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA04840 for ; Fri, 7 Nov 1997 16:59:40 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA14018 for ; Fri, 7 Nov 1997 16:59:14 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA14868; Fri, 7 Nov 1997 16:59:12 -0800 Message-Id: <3.0.3.32.19971107165843.007c2140@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 07 Nov 1997 16:58:43 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4753) New "TLA and NLA Assignment Rules" draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk I just submitted a new version of the "TLA and NLA Assignment Rules" draft. The changes reflect discussion at the last IETF and comments from the IANA. Significant changes to the document include: - Added a definition of "native IPv6 service" - Require independent verification of track record providing public Internet transit service by independent third parties including examples of the latter. - Added requirement for payment of a registration fee. - Added an annual auction for a limited number of TLA's for organization that do not have a track record of providing public Internet transit service to permit new organizations a method of obtaining TLA's. Once the new draft is out, I plan to submit it to the IESG for BCP status. Bob p.s. Prior to the new draft being published it can be found at ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-tla-assignment-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 7 17:50:16 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id RAA07378 for ipng-dist; Fri, 7 Nov 1997 17:47:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id RAA07371 for ; Fri, 7 Nov 1997 17:47:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA15546 for ; Fri, 7 Nov 1997 17:47:08 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id RAA04300 for ; Fri, 7 Nov 1997 17:47:04 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA16595; Fri, 7 Nov 1997 17:46:59 -0800 Message-Id: <3.0.3.32.19971107174631.008226b0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 07 Nov 1997 17:46:31 -0800 To: Paul Ferguson From: Bob Hinden Subject: (IPng 4755) Re: New "TLA and NLA Assignment Rules" draft Cc: ipng@sunroof.eng.sun.com, kimh@internic.net, davidc@apnic.net, Daniel.Karrenberg@ripe.net In-Reply-To: <3.0.3.32.19971107202555.00837700@lint.cisco.com> References: <3.0.3.32.19971107165843.007c2140@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Paul, I suggest you read the draft and the minutes from the last IPng meeting. They will answer most of your questions. The purpose of this document is to provide procedures for the IANA and registries to allocate TLA's. The guidance from the Internet AD's was that this type of document should be a BCP. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 03:02:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id CAA08603 for ipng-dist; Mon, 10 Nov 1997 02:59:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id CAA08596 for ; Mon, 10 Nov 1997 02:59:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA18843 for ; Mon, 10 Nov 1997 02:59:48 -0800 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id CAA01773 for ; Mon, 10 Nov 1997 02:59:49 -0800 (PST) Received: from sanam.india.hp.com (sanam.india.hp.com [15.10.43.113]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id CAA07930 for ; Mon, 10 Nov 1997 02:59:44 -0800 (PST) Message-Id: <199711101059.CAA07930@palrel3.hp.com> Received: by sanam.india.hp.com (1.39.111.2/16.2) id AA117650301; Mon, 10 Nov 1997 16:41:41 +0530 From: Rajesh "Kumar." L Subject: (IPng 4757) NAT To: ipng@sunroof.eng.sun.com Date: Mon, 10 Nov 1997 16:41:41 +0530 (IST) X-Mailer: ELM [Revision: 213.1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk Hi, Is NAT a tool for IPv4 to IPv6 conversion for applications? Where can i get more information about NAT (Network Address Translator)? Thanks, Rajesh. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 08:56:57 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA08821 for ipng-dist; Mon, 10 Nov 1997 08:52:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id IAA08814 for ; Mon, 10 Nov 1997 08:52:50 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id IAA14529 for ; Mon, 10 Nov 1997 08:52:50 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13792; Mon, 10 Nov 1997 08:52:43 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id RAA07295 for ; Fri, 7 Nov 1997 17:26:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA11254 for ; Fri, 7 Nov 1997 17:26:45 -0800 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id RAA25734 for ; Fri, 7 Nov 1997 17:26:36 -0800 (PST) Received: from big-dawgs.cisco.com (herndon-dhcp-42.cisco.com [171.68.53.42]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id RAA14926; Fri, 7 Nov 1997 17:25:57 -0800 (PST) Message-Id: <3.0.3.32.19971107202555.00837700@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 07 Nov 1997 20:25:55 -0500 To: Bob Hinden From: Paul Ferguson Subject: (IPng 4758) Re: New "TLA and NLA Assignment Rules" draft Cc: ipng@sunroof.eng.sun.com, kimh@internic.net, davidc@apnic.net, Daniel.Karrenberg@ripe.net In-Reply-To: <3.0.3.32.19971107165843.007c2140@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Bob, I am a little confused. How can a concept paper be submitted as a BCP? It was my understanding that BCP's reflected reality, insofar as a BCP was simply documenting how, in practice, the majority of the Internet community executed a particular concept. Are the registries completely out-of-the-loop on IPv6 TLA and NLA assignments? Or is TLA and NLA assignments done solely by IANA? I understand that while this may be done currently by the IANA, I am a little curious as to why this could be advanced as a BCP if the IANA is not the long-term allocator. For some odd reason, there seems to be something remiss with associating a BCP with a science experiment. Apologies in advance, but I admittedly have not been following this particular issue very closely. - paul At 04:58 PM 11/7/97 -0800, Bob Hinden wrote: >I just submitted a new version of the "TLA and NLA Assignment Rules" draft. > The changes reflect discussion at the last IETF and comments from the >IANA. Significant changes to the document include: > > - Added a definition of "native IPv6 service" > - Require independent verification of track record providing public > Internet transit service by independent third parties including > examples of the latter. > - Added requirement for payment of a registration fee. > - Added an annual auction for a limited number of TLA's for organization > that do not have a track record of providing public Internet transit > service to permit new organizations a method of obtaining TLA's. > >Once the new draft is out, I plan to submit it to the IESG for BCP status. > >Bob > >p.s. Prior to the new draft being published it can be found at > > ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-tla-assignment-01.txt > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 09:06:13 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA08888 for ipng-dist; Mon, 10 Nov 1997 09:03:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA08881 for ; Mon, 10 Nov 1997 09:03:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA22915 for ; Mon, 10 Nov 1997 09:03:24 -0800 Received: from wyrsa.cs.umbc.edu (wyrsa.cs.umbc.edu [130.85.100.164]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA20035 for ; Mon, 10 Nov 1997 09:03:07 -0800 (PST) Received: from underdog.cs.umbc.edu (kodeswar@underdog.cs.umbc.edu [130.85.100.52]) by wyrsa.cs.umbc.edu (8.8.7/8.8.6) with ESMTP id MAA27274 for ; Mon, 10 Nov 1997 12:03:05 -0500 (EST) Received: (from kodeswar@localhost) by underdog.cs.umbc.edu (8.8.7/8.8.6) id MAA03666; Mon, 10 Nov 1997 12:03:03 -0500 (EST) Date: Mon, 10 Nov 1997 12:03:03 -0500 (EST) From: Sethurambalaji Kodeswaran To: ipng@sunroof.eng.sun.com Subject: (IPng 4759) Re: NAT In-Reply-To: <199711101059.CAA07930@palrel3.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Hi, I'm told that a new standard fro IP is being investigated - IPv8. Can you tell me some sites where i might be able to get some info about this Bye, Balaji. ######################################################################## K.SETHURAM BALAJI Tel # : (410) - 536 -0734 4755,Chapel Square, E-Mail: kodeswar@cs.umbc.edu Baltimore , kodeswar@gl.umbc.edu Maryland - 21227 kodeswar@mctr.umbc.edu USA. Web page: www.cs.umbc.edu/~kodeswar ALL'S WELL THAT ENDS WELL ######################################################################## -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 09:16:16 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA08914 for ipng-dist; Mon, 10 Nov 1997 09:13:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA08906 for ; Mon, 10 Nov 1997 09:13:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA26396 for ; Mon, 10 Nov 1997 09:12:54 -0800 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA25351 for ; Mon, 10 Nov 1997 09:12:35 -0800 (PST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA16759; Mon, 10 Nov 1997 09:08:03 -0800 (PST) Received: from minnesota.livingston.com (minnesota.livingston.com [149.198.32.23]) by server.livingston.com (8.8.5/8.6.9) with SMTP id JAA00210; Mon, 10 Nov 1997 09:12:06 -0800 (PST) From: Pyda Srisuresh Message-Id: <199711101712.JAA00210@server.livingston.com> Subject: (IPng 4760) Re: NAT To: rajeshk@india.hp.com (Rajesh "Kumar." L) Date: Mon, 10 Nov 1997 09:14:27 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199711101059.CAA07930@palrel3.hp.com> from "Rajesh "Kumar." L" at Nov 10, 97 04:41:41 pm Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk > > > Hi, > > Is NAT a tool for IPv4 to IPv6 conversion for applications? > Where can i get more information about NAT (Network Address Translator)? > > Thanks, > Rajesh. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > NAT is used in V4 context only and NOT for V4 to V6 conversions. Check the draft for more info. Also, you may check the following URL for NAT-BOF meeting minutes at Munich IETF. http://www.livingston/Tech/IETF/nat cheers, suresh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 09:20:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA08952 for ipng-dist; Mon, 10 Nov 1997 09:16:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA08945 for ; Mon, 10 Nov 1997 09:16:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA27678 for ; Mon, 10 Nov 1997 09:16:32 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA27493 for ; Mon, 10 Nov 1997 09:16:23 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id MAA22210; Mon, 10 Nov 1997 12:16:07 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.12) id MAA03854; Mon, 10 Nov 1997 12:16:06 -0500 Date: Mon, 10 Nov 1997 12:16:06 -0500 From: huitema@bellcore.com (Christian Huitema) Message-Id: <971110121606.ZM3852@seawind.bellcore.com> In-Reply-To: Sethurambalaji Kodeswaran "(IPng 4759) Re: NAT" (Nov 10, 12:03pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Sethurambalaji Kodeswaran , ipng@sunroof.eng.sun.com Subject: (IPng 4761) Re: NAT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@eng.sun.com Precedence: bulk On Nov 10, 12:03pm, Sethurambalaji Kodeswaran wrote: > Subject: (IPng 4759) Re: NAT > Hi, > > I'm told that a new standard fro IP is being investigated - IPv8. Sure. Someone else is also probably out there investigating IPv9, IPvA, and many more. But if you refer to standards, there are only two -- IPv4, which we know and love, and IPv6, which we are busy adopting. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 09:25:54 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA08965 for ipng-dist; Mon, 10 Nov 1997 09:19:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA08958 for ; Mon, 10 Nov 1997 09:19:22 -0800 (PST) From: bmanning@ISI.EDU Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA28619 for ; Mon, 10 Nov 1997 09:19:05 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA29158 for ; Mon, 10 Nov 1997 09:18:55 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA14523; Mon, 10 Nov 1997 09:18:53 -0800 (PST) Posted-Date: Mon, 10 Nov 1997 09:18:14 -0800 (PST) Message-Id: <199711101718.AA02775@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Mon, 10 Nov 1997 09:18:14 -0800 Subject: (IPng 4762) Re: NAT To: kodeswar@cs.umbc.edu (Sethurambalaji Kodeswaran) Date: Mon, 10 Nov 1997 09:18:14 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Sethurambalaji Kodeswaran" at Nov 10, 97 12:03:03 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk > > Hi, > > I'm told that a new standard fro IP is being investigated - IPv8. > > Can you tell me some sites where i might be able to get some info about this > > Bye, > Balaji. > > ######################################################################## > K.SETHURAM BALAJI Tel # : (410) - 536 -0734 > 4755,Chapel Square, E-Mail: kodeswar@cs.umbc.edu > Baltimore , kodeswar@gl.umbc.edu > Maryland - 21227 kodeswar@mctr.umbc.edu > USA. Web page: www.cs.umbc.edu/~kodeswar > > ALL'S WELL THAT ENDS WELL > ######################################################################## The offical IPv8 code point has been depricated and folded into IPv6. There is an indivdual who claims to have an addressing scheme which he calls IPv8. It has never been approved by the IANA as such and few, if any, have seen this persons specs. Most consider it a fly-by-night scheme by a person who does not play well with others. My personal advice. Ignore any reference to IPv8. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 09:38:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA09021 for ipng-dist; Mon, 10 Nov 1997 09:34:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA09014 for ; Mon, 10 Nov 1997 09:34:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA04250 for ; Mon, 10 Nov 1997 09:34:32 -0800 Received: from maltese.cisco.com (maltese.cisco.com [171.69.1.187]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA08260 for ; Mon, 10 Nov 1997 09:34:20 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by maltese.cisco.com (8.6.12/8.6.5) with ESMTP id JAA28816; Mon, 10 Nov 1997 09:32:40 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA16755; Mon, 10 Nov 1997 09:32:40 -0800 (PST) Date: Mon, 10 Nov 1997 09:32:40 -0800 (PST) Message-Id: <199711101732.JAA16755@pedrom-ultra.cisco.com> From: Pedro Marques To: Pyda Srisuresh Cc: rajeshk@india.hp.com (Rajesh "Kumar." L), ipng@sunroof.eng.sun.com Subject: (IPng 4763) Re: NAT In-Reply-To: <199711101712.JAA00210@server.livingston.com> References: <199711101059.CAA07930@palrel3.hp.com> <199711101712.JAA00210@server.livingston.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk >>>>> "Suresh" == Pyda Srisuresh writes: Suresh> NAT is used in V4 context only and NOT for V4 to V6 Suresh> conversions. I'm sorry Suresh, but i believe you are wrong. There is a protocol coverter between IPv6 and IPv4 which i know of and which is refered to as "IPv6 NAT". Whenever the term is used correctly or incorrectly can be open for discussion but the fact is that translating between IPv6 and IPv4 is an operation is all similiar to IPv4 NAT: maintaining mappings between addresses and tweaking the necessary bits as packets go by. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 09:47:26 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA09085 for ipng-dist; Mon, 10 Nov 1997 09:42:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA09078 for ; Mon, 10 Nov 1997 09:42:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA07277 for ; Mon, 10 Nov 1997 09:42:39 -0800 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA12980 for ; Mon, 10 Nov 1997 09:42:02 -0800 (PST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA17569; Mon, 10 Nov 1997 09:37:44 -0800 (PST) Received: from minnesota.livingston.com (minnesota.livingston.com [149.198.32.23]) by server.livingston.com (8.8.5/8.6.9) with SMTP id JAA02705; Mon, 10 Nov 1997 09:41:47 -0800 (PST) From: Pyda Srisuresh Message-Id: <199711101741.JAA02705@server.livingston.com> Subject: (IPng 4764) Re: NAT To: roque@cisco.com (Pedro Marques) Date: Mon, 10 Nov 1997 09:44:08 -0800 (PST) Cc: suresh@livingston.com, rajeshk@india.hp.com, ipng@sunroof.eng.sun.com In-Reply-To: <199711101732.JAA16755@pedrom-ultra.cisco.com> from "Pedro Marques" at Nov 10, 97 09:32:40 am Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk > > >>>>> "Suresh" == Pyda Srisuresh writes: > > Suresh> NAT is used in V4 context only and NOT for V4 to V6 > Suresh> conversions. > > I'm sorry Suresh, but i believe you are wrong. There is a protocol > coverter between IPv6 and IPv4 which i know of and which is refered to as > "IPv6 NAT". Whenever the term is used correctly or incorrectly can be > open for discussion but the fact is that translating between IPv6 and IPv4 > is an operation is all similiar to IPv4 NAT: maintaining mappings between > addresses and tweaking the necessary bits as packets go by. > > Pedro. > Fair enough. Thanks for the clarification. cheers, suresh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 09:59:10 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA09127 for ipng-dist; Mon, 10 Nov 1997 09:55:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA09120 for ; Mon, 10 Nov 1997 09:55:46 -0800 (PST) From: EDS@RHQVM21.VNET.IBM.COM Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAB12014 for ; Mon, 10 Nov 1997 09:55:42 -0800 Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA20689 for ; Mon, 10 Nov 1997 09:55:22 -0800 (PST) Message-Id: <199711101755.JAA20689@saturn.sun.com> Received: from RHQVM21 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4768; Mon, 10 Nov 97 12:55:18 EST Date: Mon, 10 Nov 97 12:51:56 EST To: ipng@sunroof.eng.sun.com Subject: (IPng 4765) Re: NAT Sender: owner-ipng@eng.sun.com Precedence: bulk > I'm told that a new standard fro IP is being investigated - IPv8. It is nowhere near as well developed as IPv6. > Can you tell me some sites where i might be able to get some info about this If you are interested in the issue, There has been some discussion over the last few days on the nanog mailing list on IPv8 and IPv6. (see www.nanog.org or http://www.merit.edu/mail.archives /html/nanog/maillist.html). The main item is a hierarchical addressing mechanism which some consider a feature, others consider it a limitation. Ed Segal EDS@RHQVM21.VNET.IBM.COM 914 784-3259 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 10:40:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA09212 for ipng-dist; Mon, 10 Nov 1997 10:38:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id KAA09205 for ; Mon, 10 Nov 1997 10:37:55 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id KAA28493 for ; Mon, 10 Nov 1997 10:37:55 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA14049; Mon, 10 Nov 1997 10:37:47 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA09192 for ; Mon, 10 Nov 1997 10:28:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA21323 for ; Mon, 10 Nov 1997 10:28:08 -0800 Received: from dilbert.is.chrysler.com (dilbert.is.chrysler.com [204.189.95.144]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA09748 for ; Mon, 10 Nov 1997 10:27:26 -0800 (PST) Received: by dilbert.is.chrysler.com; id NAA05245; Mon, 10 Nov 1997 13:27:24 -0500 (EST) Received: from rgm3.is.chrysler.com(129.9.247.160) by dilbert.is.chrysler.com via smap (3.2) id xma005242; Mon, 10 Nov 97 13:26:58 -0500 Message-Id: <3.0.3.32.19971110132424.00baabf0@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 10 Nov 1997 13:24:24 -0500 To: huitema@bellcore.com (Christian Huitema), Sethurambalaji Kodeswaran , ipng@sunroof.eng.sun.com From: Robert Moskowitz Subject: (IPng 4767) Re: NAT In-Reply-To: <971110121606.ZM3852@seawind.bellcore.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk At 12:16 PM 11/10/97 -0500, Christian Huitema wrote: > >Sure. Someone else is also probably out there investigating IPv9, IPvA, >and many more. See RFCs 1606 and 1607. Robert Moskowitz Chrysler Corporation (810) 758-8212 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 12:31:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA09402 for ipng-dist; Mon, 10 Nov 1997 12:24:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA09395 for ; Mon, 10 Nov 1997 12:24:28 -0800 (PST) From: mef@cs.washington.edu Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA29830 for ; Mon, 10 Nov 1997 12:23:46 -0800 Received: from wile-e-coyote.cs.washington.edu (wile-e-coyote.cs.washington.edu [128.95.2.83]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA15777 for ; Mon, 10 Nov 1997 12:23:36 -0800 (PST) Received: (mef@localhost) by wile-e-coyote.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA21914; Mon, 10 Nov 1997 12:23:34 -0800 (PST) Date: Mon, 10 Nov 1997 12:23:34 -0800 (PST) Message-Id: <199711102023.MAA21914@wile-e-coyote.cs.washington.edu> To: ipng@sunroof.eng.sun.com CC: vkl@cs.washington.edu Subject: (IPng 4768) searching for a description of the IPv6/IPv4 header translating router. Sender: owner-ipng@eng.sun.com Precedence: bulk The SIT Overview document refers to an "Ipv6 Transition Mechanisms for Header Translating routers" document. The reference section of the SIT overview mentions that this document still needs to be written. Using various search engines and skimming through this years ipng mailing archives I could not find such a document. Could someone point me to such a document if it exists? I'd be interested if someone could point me at an informal discussion of header translators and the issues involved. Also, I'd be happy to share thoughts regarding the protocol conversion of IPv6<->IPv4 with anyone who is currently working on this problem. Marc Marc E. Fiuczynski Department of CS&E U. of Washington -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 12:58:47 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA09427 for ipng-dist; Mon, 10 Nov 1997 12:55:26 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id MAA09420 for ; Mon, 10 Nov 1997 12:55:16 -0800 (PST) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id MAA18555; Mon, 10 Nov 1997 12:55:13 -0800 (PST) Date: Mon, 10 Nov 1997 12:53:42 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4769) Re: searching for a description of the IPv6/IPv4 header translating router. To: mef@cs.washington.edu Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199711102023.MAA21914@wile-e-coyote.cs.washington.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk > The SIT Overview document > refers to an "Ipv6 Transition Mechanisms for Header Translating > routers" document. The reference section of the SIT overview mentions > that this document still needs to be written. Using various search > engines and skimming through this years ipng mailing archives I could > not find such a document. The transition issues are discussed in the ngtrans working group and mailing lists. This draft describes the v4/v6 translators. draft-ietf-ngtrans-header-trans-00.txt Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 14:49:04 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA09711 for ipng-dist; Mon, 10 Nov 1997 14:45:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA09703 for ; Mon, 10 Nov 1997 14:45:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA11673 for ; Mon, 10 Nov 1997 14:45:45 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA02938 for ; Mon, 10 Nov 1997 14:45:32 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA27418; Mon, 10 Nov 1997 14:45:31 -0800 Message-Id: <3.0.3.32.19971110144411.008d7df0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 10 Nov 1997 14:44:11 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4770) W.G. Last Call on "Transmission of IPv6 Packets over Token Ring Networks" Cc: hinden@ipsilon.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document to Proposed Standard: Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : T. Narten, M. Crawford, S. Thomas Filename : draft-ietf-ipngwg-trans-tokenring-04.txt Pages : 10 Date : 06-Nov-97 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end one week from today, on November 17, 1997. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 15:17:54 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA09779 for ipng-dist; Mon, 10 Nov 1997 15:14:44 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA09772 for ; Mon, 10 Nov 1997 15:14:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA20563 for ; Mon, 10 Nov 1997 15:14:32 -0800 Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA01855 for ; Mon, 10 Nov 1997 12:54:35 -0800 (PST) Received: from javaid (slip139-92-120-106.kar.pk.ibm.net [139.92.120.106]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id UAA106838 for ; Mon, 10 Nov 1997 20:54:28 GMT Message-ID: <34677484.9B2@ibm.net> Date: Tue, 11 Nov 1997 01:54:28 +0500 From: soomro X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 4771) adoption Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk The thing we should all discuss is that. As we can see the Internet today as being the proof of IPv4 being perfect protocol. Untill we ran out of IP addresses. What other facilities can we think of which were not included earlier and is todays need? what we want to do on a computer network today and the day after? are they completely incorporated in IPv6? what issues we will face while transitioning to IPv6? (with due request to Mr.Huitema. Ps answer) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 16:18:59 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA10001 for ipng-dist; Mon, 10 Nov 1997 16:15:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA09994 for ; Mon, 10 Nov 1997 16:15:13 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA10543 for ; Mon, 10 Nov 1997 16:15:10 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA20036 for ; Mon, 10 Nov 1997 16:15:07 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id TAA30895; Mon, 10 Nov 1997 19:07:46 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA08847; Mon, 10 Nov 1997 19:07:28 -0500 Message-Id: <199711110007.AA08847@wasted.zk3.dec.com> To: Pyda Srisuresh , rajeshk@india.hp.com (Rajesh "Kumar." L) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4772) Re: NAT In-Reply-To: Your message of "Mon, 10 Nov 1997 09:32:40 PST." <199711101732.JAA16755@pedrom-ultra.cisco.com> Date: Mon, 10 Nov 1997 19:07:28 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk >>>>>> "Suresh" == Pyda Srisuresh writes: > Suresh> NAT is used in V4 context only and NOT for V4 to V6 > Suresh> conversions. >I'm sorry Suresh, but i believe you are wrong. There is a protocol >coverter between IPv6 and IPv4 which i know of and which is refered to as >"IPv6 NAT". Whenever the term is used correctly or incorrectly can be >open for discussion but the fact is that translating between IPv6 and IPv4 >is an operation is all similiar to IPv4 NAT: maintaining mappings between >addresses and tweaking the necessary bits as packets go by. Not quite. You can translate the addresses using v6 to v4 in the header in some fashion, but one can't assume only being done with IPv4-compatible/mapped addresses. But one cannot translate to IPv4 the Class (maybe if we do TOS bits but not the CE bits) and Flow Label. It can be done but one cannot have the same expectations as v4 to v4. I would also look at: draft-ietf-ngtrans-header-trans-00.txt for the first draft I know of discussing v6. Also there will be a draft before the IETF deadline discussing NO-NAT which is for IPv6 only and avoids NAT all together. See the NGTRANS minutes from the IETF Munich meeting where NO-NAT was first depicted. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 16:20:45 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA10010 for ipng-dist; Mon, 10 Nov 1997 16:17:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA10003 for ; Mon, 10 Nov 1997 16:17:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA11127 for ; Mon, 10 Nov 1997 16:17:14 -0800 Received: from hitiij.hitachi.co.jp (hitiij.hitachi.co.jp [133.145.224.3]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA21072 for ; Mon, 10 Nov 1997 16:17:10 -0800 (PST) Received: from isrdgw.isrd.hitachi.co.jp by hitiij.hitachi.co.jp (8.8.5+2.7Wbeta5/3.5W-hitiij) id JAA03623; Tue, 11 Nov 1997 09:08:50 +0900 (JST) Received: from magic.33g.isrd.hitachi.co.jp by isrdgw.isrd.hitachi.co.jp (8.6.9+2.4W/2.7W-ISRD) id JAA03179; Tue, 11 Nov 1997 09:16:42 +0900 Message-Id: <9711110020.AA00390@magic.33g.isrd.hitachi.co.jp> From: tsuchiya Date: Tue, 11 Nov 1997 09:20:48 +0900 To: mef@cs.washington.edu Cc: ipng@sunroof.eng.sun.com, vkl@cs.washington.edu Subject: (IPng 4773) Re: searching for a description of the IPv6/IPv4 header translating router. In-Reply-To: <199711102023.MAA21914@wile-e-coyote.cs.washington.edu> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@eng.sun.com Precedence: bulk Dear all My name is Kazuaki Tsuchiya. I work at Hitachi, Ltd. in Japan and I develop an IPv6 router. mef@cs.washington.edu wroute. >Could someone point me to such a document if it exists? I'd be >interested if someone could point me at an informal discussion of >header translators and the issues involved. Also, I'd be happy to >share thoughts regarding the protocol conversion of IPv6<->IPv4 with >anyone who is currently working on this problem. > I have a idea about this prblem. So I am writing a draft and I think I'd like to talk about this next IETF meeting. # Please wait a minute! ---------------------------------------------------------- Kazuaki Tsuchiya(E-mail:tsuchi@isrd.hitachi.co.jp) Hitachi, Ltd. in Japan. Phone:044-549-1714 Fax:044-549-1721 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 16:26:13 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA10038 for ipng-dist; Mon, 10 Nov 1997 16:23:40 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA10031 for ; Mon, 10 Nov 1997 16:23:32 -0800 (PST) From: mef@cs.washington.edu Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA12998 for ; Mon, 10 Nov 1997 16:23:29 -0800 Received: from wile-e-coyote.cs.washington.edu (wile-e-coyote.cs.washington.edu [128.95.2.83]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA19236 for ; Mon, 10 Nov 1997 16:23:23 -0800 Received: (mef@localhost) by wile-e-coyote.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA21977; Mon, 10 Nov 1997 16:23:16 -0800 (PST) Date: Mon, 10 Nov 1997 16:23:16 -0800 (PST) Message-Id: <199711110023.QAA21977@wile-e-coyote.cs.washington.edu> To: tsuchi@isrd.hitachi.co.jp CC: ipng@sunroof.eng.sun.com, vkl@cs.washington.edu In-reply-to: <9711110020.AA00390@magic.33g.isrd.hitachi.co.jp> (message from tsuchiya on Tue, 11 Nov 1997 09:20:48 +0900) Subject: (IPng 4774) Re: searching for a description of the IPv6/IPv4 header translating router. Sender: owner-ipng@eng.sun.com Precedence: bulk Note that there is a draft by Erik Nordmark dated July 30th, 1997. It is available as from various IEFT mirror sites. It is a good starting point for a discussion. Maybe the discussion of IPv6/IPv4 header translating routers should move to the ngtrans mailing list. Marc From: tsuchiya Date: Tue, 11 Nov 1997 09:20:48 +0900 Cc: ipng@sunroof.Eng.Sun.COM, vkl@cs.washington.edu MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Dear all My name is Kazuaki Tsuchiya. I work at Hitachi, Ltd. in Japan and I develop an IPv6 router. mef@cs.washington.edu wroute. >Could someone point me to such a document if it exists? I'd be >interested if someone could point me at an informal discussion of >header translators and the issues involved. Also, I'd be happy to >share thoughts regarding the protocol conversion of IPv6<->IPv4 with >anyone who is currently working on this problem. > I have a idea about this prblem. So I am writing a draft and I think I'd like to talk about this next IETF meeting. # Please wait a minute! ---------------------------------------------------------- Kazuaki Tsuchiya(E-mail:tsuchi@isrd.hitachi.co.jp) Hitachi, Ltd. in Japan. Phone:044-549-1714 Fax:044-549-1721 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 16:49:21 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA10107 for ipng-dist; Mon, 10 Nov 1997 16:45:00 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA10100 for ; Mon, 10 Nov 1997 16:44:50 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA18889 for ; Mon, 10 Nov 1997 16:44:47 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA03679 for ; Mon, 10 Nov 1997 16:44:48 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id TAA08498; Mon, 10 Nov 1997 19:39:51 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA11462; Mon, 10 Nov 1997 19:39:51 -0500 Message-Id: <199711110039.AA11462@wasted.zk3.dec.com> To: fred@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4775) Hello Fred - IPv6 is IPng Date: Mon, 10 Nov 1997 19:39:50 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Fred, Sitting here in this WG I am unclear that you as IETF Chair understand all the IPng issues per RFC 1752. None of what you mention as IETF Chair (Jim Duffy is quoting you in your role not as individual) fixes the problems with IPv4 for many of the issues in 1752 IMO. But I am more concerned about your statement of "something better" IPv6 is being tracked for a Global Internet Standard. /jim >http://www.nwfusion.com/news/1105ipv6.html > ---------------------------------------------- > > IETF head questions need for IPv6 > > By Jim Duffy > Network World Fusion, 11/5/97 > > Arlington, Va. - The chairman of the > IETF today questioned whether the > industry needs to migrate to IPv6, a > revision of the venerable Internet > Protocol designed to preserve > addresses. > > After delivering a keynote address on > the future of the Internet at the > Next Generation Networks conference > here, IETF Chairman Fred Baker was > asked why his remarks did not include > even a mention of IPv6. > > ''I'm not sure where IPv6 is going,'' > Baker replied. ''It turns out we had > other things we could do (to preserve > IP addresses),'' such as network > address translators, Classless > Interdomain Routing (CIDR) and > Dynamic Host Configuration > Protocol,(DHCP)he said. > > ''They're Band-Aids, but they're very effective > Band-Aids,'' Baker said. ''If we run out of addresses in > 2008, we're going to need something at that point. Is > that going to be IPv6 or our we going to have a better > idea by then?'' > > Nonetheless, the IETF will continue to work on IPv6, said > Baker, who is also a senior software engineer at Cisco > Systems, Inc. The IETF also is working on enhancements to > the Transmission Control Protocol, such as selective > acknowledgement and large window sizes, Baker said. He > said Microsoft Corp. will include these enhancements in > its Windows 98 operating system which is slated to ship > in the first half of next year. > > -------------------------------------------------------- > Feedback | Network World, Inc. | Sponsor index > How to Advertise | Copyright > > Home | NetFlash | This Week | Industry/Stocks > Buyer's Guides/Tests | Net Resources | Opinions | Careers > > Seminars & Events | Product Demos/Info > Audio Primers | IntraNet ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 16:49:51 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA10120 for ipng-dist; Mon, 10 Nov 1997 16:45:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA10112 for ; Mon, 10 Nov 1997 16:45:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA18976 for ; Mon, 10 Nov 1997 16:45:06 -0800 Received: from citytelprct8.citytel.net (citytelprct53.citytel.net [204.244.99.6]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA03829 for ; Mon, 10 Nov 1997 16:45:06 -0800 (PST) Received: from localhost ([127.0.0.1]) by citytelprct8.citytel.net with smtp (ident jwalther using rfc1413) id m0xUxyo-000UmlC (Debian Smail-3.2 1996-Jul-4 #2); Mon, 10 Nov 1997 17:50:30 +0000 () Date: Mon, 10 Nov 1997 17:50:29 +0000 ( ) From: Bjarne Lorftesonne X-Sender: jwalther@debian To: ipng@sunroof.eng.sun.com Subject: (IPng 4776) Dynamic addressing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk With all due respect to the readers here, could anyone give me a pointer to information on maintaining an address? In a previous post on here, I believe I saw someone state that all IP's would be dynamically allocated. Does this mean I wont be able to snag one, without having to get a new one every time my box goes down for maintenance? Hoping this can be explained, Bjarne -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 16:52:35 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA10137 for ipng-dist; Mon, 10 Nov 1997 16:49:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA10130 for ; Mon, 10 Nov 1997 16:49:01 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA20118 for ; Mon, 10 Nov 1997 16:48:57 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA05680 for ; Mon, 10 Nov 1997 16:48:57 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id TAA19563; Mon, 10 Nov 1997 19:43:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA11527; Mon, 10 Nov 1997 19:43:58 -0500 Message-Id: <199711110043.AA11527@wasted.zk3.dec.com> To: soomro Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4777) Re: adoption In-Reply-To: Your message of "Tue, 11 Nov 1997 01:54:28 +0500." <34677484.9B2@ibm.net> Date: Mon, 10 Nov 1997 19:43:57 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Go read RFC 1752. Or read IPng The Next Generation - Editors Bradner/Mankin, publisher Addison-Wesley. And Mr. Huitema is right and yes we did address all your questions and many more from the Global International Internet Community and Users Communities that took the time to participate. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 17:17:15 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id RAA10207 for ipng-dist; Mon, 10 Nov 1997 17:14:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id RAA10200 for ; Mon, 10 Nov 1997 17:14:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA26294 for ; Mon, 10 Nov 1997 17:14:08 -0800 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id RAA17089 for ; Mon, 10 Nov 1997 17:14:10 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id RAA10701; Mon, 10 Nov 1997 17:14:09 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA17056; Mon, 10 Nov 1997 17:14:09 -0800 (PST) Date: Mon, 10 Nov 1997 17:14:09 -0800 (PST) Message-Id: <199711110114.RAA17056@pedrom-ultra.cisco.com> From: Pedro Marques To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4778) Re: NAT In-Reply-To: <199711110007.AA08847@wasted.zk3.dec.com> References: <199711101732.JAA16755@pedrom-ultra.cisco.com> <199711110007.AA08847@wasted.zk3.dec.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk >>>>> "bound" == bound writes: >>>>>>> "Suresh" == Pyda Srisuresh writes: Suresh> NAT is used in V4 context only and NOT for V4 to V6 Suresh> conversions. >> I'm sorry Suresh, but i believe you are wrong. There is a >> protocol coverter between IPv6 and IPv4 which i know of and >> which is refered to as "IPv6 NAT". Whenever the term is used >> correctly or incorrectly can be open for discussion but the >> fact is that translating between IPv6 and IPv4 is an operation >> is all similiar to IPv4 NAT: maintaining mappings between >> addresses and tweaking the necessary bits as packets go by. bound> Not quite. You can translate the addresses using v6 to v4 bound> in the header in some fashion, but one can't assume only bound> being done with IPv4-compatible/mapped addresses. To be clear, the implementation i'm refering to doesn't do any assumption of that kind. NAT, IPv4 NAT, works basically by mapping an (arbitrary) address or group of addresses to another... IPv6 NAT does basically the same job. It doesn't even care how long the addresses are... bound> But one bound> cannot translate to IPv4 the Class (maybe if we do TOS bits bound> but not the CE bits) and Flow Label. Since they are undefined in IPv6 at the moment and unused in IPv4, translation is quite easy ;-) bound> It can be done but bound> one cannot have the same expectations as v4 to v4. Because you don't translate TOS to class and vice-versa ? My guess is that many users with be able to live pretty well with that limitation. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 19:56:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id TAA10346 for ipng-dist; Mon, 10 Nov 1997 19:53:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id TAA10339 for ; Mon, 10 Nov 1997 19:53:46 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA25550 for ; Mon, 10 Nov 1997 19:53:46 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id TAA14213 for ; Mon, 10 Nov 1997 19:53:46 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA01648; Mon, 10 Nov 1997 22:43:58 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19620; Mon, 10 Nov 1997 22:43:57 -0500 Message-Id: <199711110343.AA19620@wasted.zk3.dec.com> To: Bjarne Lorftesonne Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4779) Re: Dynamic addressing In-Reply-To: Your message of "Mon, 10 Nov 1997 17:50:29 GMT." Date: Mon, 10 Nov 1997 22:43:57 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk >With all due respect to the readers here, could anyone give me a pointer >to information on maintaining an address? Read these: draft-ietf-ipngwg-addr-arch-v2-04.txt draft-ietf-ipngwg-multicast-assgn-04.txt draft-ietf-ipngwg-tla-assignment-01.txt draft-ietf-ipngwg-unicast-aggr-02.txt draft-ietf-ipngwg-addrconf-v2-00.txt draft-ietf-ipngwg-discovery-v2-00.txt draft-ietf-ipngwg-trans-ethernet-02.txt (see same for fddi, ppp, token ring) draft-ietf-dhc-dhcpv6-11.txt (being updated so wait a week) draft-ietf-dhc-v6exts-07.txt (being updated so wait a week) draft-ietf-ipngwg-router-renum-01.txt RFC 2136 (dynamic updates to DNS) These should give you a good picture. >In a previous post on here, I believe I saw someone state that all IP's >would be dynamically allocated. Does this mean I wont be able to snag >one, without having to get a new one every time my box goes down for >maintenance? Bottom line is that you will get two lifetimes with an address for your machine. One lifetime is called "valid" .. When this timer goes to zero your address is invalid and no good anymore. The other lifetime is called "preferred". When this timer goes to zero you should begin looking for a new address. Where preferred cannot be greater than or equal to valid. This is all discussed if thats all you care about in "addrconf" above and in "dhcpv6". So its really up to your admin that sets the timers. If they set valid to 16 hours and preferred to 8 hours, your machine should look for a new address after 8 hours and get you a new address before the 16 hours expires. The valid and preferred liftime fields are 32bits. Setting them all high means they are at infinity. Though that is an error with the preferred timer in theory. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 20:26:13 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id UAA10375 for ipng-dist; Mon, 10 Nov 1997 20:23:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id UAA10368 for ; Mon, 10 Nov 1997 20:23:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA29204 for ; Mon, 10 Nov 1997 20:23:28 -0800 Received: from citytelprct8.citytel.net (citytelprct60.citytel.net [204.244.99.13]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA23320 for ; Mon, 10 Nov 1997 20:23:27 -0800 (PST) Received: from localhost ([127.0.0.1]) by citytelprct8.citytel.net with smtp (ident jwalther using rfc1413) id m0xV1Om-000UmlC (Debian Smail-3.2 1996-Jul-4 #2); Mon, 10 Nov 1997 21:29:32 +0000 () Date: Mon, 10 Nov 1997 21:29:31 +0000 ( ) From: Bjarne Lorftesonne X-Sender: jwalther@citytelprct62.citytel.net To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 4780) Re: Dynamic addressing In-Reply-To: <199711110343.AA19620@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk On Mon, 10 Nov 1997 bound@zk3.dec.com wrote: > So its really up to your admin that sets the timers. If they set valid > to 16 hours and preferred to 8 hours, your machine should look for a new > address after 8 hours and get you a new address before the 16 hours > expires. So I am to understand that there will still be admins that will control blocks of these addresses? How will I be able to become such an admin? The current situation where IP's are hogged by ISP's and doled out in miserly fashion for big bucks is something Im hoping will be eliminated. Will it? Respectfully, Jonathan Walther -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 10 20:36:41 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id UAA10397 for ipng-dist; Mon, 10 Nov 1997 20:33:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id UAA10390 for ; Mon, 10 Nov 1997 20:33:45 -0800 (PST) From: mef@cs.washington.edu Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA00105 for ; Mon, 10 Nov 1997 20:33:45 -0800 Received: from wile-e-coyote.cs.washington.edu (wile-e-coyote.cs.washington.edu [128.95.2.83]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA26172 for ; Mon, 10 Nov 1997 20:33:41 -0800 (PST) Received: (mef@localhost) by wile-e-coyote.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA17851; Mon, 10 Nov 1997 20:33:42 -0800 (PST) Date: Mon, 10 Nov 1997 20:33:42 -0800 (PST) Message-Id: <199711110433.UAA17851@wile-e-coyote.cs.washington.edu> To: ipng@sunroof.eng.sun.com CC: vkl@cs.washington.edu Subject: (IPng 4781) IPv6 compatible/mapped IPv4 address Sender: owner-ipng@eng.sun.com Precedence: bulk Hi, Please pardon my ignorance. I haven't been able to wrap my head around the actual value of using "IPv6 compatible & mapped IPv4 addresses". It seems that one use of these addresses is to ease the implementation of a stateless IPv6/IPv4 header translating router . Otherwise, it just seems to complicate the routing issues for IPv6-complete networks. I.e., IPv6 routing may be easier if it never needed to route IPv6-compatible or IPv6-mapped IPv4 addresses. Is there something obvious that I am overlooking? If so, feel free to flame me, as long as you point out the appropriate Internet Draft or RFC that explains why IPv6 compatible/mapped IPv4 addresses are absolutely required. :) Thanks, Marc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 11 06:09:44 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA10704 for ipng-dist; Tue, 11 Nov 1997 06:06:53 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA10697 for ; Tue, 11 Nov 1997 06:06:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA22894 for ; Tue, 11 Nov 1997 06:06:25 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA14552 for ; Tue, 11 Nov 1997 06:06:25 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA00833; Tue, 11 Nov 1997 09:06:20 -0500 (EST) Message-Id: <199711111406.JAA00833@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4782) I-D ACTION:draft-ietf-ipngwg-tla-assignment-01.txt Date: Tue, 11 Nov 1997 09:06:20 -0500 Sender: owner-ipng@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 : TLA and NLA Assignment Rules Author(s) : B. Hinden, M. O'Dell Filename : draft-ietf-ipngwg-tla-assignment-01.txt Pages : 6 Date : 10-Nov-97 This document defines assignment rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-tla-assignment-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-tla-assignment-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971110155725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tla-assignment-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971110155725.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 11 07:29:43 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA10761 for ipng-dist; Tue, 11 Nov 1997 07:27:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA10754 for ; Tue, 11 Nov 1997 07:26:52 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA13472 for ; Tue, 11 Nov 1997 07:26:51 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA16927 for ; Tue, 11 Nov 1997 07:26:49 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id KAA22910; Tue, 11 Nov 1997 10:13:20 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA11551; Tue, 11 Nov 1997 10:13:18 -0500 Message-Id: <199711111513.AA11551@wasted.zk3.dec.com> To: Bjarne Lorftesonne Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4783) Re: Dynamic addressing In-Reply-To: Your message of "Mon, 10 Nov 1997 21:29:31 GMT." Date: Tue, 11 Nov 1997 10:13:18 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Bjarne, >On Mon, 10 Nov 1997 bound@zk3.dec.com wrote: >> So its really up to your admin that sets the timers. If they set valid >> to 16 hours and preferred to 8 hours, your machine should look for a new >> address after 8 hours and get you a new address before the 16 hours >> expires. >So I am to understand that there will still be admins that will control >blocks of these addresses? How will I be able to become such an admin? >The current situation where IP's are hogged by ISP's and doled out in >miserly fashion for big bucks is something Im hoping will be eliminated. >Will it? In my note I was referencing the admin function of setting the config parameters for Router Advertisements when you get your address/lifetimes from stateless or the DHCPv6 Reply Msg from a DHCPv6 Server via stateful. But as I read your mail I see your asking how to get a block of addresses now. The way it is to be is that if you are willing to be a major provider you may request what is called a Top Level Aggregator (TLA). It is perceived that only large ISPs will request these and be granted them (e.g. AT&T, BT, UUNET, World Com, etc). Under that will exist Next Level Aggregators (NLA) which will I believe be granted to smaller or region/specific ISPs or in some cases very large enterprises. Under that is the Site Level Aggregator (SLA) which would be given to a site. If your an exchange provider you will use an NLA or possbily an SLA (depending on what kind of exchange you are). But the bottom line is if you cannot justify being a TLA all folks will have to go to their Provider (TLA or NLA) to get their IPv6 addresses. So going back to your original mail, we use Dynamic Addressing as inherent in the IPv6 architecture, and it is not within IPv4, and that part is Dynamic. But allocation of blocks of addresses is now to TLAs and then folks get the blocks from those points of light. If you want to really understand this you need to read the specs I sent in previous mail, we cannot do this via email msgs and thats why the authors wrote them. Another good feature for IPv6 is that if you switch providers you will most likely have to renumber your site (and should assume this in most cases), and a practical reason for why we built dynamic renumbering into the IPv6 architecture. IPv4 cannot do this gracefully and inexpensively. Hope this helps, but its no alternative to reading the specs. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 11 08:12:55 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA10888 for ipng-dist; Tue, 11 Nov 1997 08:09:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA10881 for ; Tue, 11 Nov 1997 08:09:48 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26405 for ; Tue, 11 Nov 1997 08:09:46 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA07420 for ; Tue, 11 Nov 1997 08:09:45 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id KAA26525; Tue, 11 Nov 1997 10:30:07 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA12716; Tue, 11 Nov 1997 10:30:06 -0500 Message-Id: <199711111530.AA12716@wasted.zk3.dec.com> To: mef@cs.washington.edu Cc: ipng@sunroof.eng.sun.com, vkl@cs.washington.edu Subject: (IPng 4784) Re: IPv6 compatible/mapped IPv4 address In-Reply-To: Your message of "Mon, 10 Nov 1997 20:33:42 PST." <199711110433.UAA17851@wile-e-coyote.cs.washington.edu> Date: Tue, 11 Nov 1997 10:30:06 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk >Please pardon my ignorance. I haven't been able to wrap my head >around the actual value of using "IPv6 compatible & mapped IPv4 >addresses". It seems that one use of these addresses is to ease the >implementation of a stateless IPv6/IPv4 header translating router >. Otherwise, it just seems to >complicate the routing issues for IPv6-complete networks. I.e., IPv6 >routing may be easier if it never needed to route IPv6-compatible or >IPv6-mapped IPv4 addresses. See: RFC 1933 RFC 2133 RFC 2185 draft-ietf-ipngwg-addr-arch-v2-04.txt >Is there something obvious that I am overlooking? If so, feel free to >flame me, as long as you point out the appropriate Internet Draft or >RFC that explains why IPv6 compatible/mapped IPv4 addresses are >absolutely required. :) The ipv4-compatible is used to set up IPv4 tunnels in an IPv4 only domain or path. See 1933 and 2185 above. This is being done on the 6bone live right now you can go see it at http://www-6bone.lbl.gov/6bone/ The ipv4-compatible and ipv4-mapped addresses are also use to support handling IPv6 or IPv4 addresses into a dual or hybrid v4/v6 stack at the IP layer or from user input or DNS resolver at the applications layer, and see RFC 2133 for some discussion there. The bottom line is they are one attribute of a set of transition mechanisms to begin adoption of IPv6. I don't believe that IPv6 routing needs either of them unless the packet has to cross an IPv4 domain or path. Then a tunnel can be created which in effect creates a VPN between IPv6 and IPv4. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 11 08:31:14 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA10913 for ipng-dist; Tue, 11 Nov 1997 08:27:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA10906 for ; Tue, 11 Nov 1997 08:27:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA00617 for ; Tue, 11 Nov 1997 08:27:36 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA16402 for ; Tue, 11 Nov 1997 08:27:29 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA01889; Tue, 11 Nov 1997 08:26:18 -0800 Message-Id: <3.0.3.32.19971111082555.008db1d0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 11 Nov 1997 08:25:55 -0800 To: Jeffrey Burgan From: Bob Hinden Subject: (IPng 4785) Request to Advance "TLA and NLA Assignment Rules" Cc: narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a BCP: Title : TLA and NLA Assignment Rules Author(s) : R. Hinden, M. O'Dell Filename : draft-ietf-ipngwg-tla-assignment-01.txt Pages : 6 Date : 10-Nov-97 A working group last call for this document was completed on August 13, 1997 and this documents was discussed at the Munich IETF IPng sessions. This draft incorporates changes based on comments received during the w.g. last call and w.g. sessions. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 12 08:21:57 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA12051 for ipng-dist; Wed, 12 Nov 1997 08:19:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA12044 for ; Wed, 12 Nov 1997 08:18:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA09120 for ; Wed, 12 Nov 1997 08:18:57 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA18730 for ; Wed, 12 Nov 1997 08:18:55 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id LAA55868; Wed, 12 Nov 1997 11:18:44 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA08358; Wed, 12 Nov 1997 11:18:44 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20084; Wed, 12 Nov 1997 11:18:33 -0500 Message-Id: <9711121618.AA20084@cichlid.raleigh.ibm.com> To: Paul Ferguson Cc: Bob Hinden , ipng@sunroof.eng.sun.com, kimh@internic.net, davidc@apnic.net, Daniel.Karrenberg@ripe.net Subject: (IPng 4786) Re: New "TLA and NLA Assignment Rules" draft In-Reply-To: Your message of "Fri, 07 Nov 1997 20:25:55 EST." <3.0.3.32.19971107202555.00837700@lint.cisco.com> Date: Wed, 12 Nov 1997 11:18:33 -0500 From: Thomas Narten Sender: owner-ipng@eng.sun.com Precedence: bulk Paul, > It was my understanding that BCP's reflected reality, insofar as a > BCP was simply documenting how, in practice, the majority of the > Internet community executed a particular concept. I think you've fallen into the all-to-familiar (and unfortunately, all-to-common) trap of seeing the words "best current practice" and assuming that they literally mean what they say. They don't. Quoting from RFC 2026: 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. Historically Internet standards have generally been concerned with the technical specifications for hardware and software required for computer communication across interconnected networks. However, since the Internet itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations. While these guidelines are generally different in scope and style from protocol standards, their establishment needs a similar process for consensus building. While it is recognized that entities such as the IAB and IESG are composed of individuals who may participate, as individuals, in the technical work of the IETF, it is also recognized that the entities Bradner Best Current Practice [Page 16] RFC 2026 Internet Standards Process October 1996 themselves have an existence as leaders in the community. As leaders in the Internet technical community, these entities should have an outlet to propose ideas to stimulate work in a particular area, to raise the community's sensitivity to a certain issue, to make a statement of architectural principle, or to communicate their thoughts on other matters. The BCP subseries creates a smoothly structured way for these management entities to insert proposals into the consensus-building machinery of the IETF while gauging the community's view of that issue. Finally, the BCP series may be used to document the operation of the IETF itself. For example, this document defines the IETF Standards Process and is published as a BCP. 5.1 BCP Review Process Unlike standards-track documents, the mechanisms described in BCPs are not well suited to the phased roll-in nature of the three stage standards track and instead generally only make sense for full and immediate instantiation. The BCP process is similar to that for proposed standards. The BCP is submitted to the IESG for review, (see section 6.1.1) and the existing review process applies, including a Last-Call on the IETF Announce mailing list. However, once the IESG has approved the document, the process ends and the document is published. The resulting document is viewed as having the technical approval of the IETF. Specifically, a document to be considered for the status of BCP must undergo the procedures outlined in sections 6.1, and 6.4 of this document. The BCP process may be appealed according to the procedures in section 6.5. Because BCPs are meant to express community consensus but are arrived at more quickly than standards, BCPs require particular care. Specifically, BCPs should not be viewed simply as stronger Informational RFCs, but rather should be viewed as documents suitable for a content different from Informational RFCs. A specification, or group of specifications, that has, or have been approved as a BCP is assigned a number in the BCP series while retaining its RFC number(s). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 12 09:08:27 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA12132 for ipng-dist; Wed, 12 Nov 1997 09:05:29 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA12125 for ; Wed, 12 Nov 1997 09:05:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA20744 for ; Wed, 12 Nov 1997 09:05:17 -0800 Received: from pitbull.cisco.com (pitbull.cisco.com [171.69.223.73]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA14386 for ; Wed, 12 Nov 1997 09:05:16 -0800 (PST) Received: from [171.69.123.77] (chanty-async-27.cisco.com [171.69.123.77]) by pitbull.cisco.com (8.6.12/8.6.5) with ESMTP id JAA00941; Wed, 12 Nov 1997 09:02:38 -0800 X-Sender: fred@stilton.cisco.com (Unverified) Message-Id: In-Reply-To: <199711110039.AA11462@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Nov 1997 03:45:08 -0800 To: bound@zk3.dec.com From: Fred Baker Subject: (IPng 4787) Re: Hello Fred - IPv6 is IPng Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@eng.sun.com Precedence: bulk At 7:39 PM -0500 11/10/97, bound@zk3.dec.com wrote: >Sitting here in this WG I am unclear that you as IETF Chair understand >all the IPng issues per RFC 1752. None of what you mention as IETF >Chair (Jim Duffy is quoting you in your role not as individual) fixes >the problems with IPv4 for many of the issues in 1752 IMO. But I am >more concerned about your statement of "something better" IPv6 is being >tracked for a Global Internet Standard. There are several things that concern me here, some of which are in your note and some of which are in his article. I would describe his article as a particularly poor bit of reporting. I spoke for some 45 minutes on the subject of the trends that I personally (not the IETF corporately) see as important in the Internet for the next few years, which have to do with putting an economic underpinning under the net in the form of what the Integrated Services folks call the Differentiated Services model. This basically calls for and enables the Internet to provide best effort services with a business model more like a telco's. Note that the primary subject of the talk, what I discussed for at least 30 out of those 45 minutes, is not mentioned in his report. That is, at best, incomplete reporting. When the talk was over, I was asked a few questions, one of which was "you didn't mention IP6 - why not?" The answer was simple enough - I didn't mention IP4 either. IP4 has facilities that can be used to deploy the Differentiated Services model, and as IP4 is in place today and will be predominant for the foreseeable future (which I stated during that Q&A to be "until we all walk into the hall to get coffee", but which I think will probably be until after both of us retire), is the first vehicle that will be used to deploy this. IP6, last we discussed this subject on this mailing list, was in danger of having its priority field removed and has no TOS flags, and therefore doesn't presently have the facilities necessary to deploy Van Jacobsen's "Pre-emptive Service" and was at least at one point in time considering being unable to deploy Clark's "Assured Service". So IP6 may or may not be able to support the facilities that I see as critical to the Internet over the coming years. That remains to be seen. I did not say that something else was on the standards track for IPng. What I said - and he got parts of the quote right - was that the initial urgency of deploying an IPng has been mitigated by developments such as CIDR, NATs, DHCP, and private address spaces. No comment on the architectural aspects of that - frankly, there are serious architectural problems with NATs, not the least of which is a single point of failure, the loss of which forces an end to end restart of TCP sessions. But what we thought at one time we might be forced to deploy as early as 1993 looks like (according to Frank Solenski's Address Usage statistics the last time I saw them) it might not be needed for as much as another decade. And in that time - well, maybe your crystal ball is clearer than mine, but my crystal ball doesn't preclude somebody having a better idea than IP6 as presently formulated. If we do indeed have a better idea in the meantime, I said, we would deploy said better idea. If you want my concerns with IP6, I think you are already in receipt of them. But I'll give you a little list. First, as I say, I think scalable differentiated services of some form are mission critical, and I think that this does not imply RSVP or any other per-flow state negotiation over the backbone. Per-flow state negotiation using protocols such as RSVP is important in unregulated portions of the net such as corporate networks, but when the data enters a service provider's transit network, such things will be managed by contract, and therefore by message attributes, rather than by maintenance of per-flow state. Question of applicability space. Second, I think the flow label in IP6 is poorly designed. One needs something akin to what it is now fashionable to call "label switching" to do special-flow QoS in a scalable fashion. We can do it at the IP layer or at a layer one below, it really doesn't matter to me. Third, the address size discriminates against low delay applications on low speed lines. Say it any way you want to, I don't care, but take this example and think about it. On an ISDN basic rate line (128 KBPS in two B channels), I can place two standard telephone calls using voice technology, and perhaps three VoIP calls if I use IP4, or two voice calls plus miscellaneous best effort traffic such as web and email exchanges. VoIP uses a compression technique that sends standard voice at about 40 messages a second comprising an 8-16 KHz voice bit stream. The difference between an IP4 and an IP6 header is an additional 20 bytes (if memory serves), which means that using IP6, I will get two voice calls on that same line, no more. The stated ROAD requirement was for an address that would identify 10^12 networks and 10^15 hosts, which is achievable with a 64 bit address at a usage density of only one address in 16,000 - where the moaning I hear today is that folks (deplorably) use about one address in one hundred. I'm sorry, nobody has ever given me an explanation for the bloated 128 bit fixed size address that I could correlate to the requirements the address had to meet, and I see the address as hurting interactive, transaction, and real time applications on the most widely deployed links in the world - T-1 and below. >From my perspective, if a typical network administrator can do all of his work using either IP4 or IP6, and he gets better service (higher throughput and lower delay on the delay-sensitive applications that his users form their impressions of his network from) on IP4 using economical lines, while IP6 pushes him toward higher cost lines, I should expect the typical network administrator is going to delay introduction of IP6 as long as possible. I don't see how he could otherwise defend his job. And until there is someone else using IP6 that he *has* to use IP6 to talk to, and he *has* to talk with him, I don't see any community of interest that he serves requesting IP6 services by name. The laws of the marketplace militate for "IP4 with band-aids" over IP6 with a vengeance. Note that I am not speaking, in that, as a detractor of IP6. I am speaking as a practical person with a finite wallet about how people like me behave in the marketplace, whether that marketplace is the grocery store, the hardware store, the corporate budget cycle, or the Internet. So much for the issues in the article. Now for my issues with your note. Jim, you live in a state whose motto is "live free or die". You live with that fundamental ethic in your daily life, and you display that ethic in the messages you send to the net and your interactions in IETF meetings. Do you have a problem with other people also living by that ethic? When I am asked to speak about the issues that I see (from my vantage point as IETF chair) as critical trends over the next few years, where does it say that I must reflect your marketing viewpoint? Where does it say that I must mention your favorite work item, or that if I am asked about it I must reflect your viewpoint on it? I should expect that when my opinion is asked, my opinion is what should be given. And my opinion doesn't have to be politically correct, or stated in a politically correct way, any more than yours does. Now, let's think about your statement that I said that something other than IP6 was on the standards track as IPng. According to the report, I said: > ''They [NATs, CIDR, etc] are Band-Aids, but they're very effective > Band-Aids,'' Baker said. ''If we run out of addresses in > 2008, we're going to need something at that point. Is > that going to be IPv6 or our we going to have a better > idea by then?'' That's not quite what I said - that last was, if my memory serves, not a question, but a statement - at that point, we would likely deploy IP6, but if we had a better idea between now and then, we would deploy the better technology. But let's assume for the sake of argument that this sorry excuse for journalism was perfectly accurate. Explain to me how you get your statement out of what mine is reported to have been? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= NT 5: the power of Windows, the simplicity of Unix. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 12 13:11:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA12512 for ipng-dist; Wed, 12 Nov 1997 13:08:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA12505 for ; Wed, 12 Nov 1997 13:08:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA09062 for ; Wed, 12 Nov 1997 13:07:39 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA02643 for ; Wed, 12 Nov 1997 13:07:29 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id NAA05382; Wed, 12 Nov 1997 13:04:53 -0800 Message-Id: <3.0.3.32.19971112130425.00992260@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 12 Nov 1997 13:04:25 -0800 To: bound@zk3.dec.com, Fred Baker From: Bob Hinden Subject: (IPng 4788) Re: Hello Fred - IPv6 is IPng Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <199711110039.AA11462@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Fred, Jim, I would strongly encourage the two of you to take the personal discussion off the IPng list. It is not appropriate for the working group mailing list. Fred, Steve Deering and I will respond later to the technical concerns you raise about IPv6. I think your technical concerns are largely misplaced and suspect that you have not been following the work in enough detail to know that there are easy answers to the questions you raise. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 12 13:32:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA12537 for ipng-dist; Wed, 12 Nov 1997 13:28:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA12530 for ; Wed, 12 Nov 1997 13:28:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14315 for ; Wed, 12 Nov 1997 13:27:57 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA13387 for ; Wed, 12 Nov 1997 13:27:53 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id QAA44764; Wed, 12 Nov 1997 16:27:38 -0500 (EST) Received: from trinh.raleigh.ibm.com (trinh.raleigh.ibm.com [9.37.178.89]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA34808; Wed, 12 Nov 1997 16:27:41 -0500 Received: by trinh.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA23770; Wed, 12 Nov 1997 16:27:38 -0500 Message-Id: <9711122127.AA23770@trinh.raleigh.ibm.com> To: Jeremy McCooey Cc: ipv6imp@munnari.oz.au, ipng@sunroof.eng.sun.com Subject: (IPng 4789) Re: UNH test period clarifications Date: Wed, 12 Nov 97 16:27:38 -0500 From: Hoe Trinh Sender: owner-ipng@eng.sun.com Precedence: bulk Jeremy, I just talked to you on phone few minutes ago. Please give me URL/web pages that I can find IPV6 test info online from UNH. Thank you. Hoe Trinh Phone: 919-254-6226 Email: trinh@raleigh.ibm.com Jeremy McCooey writes: > > First, before I get flooded with messages, the group test period > information/registration is *not* yet online. The basic information > will be up by Monday. More detailed information will be online > later. If you need particular information and can't wait, you can > email me at jam@iol.unh.edu. > > Regarding the associated costs: > > The cost of the *testing* is $1250 per company for non-members and is > free for members. However, since the testing will be taking place > off-site, there is an additional *per-person* charge. This charge > covers the expenses associated with the use of the New England > Center. > > For those who are not staying at the NEC, the charge is > $75/day and includes lunch, morning and afternoon breaks, and snacks. > > For those who stay at the NEC, a charge of $175/day covers the above > as well as your room, breakfast, and dinner. > > Also, we moved the discussion of test period details to a private list > last time. If you would like to be included on that list, please send > me mail (or register). > > Jeremy > > -- > +---------------------------------+-------------------+ > | Jeremy McCooey | jam@iol.unh.edu | > | UNH InterOperability Laboratory | 603-862-0090 | > | IP/Routing Consortium | | > +---------------------------------+-------------------+ > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 12 15:34:24 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA12711 for ipng-dist; Wed, 12 Nov 1997 15:31:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA12704 for ; Wed, 12 Nov 1997 15:31:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA26214 for ; Wed, 12 Nov 1997 15:31:09 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA24032 for ; Wed, 12 Nov 1997 15:31:02 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id SAA27435; Wed, 12 Nov 1997 18:30:54 -0500 (EST) Message-Id: <199711122330.SAA27435@ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 4791) Last Call: IP Version 6 Addressing Architecture to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 12 Nov 1997 18:30:53 -0500 Sender: owner-ipng@eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider the following: o IP Version 6 Addressing Architecture for publication as a Proposed Standard. Note: This document is a replacement for RFC1884, which will be reclassified as Historic. o An IPv6 Aggregatable Global Unicast Address Format for publication as a Proposed Standard. Note: This document is a replacement for RFC2073, which will be reclassified as Historic. o IPv6 Testing Address Allocation as an Experimental protocol. Note: This document is a replacement for RFC1897, which will be reclassified as Historic. o IPv6 Multicast Address Assignments as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 26, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-05.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-aggr-02.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-testv2-addralloc-01.txt ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-04.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 05:46:54 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id FAA13246 for ipng-dist; Thu, 13 Nov 1997 05:43:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id FAA13239 for ; Thu, 13 Nov 1997 05:43:36 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA06262 for ; Thu, 13 Nov 1997 05:40:50 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA13718 for ; Thu, 13 Nov 1997 05:40:36 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA32098; Thu, 13 Nov 1997 08:20:26 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA13238; Thu, 13 Nov 1997 08:20:22 -0500 Message-Id: <199711131320.AA13238@wasted.zk3.dec.com> To: hinden@ipsilon.com, deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4792) IPv6 Base Spec Date: Thu, 13 Nov 1997 08:20:22 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Bob/Steve, Are we to get a new IPv6 base spec for Wash D.C. with the new flow label and the Class field extended. Also is the min MTU to be 1500 bytes? Also its unacceptable for the norm to be like the last Munich IPng WG meeting to be how Wash D.C. goes. We come and the chairs tell us what they think should be changed in the base header every three months without some mail discussion and an updated Internet draft. We will never get done. Telling us that this is what XXXX Internet illuminary thinks is good is OK but that don't make it a done deal or go through the rigorous testing of this mailing list. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 06:09:04 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA13277 for ipng-dist; Thu, 13 Nov 1997 06:06:24 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA13270 for ; Thu, 13 Nov 1997 06:06:15 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA10068 for ; Thu, 13 Nov 1997 06:06:13 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA23803 for ; Thu, 13 Nov 1997 06:06:14 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id HAA29758; Thu, 13 Nov 1997 07:28:51 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09429; Thu, 13 Nov 1997 07:28:45 -0500 Message-Id: <199711131228.AA09429@wasted.zk3.dec.com> To: Fred Baker Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4793) Re: Hello Fred - IPv6 is IPng In-Reply-To: Your message of "Wed, 12 Nov 1997 03:45:08 PST." Date: Thu, 13 Nov 1997 07:28:44 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Fred, Per the chairs I will respond offline to your very good reply and my reasons for asking. Both technical and personal. I don't think the chairs are the only ones who can or should respond to your technical issues, but thats essentially what they just asked. I have an issue with that too but will take that offline too. But again do want to thank you for your response to me and other working group members who are working on this stuff and why I still believe fyi your doing a very good job as IESG chair. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 08:39:08 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA13407 for ipng-dist; Thu, 13 Nov 1997 08:34:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA13400 for ; Thu, 13 Nov 1997 08:34:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA25031 for ; Thu, 13 Nov 1997 08:34:35 -0800 Received: from arthur.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA06173 for ; Thu, 13 Nov 1997 08:34:15 -0800 (PST) Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by arthur.axion.bt.co.uk with SMTP (PP); Thu, 13 Nov 1997 16:25:54 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA02772; Thu, 13 Nov 1997 16:22:55 GMT Date: Thu, 13 Nov 1997 16:22:54 +0000 (GMT) From: George Tsirtsis To: Pedro Marques Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4794) Re: NAT In-Reply-To: <199711110114.RAA17056@pedrom-ultra.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk All, Sorry for the late reply but to summarise (please correct me if I misinterpret solutions) and clarify: The issue is how you interoperate IPv4 and IPv6. Last year we suggested to the list that the dualstack routers that ngtrans had adopted as the main interoperability tool was not enough. We also suggested that a NAT/PT (v4-v6 NAT combined with Protocol Translator) could enhance the interoperability of the two protocols. Since then Jim has proposed the No-Nat solution, involving DHCP servers instead of NAT boxes, and Erik has written a draft on stateless Protocol Translators. All proposals are valid and very important part of the migration process, they just are applicable to different network configurations. * The NAT-PT proposal assumes that IPv4 ONLY hosts want to communicate with IPv6 ONLY hosts (and the other way around). The problem is that NAT boxes have all kinds of problems that were highlighted in the NAT BOF during the last IETF (break end-to-end principle, IPSEC etc...). * The No-NAT solution assumes (correct me if I am wrong) that IPv4 ONLY hosts need to communicate with IPv6/v4 hosts (dualstack or hybrid) and the other way arrount. The problem here is that the IPv6 hosts also have to speek IPv4. * The Protocol Translation Draft can work with either solution. I think this work is very important if we want to see IPv6 being deployed in any significant scale. Regards George ------------------- Internet Transport| BTLABS | ------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. ------------------------------------------------------------------------- On Mon, 10 Nov 1997, Pedro Marques wrote: > >>>>> "bound" == bound writes: > > >>>>>>> "Suresh" == Pyda Srisuresh writes: > > Suresh> NAT is used in V4 context only and NOT for V4 to V6 > Suresh> conversions. > > >> I'm sorry Suresh, but i believe you are wrong. There is a > >> protocol coverter between IPv6 and IPv4 which i know of and > >> which is refered to as "IPv6 NAT". Whenever the term is used > >> correctly or incorrectly can be open for discussion but the > >> fact is that translating between IPv6 and IPv4 is an operation > >> is all similiar to IPv4 NAT: maintaining mappings between > >> addresses and tweaking the necessary bits as packets go by. > > bound> Not quite. You can translate the addresses using v6 to v4 > bound> in the header in some fashion, but one can't assume only > bound> being done with IPv4-compatible/mapped addresses. > > To be clear, the implementation i'm refering to doesn't do any assumption > of that kind. NAT, IPv4 NAT, works basically by mapping an (arbitrary) address > or group of addresses to another... IPv6 NAT does basically the same job. > It doesn't even care how long the addresses are... > > bound> But one > bound> cannot translate to IPv4 the Class (maybe if we do TOS bits > bound> but not the CE bits) and Flow Label. > > Since they are undefined in IPv6 at the moment and unused in IPv4, translation > is quite easy ;-) > > bound> It can be done but > bound> one cannot have the same expectations as v4 to v4. > > Because you don't translate TOS to class and vice-versa ? My guess is that > many users with be able to live pretty well with that limitation. > > Pedro. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 10:36:44 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA13648 for ipng-dist; Thu, 13 Nov 1997 10:33:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA13641 for ; Thu, 13 Nov 1997 10:33:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA04489 for ; Thu, 13 Nov 1997 10:33:00 -0800 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA17792 for ; Thu, 13 Nov 1997 10:32:46 -0800 (PST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA18909; Thu, 13 Nov 1997 10:28:30 -0800 (PST) Received: from minnesota.livingston.com (minnesota.livingston.com [149.198.32.23]) by server.livingston.com (8.8.5/8.6.9) with SMTP id KAA07095; Thu, 13 Nov 1997 10:32:33 -0800 (PST) From: Pyda Srisuresh Message-Id: <199711131832.KAA07095@server.livingston.com> Subject: (IPng 4795) Terminology of Address Translation To: george@gideon.bt.co.uk (George Tsirtsis) Date: Thu, 13 Nov 1997 10:35:00 -0800 (PST) Cc: roque@cisco.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: from "George Tsirtsis" at Nov 13, 97 04:22:54 pm Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk Hi, The draft assumes that V4 to V6 and vice versa address mapping is outside the scope of packet/protocol translation and considers the V4-to-V6 packet translators to be stateless. As pointed out by George below, NAT/PTs focus on "Protocol translation". This is different from V4-to-V4 NATs, where address mapping is an integral part of packet translation. As a result, NATs are stateful (i.e., maintain state) on sessions they translate. Unlike NAT/PTs, NATs do not perform protocol translations. Instead, the focus of NATs is principally on address mapping and packet translations as a result of address mapping. So, I would like to suggest that term "NAT" or "NATs" be used strictly in the context on V4-to-V4 address translations and that V4-to-V6 translation be referred to as "NAT/PT" or some other appropriate term that reflects its function as distinguished from NATs. I believe, this will prevent obfuscation of semantics. Thanks. cheers, suresh > > All, > > Sorry for the late reply but to summarise (please correct me if I > misinterpret solutions) and clarify: > > The issue is how you interoperate IPv4 and IPv6. Last year we suggested > to the list that the dualstack routers that ngtrans had adopted as the > main interoperability tool was not enough. We also suggested that a NAT/PT > (v4-v6 NAT combined with Protocol Translator) could enhance the > interoperability of the two protocols. Since then Jim has proposed > the No-Nat solution, involving DHCP servers instead of NAT boxes, and Erik > has written a draft on stateless Protocol Translators. > > All proposals are valid and very important part of the migration process, > they just are applicable to different network configurations. > > * The NAT-PT proposal assumes that IPv4 ONLY hosts want to communicate > with IPv6 ONLY hosts (and the other way around). The problem is that NAT > boxes have all kinds of problems that were highlighted in the NAT BOF > during the last IETF (break end-to-end principle, IPSEC etc...). > > * The No-NAT solution assumes (correct me if I am wrong) that IPv4 ONLY > hosts need to communicate with IPv6/v4 hosts (dualstack or hybrid) and the > other way arrount. The problem here is that the IPv6 hosts also have to > speek IPv4. > > * The Protocol Translation Draft can work with either solution. > > I think this work is very important if we want to see IPv6 being deployed > in any significant scale. > > Regards > George > ------------------- > Internet Transport| > BTLABS | > ------------------------------------------------------------------------- > Notice: This contribution is the personal view of the author and does not > necessarily reflect the technical nor commercial direction of British > Telecommunications plc. > ------------------------------------------------------------------------- > > On Mon, 10 Nov 1997, Pedro Marques wrote: > > > >>>>> "bound" == bound writes: > > > > >>>>>>> "Suresh" == Pyda Srisuresh writes: > > > > Suresh> NAT is used in V4 context only and NOT for V4 to V6 > > Suresh> conversions. > > > > >> I'm sorry Suresh, but i believe you are wrong. There is a > > >> protocol coverter between IPv6 and IPv4 which i know of and > > >> which is refered to as "IPv6 NAT". Whenever the term is used > > >> correctly or incorrectly can be open for discussion but the > > >> fact is that translating between IPv6 and IPv4 is an operation > > >> is all similiar to IPv4 NAT: maintaining mappings between > > >> addresses and tweaking the necessary bits as packets go by. > > > > bound> Not quite. You can translate the addresses using v6 to v4 > > bound> in the header in some fashion, but one can't assume only > > bound> being done with IPv4-compatible/mapped addresses. > > > > To be clear, the implementation i'm refering to doesn't do any assumption > > of that kind. NAT, IPv4 NAT, works basically by mapping an (arbitrary) address > > or group of addresses to another... IPv6 NAT does basically the same job. > > It doesn't even care how long the addresses are... > > > > bound> But one > > bound> cannot translate to IPv4 the Class (maybe if we do TOS bits > > bound> but not the CE bits) and Flow Label. > > > > Since they are undefined in IPv6 at the moment and unused in IPv4, translation > > is quite easy ;-) > > > > bound> It can be done but > > bound> one cannot have the same expectations as v4 to v4. > > > > Because you don't translate TOS to class and vice-versa ? My guess is that > > many users with be able to live pretty well with that limitation. > > > > Pedro. > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 11:46:15 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA13744 for ipng-dist; Thu, 13 Nov 1997 11:43:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA13737 for ; Thu, 13 Nov 1997 11:43:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA26334 for ; Thu, 13 Nov 1997 11:43:06 -0800 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA27504 for ; Thu, 13 Nov 1997 11:42:39 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id LAA20828; Thu, 13 Nov 1997 11:42:37 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA18950; Thu, 13 Nov 1997 11:42:37 -0800 (PST) Date: Thu, 13 Nov 1997 11:42:37 -0800 (PST) Message-Id: <199711131942.LAA18950@pedrom-ultra.cisco.com> From: Pedro Marques To: Pyda Srisuresh Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4796) Terminology of Address Translation In-Reply-To: <199711131832.KAA07095@server.livingston.com> References: <199711131832.KAA07095@server.livingston.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk >>>>> "Suresh" == Pyda Srisuresh writes: Suresh> Hi, Suresh> The draft Suresh> assumes that V4 to V6 and vice versa address mapping is Suresh> outside the scope of packet/protocol translation and Suresh> considers the V4-to-V6 packet translators to be Suresh> stateless. As pointed out by George below, NAT/PTs focus Suresh> on "Protocol translation". Suresh, The "IPv6 NAT" implementation i was refering to has nothing to do with the above draft... Suresh> This is different from V4-to-V4 NATs, where address Suresh> mapping is an integral part of packet translation. Indeed the draft is diferent. In cisco's IPv6 NAT, on the other hand, address mapping is an integral part of translation as in V4-to-V4 NATs. Suresh> As a Suresh> result, NATs are stateful (i.e., maintain state) on Suresh> sessions they translate. Agreed. Suresh> Unlike NAT/PTs, NATs do not Suresh> perform protocol translations. Instead, the focus of NATs Suresh> is principally on address mapping and packet translations Suresh> as a result of address mapping. Network protocol translation is the "easy" part of V6-to-V4 NAT... it's main job is really to maintain address mapping and to do layer4 and up translation / editing. Suresh> So, I would like to suggest that term "NAT" or "NATs" Suresh> be used strictly in the context on V4-to-V4 address Suresh> translations and that V4-to-V6 translation be referred to Suresh> as "NAT/PT" Suresh> or some other appropriate term that reflects Suresh> its function as distinguished from NATs. I would agree that what the draft you mentioned shouldn't be refered to as "NAT"... But there is actually an "V6-V4 NAT". Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 11:57:56 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA13762 for ipng-dist; Thu, 13 Nov 1997 11:52:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA13755 for ; Thu, 13 Nov 1997 11:52:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA29393 for ; Thu, 13 Nov 1997 11:52:37 -0800 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA02857 for ; Thu, 13 Nov 1997 11:52:30 -0800 (PST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA21413; Thu, 13 Nov 1997 11:48:14 -0800 (PST) Received: from minnesota.livingston.com (minnesota.livingston.com [149.198.32.23]) by server.livingston.com (8.8.5/8.6.9) with SMTP id LAA13469; Thu, 13 Nov 1997 11:52:17 -0800 (PST) From: Pyda Srisuresh Message-Id: <199711131952.LAA13469@server.livingston.com> Subject: (IPng 4797) Re: Terminology of Address Translation To: roque@cisco.com (Pedro Marques) Date: Thu, 13 Nov 1997 11:54:44 -0800 (PST) Cc: suresh@livingston.com, ipng@sunroof.eng.sun.com In-Reply-To: <199711131942.LAA18950@pedrom-ultra.cisco.com> from "Pedro Marques" at Nov 13, 97 11:42:37 am Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk > > >>>>> "Suresh" == Pyda Srisuresh writes: > > Suresh> Hi, > > Suresh> The draft > Suresh> assumes that V4 to V6 and vice versa address mapping is > Suresh> outside the scope of packet/protocol translation and > Suresh> considers the V4-to-V6 packet translators to be > Suresh> stateless. As pointed out by George below, NAT/PTs focus > Suresh> on "Protocol translation". > > Suresh, > The "IPv6 NAT" implementation i was refering to has nothing to do with > the above draft... I understand. > > Suresh> This is different from V4-to-V4 NATs, where address > Suresh> mapping is an integral part of packet translation. > > Indeed the draft is diferent. In cisco's IPv6 NAT, on the other hand, > address mapping is an integral part of translation as in V4-to-V4 NATs. > Clearly, the common theme between your implementation and the draft above is that both perform "Protocol translation". > Suresh> As a > Suresh> result, NATs are stateful (i.e., maintain state) on > Suresh> sessions they translate. > > Agreed. > > Suresh> Unlike NAT/PTs, NATs do not > Suresh> perform protocol translations. Instead, the focus of NATs > Suresh> is principally on address mapping and packet translations > Suresh> as a result of address mapping. > > Network protocol translation is the "easy" part of V6-to-V4 NAT... it's main > job is really to maintain address mapping and to do layer4 and up > translation / editing. > Can you refer me to the draft that describes what you are saying, if there is one. Thanks. > Suresh> So, I would like to suggest that term "NAT" or "NATs" > Suresh> be used strictly in the context on V4-to-V4 address > Suresh> translations and that V4-to-V6 translation be referred to > Suresh> as "NAT/PT" > Suresh> or some other appropriate term that reflects > Suresh> its function as distinguished from NATs. > > I would agree that what the draft you mentioned shouldn't be refered to as > "NAT"... But there is actually an "V6-V4 NAT". > > Pedro. > OK, I have no problem with "V6-V4 NAT" or any other term that reflects the "protocol translation" aspect. Thanks. cheers, suresh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 15:27:55 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA14006 for ipng-dist; Thu, 13 Nov 1997 15:24:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA13999 for ; Thu, 13 Nov 1997 15:24:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA06978 for ; Thu, 13 Nov 1997 15:24:32 -0800 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA23155 for ; Thu, 13 Nov 1997 15:24:04 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by trix.cisco.com (8.6.12/8.6.5) with ESMTP id PAA28847; Thu, 13 Nov 1997 15:24:02 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA19052; Thu, 13 Nov 1997 15:24:01 -0800 (PST) Date: Thu, 13 Nov 1997 15:24:01 -0800 (PST) Message-Id: <199711132324.PAA19052@pedrom-ultra.cisco.com> From: Pedro Marques To: Pyda Srisuresh Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4798) Re: Terminology of Address Translation In-Reply-To: <199711131952.LAA13469@server.livingston.com> References: <199711131942.LAA18950@pedrom-ultra.cisco.com> <199711131952.LAA13469@server.livingston.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk >>>>> "Suresh" == Pyda Srisuresh writes: Suresh> Can you refer me to the draft that describes what you are Suresh> saying, if there is one. Thanks. There isn't one since it isn't strictly necessary... the translation is performed by an intermediate box and is transparent to the network. The outputs of the translation box are already defined by the v4 and v6 protocol specs... It looks pretty much like what is described in draft-rfced-info-srisuresh-03.txt... Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 15:49:43 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA14060 for ipng-dist; Thu, 13 Nov 1997 15:46:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA14053 for ; Thu, 13 Nov 1997 15:46:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA12938 for ; Thu, 13 Nov 1997 15:46:28 -0800 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA05794 for ; Thu, 13 Nov 1997 15:46:19 -0800 Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA01293; Thu, 13 Nov 1997 15:36:58 -0800 (PST) Received: from minnesota.livingston.com (minnesota.livingston.com [149.198.32.23]) by server.livingston.com (8.8.5/8.6.9) with SMTP id PAA04283; Thu, 13 Nov 1997 15:41:01 -0800 (PST) From: Pyda Srisuresh Message-Id: <199711132341.PAA04283@server.livingston.com> Subject: (IPng 4799) Re: Terminology of Address Translation To: roque@cisco.com (Pedro Marques) Date: Thu, 13 Nov 1997 15:43:27 -0800 (PST) Cc: suresh@livingston.com, ipng@sunroof.eng.sun.com In-Reply-To: <199711132324.PAA19052@pedrom-ultra.cisco.com> from "Pedro Marques" at Nov 13, 97 03:24:01 pm Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk > > >>>>> "Suresh" == Pyda Srisuresh writes: > > > Suresh> Can you refer me to the draft that describes what you are > Suresh> saying, if there is one. Thanks. > > There isn't one since it isn't strictly necessary... the translation > is performed by an intermediate box and is transparent to the network. > The outputs of the translation box are already defined by the v4 and v6 > protocol specs... > > It looks pretty much like what is described in > draft-rfced-info-srisuresh-03.txt... > > Pedro. > OK, Thanks. cheers, suresh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 16:04:03 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA14091 for ipng-dist; Thu, 13 Nov 1997 15:59:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA14084 for ; Thu, 13 Nov 1997 15:59:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA16458 for ; Thu, 13 Nov 1997 15:59:06 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA10000 for ; Thu, 13 Nov 1997 15:58:59 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA16001; Thu, 13 Nov 1997 17:58:02 -0600 Message-Id: <199711132358.RAA16001@gungnir.fnal.gov> To: iesg@ietf.org Cc: Steve Deering , Bob Hinden , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4800) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-reply-to: Your message of Wed, 12 Nov 1997 18:30:53 EST. <199711122330.SAA27435@ietf.org> Date: Thu, 13 Nov 1997 17:58:01 -0600 Sender: owner-ipng@eng.sun.com Precedence: bulk To the IESG, I think we, the IPNG working group, may have made a poor choice in deciding to complement the universal/local bit when forming an IPv6 address from an EUI-64 identifier. (For details, see draft-ietf-ipngwg-addr-arch-v2-05.txt or draft-ietf-ipngwg-trans-ethernet-04.txt.) It's a poor choice I could live with, but I'm hoping it can be scrutinized first by individuals who weren't involved in the choice. As long as the point is examined, any outcome will be acceptable. The trade-off, as I see it, is this: With the current documents, small integers may be freely used as interface identifers, forming, for example, the Subnet-Router anycast address which neatly ends with 64 zero bits. But nodes auto-configuring their IPv6 unicast addresses must flip a single bit in their built-in address to form their Interface Identifier. The Address Architecture and the IPv6-over-(various 802 media) devote several paragraphs to explaining the bit- flipping, and the identities of nodes whose IPv6 addresses appear in neighbor tables or packet traces are slightly obscured by the alteration of the bit. If the spec were written the other way, so that an EUI-64 is used directly as an Interface Identifier, the language in the documents would be simpler, MAC addresses would be somewhat more recognizable in packet traces or tables. On the down side, those small-integer identifiers would have to look like this 3ffe:7c0:40:9:200::0 instead of the current 3ffe:7c0:40:9::0 We might arguably appear a little more IEEE-friendly by not fiddling with the bit, but I can't really make a case on that argument. The simplification of the specs is my main point. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 16:28:02 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA14310 for ipng-dist; Thu, 13 Nov 1997 16:24:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA14303 for ; Thu, 13 Nov 1997 16:24:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA24134 for ; Thu, 13 Nov 1997 16:24:28 -0800 Received: from arthur.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA22227 for ; Thu, 13 Nov 1997 16:24:24 -0800 (PST) Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by arthur.axion.bt.co.uk with SMTP (PP); Fri, 14 Nov 1997 00:16:59 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA00638; Thu, 13 Nov 1997 21:50:21 GMT Date: Thu, 13 Nov 1997 21:50:20 +0000 (GMT) From: George Tsirtsis To: Pyda Srisuresh Cc: Pedro Marques , ipng@sunroof.eng.sun.com Subject: (IPng 4801) Re: Terminology of Address Translation In-Reply-To: <199711131952.LAA13469@server.livingston.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk On Thu, 13 Nov 1997, Pyda Srisuresh wrote: > > > Suresh> So, I would like to suggest that term "NAT" or "NATs" > > Suresh> be used strictly in the context on V4-to-V4 address > > Suresh> translations and that V4-to-V6 translation be referred to > > Suresh> as "NAT/PT" > > Suresh> or some other appropriate term that reflects > > Suresh> its function as distinguished from NATs. > > > > I would agree that what the draft you mentioned shouldn't be refered to as > > "NAT"... But there is actually an "V6-V4 NAT". > > > > Pedro. > > > > OK, I have no problem with "V6-V4 NAT" or any other term that reflects the > "protocol translation" aspect. Thanks. > > cheers, > suresh In fact a NAT-PT is more a PT than a NAT. By that i meen that the main function is Protocol Translation from IPv4 to IPv6 and the other way arround. The NAT part of NAT-PT says that there is a pull of addresses that the protocol translator uses during the header translation. So, There are three functions: * NAT-PT: Protocol Translation and a pool of addresses There are two modes of operation for that: ___________ / \ [IPv6 Host]---[NAT-PT]-------< IPv4 network>--[IPv4 Host] | \___________/ (pool of v4 addresses) ___________ / \ [IPv4 Host]---[NAT-PT]-------< IPv6 network>--[IPv6 Host] | \___________/ (pool of v6 addresses) Note that the second could become useful the world is taken over by IPv6 and there are only some remaining pockets of IPv4 :) * No-NAT: No Protocol Translation, dualstack hosts and a pool of addresses in a DHCP server. In this case the IPv6/v4 host has an IPv6 address and only takes a v4 address through the DHCP server from the pool of addresses. (details to come with Jim's draft?) ___________ / \ [IPv6/v4 Host]------< IPv4 Network>------[IPv4 Host] | \___________/ [DHCP server] | (pool of IPv4 addresses) * PT-DHCP?: This is a combination of Erik's PT and Jim's No-NAT. In this case there is a protocol translator, as in the NAT-PT, but the addresses come from a DHCP server, as in No-NAT. Would that be useful? I think we have not yet solved the implication that the above proposals have to DNS; there were some proposals from us, as well as from jim and I hope we will discuss those in the next meeting. Regards George ------------------ Internet Transport| BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 16:41:01 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA14339 for ipng-dist; Thu, 13 Nov 1997 16:38:00 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA14332 for ; Thu, 13 Nov 1997 16:37:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA28654 for ; Thu, 13 Nov 1997 16:37:48 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA28706 for ; Thu, 13 Nov 1997 16:37:49 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20862; Thu, 13 Nov 1997 16:37:48 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Nov 1997 16:37:00 -0800 To: IPng Working Group From: Steve Deering Subject: (IPng 4802) increasing the IPv6 minimum MTU Cc: hinden@ipsilon.com Sender: owner-ipng@eng.sun.com Precedence: bulk In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e., 1500 minus room for a couple layers of encapsulating headers, so that min- MTU-size packets that are tunneled across 1500-byte-MTU paths won't be subject to fragmentation/reassembly on ingress/egress from the tunnels, in most cases). After the short discussion in the Munich meeting, I called for a show of hands, and of those who raised their hands (about half the attendees, if I recall correctly), the vast majority were in favor of this change -- there were only two or three people opposed. However, we recognized that a fundamental change of this nature requires thoughtful discussion and analysis on the mailing list, to allow those who were not at the meeting and those who were there but who have since had second thoughts, to express their opinions. A couple of people have already, in private conversation, raised some concerns that were not identified in the discussion at the meeting, which I report below. We would like to get this issue settled as soon as possible, since this is the only thing holding up the publication of the updated Proposed Standard IPv6 spec (the version we expect to advance to Draft Standard), so let's see if we can come to a decision before the ID deadline at the end of next week (hoping there isn't any conflict between "thoughtful analysis" and "let's decide quickly" :-). The reason I would like to increase the minimum MTU is that there are some applications for which Path MTU Discovery just won't work very well, and which will therefore limit themselves to sending packets no larger than the minimum MTU. Increasing the minimum MTU would improve the bandwidth efficiency, i.e., reduce the header overhead (ratio of header bytes to payload bytes), for those applications. Some examples of such applications are: (1) Large-fanout, high-volume multicast apps, such as multicast video ("Internet TV"), multicast netnews, and multicast software distribution. I believe these applications will end up limiting themselves to packets no large than the min MTU in order to avoid the danger of incurring an "implosion" of ICMP Packet-Too-Big messages in response. Even though we have specified that router implementations must carefully rate-limit the emission of ICMP error messages, I am nervous about how well this will work in practice, especially once there is a lot of high-speed, bulk multicasting happening. An appropriate choice of rate or probability of emission of Packet-Too-Big responses to multicasts really depends on the fan-out of the multicast trees and the MTUs of all the branches in that tree, which is unknown and unknowable to the routers. Being sensibly conservative by choosing a very low rate could, in many cases, significantly increase the delay before the multicast source learns the right MTU for the tree and, hence, before receivers on smaller-MTU branches can start receiving the data. (2) DNS servers, or other similar apps that have the requirement of sending a small amount of data (a few packets at most) to a very large and transient set of clients. Such servers often reside on links, such as Ethernet, that have an MTU bigger than the links on which many of their clients may reside, such as dial-up links. If those servers were to send many reply messages of the size of their own links (as required by PMTU Discovery), they could incur very many ICMP packet-too-big messages and consequent retransmissions of the replies -- in the worse case, multiplying the total bandwidth consumption (and delivery delay) by 2 or 3 times that of the alternative approach of just using the min MTU always. Furthermore, the use of PMTU Discovery could result in such servers filling up lots of memory withed cached PMTU information that will never be used again (at least, not before it gets garbage-collected). The number I propose for the new minimum MTU is 1280 bytes (1024 + 256, as compared to the classic 576 value which is 512 + 64). That would leave generous room for encapsulating/tunnel headers within the Ethernet MTU of 1500, e.g., enough for two layers of secure tunneling including both ESP and AUTH headers. For medium-to-high speed links, this change would reduce the IPv6 header overhead for min MTU packets from 7% to 3% (a little less than the IPv4 header overhead for 576-byte IPv4 packets). For low-speed links such as analog dial-up or low-speed wireless, I assume that header compression will be employed, which compresses out the IPv6 header completely, so the IPv6 header overhead on such links is effectively zero in any case. Here is a list of *disadvantages* to increasing the IPv6 minimum MTU that have been raised, either publically or privately: (1) This change would require the specification of link-specific fragmentation and reassembly protocols for those link-layers that can support 576-byte packets but not 1280-byte packets, e.g., AppleTalk. I think such a protocol could be very simple, and I briefly sketch such a protocol in Appendix I of this message, as an example. Often, those links that have a small native MTU are also the ones that have low bandwidth. On low-bandwidth links, it is often desirable to locally fragment and reassemble IPv6 packets anyway (even 576-byte ones) in order to avoid having small, interactive packets (e.g., keystrokes, character echoes, or voice samples) be delayed excessively behind bigger packets (e.g., file transfers); the small packets can be interleaved with the fragments of the big packets. Someone mentioned in the meeting in Munich that the ISSLL WG was working on a PPP-specific fragmentation and reassembly protocol for precisely this reason, so maybe the job of specifying such a protocol is already being taken care of. (2) Someone raised the concern that, if we make the minimum MTU close to Ethernet size, implementors might never bother to implement PMTU Discovery. That would be regrettable, especially if the Internet evolves to much more widespread use of links with MTUs bigger than Ethernet's, since IPv6 would then fail to take advantage of the bandwidth efficiencies possible on larger MTU paths. (3) Peter Curran pointed out to me that using a larger minimum MTU for IPv6 may result in much greater reliance on *IPv4* fragmentation and reassembly during the transition phase while much of the IPv6 traffic is being tunneled over IPv4. This could incur unfortunate performance penalties for tunneled IPv6 traffic (disasterous penalties if there is non-negligible loss of IPv4 fragments). I have included Peter's message, describing his concern in more detail, in Appendix II of this message. (4) Someone expressed the opinion that the requirement for link-layer fragmentation and reassembly of IPv6 over low-cost, low-MTU links like Firewire, would doom the potential use of IPv6 in cheap consumer devices in which minimizing code size is important -- implementors of cheap Firewire devices would choose IPv4 instead, since it would not need a fragmenting "shim" layer. This may well be true, though I suspect the code required for local frag/reasm would be negligible compared to the code required for Neighbor Discovery. Personally, I am not convinced by the above concerns that increasing the minimum MTU would be a mistake, but I'd like to hear what the rest of the WG thinks. Are there other problems that anyone can think of? As I mentioned earlier, the clear consensus of the Munich attendees was to increase the minimum MTU, so we need to find out if these newly-identified problems are enough to swing the consensus in the other direction. Your feedback is heartily requested. Steve ---------- Appendix I Here is a sketch of a fragmentation and reassembly protocol (call it FRP) to be employed between the IP layer and the link layer of a link with native (or configured) MTU less than 1280 bytes. Identify a Block Size, B, which is the lesser of (a) the native MTU of the link or (b) a value related to the bandwidth of the link, chosen to bound the latency that one block can impose on a subsequent block. For example, to stay within a latency of 200 ms on a 9600 bps link, choose a block size of .2 * 9600 = 2400 bits = 240 bytes. IPv6 packets of length <= B are transmitted directly on the link. IPv6 packets of length > B are fragmented into blocks of size B (the last block possibly being shorter than B), and those fragments are transmitted on the link with an FRP header containing the following fields: [packet ID, block number, end flag] where: packet ID is the same for all fragments of the same packet, and is incremented for each new fragmented packet. The size of the packet ID field limits how many packets can be in flight or interleaved on the link at any one time. block number identifies the blocks within a packet, starting at block zero. The block number field must be large enough to identify 1280/B blocks. end flag is a one-bit flag which is used to mark the last block of a packet. For example, on a 9600 bps serial link, one might use a block size of 240 bytes and an 8-bit FRP header of the following format: 4-bit packet ID, which allows interleaving of up to 16 packets. 3-bit block number, to identify blocks numbered 0 through 5. 1-bit end flag. On a 256 kpbs AppleTalk link, one might use the AppleTalk-imposed block size of ~580 bytes and an 8-bit FRP header of the following format: 5-bit packet ID, which allows for up to 32 fragmented packets in flight from each source across the AppleTalk internet. 2-bit block number, to identify blocks numbered 0 through 2. 1-bit end flag. On a multi-access link, like AppleTalk, the receiver uses the link-level source address as well as the packet ID to identify blocks belonging to the same packet. If a receiver fails to receive all of the blocks of a packet by the time the packet number wraps around, it discards the incompletely-reassembled packet. Taking this approach, no timers should be needed at the receiver to detect fragment loss. We expect the transport layer (e.g., TCP) checksum at the final IPv6 destination to detect mis-assembly that might be caused by extreme misordering/delay during transit across the link. On links on which IPv6 header compression is being used, compression is performed before fragmentation, and reassembly is done before decompression. ---------- Appendix II From: Peter Curran Subject: Re: IPv6 MTU issue To: deering@cisco.com (Steve Deering) Date: Mon, 22 Sep 1997 11:50:34 +0100 (BST) Steve My problem was that moving the MTU close to 1500 would have an adverse effect on the transition strategy. The current strategy assumes that the typical Internet MTU is >576, and that sending an IPv6 packet close to the minimum MTU will not require any IPv4 fragmentation to support the tunnel transparently. The PMTU discovery mechanism will 'tune' IPv6 to use a suitable MTU. If the IPv4 MTU is <= 576 then IPv4 fragmentation will be required to provide a tunnel with a minimum MTU of 576 for IPv6. This clearly places a significant strain on the tunnelling nodes - as these will normally be routers then there will be a demand for memory (for reassembly buffers) as well as CPU (for the frag/reassembly process) that will have an overall impact on performance. This is an acceptable risk, as Internet MTU's of <= 576 are not too common. However, if the minimum MTU of IPv6 is increased to something of the order of 1200-1500 octets then the likelihood of finding an IPv4 path with an MTU lower than this value increases (I think significantly) and this will have a performance impact on these devices. During the brief discussion of this matter in the IPNG session at Munich you stated that MTU's less than 1500 where rare. I don't agree with this completely - it seems to be pretty common practise for smaller 2nd and 3rd tier ISP's in the UK to use an MTU of 576 for connection to their transit provider. Their objective, I believe, is to 'normalize' the packet sizes on relatively low bandwidth circuits (typically <1Mbps) to provide better performance for interactive sessions compared to bulk-file transfer users. I think that before we go ahead and make a decision on an increased minimum MTU for IPv6 then we should discuss the issues a little more. Incidentally, I am not convinced of the benefits of doing this anyway (ignoring the issue raised above). With a properly setup stack the PMTU discovery mechanism seems to be able to select a good MTU for use on the path - at least that is my experience on our test network and the 6Bone. I appreciate that you are trying to address the issues of PMTU for multi- casting but I don't see how raising the minumum MTU is going to help much. PMTU discovery will still be required irrespective of the minimum MTU adopted, unless we adopt a value that can be used on all link-layer technolo- gies. I would welcome wider discussion of these issues before pressing ahead with a change. Best regards Peter Curran TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 17:00:55 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA14394 for ipng-dist; Thu, 13 Nov 1997 16:57:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA14387 for ; Thu, 13 Nov 1997 16:57:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA06668 for ; Thu, 13 Nov 1997 16:57:31 -0800 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA08012 for ; Thu, 13 Nov 1997 16:57:22 -0800 (PST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA03655; Thu, 13 Nov 1997 16:53:06 -0800 (PST) Received: from minnesota.livingston.com (minnesota.livingston.com [149.198.32.23]) by server.livingston.com (8.8.5/8.6.9) with SMTP id QAA10754; Thu, 13 Nov 1997 16:57:08 -0800 (PST) From: Pyda Srisuresh Message-Id: <199711140057.QAA10754@server.livingston.com> Subject: (IPng 4803) Re: Terminology of Address Translation To: george@gideon.bt.co.uk (George Tsirtsis) Date: Thu, 13 Nov 1997 16:59:35 -0800 (PST) Cc: suresh@livingston.com, roque@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: from "George Tsirtsis" at Nov 13, 97 09:50:20 pm Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk > > On Thu, 13 Nov 1997, Pyda Srisuresh wrote: > > > > > > Suresh> So, I would like to suggest that term "NAT" or "NATs" > > > Suresh> be used strictly in the context on V4-to-V4 address > > > Suresh> translations and that V4-to-V6 translation be referred to > > > Suresh> as "NAT/PT" > > > Suresh> or some other appropriate term that reflects > > > Suresh> its function as distinguished from NATs. > > > > > > I would agree that what the draft you mentioned shouldn't be refered to as > > > "NAT"... But there is actually an "V6-V4 NAT". > > > > > > Pedro. > > > > > > > OK, I have no problem with "V6-V4 NAT" or any other term that reflects the > > "protocol translation" aspect. Thanks. > > > > cheers, > > suresh > > In fact a NAT-PT is more a PT than a NAT. By that i meen that the main > function is Protocol Translation from IPv4 to IPv6 and the other way > arround. The NAT part of NAT-PT says that there is a pull of addresses > that the protocol translator uses during the header translation. > > So, There are three functions: > * NAT-PT: Protocol Translation and a pool of addresses > There are two modes of operation for that: > ___________ > / \ > [IPv6 Host]---[NAT-PT]-------< IPv4 network>--[IPv4 Host] > | \___________/ > (pool of v4 addresses) > > ___________ > / \ > [IPv4 Host]---[NAT-PT]-------< IPv6 network>--[IPv6 Host] > | \___________/ > (pool of v6 addresses) > > Note that the second could become useful the world is taken over by IPv6 > and there are only some remaining pockets of IPv4 :) > > * No-NAT: No Protocol Translation, dualstack hosts and a pool of > addresses in a DHCP server. In this case the IPv6/v4 host has an IPv6 > address and only takes a v4 address through the DHCP server from the pool > of addresses. (details to come with Jim's draft?) > ___________ > / \ > [IPv6/v4 Host]------< IPv4 Network>------[IPv4 Host] > | \___________/ > [DHCP server] > | > (pool of IPv4 addresses) > > * PT-DHCP?: This is a combination of Erik's PT and Jim's No-NAT. In this > case there is a protocol translator, as in the NAT-PT, but the addresses > come from a DHCP server, as in No-NAT. Would that be useful? > > I think we have not yet solved the implication that the above proposals > have to DNS; there were some proposals from us, as well as from jim and I > hope we will discuss those in the next meeting. > > Regards > George > ------------------ > Internet Transport| > BTLABS | > -------------------------------------------------------------------------- > Notice: This contribution is the personal view of the author and does not > necessarily reflect the technical nor commercial direction of British > Telecommunications plc. > -------------------------------------------------------------------------- > > Great, thanks for the clarification. I think, it would be useful to have these diagrams (especially the first two) in the draft . No-NAT setup above sounds like a V6-to-V4 gateway, using DHCP to obtain a V4 address to map to its V6 address. With no protocol translation in the box, I imagine, there exists a gateway agent that terminates the session on either end(i.e., V4 end with remote host and V6 end internally to iteself) and pushes the payload from one side to the other. I assume, this agent is also responsible for any payload interpretations, when the payload contains IP (v4 or V6) addresses. Does this make sense? Thanks. cheers, suresh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 17:48:30 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id RAA14517 for ipng-dist; Thu, 13 Nov 1997 17:45:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id RAA14510 for ; Thu, 13 Nov 1997 17:45:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA20551 for ; Thu, 13 Nov 1997 17:45:00 -0800 Received: from brownale.cisco.com (brownale.cisco.com [171.69.95.89]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id RAA29886 for ; Thu, 13 Nov 1997 17:44:12 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by brownale.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id RAA10907; Thu, 13 Nov 1997 17:43:33 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id RAA19194; Thu, 13 Nov 1997 17:43:32 -0800 (PST) Date: Thu, 13 Nov 1997 17:43:32 -0800 (PST) Message-Id: <199711140143.RAA19194@pedrom-ultra.cisco.com> From: Pedro Marques To: George Tsirtsis Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4804) Re: Terminology of Address Translation In-Reply-To: References: <199711131952.LAA13469@server.livingston.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk >>>>> "George" == George Tsirtsis writes: George> In fact a NAT-PT is more a PT than a NAT. That's a subjective assessment... i happen to think otherwise. George> By that i meen George> that the main function is Protocol Translation from IPv4 George> to IPv6 and the other way arround. The NAT part of NAT-PT George> says that there is a pull of addresses that the protocol George> translator uses during the header translation. George> So, There are three functions: * NAT-PT: Protocol George> Translation and a pool of addresses There are two modes of George> operation for that: ___________ / \ [IPv6 Host]---[NAT-PT]-------< IPv4 network>--[IPv4 Host] | \___________/ (pool of v4 addresses) ___________ / \ [IPv4 Host]---[NAT-PT]-------< IPv6 network>--[IPv6 Host] | \___________/ (pool of v6 addresses) George> Note that the second could become useful the world is George> taken over by IPv6 and there are only some remaining George> pockets of IPv4 :) Not true. The main objective of a NAT box is to interconnect networks that take thier addresses from different "addressing domains"... You need that pool of v6 addresses to be able to access a server in a v6 network from a client in a v4 network... (server = host that does passive open; client = host that does active open) The typical application domain of the above is exactly the usual application domain of IPv4 NAT: connect an "private" network (in this case a IPv6 network) to a "public" network (usually the v4 Internet). Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 20:29:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id UAA14594 for ipng-dist; Thu, 13 Nov 1997 20:26:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id UAA14587 for ; Thu, 13 Nov 1997 20:26:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA17541 for ; Thu, 13 Nov 1997 20:26:21 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA29609 for ; Thu, 13 Nov 1997 20:26:19 -0800 (PST) From: Masataka Ohta Message-Id: <199711140419.NAA12085@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA12085; Fri, 14 Nov 1997 13:19:33 +0900 Subject: (IPng 4805) Re: increasing the IPv6 minimum MTU To: deering@cisco.com (Steve Deering) Date: Fri, 14 Nov 97 13:19:32 JST Cc: ipng@sunroof.eng.sun.com, hinden@ipsilon.com In-Reply-To: ; from "Steve Deering" at Nov 13, 97 4:37 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@eng.sun.com Precedence: bulk Steve; > a fundamental change of this nature requires thoughtful discussion and > of the updated Proposed Standard IPv6 spec (the version we expect to advance > to Draft Standard), so let's see if we can come to a decision before the ID Can the draft advance to Draft Standard, dispite the fundamental change? > The number I propose for the new minimum MTU is 1280 bytes (1024 + 256, > as compared to the classic 576 value which is 512 + 64). Does 1024+256 means that there is a new restriction that the maximum overhead before real payload (removing all the header like things) is limited to 256? With 576, it is obvious that it is, in this sense, not 512+64 and header like things, sometimes, must be longer than 64 bytes, without which things like routing headers are meaningless, which means 512 byte payload of DNS is unsafe, which was my concern. > (4) Someone expressed the opinion that the requirement for link-layer > fragmentation and reassembly of IPv6 over low-cost, low-MTU links > like Firewire, would doom the potential use of IPv6 in cheap > consumer devices in which minimizing code size is important -- > implementors of cheap Firewire devices would choose IPv4 instead, > since it would not need a fragmenting "shim" layer. This may well > be true, though I suspect the code required for local frag/reasm > would be negligible compared to the code required for Neighbor > Discovery. The MTU of Firewire for best effort communication is only 512 byte long, which was already a problem when minimum MTU was 576, which I pointed out last year, which already caused IP over Firewire proposals use link fragmentation (even for IPv4). Now, it was revealed that the MTU of Firewire for QoSed communication can be as small as 32. So, who cares? Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 21:09:57 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id VAA14695 for ipng-dist; Thu, 13 Nov 1997 21:07:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id VAA14688 for ; Thu, 13 Nov 1997 21:06:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA24041 for ; Thu, 13 Nov 1997 21:06:57 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id VAA13932 for ; Thu, 13 Nov 1997 21:06:56 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA09217; Thu, 13 Nov 97 21:05:02 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id VAA03674; Thu, 13 Nov 1997 21:07:41 -0800 Date: Thu, 13 Nov 1997 21:07:41 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199711140507.VAA03674@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4806) Re: increasing the IPv6 minimum MTU X-Sun-Charset: US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Steve, > > (1) This change would require the specification of link-specific > fragmentation and reassembly protocols for those link-layers > that can support 576-byte packets but not 1280-byte packets, > e.g., AppleTalk. I think such a protocol could be very simple, > and I briefly sketch such a protocol in Appendix I of this > message, as an example. > I believe that AppleTalk already has at least one fragmentation mechanism which would allow it to deal with the increased MinMTU. If we choose to change this I don't think AppleTalk will require extra attention. > > (2) Someone raised the concern that, if we make the minimum MTU close > to Ethernet size, implementors might never bother to implement PMTU > Discovery. That would be regrettable, especially if the Internet > evolves to much more widespread use of links with MTUs bigger > than Ethernet's, since IPv6 would then fail to take advantage of > the bandwidth efficiencies possible on larger MTU paths. > PMTU discovery needs to be implemented in everything except the most hard- ware limited implementations. I would argue that it actually should be a MUST not a SHOULD. I really hope implementors don't take a pass on PMTU discovery. That would be a real disaster. > (3) Peter Curran pointed out to me that using a larger minimum MTU for > IPv6 may result in much greater reliance on *IPv4* fragmentation and > reassembly during the transition phase while much of the IPv6 > traffic is being tunneled over IPv4. This could incur unfortunate > performance penalties for tunneled IPv6 traffic (disasterous > penalties if there is non-negligible loss of IPv4 fragments). > I have included Peter's message, describing his concern in more > detail, in Appendix II of this message. > After reading this argument it occurs to me that if we really wanted to deal with this problem we probably should have made the IPv6 MinMTU 556 (576 - 20 bytes of IPv4 header). That would have dealt with the IPv4 tunnel frag- mentation issue more completely. Is my thinking correct here? > > Personally, I am not convinced by the above concerns that increasing the > minimum MTU would be a mistake, but I'd like to hear what the rest of the > WG thinks. Are there other problems that anyone can think of? As I > mentioned earlier, the clear consensus of the Munich attendees was to > increase the minimum MTU, so we need to find out if these newly-identified > problems are enough to swing the consensus in the other direction. Your > feedback is heartily requested. > The only argument I find compelling is 3. However, I don't believe the current IPv6 MinMTU actually addresses the issue raised in 3. In order to properly align the IPv6 MinMTU with the IPv4 MinMTU for the purposes of IPv6-in-IPv4 tunnelling I believe we would need to reduce the IPv6 MinMTU a further 20 bytes to 556. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 22:04:16 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id WAA14738 for ipng-dist; Thu, 13 Nov 1997 22:01:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id WAA14731 for ; Thu, 13 Nov 1997 22:01:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA01574 for ; Thu, 13 Nov 1997 22:01:17 -0800 Received: from hitiij.hitachi.co.jp (hitiij.hitachi.co.jp [133.145.224.3]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA28336 for ; Thu, 13 Nov 1997 22:01:09 -0800 Received: from isrdgw.isrd.hitachi.co.jp by hitiij.hitachi.co.jp (8.8.5+2.7Wbeta5/3.5W-hitiij) id OAA25850; Fri, 14 Nov 1997 14:52:38 +0900 (JST) Received: from magic.33g.isrd.hitachi.co.jp by isrdgw.isrd.hitachi.co.jp (8.6.9+2.4W/2.7W-ISRD) id PAA08399; Fri, 14 Nov 1997 15:00:46 +0900 Message-Id: <9711140604.AA00404@magic.33g.isrd.hitachi.co.jp> From: tsuchiya Date: Fri, 14 Nov 1997 15:04:54 +0900 To: hinden@Ipsilon.COM, deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4807) IPv4/IPv6 translator MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@eng.sun.com Precedence: bulk Hi, My name is Kazuaki Tsuchiya. I work at Hitachi, Ltd. in Japan and develop an IPv6 router (NR60). I am also a WIDE project member. Various transition mechanisms have been already studied as ways to transit from an IPv4 to an IPv6 smoothly. Additionally I think that it is necessary to be able to communicate between an IPv6-only node and an IPv4-only node. So now I am writing an Internet-Draft about it and I will submit it next Monday. Would you plese have time to talk about it at the ipngwg next IETF meeting in Washington, DC? Thanks, -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 13 22:12:18 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id WAA14756 for ipng-dist; Thu, 13 Nov 1997 22:09:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id WAA14749 for ; Thu, 13 Nov 1997 22:09:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA02821 for ; Thu, 13 Nov 1997 22:09:24 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA28010 for ; Thu, 13 Nov 1997 22:09:25 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA11282; Thu, 13 Nov 1997 22:09:06 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199711140419.NAA12085@necom830.hpcl.titech.ac.jp> References: ; from "Steve Deering" at Nov 13, 97 4:37 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Nov 1997 22:10:17 -0800 To: Masataka Ohta From: Steve Deering Subject: (IPng 4808) Re: increasing the IPv6 minimum MTU Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@eng.sun.com Precedence: bulk At 8:19 PM -0800 11/13/97, Masataka Ohta wrote: > > a fundamental change of this nature requires thoughtful discussion and > > of the updated Proposed Standard IPv6 spec (the version we expect to >advance > > to Draft Standard), so let's see if we can come to a decision before the ID > > Can the draft advance to Draft Standard, dispite the fundamental > change? It's a change of quantity, not a change of semantics, so maybe yes. It will be up to the IESG to decide, assuming the WG approves. > Does 1024+256 means that there is a new restriction that the > maximum overhead before real payload (removing all the header > like things) is limited to 256? No. That was just an explanation of where the 1280 number came from. It does not limit total length of headers to 256 bytes any more than the 576 (64+512) MTU limted headers to 64 bytes. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 00:05:21 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id AAA14844 for ipng-dist; Fri, 14 Nov 1997 00:02:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id AAA14837 for ; Fri, 14 Nov 1997 00:02:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA16584 for ; Fri, 14 Nov 1997 00:02:15 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id AAA25189 for ; Fri, 14 Nov 1997 00:02:02 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA02587; Fri, 14 Nov 1997 19:01:35 +1100 (from kre@munnari.OZ.AU) To: Steve Deering Cc: IPng Working Group , hinden@ipsilon.com Subject: (IPng 4809) Re: increasing the IPv6 minimum MTU In-Reply-To: Steve Deering's message of "Thu, 13 Nov 1997 16:37:00 -0800." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Nov 1997 19:01:30 +1100 Message-Id: <5961.879494490@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@eng.sun.com Precedence: bulk Date: Thu, 13 Nov 1997 16:37:00 -0800 From: Steve Deering Message-ID: | (1) This change would require the specification of link-specific | fragmentation It would. That is, as you point out, probably going to be for their benefit anyway. Not a significant objection. | (2) Someone raised the concern that, if we make the minimum MTU close | to Ethernet size, implementors might never bother to implement PMTU | Discovery. Implementors might not bother to implement it anyway, based upon the practical vision (correct or not) that they're not going to see a MTU less than 1500 that doesn't have a shim layer anyway. We can't make decisions based on what sub-standard implementations might do. | (3) Peter Curran pointed out to me that using a larger minimum MTU for | IPv6 may result in much greater reliance on *IPv4* fragmentation and | reassembly during the transition phase I would absolutely hate to nobble IPv6 forever based upon some perceived transition difficulty. Even if this were to be a significant problem, which I doubt (if those UK ISPs who think they're achieving something by limiting the MTU eventually receive lots of complaints that IPv6 traffic is being damaged by their policy, they can simply change it - the low MTU there is not something that cannot be easily altered). | (4) Someone expressed the opinion that the requirement for link-layer | fragmentation and reassembly of IPv6 over low-cost, low-MTU links | like Firewire, would doom the potential use of IPv6 in cheap | consumer devices in which minimizing code size is important -- This is very hard to imagine, if necessary on a link layer that is intended for very cheap devices (or which might be used that way) the shim layer can be defined to be very simple - allowing no interleaving of packets at all, simply sending N link layer packets, one after another, in order, which combined make the full packet. The code required to do that is trivial. They wouldn't get all the benefits they could get from a shim layer, but that is just a trade off for simplicity. | Personally, I am not convinced by the above concerns that increasing the | minimum MTU would be a mistake, I am convinced that not increasing the minimum MTU over 576 would be a mistake. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 00:45:53 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id AAA14902 for ipng-dist; Fri, 14 Nov 1997 00:43:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id AAA14895 for ; Fri, 14 Nov 1997 00:43:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA20704 for ; Fri, 14 Nov 1997 00:42:58 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id AAA05985 for ; Fri, 14 Nov 1997 00:42:58 -0800 (PST) From: Masataka Ohta Message-Id: <199711140835.RAA12447@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA12447; Fri, 14 Nov 1997 17:35:29 +0900 Subject: (IPng 4810) Re: increasing the IPv6 minimum MTU To: deering@cisco.com (Steve Deering) Date: Fri, 14 Nov 97 17:35:27 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: ; from "Steve Deering" at Nov 13, 97 10:10 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@eng.sun.com Precedence: bulk Steve; > > > a fundamental change of this nature requires thoughtful discussion and > > > of the updated Proposed Standard IPv6 spec (the version we expect to > >advance > > > to Draft Standard), so let's see if we can come to a decision before the ID > > > > Can the draft advance to Draft Standard, dispite the fundamental > > change? > > It's a change of quantity, not a change of semantics, so maybe yes. It > will be up to the IESG to decide, assuming the WG approves. Political distortion of procedure will be rewarded accordingly. > > Does 1024+256 means that there is a new restriction that the > > maximum overhead before real payload (removing all the header > > like things) is limited to 256? > > No. That was just an explanation of where the 1280 number came from. > It does not limit total length of headers to 256 bytes any more > than the 576 (64+512) MTU limted headers to 64 bytes. Making MTU 1280 does not help so much unless the total length of headers is limited to 768 (not necessarily 256). BTW, don't we need some recommendation that raw link MTU should be >=1500, not just 1280? Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 02:23:46 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id CAA15017 for ipng-dist; Fri, 14 Nov 1997 02:21:02 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id CAA15010 for ; Fri, 14 Nov 1997 02:20:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA00411 for ; Fri, 14 Nov 1997 02:20:51 -0800 Received: from dent.axion.bt.co.uk (dent.axion.bt.co.uk [132.146.16.161]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id CAA00364 for ; Fri, 14 Nov 1997 02:20:50 -0800 (PST) Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by dent.axion.bt.co.uk with SMTP (PP); Fri, 14 Nov 1997 10:18:50 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA01876; Fri, 14 Nov 1997 10:17:55 GMT Date: Fri, 14 Nov 1997 10:17:55 +0000 (GMT) From: George Tsirtsis To: Pedro Marques Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4812) Re: Terminology of Address Translation In-Reply-To: <199711140143.RAA19194@pedrom-ultra.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk On Thu, 13 Nov 1997, Pedro Marques wrote: > > ___________ > / \ > [IPv4 Host]---[NAT-PT]-------< IPv6 network>--[IPv6 Host] > | \___________/ > (pool of v6 addresses) > > > George> Note that the second could become useful the world is > George> taken over by IPv6 and there are only some remaining > George> pockets of IPv4 :) > > Not true. The main objective of a NAT box is to interconnect networks > that take thier addresses from different "addressing domains"... > You need that pool of v6 addresses to be able to access a server > in a v6 network from a client in a v4 network... > > (server = host that does passive open; client = host that does active open) > > The typical application domain of the above is exactly the usual application > domain of IPv4 NAT: connect an "private" network (in this case a IPv6 network) > to a "public" network (usually the v4 Internet). > > Pedro. > Not exactly necessary. According to what you say, all IPv4 networks that want to communicate with IPv6 ONLY hosts should get a NAT-PT box. This can be done but we may be able to get away with something easier. Actually we have been through this before but it goes like this: -An IPv4 host wants to contact an IPv6 ONLY host. -The IPv4 host knows the dns name of the IPv6 hosts (this has the same format with IPv4). -The dns lookup, however, can not return an IPv4 address since the IPv6 host only speeks IPv6. The dns server recognises that an AA record was requested but this name only has AAAA record and makes a request to the parent dns server. -The idea is to go back towards the IPv6 network where there is a NAT box that can allocate a temporary IPv4 address to the IPv6 host and through dns return it to the IPv4 host. (A mechanism to update dns from a NAT box is required? exists?). -Now the IPv4 host can use this address and send packets to the IPv6 host through the NAT-PT box that is located at the edge of the IPv6 network. This way you avoid having NAT-PT boxes allover the place. I think it is important to make the transition to IPv6 seamless to the IPv4 networks. We should not require IPv4 domains to do anything in order to have basic connectivity to IPv6. This should be taken care of by the IPv6 domains. The No-NAT solution does that and so should the NAT-PT solution. Regards George ----------------------------- Internet Transport Research BTLABS ------------------------------------------------------------------------ Notice: this contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 02:29:08 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id CAA15035 for ipng-dist; Fri, 14 Nov 1997 02:26:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id CAA15028 for ; Fri, 14 Nov 1997 02:25:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA00794 for ; Fri, 14 Nov 1997 02:25:44 -0800 Received: from dent.axion.bt.co.uk (dent.axion.bt.co.uk [132.146.16.161]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id CAA01523 for ; Fri, 14 Nov 1997 02:25:44 -0800 (PST) Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by dent.axion.bt.co.uk with SMTP (PP); Fri, 14 Nov 1997 10:25:19 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA01879; Fri, 14 Nov 1997 10:23:40 GMT Date: Fri, 14 Nov 1997 10:23:39 +0000 (GMT) From: George Tsirtsis To: tsuchiya Cc: hinden@Ipsilon.COM, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 4813) Re: IPv4/IPv6 translator In-Reply-To: <9711140604.AA00404@magic.33g.isrd.hitachi.co.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk On Fri, 14 Nov 1997, tsuchiya wrote: > Hi, > > My name is Kazuaki Tsuchiya. I work at Hitachi, Ltd. in Japan and > develop an IPv6 router (NR60). I am also a WIDE project member. > > > Various transition mechanisms have been already studied as ways to > transit from an IPv4 to an IPv6 smoothly. Additionally I think that it > is necessary to be able to communicate between an IPv6-only node and an > IPv4-only node. So now I am writing an Internet-Draft about it and I > will submit it next Monday. That is what NAT-PT does but any new ideas are welcome. Looking forward to read your draft George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 04:52:47 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id EAA15145 for ipng-dist; Fri, 14 Nov 1997 04:50:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id EAA15138 for ; Fri, 14 Nov 1997 04:49:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA14269 for ; Fri, 14 Nov 1997 04:49:49 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id EAA04798 for ; Fri, 14 Nov 1997 04:49:49 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA27403; Fri, 14 Nov 1997 12:49:46 GMT Received: (from brian@localhost) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) id MAA15884; Fri, 14 Nov 1997 12:49:40 GMT From: Brian E Carpenter Message-Id: <199711141249.MAA15884@sp3at21.hursley.ibm.com> Subject: (IPng 4814) Re: NAT To: kodeswar@cs.umbc.edu (Sethurambalaji Kodeswaran) Date: Fri, 14 Nov 1997 12:49:39 +0000 (GMT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Sethurambalaji Kodeswaran" at Nov 10, 97 12:03:03 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk Balaji, Look at it this way. There are 27 implementations of IPv6 and its main documents are under advancement as IETF standards. And even pessimists agree that IPv4 has several years to run before it expires. So why would anybody want to look elsewhere? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) brian@hursley.ibm.com IBM United Kingdom Laboratories http://www.hursley.ibm.com/~bc/ MP 185 phone: +44 1962 816833 Hursley Park fax: +44 1962 818101 Winchester Hampshire SO21 2JN, UK >- Sethurambalaji Kodeswaran said: > > Hi, > > I'm told that a new standard fro IP is being investigated - IPv8. > > Can you tell me some sites where i might be able to get some info about this > > Bye, > Balaji. > > ######################################################################## > K.SETHURAM BALAJI Tel # : (410) - 536 -0734 > 4755,Chapel Square, E-Mail: kodeswar@cs.umbc.edu > Baltimore , kodeswar@gl.umbc.edu > Maryland - 21227 kodeswar@mctr.umbc.edu > USA. Web page: www.cs.umbc.edu/~kodeswar > > ALL'S WELL THAT ENDS WELL > ######################################################################## > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 04:57:52 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id EAA15162 for ipng-dist; Fri, 14 Nov 1997 04:55:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id EAA15155 for ; Fri, 14 Nov 1997 04:55:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA14804 for ; Fri, 14 Nov 1997 04:55:01 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id EAA05984 for ; Fri, 14 Nov 1997 04:55:01 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA27464; Fri, 14 Nov 1997 12:54:58 GMT Received: (from brian@localhost) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) id MAA26588; Fri, 14 Nov 1997 12:54:58 GMT From: Brian E Carpenter Message-Id: <199711141254.MAA26588@sp3at21.hursley.ibm.com> Subject: (IPng 4815) Re: NAT To: roque@cisco.com (Pedro Marques) Date: Fri, 14 Nov 1997 12:54:58 +0000 (GMT) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <199711110114.RAA17056@pedrom-ultra.cisco.com> from "Pedro Marques" at Nov 10, 97 05:14:09 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk > bound> But one > bound> cannot translate to IPv4 the Class (maybe if we do TOS bits > bound> but not the CE bits) and Flow Label. > > Since they are undefined in IPv6 at the moment and unused in IPv4, translation > is quite easy ;-) > > bound> It can be done but > bound> one cannot have the same expectations as v4 to v4. > > Because you don't translate TOS to class and vice-versa ? My guess is that > many users with be able to live pretty well with that limitation. Wrong. Fixing this is key to differential services in the mixed v4/v6 world. We just need to agree that the TOS octet in IPv4 and the traffic class octet in IPv6 have the same content, and we're done on this. Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 05:05:41 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id FAA15182 for ipng-dist; Fri, 14 Nov 1997 05:01:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id FAA15175 for ; Fri, 14 Nov 1997 05:01:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA15234 for ; Fri, 14 Nov 1997 05:01:12 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA07416 for ; Fri, 14 Nov 1997 05:01:08 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA56721; Fri, 14 Nov 1997 13:01:03 GMT Received: (from brian@localhost) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) id NAA22412; Fri, 14 Nov 1997 13:01:03 GMT From: Brian E Carpenter Message-Id: <199711141301.NAA22412@sp3at21.hursley.ibm.com> Subject: (IPng 4816) Re: Dynamic addressing To: krooger@kurzo.ml.org (Bjarne Lorftesonne) Date: Fri, 14 Nov 1997 13:01:03 +0000 (GMT) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Bjarne Lorftesonne" at Nov 10, 97 09:29:31 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk Bjarne, Let me try to say what Jim was saying in fewer words. Dyanamic renumbering will be the normal case in IPv6. Therefore end users and small ISPs will not care if their address block changes when they change ISPs. For this to work we have to succeed in deploying dynamic DNS as well as IPv6. Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 05:19:02 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id FAA15222 for ipng-dist; Fri, 14 Nov 1997 05:12:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id FAA15215 for ; Fri, 14 Nov 1997 05:12:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA16941 for ; Fri, 14 Nov 1997 05:12:31 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA10457 for ; Fri, 14 Nov 1997 05:12:31 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA16955; Fri, 14 Nov 1997 13:12:28 GMT Received: (from brian@localhost) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) id NAA25008; Fri, 14 Nov 1997 13:12:25 GMT From: Brian E Carpenter Message-Id: <199711141312.NAA25008@sp3at21.hursley.ibm.com> Subject: (IPng 4817) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard To: crawdad@fnal.gov (Matt Crawford) Date: Fri, 14 Nov 1997 13:12:24 +0000 (GMT) Cc: iesg@ietf.org, deering@cisco.com, hinden@ipsilon.com, ipng@sunroof.eng.sun.com In-Reply-To: <199711132358.RAA16001@gungnir.fnal.gov> from "Matt Crawford" at Nov 13, 97 05:58:01 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk I concur with Matt, and in addition I believe that this bit inversion will cause endless (literally) confusion to at least a generation of network operators and maintenance techs. Brian Carpenter >- Matt Crawford said: > > To the IESG, > > I think we, the IPNG working group, may have made a poor > choice in deciding to complement the universal/local bit > when forming an IPv6 address from an EUI-64 identifier. > (For details, see draft-ietf-ipngwg-addr-arch-v2-05.txt > or draft-ietf-ipngwg-trans-ethernet-04.txt.) It's a poor > choice I could live with, but I'm hoping it can be > scrutinized first by individuals who weren't involved in > the choice. As long as the point is examined, any > outcome will be acceptable. > > > The trade-off, as I see it, is this: > > With the current documents, small integers may be freely > used as interface identifers, forming, for example, the > Subnet-Router anycast address which neatly ends with 64 > zero bits. But nodes auto-configuring their IPv6 unicast > addresses must flip a single bit in their built-in > address to form their Interface Identifier. > > The Address Architecture and the IPv6-over-(various 802 > media) devote several paragraphs to explaining the bit- > flipping, and the identities of nodes whose IPv6 > addresses appear in neighbor tables or packet traces are > slightly obscured by the alteration of the bit. > > > If the spec were written the other way, so that an EUI-64 > is used directly as an Interface Identifier, the language > in the documents would be simpler, MAC addresses would be > somewhat more recognizable in packet traces or tables. > > On the down side, those small-integer identifiers would > have to look like this > 3ffe:7c0:40:9:200::0 > instead of the current > 3ffe:7c0:40:9::0 > > We might arguably appear a little more IEEE-friendly by > not fiddling with the bit, but I can't really make a case > on that argument. The simplification of the specs is my > main point. > Matt Crawford > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 06:54:31 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA15331 for ipng-dist; Fri, 14 Nov 1997 06:51:46 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA15324 for ; Fri, 14 Nov 1997 06:51:38 -0800 (PST) From: RAMAMIRTHAM@PROCESS.COM Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA01319 for ; Fri, 14 Nov 1997 06:51:34 -0800 Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id GAA14022 for ; Fri, 14 Nov 1997 06:51:30 -0800 (PST) Date: Fri, 14 Nov 1997 09:51 -0400 Message-Id: <009BD46B55F168BF.5A2C@PROCESS.COM> To: deering@cisco.com, IPNG@sunroof.eng.sun.com Subject: (IPng 4818) RE: increasing the IPv6 minimum MTU X-VMS-To: SMTP%"deering@cisco.com" X-VMS-Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@eng.sun.com Precedence: bulk >In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU >from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e., ............ Yes, I think this is a good idea.. Ravi Ramamirtham Process Software Corporation Framingham, MA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 07:19:06 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA15375 for ipng-dist; Fri, 14 Nov 1997 07:16:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA15368 for ; Fri, 14 Nov 1997 07:16:11 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09645 for ; Fri, 14 Nov 1997 07:16:10 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA23822 for ; Fri, 14 Nov 1997 07:16:06 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id KAA08942; Fri, 14 Nov 1997 10:03:45 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA20867; Fri, 14 Nov 1997 10:03:42 -0500 Message-Id: <199711141503.AA20867@wasted.zk3.dec.com> To: George Tsirtsis Cc: Pyda Srisuresh , Pedro Marques , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4819) Re: Terminology of Address Translation In-Reply-To: Your message of "Thu, 13 Nov 1997 21:50:20 GMT." Date: Fri, 14 Nov 1997 10:03:42 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk George, I have pretty much figured out the DNS problem for NNAT. Entering a network a standard relay.org.com record will get the DNS query into the site. At the site that DNS server will have an RT record (like mailx record - THis idea was not mine but Gerd Hoelzing at Digital Germany). node.needs.ipv4.site RT nnat.server.site I will not in this draft define what the nnat server must do as it can be colocated DNS+DHCPv6 but it will use the DHCPv6 reconfigure msg to notifty the node hear is an IPv4 address and await client response. Then the nnat server will respond to the query from the outside. Note here that the big win is in IPv6 DHCP clients can hear msgs from Servers. What I will discuss in the draft and want to review at Wash D.C. is 1. DNS QUERY - RT RECORD - NNAT Server 2. DHCPv6 Reconfigure Message Processing 3. IPv4 Tunnels and IPv6 Tunnels that may be necessary at the site. 4. Using this in a site for IPv4/IPv6 Interoperation not just for Internet connectivity. 5. Reverse DNS Mapping issues outside of the DNS 6. Firewall Issues. 7. Colocating DHCPv6/DNS NNAT Server 8. IPSEC is the assumption for Security I have asked for time on NGTRANS though not IPng WG? This should get us moving working on NNAT as a working group is my hope. ALso we will have a few weeks to pick at the draft before the meeting. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 07:27:13 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA15395 for ipng-dist; Fri, 14 Nov 1997 07:24:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA15388 for ; Fri, 14 Nov 1997 07:24:14 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA11953 for ; Fri, 14 Nov 1997 07:24:11 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA27011 for ; Fri, 14 Nov 1997 07:24:08 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id KAA30705; Fri, 14 Nov 1997 10:12:16 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22237; Fri, 14 Nov 1997 10:12:16 -0500 Message-Id: <199711141512.AA22237@wasted.zk3.dec.com> To: Pyda Srisuresh Cc: george@gideon.bt.co.uk (George Tsirtsis), roque@cisco.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4820) Re: Terminology of Address Translation In-Reply-To: Your message of "Thu, 13 Nov 1997 16:59:35 PST." <199711140057.QAA10754@server.livingston.com> Date: Fri, 14 Nov 1997 10:12:15 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Suresh, >No-NAT setup above sounds like a V6-to-V4 gateway, using DHCP to >obtain a V4 address to map to its V6 address. With no protocol >translation in the box, I imagine, there exists a gateway agent >that terminates the session on either end(i.e., V4 end with remote >host and V6 end internally to iteself) and pushes the payload >from one side to the other. I assume, this agent is also responsible >for any payload interpretations, when the payload contains >IP (v4 or V6) addresses. Does this make sense? Its not really a gateway. Gateways to me imply the entire packet is altered at some point in the network to support a particular function which could even be translation of some form. NNAT uses a one time set up for an incoming IPv4 packet wanting to connect with an IPv6 node. The IPv6 node is assigned a temporary IPv4 address and the DNS query responds to the IPv4 node with that address. Once set up is complete the nodes just speak IPv4 to IPv4 there is no gateway. I will suggest that the pool of temporary IPv4 addresses remain with DHCPv6 server. WHen a node wants to communicate out to IPv4 I will suggest it use DHCPv4 servers to get those addresses for now. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 07:40:28 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA15426 for ipng-dist; Fri, 14 Nov 1997 07:37:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA15419 for ; Fri, 14 Nov 1997 07:37:17 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA15860 for ; Fri, 14 Nov 1997 07:37:15 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA02722 for ; Fri, 14 Nov 1997 07:37:12 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA00039; Fri, 14 Nov 1997 09:43:38 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19113; Fri, 14 Nov 1997 09:43:34 -0500 Message-Id: <199711141443.AA19113@wasted.zk3.dec.com> To: George Tsirtsis Cc: Pedro Marques , bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4821) Re: NAT In-Reply-To: Your message of "Thu, 13 Nov 1997 16:22:54 GMT." Date: Fri, 14 Nov 1997 09:43:33 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk >* The No-NAT solution assumes (correct me if I am wrong) that IPv4 ONLY >hosts need to communicate with IPv6/v4 hosts (dualstack or hybrid) and the >other way arrount. The problem here is that the IPv6 hosts also have to >speek IPv4. This is correct. But IPv6 hosts speaking IPv4 is not a problem. None of us Host vendors will ship any IPv6 products that do not support IPv6. I apologize to all for not having a draft out already, I will have one before the 11/21 deadline and will be on the agenda for ngtrans. In my own defense I have been very busy with my co-author Charlie Perkins putting the finishing touches on DHCPv6 for last call and to get to proposed standard. But we just got that done and next week I will get this out to the list. One confusion I have is as follows: SHouldn't this discussionn be happening on NGTRANS? ALso for NNAT all need to become familiar with the RT Record which is the ROute Through DNS record per RFC 1138. And obviously DNS and DHCPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 07:43:10 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA15435 for ipng-dist; Fri, 14 Nov 1997 07:40:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA15428 for ; Fri, 14 Nov 1997 07:40:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA16724 for ; Fri, 14 Nov 1997 07:40:08 -0800 Received: from mailhub.mk.net (www01.mk.net [208.206.80.32]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA04031 for ; Fri, 14 Nov 1997 07:40:01 -0800 (PST) Received: from localhost (globis@localhost [127.0.0.1]) by mailhub.mk.net (8.8.6/8.8.6) with SMTP id KAA00858 for ; Fri, 14 Nov 1997 10:39:53 -0500 Date: Fri, 14 Nov 1997 10:39:53 -0500 From: Ray Hunter Message-Id: <199711141539.KAA00858@mailhub.mk.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 4822) FW: increasing the IPv6 minimum MTU Sender: owner-ipng@eng.sun.com Precedence: bulk Here is my take on the MTU debate from a pragmatic slant: There are basically 2 types of packets on networks. There are small ones, and max size ones, and very very little exists in between. Small ones for control messages and keystrokes, max size ones for data transfer such as printing/email/file sharing. If it doesn't break anything, the MTU should be set so that it optimizes transfer on the most common network media today.... read Ethernet. After all, experimental evidence today, [the internet] suggests that the queueing technology exists to avoid excessive delay of small packets by 1500 byte ones. [how many people actually change the MTU parameter from the Cisco default???] Going beyond 1500 bytes would be a different ball game, because there is an aweful lot of experince/code/hardware that relies on this limit. Any new technologies with small MTU's will almost certainly want to do header/data compression in the interests of efficiency, or they will have an adaption layer built in anyway (e.g. AAL5 ala ATM), so burdening them with the task of a link layer assembly/ disassembly task doesn't seem such a big deal to me.... [developers of such drivers are welcome to flame me if they know better] Let's learn for Novell IPX, and DECnet IV which behaved like dogs on wide area networks until you either installed the big packet NLM or reconfigured the retransmit timers to improve things. Also considering switching performance of many systems (which is often the limit on a router performance rather than pure bandwidth)..... The mean size packet on a typical Ethernet falls in the range of around 128 to 256 bytes.... meaning an average of around 13% of large packets. If you suddenly decrease the max size to 576 bytes [assuming people are lazy and MTU discovery is not widely implemented for a significant amount of applications for large server systems with many clients] then you get 3 times as many large packets on your network [1500/576] = an increase of 26% in the thruput requirement of any equipment that switches packets. best regards, Ray.Hunter@globis.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 08:28:01 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id IAA15531 for ipng-dist; Fri, 14 Nov 1997 08:25:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA15524 for ; Fri, 14 Nov 1997 08:25:09 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA28940 for ; Fri, 14 Nov 1997 08:25:07 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA26530 for ; Fri, 14 Nov 1997 08:25:04 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA01164; Fri, 14 Nov 1997 11:10:38 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA27423; Fri, 14 Nov 1997 11:10:29 -0500 Message-Id: <199711141610.AA27423@wasted.zk3.dec.com> To: bound@zk3.dec.com Cc: George Tsirtsis , Pedro Marques , ipng@sunroof.eng.sun.com Subject: (IPng 4823) Re: NAT In-Reply-To: Your message of "Fri, 14 Nov 1997 09:43:33 EST." <199711141443.AA19113@wasted.zk3.dec.com> Date: Fri, 14 Nov 1997 11:10:29 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Correction... This is correct. But IPv6 hosts speaking IPv4 is not a problem. None >of us Host vendors will ship any IPv6 products that do not support IPv6. ^^^^ IPv4 I apologize to all for not having a draft out already, I will have one before the 11/21 deadline and will be on the agenda for ngtrans. In my own defense I have been very busy with my co-author Charlie Perkins putting the finishing touches on DHCPv6 for last call and to get to proposed standard. But we just got that done and next week I will get this out to the list. Sorry, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 09:14:55 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA15575 for ipng-dist; Fri, 14 Nov 1997 09:12:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA15568 for ; Fri, 14 Nov 1997 09:11:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA10516 for ; Fri, 14 Nov 1997 09:11:50 -0800 Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA21723 for ; Fri, 14 Nov 1997 09:11:40 -0800 (PST) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id IAA28671; Fri, 14 Nov 1997 08:56:31 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id JAA12275; Fri, 14 Nov 1997 09:09:50 -0800 (PST) Received: from greenfield.engeast.baynetworks.com (dhcp139-233 [192.32.139.233]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA00442; Fri, 14 Nov 1997 12:09:49 -0500 for Message-Id: <3.0.1.32.19971114120952.0073be28@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 14 Nov 1997 12:09:52 -0500 To: iesg@ietf.org From: Dimitry Haskin Subject: (IPng 4824) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard Cc: crawdad@fnal.gov, Steve Deering , Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <199711132358.RAA16001@gungnir.fnal.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk I disagree with Matt on this issue. To be frank, I don't think that it makes much technical difference one way or other. Nevertheless, at the point where there are a score of implementations and at least one released product that incorporate the previously agreed interface identifier format, changing it for the sake of removing a couple paragraphs from the specs is not a justifiable tradeoff and only add to confusion. In addition, it will increase the probability that an incorrect interface identifier will be generated with manual configuration. As to the concern that MAC addresses are not readily recognizable in IPv6 addresses, I don't think that it is a detriment but rather a benefit. Let me remind that EUI-64 identifier has been chosen only as a convenient base for deriving globally unique IPv6 interface identifiers. No other relationships shell be implied from that. There has been past attempt to utilize the interface identifier properties to bypass the ND's address resolution mechanism. If flipping one bit can help to obscure the MAC origin of interface identifiers, it's only for better. Dimitry At 05:58 PM 11/13/97 -0600, Matt Crawford wrote: >To the IESG, > >I think we, the IPNG working group, may have made a poor >choice in deciding to complement the universal/local bit >when forming an IPv6 address from an EUI-64 identifier. >(For details, see draft-ietf-ipngwg-addr-arch-v2-05.txt >or draft-ietf-ipngwg-trans-ethernet-04.txt.) It's a poor >choice I could live with, but I'm hoping it can be >scrutinized first by individuals who weren't involved in >the choice. As long as the point is examined, any >outcome will be acceptable. > > >The trade-off, as I see it, is this: > >With the current documents, small integers may be freely >used as interface identifers, forming, for example, the >Subnet-Router anycast address which neatly ends with 64 >zero bits. But nodes auto-configuring their IPv6 unicast >addresses must flip a single bit in their built-in >address to form their Interface Identifier. > >The Address Architecture and the IPv6-over-(various 802 >media) devote several paragraphs to explaining the bit- >flipping, and the identities of nodes whose IPv6 >addresses appear in neighbor tables or packet traces are >slightly obscured by the alteration of the bit. > > >If the spec were written the other way, so that an EUI-64 >is used directly as an Interface Identifier, the language >in the documents would be simpler, MAC addresses would be >somewhat more recognizable in packet traces or tables. > >On the down side, those small-integer identifiers would >have to look like this > 3ffe:7c0:40:9:200::0 >instead of the current > 3ffe:7c0:40:9::0 > >We might arguably appear a little more IEEE-friendly by >not fiddling with the bit, but I can't really make a case >on that argument. The simplification of the specs is my >main point. > Matt Crawford >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 09:40:18 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA15664 for ipng-dist; Fri, 14 Nov 1997 09:37:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA15657 for ; Fri, 14 Nov 1997 09:37:09 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA17661 for ; Fri, 14 Nov 1997 09:37:06 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA05792 for ; Fri, 14 Nov 1997 09:37:00 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA16032; Fri, 14 Nov 1997 11:39:18 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30186; Fri, 14 Nov 1997 11:39:11 -0500 Message-Id: <199711141639.AA30186@wasted.zk3.dec.com> To: George Tsirtsis Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4825) Re: Is that correct? In-Reply-To: Your message of "Fri, 14 Nov 1997 15:50:27 GMT." Date: Fri, 14 Nov 1997 11:39:11 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk George/WG, >is that the correct RFC (1138? Mapping between X400/ISO100021...) >This is a very big document but I could not find reference to RT records I transposed (I am having a bad day and its only 11:30 a.m) its RFC 1183. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 09:53:51 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA15709 for ipng-dist; Fri, 14 Nov 1997 09:50:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA15700 for ; Fri, 14 Nov 1997 09:50:03 -0800 (PST) From: bmanning@ISI.EDU Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA21152 for ; Fri, 14 Nov 1997 09:50:00 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA13103 for ; Fri, 14 Nov 1997 09:49:51 -0800 (PST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA25732; Fri, 14 Nov 1997 09:49:50 -0800 (PST) Posted-Date: Fri, 14 Nov 1997 09:49:05 -0800 (PST) Message-Id: <199711141749.AA04963@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Fri, 14 Nov 1997 09:49:05 -0800 Subject: (IPng 4826) Re: Is that correct? To: bound@zk3.dec.com Date: Fri, 14 Nov 1997 09:49:05 -0800 (PST) Cc: george@gideon.bt.co.uk, ipng@sunroof.eng.sun.com In-Reply-To: <199711141639.AA30186@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Nov 14, 97 11:39:11 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk > > George/WG, > > >is that the correct RFC (1138? Mapping between X400/ISO100021...) > >This is a very big document but I could not find reference to RT records > > I transposed (I am having a bad day and its only 11:30 a.m) its RFC 1183. > > thanks > /jim RT records don't reflect how routing works folks. They're effectivly OBE, much like WKS records. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 10:12:07 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA15768 for ipng-dist; Fri, 14 Nov 1997 10:08:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA15761 for ; Fri, 14 Nov 1997 10:08:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA26282 for ; Fri, 14 Nov 1997 10:08:20 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA23234 for ; Fri, 14 Nov 1997 10:08:15 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA18245; Fri, 14 Nov 1997 12:07:35 -0600 Message-Id: <199711141807.MAA18245@gungnir.fnal.gov> To: IPng Working Group From: "Matt Crawford" Subject: (IPng 4827) Re: increasing the IPv6 minimum MTU In-reply-to: Your message of Thu, 13 Nov 1997 16:37:00 PST. Date: Fri, 14 Nov 1997 12:07:35 -0600 Sender: owner-ipng@eng.sun.com Precedence: bulk I'm in favor of raising the minimum IPv6 MTU which must be supported, although I think the exact value chosen needs a little more consideration. > The number I propose for the new minimum MTU is 1280 bytes (1024 + 256, > as compared to the classic 576 value which is 512 + 64). That would > leave generous room for encapsulating/tunnel headers within the Ethernet > MTU of 1500, e.g., enough for two layers of secure tunneling including > both ESP and AUTH headers. Even though it's likely that ESP and AH won't be used together, I can't make the overhead of two layers of IPv6+ESP+AH encapsulation come out any worse than 217 bytes. This assumes No extension headers in the encapsulating IPv6 packets other than AH+ESP 8 byte IV carried in the ESP ESP includes authentication AH authentication data is 128 bits (instead of being truncated to 96 bits) 7 byte worst-case padding (It turns out that the outer of two ESP payloads will use exactly 6 bytes of padding) Golly. Since Steve didn't "show his work" I was expecting to find a bad fit to his allowance of 1500 - 1280 = 220 but instead it fits like a glove. If the tunnels are sensibly configured to not use AH with the ESP, the overhead of two IPv6+ESP encapsulations is limited to 153 bytes, leaving room for 3 hops of type-1 routing header divided between the two tunnels any way you like. What can the end node fit into 1024+256=1280 bytes of MTU? 1024 bytes of TCP data + IPv6 header (40), TCP header with timestamp option (30), a destination option for mobility support (24, I predict) and ESP with authentication will use up 1024+130. 126 bytes are still left. OK, the number 1280 is fine. __________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 11:56:46 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA15969 for ipng-dist; Fri, 14 Nov 1997 11:53:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA15962 for ; Fri, 14 Nov 1997 11:53:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA28338 for ; Fri, 14 Nov 1997 11:53:34 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA18075 for ; Fri, 14 Nov 1997 11:53:24 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA22753; Fri, 14 Nov 97 11:51:17 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA04362; Fri, 14 Nov 1997 11:53:57 -0800 Date: Fri, 14 Nov 1997 11:53:57 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199711141953.LAA04362@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4828) Reassembly Size X-Sun-Charset: US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Folks, In section 5 of draft-ietf-ipngwg-ipv6-spec-v2-00.txt we have the following discussion of minimum reassembly size. A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets, including the IPv6 header. A node is permitted to accept fragmented packets that reassemble to more than 1500 octets. However, a node must not send fragments that reassemble to a size greater than 1500 octets unless it has explicit knowledge that the destination(s) can reassemble a packet of that size. I have a concern about the last sentence. Specifically, this document does not specify any mechanism for this explicit knowledge to be acquired. Neither does the current draft of the ICMPv6 specification. I feel that if this is going to remain a MUST NOT then we need to specify a mechanism which will allow the sending node to determine the maximum reassembly size of the destination node. Some sort of ICMPv6 error message would probably handle the situation. In the alternative, changing the MUST NOT to a SHOULD NOT would be sufficient. On a practical note, I have not done interoperability testing with any implementation which adheres to this prescription. I very much doubt that any implementation ever will adhere to it. This text has been in the IPv6 base specification for a long time and implementation experience indicates that it is being ignored. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 12:10:27 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA16001 for ipng-dist; Fri, 14 Nov 1997 12:07:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA15994 for ; Fri, 14 Nov 1997 12:07:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA02306 for ; Fri, 14 Nov 1997 12:07:12 -0800 Received: from pleco.cisco.com (pleco.cisco.com [171.69.30.22]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA25096 for ; Fri, 14 Nov 1997 12:07:00 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by pleco.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id MAA02827; Fri, 14 Nov 1997 12:06:55 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA19523; Fri, 14 Nov 1997 12:06:54 -0800 (PST) Date: Fri, 14 Nov 1997 12:06:54 -0800 (PST) Message-Id: <199711142006.MAA19523@pedrom-ultra.cisco.com> From: Pedro Marques To: George Tsirtsis Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4829) Re: Terminology of Address Translation In-Reply-To: References: <199711140143.RAA19194@pedrom-ultra.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk >>>>> "George" == George Tsirtsis writes: >> Not true. The main objective of a NAT box is to interconnect >> networks that take thier addresses from different "addressing >> domains"... You need that pool of v6 addresses to be able to >> access a server in a v6 network from a client in a v4 >> network... >> >> (server = host that does passive open; client = host that does >> active open) >> >> The typical application domain of the above is exactly the >> usual application domain of IPv4 NAT: connect an "private" >> network (in this case a IPv6 network) to a "public" network >> (usually the v4 Internet). >> >> Pedro. >> George> Not exactly necessary. According to what you say, all IPv4 George> networks that want to communicate with IPv6 ONLY hosts George> should get a NAT-PT box. I'm saying something completly different: i'm saying that there must be a NAT box between (in the network path) of two systems talking using different addressing domains. To put it in another way: if you wish to connect an IPv6 network to an IPv4 network put a nat box at the border between the two. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 12:31:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA16053 for ipng-dist; Fri, 14 Nov 1997 12:28:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA16046 for ; Fri, 14 Nov 1997 12:28:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA07496 for ; Fri, 14 Nov 1997 12:28:15 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id MAA04984 for ; Fri, 14 Nov 1997 12:28:14 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA18484; Fri, 14 Nov 1997 14:27:30 -0600 Message-Id: <199711142027.OAA18484@gungnir.fnal.gov> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4830) Re: Reassembly Size In-reply-to: Your message of Fri, 14 Nov 1997 11:53:57 PST. <199711141953.LAA04362@feller.mentat.com> Date: Fri, 14 Nov 1997 14:27:30 -0600 Sender: owner-ipng@eng.sun.com Precedence: bulk > However, a node must not send fragments that reassemble to a > size greater than 1500 octets unless it has explicit knowledge > that the destination(s) can reassemble a packet of that size. > > > I have a concern about the last sentence. Specifically, this > document does not specify any mechanism for this explicit knowledge to > be acquired. Neither does the current draft of the ICMPv6 specification. > I feel that if this is going to remain a MUST NOT then we need to specify > a mechanism ... A mechanism which covers TCP has been spec'd since Sep-01-1981 (hint, hint). Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 13:37:07 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA16110 for ipng-dist; Fri, 14 Nov 1997 13:34:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA16103 for ; Fri, 14 Nov 1997 13:34:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA22525 for ; Fri, 14 Nov 1997 13:33:59 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA05376 for ; Fri, 14 Nov 1997 13:33:54 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA24579; Fri, 14 Nov 97 13:31:58 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA00416; Fri, 14 Nov 1997 13:34:39 -0800 Date: Fri, 14 Nov 1997 13:34:39 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199711142134.NAA00416@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4831) Re: Reassembly Size X-Sun-Charset: US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Matt > > A mechanism which covers TCP has been spec'd since Sep-01-1981 (hint, hint). > I am well aware of TCP MSS option. This does not help UDP, ICMPv6 or other protocols which may use IPv6. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 13:42:57 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA16127 for ipng-dist; Fri, 14 Nov 1997 13:40:03 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA16120 for ; Fri, 14 Nov 1997 13:39:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA23894 for ; Fri, 14 Nov 1997 13:39:49 -0800 Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA07803 for ; Fri, 14 Nov 1997 13:39:45 -0800 (PST) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id NAA18494 for ; Fri, 14 Nov 1997 13:26:18 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id NAA02997 for ; Fri, 14 Nov 1997 13:39:37 -0800 (PST) Received: from greenfield.engeast.baynetworks.com (dhcp139-233 [192.32.139.233]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA05043; Fri, 14 Nov 1997 16:39:37 -0500 for Message-Id: <3.0.1.32.19971114163940.006b3bec@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 14 Nov 1997 16:39:40 -0500 To: ipng@sunroof.eng.sun.com From: Dimitry Haskin Subject: (IPng 4832) Re: Reassembly Size Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Tim, I have no problem with current wording. At the same time I would not be terribly upset if MUST NOT gets changed to SHOULD NOT. Explicit knowledge of the supported packet size can come from upper layer specification requirements. For instance the BGP specification explicitly requires implementations to support datagrams of up to 4096 octets. Naturally, a compliant BGP can not be implemented on systems that can not re-assemble this size packets. So when sending BGP packets it can be assumed that the explicit knowledge rule is satisfied. On other hand if an application does not impose any requirements on packet size, it would be reasonable to refrain from sending packets greater that the minimum required reassembly buffer size. Dimitry > >> >>Folks, >> >> In section 5 of draft-ietf-ipngwg-ipv6-spec-v2-00.txt we have >>the following discussion of minimum reassembly size. >> >> >> A node must be able to accept a fragmented packet that, after >> reassembly, is as large as 1500 octets, including the IPv6 header. A >> node is permitted to accept fragmented packets that reassemble to >> more than 1500 octets. However, a node must not send fragments that >> reassemble to a size greater than 1500 octets unless it has explicit >> knowledge that the destination(s) can reassemble a packet of that >> size. >> >> >> I have a concern about the last sentence. Specifically, this >>document does not specify any mechanism for this explicit knowledge to >>be acquired. Neither does the current draft of the ICMPv6 specification. >>I feel that if this is going to remain a MUST NOT then we need to specify >>a mechanism which will allow the sending node to determine the maximum >>reassembly size of the destination node. Some sort of ICMPv6 error message >>would probably handle the situation. In the alternative, changing the >>MUST NOT to a SHOULD NOT would be sufficient. >> >> On a practical note, I have not done interoperability testing >>with any implementation which adheres to this prescription. I very much >>doubt that any implementation ever will adhere to it. This text has been >>in the IPv6 base specification for a long time and implementation experience >>indicates that it is being ignored. >> >> >> >>Tim Hartrick >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- >> >> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 13:48:54 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA16145 for ipng-dist; Fri, 14 Nov 1997 13:45:31 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA16138 for ; Fri, 14 Nov 1997 13:45:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA25360 for ; Fri, 14 Nov 1997 13:45:21 -0800 Received: from snoopy.lucentmmit.com (smtp.Lucentmmit.com [38.160.171.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA10420 for ; Fri, 14 Nov 1997 13:45:12 -0800 (PST) Received: by SNOOPY with Internet Mail Service (5.0.1457.3) id ; Fri, 14 Nov 1997 16:51:57 -0500 Message-ID: From: "Conta, Alex" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 4833) Re: increasing the IPv6 minimum MTU Date: Fri, 14 Nov 1997 16:51:54 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@eng.sun.com Precedence: bulk While the arguments for the change are convincing, and the calculations behind the 1280 value seem to make sense, I am hoping that the value chosen will not be confusing, and we will not see LAN MTUs set such that all packets, including the local ones, max at 1280. Would I have looked at a value closer to 1024 as less dangerous in that respect? Perhaps... Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 13:59:33 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA16166 for ipng-dist; Fri, 14 Nov 1997 13:56:04 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA16159 for ; Fri, 14 Nov 1997 13:55:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA28120 for ; Fri, 14 Nov 1997 13:55:50 -0800 Received: from brownale.cisco.com (brownale.cisco.com [171.69.95.89]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA15826 for ; Fri, 14 Nov 1997 13:55:45 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by brownale.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id NAA03507; Fri, 14 Nov 1997 13:54:25 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA19597; Fri, 14 Nov 1997 13:54:25 -0800 (PST) Date: Fri, 14 Nov 1997 13:54:25 -0800 (PST) Message-Id: <199711142154.NAA19597@pedrom-ultra.cisco.com> From: Pedro Marques To: "Matt Crawford" Cc: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 4834) Re: Reassembly Size In-Reply-To: <199711142027.OAA18484@gungnir.fnal.gov> References: <199711141953.LAA04362@feller.mentat.com> <199711142027.OAA18484@gungnir.fnal.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk >>>>> "Matt" == Matt Crawford writes: >> However, a node must not send fragments that reassemble to a >> size greater than 1500 octets unless it has explicit knowledge >> that the destination(s) can reassemble a packet of that size. >> >> >> I have a concern about the last sentence. Specifically, this >> document does not specify any mechanism for this explicit >> knowledge to be acquired. Neither does the current draft of >> the ICMPv6 specification. I feel that if this is going to >> remain a MUST NOT then we need to specify a mechanism ... Matt> A mechanism which covers TCP has been spec'd since Matt> Sep-01-1981 (hint, hint). Would you care to be more specific ? Also, i tend to doubt on the usefulness of determinating the maximum reassembly size when using TCP... In IPv6 there should never be such thing as a fragmented TCP segment. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 14:13:41 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA16207 for ipng-dist; Fri, 14 Nov 1997 14:10:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA16196 for ; Fri, 14 Nov 1997 14:10:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA02371 for ; Fri, 14 Nov 1997 14:10:16 -0800 Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA23306 for ; Fri, 14 Nov 1997 14:10:12 -0800 (PST) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id NAA20803; Fri, 14 Nov 1997 13:56:40 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id OAA20172; Fri, 14 Nov 1997 14:09:58 -0800 (PST) Received: from greenfield.engeast.baynetworks.com (dhcp139-233 [192.32.139.233]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA08292; Fri, 14 Nov 1997 17:09:58 -0500 for Message-Id: <3.0.1.32.19971114171002.006e4c30@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 14 Nov 1997 17:10:02 -0500 To: thartric@mentat.com (Tim Hartrick) From: Dimitry Haskin Subject: (IPng 4835) Re: Reassembly Size Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk It occurred to me after I sent my reply to Tim that BGP is a bad example. BGP uses TCP as its transport and therefore the BGP's message size requirement does not apply to the reassembly buffer size. Therefor it is possible to support BGP's 4096 octet messages on systems that have 1500-octet reassembly buffers as long as TCP packets don't exceed this size. Dimitry >Date: Fri, 14 Nov 1997 16:07:45 -0500 >To: thartric@mentat.com (Tim Hartrick) >From: Dimitry Haskin >Subject: Re: (IPng 4828) Reassembly Size >Cc: ipng@sunroof.Eng.Sun.COM >In-Reply-To: <199711141953.LAA04362@feller.mentat.com> > >Tim, > >I have no problem with current wording. At the same time I would not be terribly upset if MUST NOT gets changed to SHOULD NOT. > >Explicit knowledge of the supported packet size can come from upper layer specification requirements. For instance the BGP specification explicitly requires implementations to support datagrams of up to 4096 octets. Naturally, a compliant BGP can not be implemented on systems that can not re-assemble this size packets. So when sending BGP packets it can be assumed that the explicit knowledge rule is satisfied. On other hand if an application does not impose any requirements on packet size, it would be reasonable to refrain from sending packets greater that the minimum required reassembly buffer size. > >Dimitry > >> >>Folks, >> >> In section 5 of draft-ietf-ipngwg-ipv6-spec-v2-00.txt we have >>the following discussion of minimum reassembly size. >> >> >> A node must be able to accept a fragmented packet that, after >> reassembly, is as large as 1500 octets, including the IPv6 header. A >> node is permitted to accept fragmented packets that reassemble to >> more than 1500 octets. However, a node must not send fragments that >> reassemble to a size greater than 1500 octets unless it has explicit >> knowledge that the destination(s) can reassemble a packet of that >> size. >> >> >> I have a concern about the last sentence. Specifically, this >>document does not specify any mechanism for this explicit knowledge to >>be acquired. Neither does the current draft of the ICMPv6 specification. >>I feel that if this is going to remain a MUST NOT then we need to specify >>a mechanism which will allow the sending node to determine the maximum >>reassembly size of the destination node. Some sort of ICMPv6 error message >>would probably handle the situation. In the alternative, changing the >>MUST NOT to a SHOULD NOT would be sufficient. >> >> On a practical note, I have not done interoperability testing >>with any implementation which adheres to this prescription. I very much >>doubt that any implementation ever will adhere to it. This text has been >>in the IPv6 base specification for a long time and implementation experience >>indicates that it is being ignored. >> >> >> >>Tim Hartrick >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- >> >> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 15:12:50 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA16325 for ipng-dist; Fri, 14 Nov 1997 15:09:04 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA16318 for ; Fri, 14 Nov 1997 15:08:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA24558 for ; Fri, 14 Nov 1997 15:08:39 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA20377 for ; Fri, 14 Nov 1997 15:08:28 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA16456; Fri, 14 Nov 1997 15:01:08 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: References: <199711110039.AA11462@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Nov 1997 15:00:19 -0800 To: Fred Baker From: Steve Deering Subject: (IPng 4836) Re: Hello Fred - IPv6 is IPng Cc: hinden@ipsilon.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@eng.sun.com Precedence: bulk Fred, This is a response to the technical issues you raised in your reply to Jim. > IP6, last we discussed this subject on this mailing > list, was in danger of having its priority field removed and has no TOS > flags, and therefore doesn't presently have the facilities necessary to > deploy Van Jacobsen's "Pre-emptive Service" and was at least at one point > in time considering being unable to deploy Clark's "Assured Service". So > IP6 may or may not be able to support the facilities that I see as critical > to the Internet over the coming years. That remains to be seen. Wow, you've completely inverted the true state of affairs. Until recently, IPv6 did not have any equivalent of the IPv4 TOS or Precedence bits, and the recent changes have been to allow such fields to be included in IPv6. We replaced the 4-bit Priority field (which was *not* the equivalent of v4 Precedence, since it was defined as priority among packets from a single source, not priority among packets from different sources, and hence not suitable for Jacobson's or Clark's proposed usage) with an 8-bit Traffic Class field with currently undefined semantics, precisely so that IPv6 will be able to accommodate whatever usage is made of the v4 TOS/Precedence bits for differentiate services. We recognized that, if the current experiments with using those bits (which have basically sat unused for 16 years, which was why we didn't originally include them in IPv6) turn out to be successful, it was important that the same functionality be possible in IPv6. Also, we recently took steps to ensure that the v6 Traffic Class (and Flow Label) field was excluded from the set of fields over which the authentication computation is performed for the IPsec AUTH header, in order that those bits could safely be changed by routers along a packet's path, as required in some of the proposed diff-serv approaches. Note that the lack of an IP header checksum in IPv6 avoids the requirement in IPv4 that a checksum be updated whenever TOS/Precedence bits are changed en route. We realize that you probably have many more urgent and important things to do than attend or read the minutes of IPv6 meetings, but it would be nice if you didn't form your judgement of IPv6's capabilities or suitablity only on the knowledge that some header fields are in flux and the assumption that we are probably changing it for the worse. Also, it's a little odd that you apparently feel that that there's no problem in making new uses of IPv4 header fields, despite its huge installed base and it's longstanding status as an Internet Standard, but that similar evolution would be impossible in IPv6, which currently has negligible deployment and is still in the mutable stage of standardization. > Second, I think the flow label in IP6 is poorly designed. One needs > something akin to what it is now fashionable to call "label switching" to > do special-flow QoS in a scalable fashion. It is tremendously frustrating to hear you say this. The ipngwg has been patiently waiting for you or anyone else from the label-switching or int-serv communities to come and tell us exactly how you want the flow labelling feature of IPv6 to work. You and some of your colleagues did indeed write a draft some time ago, proposing to use half of the flow label space as a hop-by-hop tag. But after an initial short discussion on this mailing list in which further clarification and elaboration was requested (e.g., specifying a mechanism for allocating tags for multicast packets on multi-access links in way that is robust to link partitioning and healing, which is the concern that led to the current definition of the v6 Flow Label), we heard nothing. For the next three or four ipngwg meetings following the publication of your draft, we assigned a slot in our agenda for further discussion and advancement of your proposal, but no one ever showed up to defend it. The draft has long since expired, which would lead one to conclude that its authors are no longer interested in pushing that approach (perhaps deciding that it was better to use a shim layer below IPv6 instead?). Nonetheless, we recently decided to exclude the v6 Flow Label field from the AUTH header computation so that it could be safely modified in transit, just in case the MPLS or RSVP or intserv WG ever came to us with a well-supported proposal to change the Flow Label semantics in way that required en-route modification. We're still waiting. In any case, the lack of a "well-designed" flow label in IPv6 clearly doesn't prevent the use of label switching with IPv6, assuming label switching works with IPv4 which certainly doesn't have a well-designed flow label in its header. If the IPv6 Flow Label field ends up going unused, it's no big deal -- those bits are needed anyway to keep 32-bit alignment, and they could just be declared Reserved and available for possible future uses. So, (a) the design of the IPv6 flow label is open to change if there is consensus for such change, and (b) even if it isn't changed, it does not inhibit the use of label switching with IPv6, so this particular complaint of yours is not well-founded. > Third, the address size discriminates against low delay applications on low > speed lines. Say it any way you want to, I don't care, but take this > example and think about it. On an ISDN basic rate line (128 KBPS in two B > channels), I can place two standard telephone calls using voice technology, > and perhaps three VoIP calls if I use IP4, or two voice calls plus > miscellaneous best effort traffic such as web and email exchanges. VoIP > uses a compression technique that sends standard voice at about 40 messages > a second comprising an 8-16 KHz voice bit stream. The difference between an > IP4 and an IP6 header is an additional 20 bytes (if memory serves), which > means that using IP6, I will get two voice calls on that same line, no > more. Nice analysis, but we trust you have heard of header compression. The current approach for header compression for IPv6 reduces the header size to zero bytes. This results in lower bandwidth consumption and lower transit delay on low speed lines than does IPv4 even with IPv4 header compression. > The stated ROAD requirement was for an address that would identify > 10^12 networks and 10^15 hosts, which is achievable with a 64 bit address > at a usage density of only one address in 16,000 - where the moaning I hear > today is that folks (deplorably) use about one address in one hundred. I'm > sorry, nobody has ever given me an explanation for the bloated 128 bit > fixed size address that I could correlate to the requirements the address > had to meet, and I see the address as hurting interactive, transaction, and > real time applications on the most widely deployed links in the world - T-1 > and below. Many of us had exactly the same concerns, and pushed very hard for 64-bit addresses for IPng, but we lost that battle in the IETF's IPng process. However, we now believe that the subsequently developed IPv6 header compression approach will effectively eliminate the penalty of increased header size on lower-speed links. As for the explanation that nobody has ever given you for the 128-bit address size, we suggest that you read RFC-1752, "The Recommendation for the IP Next Generation Protocol" written by Scott Bradner and Allison Mankin. BTW, when this very issue was being debated, we don't remember you speaking up in defense of 64-bit addresses. The real justification in our minds for the 128-bit addresses is to allow for easy auto-configuration and the possibility for some future separation of location from identification. The auto-configuration is modeled after IPX (i.e., advertised prefix + interface token) and also includes management mechanisms to make it easier to renumber hosts and routers. In conclusion, we hope that in the future when you make judgemental statements about IPv6 -- or any other IETF work, for that matter -- that, to the extent those judgements are based on technical issues, you will make more of an effort to first check that your facts are straight. That's one of the burdens you must bear as IETF Chair and de facto spokesperson for the IETF. Bob Hinden & Steve Deering IPng Working Group Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 15:31:58 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA16354 for ipng-dist; Fri, 14 Nov 1997 15:28:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA16347 for ; Fri, 14 Nov 1997 15:28:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA04106 for ; Fri, 14 Nov 1997 15:28:48 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA19310 for ; Fri, 14 Nov 1997 15:06:18 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA16962; Fri, 14 Nov 1997 15:05:44 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199711141807.MAA18245@gungnir.fnal.gov> References: Your message of Thu, 13 Nov 1997 16:37:00 PST. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Nov 1997 15:04:56 -0800 To: "Matt Crawford" From: Steve Deering Subject: (IPng 4837) Re: increasing the IPv6 minimum MTU Cc: IPng Working Group Sender: owner-ipng@eng.sun.com Precedence: bulk > Since Steve didn't "show his work"... Matt, Sorry for making you do the analysis on you own, but delighted that you came to the same result. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 15:53:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA16408 for ipng-dist; Fri, 14 Nov 1997 15:45:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA16399 for ; Fri, 14 Nov 1997 15:45:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA11121 for ; Fri, 14 Nov 1997 15:45:00 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA06444 for ; Fri, 14 Nov 1997 15:44:57 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA20731; Fri, 14 Nov 1997 15:44:52 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199711141953.LAA04362@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Nov 1997 15:44:04 -0800 To: thartric@mentat.com (Tim Hartrick) From: Steve Deering Subject: (IPng 4838) Re: Reassembly Size Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@eng.sun.com Precedence: bulk At 11:53 AM -0800 11/14/97, Tim Hartrick wrote: > ...However, a node must not send fragments that > reassemble to a size greater than 1500 octets unless it has explicit > knowledge that the destination(s) can reassemble a packet of that > size. > > I have a concern about the last sentence. Tim, Would it help if I replaced it with language like that in the IPv4 spec, RFC-791, page 13: "It is recommended that hosts only send datagrams larger than xxx octets if they have assurance that the destination is prepared to accept the larger datagrams." (where "xxx", the minimum reassembly buffer size, is 576 for IPv4 and 1500 for IPv6) > Specifically, this > document does not specify any mechanism for this explicit knowledge to > be acquired. Neither does the current draft of the ICMPv6 specification. Neither do the IPv4 spec or the ICMPv4 spec. Responsibility for this is punted to the upper layers. > On a practical note, I have not done interoperability testing > with any implementation which adheres to this prescription. I very much > doubt that any implementation ever will adhere to it. It's not really a prescription for the IPv6 layer itself, but rather for designers of protocols or applications that run over IPv6. It's bringing to their attention that they cannot simply assume that every IPv6 node can reassemble an arbitrarily large packet, and it's specifying a particular size that is known to be accepted everywhere. I'd be happy to change the text in the IPv6 spec to make that clearer. > This text has been in the IPv6 base specification for a long time and > implementation experience indicates that it is being ignored. Similar language has been in the IPv4 spec even longer. I suspect, however, that many upper-layer implementors don't know about it. For those for whom all the world was BSD Unix, they never had to be concerned about this, since the BSD IP implementation does not have a limit on its IP reassembly size. Is the same true of Windows IP (now that all the world is Windows)? Nonetheless, I think it is desirable to allow an IPv6 implementation to bound its reassembly buffer size, and to discourage the development of upper-layer protocols that would break when sending to such an implementation. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 16:13:08 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA16445 for ipng-dist; Fri, 14 Nov 1997 16:10:00 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id QAA16438 for ; Fri, 14 Nov 1997 16:09:50 -0800 (PST) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id QAA23723; Fri, 14 Nov 1997 16:09:47 -0800 (PST) Date: Fri, 14 Nov 1997 16:08:10 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4839) Re: Reassembly Size To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199711141953.LAA04362@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk > I feel that if this is going to remain a MUST NOT then we need to specify > a mechanism which will allow the sending node to determine the maximum > reassembly size of the destination node. Some sort of ICMPv6 error message > would probably handle the situation. In the alternative, changing the > MUST NOT to a SHOULD NOT would be sufficient. The mechanism might be specific to the higher level protocol. For instance, NFS (over both UDP and TCP) use the FSINFO call (rfc 1813) to discover the maximum size of a write request. This means that the server implicitly states that UDP can reassemble that amount (plus IP+UDP+RPC+NFS headers). Thus there doesn't have to be a generic UDP/IP mechanism to discover the reassembly buffer size. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 16:17:41 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA16466 for ipng-dist; Fri, 14 Nov 1997 16:14:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA16459 for ; Fri, 14 Nov 1997 16:14:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA19016 for ; Fri, 14 Nov 1997 16:14:19 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA18377 for ; Fri, 14 Nov 1997 16:14:06 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA27727; Fri, 14 Nov 97 16:12:06 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA00604; Fri, 14 Nov 1997 16:14:46 -0800 Date: Fri, 14 Nov 1997 16:14:46 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199711150014.QAA00604@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4840) Re: Reassembly Size X-Sun-Charset: US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Steve, > > Would it help if I replaced it with language like that in the IPv4 spec, > RFC-791, page 13: > > "It is recommended that hosts only send datagrams larger than xxx octets > if they have assurance that the destination is prepared to accept the > larger datagrams." > > (where "xxx", the minimum reassembly buffer size, is 576 for IPv4 and 1500 > for IPv6) > Fine by me. > > Specifically, this > > document does not specify any mechanism for this explicit knowledge to > > be acquired. Neither does the current draft of the ICMPv6 specification. > > Neither do the IPv4 spec or the ICMPv4 spec. Responsibility for this is > punted to the upper layers. > Yes, I know. I was hoping to improve upon this. Changing the text to a recommendation is sufficient. > > On a practical note, I have not done interoperability testing > > with any implementation which adheres to this prescription. I very much > > doubt that any implementation ever will adhere to it. > > It's not really a prescription for the IPv6 layer itself, but rather for > designers of protocols or applications that run over IPv6. It's bringing > to their attention that they cannot simply assume that every IPv6 node > can reassemble an arbitrarily large packet, and it's specifying a particular > size that is known to be accepted everywhere. I'd be happy to change the > text in the IPv6 spec to make that clearer. > Yes it is possible to interpret the text in that way particularly if one is grounded in the complete historical context of IPv4. However, it cannot be assumed that people who write RFP type documents have such grounding. They see MUST NOT in a specification and tend to flip out. Rational inter- pretation and common sense are the first casualties. > > This text has been in the IPv6 base specification for a long time and > > implementation experience indicates that it is being ignored. > > Similar language has been in the IPv4 spec even longer. I suspect, however, > that many upper-layer implementors don't know about it. For those for > whom all the world was BSD Unix, they never had to be concerned about this, > since the BSD IP implementation does not have a limit on its IP reassembly > size. Is the same true of Windows IP (now that all the world is Windows)? > Nonetheless, I think it is desirable to allow an IPv6 implementation to > bound its reassembly buffer size, and to discourage the development of > upper-layer protocols that would break when sending to such an implementation. > I believe it is true of most Windows implementations as well. I agree that it is desireable for small memory implementations to bound their reassembly buffers. The text you have suggested as a replacement provides appropriate guidance without making use of the draconian MUST NOT phrasing. This is sufficient. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 16:27:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA16492 for ipng-dist; Fri, 14 Nov 1997 16:24:13 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA16485; Fri, 14 Nov 1997 16:24:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA21449; Fri, 14 Nov 1997 16:23:56 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA22165; Fri, 14 Nov 1997 16:23:41 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA24684; Fri, 14 Nov 1997 16:22:09 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <9711140604.AA00404@magic.33g.isrd.hitachi.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Nov 1997 16:21:21 -0800 To: tsuchiya From: Steve Deering Subject: (IPng 4841) Re: IPv4/IPv6 translator Cc: tonyhain@microsoft.com, gilligan@freegate.net, rlfink@lbl.gov, ngtrans@sunroof.eng.sun.com, hinden@Ipsilon.COM, ipng@sunroof.eng.sun.com Sender: owner-ipng@eng.sun.com Precedence: bulk Tsuchiya-san, I think the discussion of v4/v6 translators and NATs falls better within the scope of the ngtrans working group, so I am forwarding your request to the chairs of that group and to that group's mailing list. Everyone else: please move any further discussion of NATs and translators to the ngtrans list . Thanks, Steve -------- At 10:04 PM -0800 11/13/97, tsuchiya wrote: > My name is Kazuaki Tsuchiya. I work at Hitachi, Ltd. in Japan and > develop an IPv6 router (NR60). I am also a WIDE project member. > > Various transition mechanisms have been already studied as ways to > transit from an IPv4 to an IPv6 smoothly. Additionally I think that it > is necessary to be able to communicate between an IPv6-only node and an > IPv4-only node. So now I am writing an Internet-Draft about it and I > will submit it next Monday. > > Would you plese have time to talk about it at the ipngwg next IETF > meeting in Washington, DC? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 16:31:05 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA16524 for ipng-dist; Fri, 14 Nov 1997 16:28:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA16509 for ; Fri, 14 Nov 1997 16:28:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA22309 for ; Fri, 14 Nov 1997 16:28:03 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA23930 for ; Fri, 14 Nov 1997 16:27:48 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA27979; Fri, 14 Nov 97 16:25:43 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA00618; Fri, 14 Nov 1997 16:28:23 -0800 Date: Fri, 14 Nov 1997 16:28:23 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199711150028.QAA00618@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4842) Re: Reassembly Size X-Sun-Charset: US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Erik, > > > I feel that if this is going to remain a MUST NOT then we need to specify > > a mechanism which will allow the sending node to determine the maximum > > reassembly size of the destination node. Some sort of ICMPv6 error message > > would probably handle the situation. In the alternative, changing the > > MUST NOT to a SHOULD NOT would be sufficient. > > The mechanism might be specific to the higher level protocol. > For instance, NFS (over both UDP and TCP) use the FSINFO call (rfc 1813) > to discover the maximum size of a write request. This means that > the server implicitly states that UDP can reassemble that amount (plus > IP+UDP+RPC+NFS headers). > I am not an NFS expert but my understanding is that the FSINFO can bound the read and write sizes but it is still possible for the result of a READDIR or READDIRPLUS to exceed the reassembly size. FSINFO does not help with this case. I may be mistaken about this. In any event I agree that this is best left to the upper layers. Putting a MUST NOT in the IPv6 base specification does not seem to leave us with the freedom to do that. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 17:02:00 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA16669 for ipng-dist; Fri, 14 Nov 1997 16:57:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA16662 for ; Fri, 14 Nov 1997 16:57:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA29191 for ; Fri, 14 Nov 1997 16:57:31 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA05286 for ; Fri, 14 Nov 1997 16:57:29 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA28212; Fri, 14 Nov 1997 16:57:25 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199711150014.QAA00604@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Nov 1997 16:56:36 -0800 To: thartric@mentat.com (Tim Hartrick) From: Steve Deering Subject: (IPng 4843) Re: Reassembly Size Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@eng.sun.com Precedence: bulk At 4:14 PM -0800 11/14/97, Tim Hartrick wrote: > The text you have suggested as a replacement provides > appropriate guidance without making use of the draconian MUST NOT phrasing. > This is sufficient. OK, I'll fix it. Thanks for pointing it out. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 17:02:57 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA16678 for ipng-dist; Fri, 14 Nov 1997 16:58:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA16671 for ; Fri, 14 Nov 1997 16:58:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA29328 for ; Fri, 14 Nov 1997 16:58:12 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA05566 for ; Fri, 14 Nov 1997 16:58:10 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA27645; Fri, 14 Nov 1997 16:50:59 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199711131320.AA13238@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Nov 1997 16:50:10 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 4844) Re: IPv6 Base Spec Cc: hinden@ipsilon.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@eng.sun.com Precedence: bulk At 5:20 AM -0800 11/13/97, bound@zk3.dec.com wrote: > Are we to get a new IPv6 base spec for Wash D.C. with the new flow label > and the Class field extended. Yes. It's just waiting for resolution of the min MTU issue, the plan being to submit the updated draft before the ID deadline next Friday. > Also its unacceptable for the norm to be like the last Munich IPng WG > meeting to be how Wash D.C. goes. We come and the chairs tell us what > they think should be changed in the base header every three months > without some mail discussion and an updated Internet draft. We will > never get done. Telling us that this is what XXXX Internet illuminary > thinks is good is OK but that don't make it a done deal or go through > the rigorous testing of this mailing list. If you are referring to me bringing up the proposal that we add a Congestion Experienced bit to the IPv6 header, the decision of the meeting -- with which I agreed -- was not to add such a bit at this time but to give its proponents and the WG group more time to evaluate the proposal. There was no "done deal". I admit that we, the chairs, didn't do an adequate job of time management in Munich: given our limit of two meeting slots, we should have reduced or postponed the discussion of the Congestion Experienced bit, so that we have could have gotten through our entire agenda (apologies again to those who got dropped off the end). However, in general (i.e., time permitting), I think it's fine for the chairs or anyone else to bring up new topics/proposals/suggestions for the first time at a WG meeting, with subsequent follow-up discussion on the mailing list, publication of drafts, etc. That's often the most efficient way to get a quick reading on the level of interest and support for a new idea, to know whether or not it is worth expending the effort on producing a draft, etc. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 14 18:38:06 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id SAA16839 for ipng-dist; Fri, 14 Nov 1997 18:31:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA16823 for ; Fri, 14 Nov 1997 18:30:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA14161 for ; Fri, 14 Nov 1997 18:30:16 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA05541 for ; Fri, 14 Nov 1997 18:30:13 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id CA15798; Sat, 15 Nov 1997 13:26:35 +1100 (from kre@munnari.OZ.AU) To: Dimitry Haskin Cc: iesg@ietf.org, crawdad@fnal.gov, Steve Deering , Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 4845) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Dimitry Haskin's message of "Fri, 14 Nov 1997 12:09:52 -0500." References: <3.0.1.32.19971114120952.0073be28@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Nov 1997 13:26:28 +1100 Message-Id: <9990.879560788@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@eng.sun.com Precedence: bulk Date: Fri, 14 Nov 1997 12:09:52 -0500 From: Dimitry Haskin Message-ID: <3.0.1.32.19971114120952.0073be28@pobox> | I disagree with Matt on this issue. I agree with Dimitry - and if we were to open this issue again, which I certainly hope that we don't, I'd suggest mangling the EUI-64 much more than just by inverting a bit. That is, instead of xoring the EUI64 with 0200000000000000 (hex) I'd suggest xoring it with something like 32e71064cf254819 such that it is absolutely unrecognisable as a related MAC type address (while still being exactly as unique). (Assigned addresses would still be used as assigned - and would keep that local/global bit clear). We need to make it 100% clear that IPv6 addresses do not contain EUI-64's, rather they are sometimes derived from an EUI-64. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 15 06:02:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id FAA17075 for ipng-dist; Sat, 15 Nov 1997 05:57:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id FAA17068 for ; Sat, 15 Nov 1997 05:57:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA01138 for ; Sat, 15 Nov 1997 05:56:52 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA20130 for ; Sat, 15 Nov 1997 05:56:49 -0800 (PST) From: Masataka Ohta Message-Id: <199711151350.WAA01329@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA01329; Sat, 15 Nov 1997 22:50:04 +0900 Subject: (IPng 4847) Re: message size To: Mark.Andrews@cmis.CSIRO.AU Date: Sat, 15 Nov 97 22:50:03 JST Cc: mohta@necom830.hpcl.titech.ac.jp, namedroppers@internic.net, ipng@sunroof.eng.sun.com In-Reply-To: <199711150238.NAA26873@snowy.nsw.cmis.CSIRO.AU>; from "Mark.Andrews@cmis.CSIRO.AU" at Nov 15, 97 1:38 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@eng.sun.com Precedence: bulk Mark; > All this indicates is that IPv6 need a mechanism to force > fragmentation to the IPv6 MTU, rather than doing PMTU discovery > at the socket level so that those applications that won't > benefit from, or will be aversely effected by PMTU discovery > will work. > > Large DNS/UDP is a example of where this is needed. Perhaps, you are partially right. But that's what PMTUD advocates don't want to admit. But, it is not an efficient way of using the network to always send fragmented packets of 576 bytes, even if the path MTU is 1500. On the other hand, 1280 byte is rather long that if applications needs 512 byte of payload and lower layers needs less than 768 byte of header, there is no inefficiency of fragmentation. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 15 12:17:33 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA17173 for ipng-dist; Sat, 15 Nov 1997 12:14:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA17166 for ; Sat, 15 Nov 1997 12:14:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA05385 for ; Sat, 15 Nov 1997 12:14:02 -0800 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id MAA27416 for ; Sat, 15 Nov 1997 12:14:03 -0800 (PST) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sat Nov 15 15:12:53 EST 1997 Received: from dnrc.bell-labs.com ([135.17.249.185]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id PAA07457; Sat, 15 Nov 1997 15:05:27 -0500 (EST) Message-ID: <346DEBAB.1B9E1BD0@dnrc.bell-labs.com> Date: Sat, 15 Nov 1997 13:36:29 -0500 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: Matt Crawford CC: iesg@ietf.org, Steve Deering , Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 4848) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard References: <199711132358.RAA16001@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk Matt Crawford wrote: [..] > The simplification of the specs is my > main point. > Matt Crawford I concur with Matt's concern. The IPv6 over NBMA spec required somewhat stilted text (although that might just be my writing style ;-) to explain why we were building on an EUI-64 number space but flipping the semantics of one particular bit. If we were simply lifting a semantic-free 64 bit field from somewhere then assigning our desired semantics to one bit it would be easy. But we're flipping 'existing' semantics for reasons that are not trivially apparent. Perhaps Dimitri is right, its too late to change, but I'd certainly feel more comfortable in 5 years if I didn't have to repeatedly explain to implementors, students, professors, etc.... the non-obvious reasons for the flip. cheers, gja ________________________________________________________________________ Grenville Armitage High Speed Networks Research http://nj5.injersey.com/~gja Bell Labs, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 16 21:32:52 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id VAA17873 for ipng-dist; Sun, 16 Nov 1997 21:30:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id VAA17866 for ; Sun, 16 Nov 1997 21:30:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA17213 for ; Sun, 16 Nov 1997 21:30:04 -0800 Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id VAA08099 for ; Sun, 16 Nov 1997 21:30:03 -0800 (PST) Received: by owl.ee.lbl.gov (8.8.8/8.8.5) id VAA03819; Sun, 16 Nov 1997 21:30:02 -0800 (PST) Message-Id: <199711170530.VAA03819@owl.ee.lbl.gov> To: ipng@sunroof.eng.sun.com cc: kkrama@research.att.com Subject: (IPng 4851) Internet Draft on Explicit Congestion Notification (ECN) Date: Sun, 16 Nov 1997 21:30:02 PST From: Sally Floyd Sender: owner-ipng@eng.sun.com Precedence: bulk K. K. Ramakrishnan and I have submitted an Internet draft on "A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP" today. A copy of the draft is attached. We would welcome comments. While the proposal involves the domain of several working groups (ipng, tcplw), and we are therefore sending this announcement to the mailing lists of several working groups, we are assuming that general discussion will happen on the end2end-interest mailing list. (Subscription information for end2end-interest: "http://www.irtf.org/irtf/charters/end2end.htm".) Thanks very much, Sally Floyd and K. K. Ramakrishnan. ----------------------------------------------------------------------- Internet Engineering Task Force K. K. Ramakrishnan INTERNET DRAFT AT&T Labs Research draft-kksjf-ecn-00.txt Sally Floyd LBNL November 1997 Expires: May 1998 A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This note describes a proposed addition of ECN (Explicit Congestion Notification) to IPv6 and to TCP. First we describe TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion, but could instead set an ECN bit in the packet header, for ECN-capable transport protocols. We describe when the ECN bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols advance through the standards process. Ramakrishnan and Floyd Informational [Page 1] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 TCP's congestion control and avoidance algorithms are based on the notion that the network is a black-box [Jacobson88, Jacobson90]. The network's state of congestion or otherwise is determined by end- systems probing for the network state, by gradually increasing the load on the network (by increasing the window of packets that are outstanding in the network) until the network becomes congested and a packet is lost. Treating the network as a "black-box" and treating loss as an indication of congestion in the network is appropriate for pure best-effort data carried by TCP that has little or no sensitivity to delay or loss of individual packets. In addition, TCP's congestion management algorithms have techniques built-in (such as fast retransmit and fast recovery) to minimize the impact of losses from a throughput perspective. However, these mechanisms are not intended to help applications that are in fact sensitive to the delay or loss of one or more individual packets. Interactive traffic such as telnet, web-browsing, and transfer of audio and video data ("real-audio" and "real-video") can be sensitive to packet losses (for unreliable data delivery such as UDP) or to the increased latency of the packet caused by the need to retransmit the packet after a loss (for reliable data delivery such as TCP). Since TCP determines the appropriate congestion window to use by gradually increasing the window size until it experiences a dropped packet, this causes the queues at the bottleneck router to build up. With most packet drop policies at the router that are not sensitive to the load placed by each individual flow, this means that some of the packets of latency-sensitive flows are going to be dropped. Active queue management mechanisms that detect congestion before the queue overflows, and provide an indication of this congestion to TCP, is desirable because it avoids some bad properties of dropping on queue overflow, especially with drop-tail schemes. Drop tail introduces synchronization of loss across multiple flows which is undesirable. Indicating incipient congestion means that TCP does not have to increase its window size up to the point where a router's buffer is filled up. This can reduce queuing delays and avoid synchronization, which are desirable characteristics. 2. Random Early Detection (RED) Random Early Detection (RED) is a mechanism for active queue management that has been proposed to detect incipient congestion [FJ93], and is currently being deployed in the Internet backbone [RED-ietf-draft]. Although RED is meant to be a general mechanism using one of several alternatives for congestion indication, in the current environment of the Internet RED is restricted to using packet drops as a mechanism for congestion indication. By dropping packets Ramakrishnan and Floyd Informational [Page 2] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 based on the average queue length exceeding a threshold, rather than only when the queue overflows, RED maintains the average queue at a smaller level, and improves the delay experienced by the flows. However, when RED drops packets before the queue actually overflows, RED is not forced by memory limitations to discard the packet. RED could set an Explicit Congestion Notification bit in the packet header instead of dropping the packet, if such a bit was provided in the IP header and understood by the transport protocol. The use of the Explicit Congestion Notification bit would allow the receiver(s) to receive the packet, avoiding the potential for excessive delays due to retransmissions after packet losses. 3. Explicit Congestion Notification We propose that the Internet provide a congestion indication for incipient congestion (as in RED and earlier work [RJ90]) where the notification can sometimes be through marking packets rather than dropping them. This would require an ECN field in the IP header with two bits. The ECN-Capable bit would be set by the data sender to indicate an ECN-capable transport protocol. The ECN bit would be set by the router to indicate congestion to the end nodes. ([Floyd94] outlines a scheme where a single bit could be overloaded to serve the function of both the ECN-Capable bit and the ECN bit, but the two-bit scheme is more straightforward to explain). We expect that routers would provide the congestion indication on incipient congestion as indicated by the average queue size, using the RED algorithms suggested in [FJ93, RED-ietf-draft]. Routers that have a packet arriving at a full queue would drop the packet, just as they do now. The congestion control algorithms followed at the end-systems would be essentially the same as the congestion control response to a *single* dropped packet, for a transport protocol where a dropped packet is used as an indication of congestion. For TCP in particular, the source TCP would halve its congestion window "cwnd" in response to an ECN indication received by the data receiver. However, this action is done only once per window of data (i.e., at most once per roundtrip time), to avoid reacting multiple times to multiple indications of congestion within a roundtrip time. 4. Proposed Algorithm at the Router We describe the proposed algorithm at the router in the context of current router implementations. We assume that the router is capable of implementing the probability computation for RED and uses a pure packet drop mechanism (e.g., drop from front, drop from tail, or random drop) whenever a packet arrives at a full queue. When the router's buffer is not yet full and the router is prepared Ramakrishnan and Floyd Informational [Page 3] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 to drop a packet to inform end nodes of incipient congestion, the router should first check to see if the ECN-Capable bit is set in that packet's IP header. If so, then instead of dropping the packet, the router could instead set the ECN bit in the IP header. When more severe congestion has occurred and the router's queue is full, then the router has no choice but to drop some packet when a new packet arrives. The router determines it is congested if the AVERAGE length of any of its queues where packets are waiting to be processed or transmitted exceeds a threshold. We believe that the router should use the ECN bit to notify that it is congested only when the *average* queue length, rather than the instantaneous queue length, exceeds a threshold. There are potentially several alternatives for estimating the average queue length and marking the ECN bit. Since there is considerable effort involved already in implementing RED, we believe it is best to leverage these efforts for ECN as well. One potential mechanism for the averaging and marking is to perform functions similar to RED queue management: RED uses an exponential moving average of the queue size. When the average queue size goes above a lower threshold, packets are marked with a probability of marking that increases with the average queue size. (Packets that are not ECN-capable are dropped instead of marked.) When the average queue size gets up to or above a high threshold, all incoming packets should be dropped (assuming that the router intends to control the average queue size even in the presence of unresponsive traffic). It is anticipated that when all of the source end-systems participate in TCP's congestion management mechanisms or other compatible congestion control, and respond to ECN by reducing their offered load, packet losses would be relatively infrequent. Packet losses in this case would occur primarily during transients and in the presence of non-cooperating entities. When a packet is received by a router with the ECN bit set indicating that congestion was encountered upstream, then the bit is left unchanged, and the packet transmitted as usual. 5. Support from the Transport Protocol ECN requires support from the transport protocol, in addition to the ECN field in the IPv6 packet header. For TCP, ECN requires two new mechanisms: negotiation between the endpoints during setup to determine if they are both ECN-capable, and an ECN-Notify bit in the TCP header so that the data receiver can inform the data sender when a packet has been received with the ECN bit set. The support Ramakrishnan and Floyd Informational [Page 4] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 required from other transport protocols is likely to be different, particular for unreliable or reliable multicast transport protocols, and will have to be determined as other transport protocols are brought to the IETF for standardization. The following sections describe in detail the proposed TCP use of ECN. This is also described in [Floyd94]. We assume that the source TCP uses the current set of congestion control algorithms of Slow-start, Fast Retransmit and Fast Recovery [RFC 2001]. 5.1. TCP Initialization Initially, the source and destination TCPs exchange the desire and/or capability to use ECN in the TCP connection setup phase. As a result of the negotiation, the TCP sender indicates using the ECN-Capable bit in the IPv6 header that the transport is capable and willing to participate in ECN. This will indicate to the routers that they may mark packets with the ECN bit, if they would like to use that as a method of congestion notification. If the TCP connection does not wish to use ECN notification, the sending TCP sets the ECN-Capable bit equal to 0 (i.e., not set), and the TCP receiver ignores the ECN bit in received packets. 5.2. The TCP Sender For a connection that expects to use ECN, packets are transmitted with the ECN-Capable bit set in the IP header (set to a "1"). If the sender receives a TCP acknowledgement with the ECN-Notify bit set in the TCP header, then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh". The sending TCP does NOT increase the congestion window in response to the receipt of an ACK packet with the ECN-Notify bit set. However, a very important difference is that TCP does not react to ECN congestion indications more than once every window of data (or more loosely, more than once every round-trip time). If a response to the ECN-Notify bit was made over the last round-trip time, based on the window of packets, then the sending TCP doesn't respond to any further ECN messages. If at time "t", the source TCP reacted to an ECN, then it notes the packets that are outstanding at that time and have not yet been acknowledged. Until all these packets are acknowledged, say at time "u", the source TCP does not react to another ECN indication of congestion. In addition, when a TCP sender receives duplicate acks during the time interval between "t" and "u", it does not reduce the congestion window. The result is that decreases in the congestion window occur Ramakrishnan and Floyd Informational [Page 5] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 at most once per roundtrip time. When the TCP sender receives a packet with the ECN-Notify bit set, and therefore reduces its congestion window, the sender does not need to slow-start (as is done in Tahoe TCP in response to a packet drop) or to stop sending packets for a period of time to allow the queue to dissipate (as is done by Reno TCP for roughly half a round-trip time in response to a packet drop). The ECN-Notify bit being set does not indicate the urgent transient congestion state of a buffer overflow. Incoming acknowledgements will still arrive to "clock out" outgoing packets when allowed by the congestion window. TCP follows existing algorithms for sending data packets in response to incoming ACKs, multiple duplicate acknowledgements, or retransmit timeouts [RFC2001]. 5.3. The TCP Receiver At the destination end-system, when TCP receives a packet with the ECN bit set in the IP header, TCP sets the ECN-Notify bit in the TCP header in the returning ACK packet. We do not provide here any notion of destination congestion, because this is already being indicated in the receiver's advertised window. The destination TCP continues to perform the duplicate ACK procedure already specified - to generate a duplicate ACK when an out-of- sequence packet is received. If there is any ACK withholding implemented, as in current TCP implementations where the TCP receiver often sends an ACK for two arriving data packets, then the TCP destination will send the OR of all the ECN bits of packets that the ACK is acknowledging. That is, if any packet is received with the ECN bit set, then the ACK carries the ECN-Notify bit set. 5.4. Congestion on the ACK-path For the current generation of TCP congestion control algorithms, pure acknowledgement packets (e.g., packets that do not contain any accompanying data) should be sent with the ECN-capable bit off. Current TCP receivers have no mechanisms for reducing traffic on the ACK-path in response to congestion notification. Mechanisms for responding to congestion on the ACK-path can be relegated as an area for future research. (One simple possibility would be for the sender to reduce its congestion window when it receives a pure ACK packet with the ECN bit set). For current TCP implementations, a single dropped ACK generally has only a very small effect on the TCP's sending rate. Ramakrishnan and Floyd Informational [Page 6] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 6. Summary of changes required in IPv6 and TCP Two bits need to be specified in the IPv6 header, the ECN-Capable bit and the ECN bit. The ECN-Capable bit set to "0" indicates that the transport protocol will ignore the ECN bit. This is the default value. The ECN-Capable bit set to "1" indicates that the transport protocol is willing and able to participate in ECN. The default value for the ECN bit is "0". The router sets the ECN bit to "1" to indicate congestion to the end nodes. The ECN bit in a packet header should never be reset by a router from "1" to "0". TCP requires two changes, a negotiation phase during setup to determine if both end nodes are ECN-capable, and a bit in the TCP header (possibly one of the "reserved" bits in the TCP flags field) as an ECN-Notify bit so that the receiver can inform the sender of a packet received with the ECN bit set. 7. Non-relationship to ATM's EFCI indicator or Frame Relay's FECN Since these ATM and Frame Relay mechanisms typically have been defined without any notion of average queue size as the basis for concluding that there is congestion, we believe that they provide a very noisy signal. The interpretation we have here for ECN is NOT the appropriate reaction for such a noisy signal of congestion notification. It is our belief that such mechanisms would be phased out over time within the ATM network. However, if the routers that interface to the ATM network have a way of maintaining the average queue at the interface, and use it to come to a conclusion that the ATM subnet is congested or otherwise, they may use the ECN notification that is defined here. 8. Non-compliance by the End Nodes We believe that, for the most part, the fairness properties of TCP will not be changed with the introduction of ECN. A key issue concerns the vulnerability of ECN to non-compliant end- nodes (i.e., end nodes that set the ECN-capable bit in packets, but do not respond to the ECN bit itself). These concerns exist even in non-ECN environments. An end-node could "turn off congestion control" by not reducing its congestion window in response to packet drops. We recognize that this is a concern for the current Internet. It has been argued that routers will have to deploy mechanisms to detect and differentially treat packets from non-compliant flows. It is likely that techniques such as end-to-end per-flow scheduling and isolation of one flow from another, potentially accompanied by end- to-end reservations, could mitigate such effects. Such isolation Ramakrishnan and Floyd Informational [Page 7] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 mechanisms could remove some of the more egregious effects of non- compliance. However, even in networks just restricted to packet losses as an indication of congestion, several methods have been proposed to identify and treat non-compliant or unresponsive flows. These mechanisms would be equally applicable for identifying flows that do not respond to ECN. If anything, routers would have a slightly easier time identifying flows that do not respond to ECN. For example, routers can observe packets arriving at the router with the ECN bit set, as well as keeping note of packets that have the ECN bit set at that router itself. It has been argued that dropping packets in itself may be considered a deterrrent for non-compliance. However, we believe that the packet drop rates are likely to be reasonably low in environments where ECN is deployed. The reduction in load due to packet drops to deal with non-compliant nodes is likely to be small. The control of congestion is more likely to come from end-nodes reacting to congestion - either from responding to dropped packets or ECN Notify indications and halving the window. ECN should be used at a router when the average queue size is below some high threshold; when the average queue size exceeds the high threshold, and therefore packet drop/marking rates are higher, our recommendation is that routers drop packets, rather then setting the ECN bit in packet headers. Thus, in scenarios with low packet drop rates, the fact that the congestion control indications are in the form of packet drops rather than ECN bits does not significantly change the negative consequences on the compliant flows because of some flow "turning off" congestion control. We also do not believe that packet dropping itself is an effective deterrent for non-compliance. Many flows that retransmit dropped packets could have an incentive to maintain or even increase their sending rate in response to packet drops, rather than decreasing their sending rate, in the absence of mechanisms at the router to provide a negative deterrance for such behavior. For example, flows that use unreliable transport protocols could simply increase their use of FEC in response to an increased packet drop rate, and might choose increased FEC and no congestion control. We believe that the effect of packet dropping as a deterrence for non-compliance with congestion control mechanisms is quite small. The possibility of non-compliant flows does not offer a compelling reason not to deploy ECN. 9. Additional Considerations Some care is required to handle the ECN and ECN-Capable bits appropriately when packets are encapsulated and un-encapsulated for Ramakrishnan and Floyd Informational [Page 8] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 tunnels. When the router at the end of the tunnel decapsulates the packet, then the ECN bit in the encapsulating ('outside') header should be ORed with the ECN bit in the encapsulated ('inside') header that remains. Basically, a 1 in the encapsulating header should be copied into the encapsulated header. An additional issue concerns packets that have the ECN bit set at one router, and are later dropped at another router. For the proposed use for ECN in this paper (that is, for data packets for TCP), this is not a concern, because end nodes detect dropped data packets, and the congestion response of the end nodes to a dropped data packet is at least as strong as the congestion response to a packet received with the ECN bit set. This issue will have to be addressed if ECN and ECN-Capable bits are used on pure ACK packets, because in current implementations of TCP the drop of an ACK packet is not explicitly detected by the end nodes. If a packet with the ECN bit is later dropped due to corruption (bit errors), the end node should still invoke congestion control, just as TCP would today, to a dropped data packet. This issue would also have to be addressed in future proposals for distinguishing between packets dropped due to corruption and packets dropped due to congestion. 10. Conclusions Given the current effort to implement RED, we believe this is the right time for router vendors to examine how to also implement congestion avoidance mechanisms that do not depend on packet drops alone. With the growth of applications and transports that are sensitive to delay and loss of a single packet, depending on packet loss as a normal congestion notification mechanism appears to be insufficient (or at the very least, non-optimal). Ramakrishnan and Floyd Informational [Page 9] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 REFERENCES [FJ93] Floyd, S., and Jacobson, V., "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf". [Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23. URL "ftp://ftp.ee.lbl.gov/papers/tcp_ecn.4.ps.Z". [Floyd97] Floyd, S., and Fall, K., "Router Mechanisms to Support End-to-End Congestion Control", Technical report, February 1997. URL "ftp://ftp.ee.lbl.gov/papers/collapse.ps". [FRED] Lin, D., and Morris, R., "Dynamics of Random Early Detection", SIGCOMM '97, September 1997. URL "http://www.inria.fr/rodeo/sigcomm97/program.html#ab078". [Jacobson88] V. Jacobson, "Congestion Avoidance and Control", Proc. ACM SIGCOMM '88, pp. 314-329. URL "ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z". [Jacobson90] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", Message to end2end-interest mailing list, April 1990. URL "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt". [RED-ietf-draft] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", Internet draft draft-irtf-e2e-queue-mgt-00.txt, March 25, 1997. [RFC2001] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. [RJ90] K. K. Ramakrishnan and Raj Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions on Computer Systems, Vol.8, No.2, pp. 158-181, May 1990. SECURITY CONSIDERATIONS Security issues are not discussed in this document. Ramakrishnan and Floyd Informational [Page 10] draft-kksjf-ecn Addition of ECN to IPv6 and TCP November 1997 AUTHORS' ADDRESSES K. K. Ramakrishnan AT&T Labs. Research Phone: +1 (973) 360-8766 Email: kkrama@research.att.com URL: http://www.research.att.com/info/kkrama Sally Floyd Lawrence Berkeley National Laboratory Phone: +1 (510) 486-7518 Email: floyd@ee.lbl.gov URL: http://www-nrg.ee.lbl.gov/floyd/ This draft was created in November 1997. It expires May 1998. Ramakrishnan and Floyd Informational [Page 11] ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 07:18:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA18396 for ipng-dist; Mon, 17 Nov 1997 07:15:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA18389 for ; Mon, 17 Nov 1997 07:15:47 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA15742 for ; Mon, 17 Nov 1997 07:15:46 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA22133 for ; Mon, 17 Nov 1997 07:15:41 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA24924; Mon, 17 Nov 1997 09:55:04 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA13024; Mon, 17 Nov 1997 09:54:48 -0500 Message-Id: <199711171454.AA13024@wasted.zk3.dec.com> To: Dimitry Haskin Cc: iesg@ietf.org, crawdad@fnal.gov, Steve Deering , Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 4853) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Fri, 14 Nov 1997 12:09:52 EST." <3.0.1.32.19971114120952.0073be28@pobox> Date: Mon, 17 Nov 1997 09:54:47 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk I just want to say we implemented this and its up and running. Also the MAC addresses are distinguishable. I am with Dimitry on this one. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 07:41:56 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA18433 for ipng-dist; Mon, 17 Nov 1997 07:39:26 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA18426 for ; Mon, 17 Nov 1997 07:39:16 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA23191 for ; Mon, 17 Nov 1997 07:39:15 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA02520 for ; Mon, 17 Nov 1997 07:39:13 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id KAA22847; Mon, 17 Nov 1997 10:03:45 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA13946; Mon, 17 Nov 1997 10:03:42 -0500 Message-Id: <199711171503.AA13946@wasted.zk3.dec.com> To: Cc: bound@zk3.dec.com, george@gideon.bt.co.uk, ipng@sunroof.eng.sun.com Subject: (IPng 4854) Re: Is that correct? In-Reply-To: Your message of "Fri, 14 Nov 1997 09:49:05 PST." <199711141749.AA04963@zed.isi.edu> Date: Mon, 17 Nov 1997 10:03:39 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk >RT records don't reflect how routing works folks. They're effectivly OBE, >much like WKS records. The code still exists so maybe they should be revitalized. As far as routing I agree. But that is not the point. A records that alias relays don't reflect routing either. The point is to direct the query to the NNAT server. That can be implementation defined too if necessary. But I believe the RT record is a nice place holder right now for discussion. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 09:27:36 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA18642 for ipng-dist; Mon, 17 Nov 1997 09:23:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA18635 for ; Mon, 17 Nov 1997 09:23:15 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id JAA09887 for ; Mon, 17 Nov 1997 09:23:15 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06481; Mon, 17 Nov 1997 09:23:04 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA16849 for ; Fri, 14 Nov 1997 18:40:33 -0800 (PST) From: Mark.Andrews@cmis.CSIRO.AU Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA15458 for ; Fri, 14 Nov 1997 18:40:30 -0800 Received: from snowy.nsw.cmis.CSIRO.AU (snowy.nsw.cmis.CSIRO.AU [130.155.16.108]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA08372 for ; Fri, 14 Nov 1997 18:40:27 -0800 (PST) Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id NAA26873; Sat, 15 Nov 1997 13:38:44 +1100 Message-Id: <199711150238.NAA26873@snowy.nsw.cmis.CSIRO.AU> Received: from pride.nsw.cmis.CSIRO.AU(130.155.16.4) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa006Zr; Sat Nov 15 13:38:38 1997 To: Masataka Ohta cc: namedroppers@internic.net cc: ipng@sunroof.eng.sun.com Subject: (IPng 4855) Re: message size In-reply-to: Your message of "Fri, 14 Nov 1997 13:26:47 +0200." <199711140427.NAA12112@necom830.hpcl.titech.ac.jp> Date: Sat, 15 Nov 1997 13:38:38 +1100 Sender: owner-ipng@eng.sun.com Precedence: bulk > Hi, > > Below is an excerpt from a Steve Deering's message posted to > IPng ML recently on the difficulty of PMTU discoverty as the > reason to increase IPv6 minimum MTU. > > : (2) DNS servers, or other similar apps that have the requirement of > : sending a small amount of data (a few packets at most) to a very > : large and transient set of clients. Such servers often reside on > : links, such as Ethernet, that have an MTU bigger than the links on > : which many of their clients may reside, such as dial-up links. If > : those servers were to send many reply messages of the size of their > : own links (as required by PMTU Discovery), they could incur very > : many ICMP packet-too-big messages and consequent retransmissions of > : the replies -- in the worse case, multiplying the total bandwidth > : consumption (and delivery delay) by 2 or 3 times that of the > : alternative approach of just using the min MTU always. Furthermore, > : the use of PMTU Discovery could result in such servers filling up > : lots of memory withed cached PMTU information that will never be > : used again (at least, not before it gets garbage-collected). > : > :The number I propose for the new minimum MTU is 1280 bytes (1024 + 256, > :as compared to the classic 576 value which is 512 + 64). That would > > Masataka Ohta > All this indicates is that IPv6 need a mechanism to force fragmentation to the IPv6 MTU, rather than doing PMTU discovery at the socket level so that those applications that won't benefit from, or will be aversely effected by PMTU discovery will work. Large DNS/UDP is a example of where this is needed. Mark -- Mark Andrews, CSIRO Mathematical and Information Sciences Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 9325 3148 INTERNET: Mark.Andrews@cmis.csiro.au MOBIL: +61 41 442 9884 UUCP:....!uunet!cmis.csiro.au!mark.andrews -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 09:48:45 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA18709 for ipng-dist; Mon, 17 Nov 1997 09:45:00 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA18702 for ; Mon, 17 Nov 1997 09:44:54 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id JAA12719 for ; Mon, 17 Nov 1997 09:44:54 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06548; Mon, 17 Nov 1997 09:44:43 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id EAA17475 for ; Sun, 16 Nov 1997 04:17:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA29274 for ; Sun, 16 Nov 1997 04:17:48 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA10179 for ; Sun, 16 Nov 1997 04:17:48 -0800 (PST) Received: (from peter@localhost) by gate.ticl.co.uk (8.8.5/8.8.5) id MAA23987; Sun, 16 Nov 1997 12:17:58 GMT From: Peter Curran Message-Id: <199711161217.MAA23987@gate.ticl.co.uk> Subject: (IPng 4856) Re: increasing the IPv6 minimum MTU In-Reply-To: <5961.879494490@munnari.OZ.AU> from Robert Elz at "Nov 14, 97 07:01:30 pm" To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 16 Nov 1997 12:17:58 +0000 (GMT) Cc: deering@cisco.com, ipng@sunroof.eng.sun.com, hinden@ipsilon.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk > | (3) Peter Curran pointed out to me that using a larger minimum MTU for > | IPv6 may result in much greater reliance on *IPv4* fragmentation and > | reassembly during the transition phase > > I would absolutely hate to nobble IPv6 forever based upon some perceived > transition difficulty. Even if this were to be a significant problem, which > I doubt (if those UK ISPs who think they're achieving something by limiting > the MTU eventually receive lots of complaints that IPv6 traffic is being > damaged by their policy, they can simply change it - the low MTU there is > not something that cannot be easily altered). I concurr - your statement is very much a good response to the problem. After looking at the discussion on the list for the past few days I strongly feel that the decision to increase the MTU to Steve's proposed 1280 is the correct one. My initial concerns about the impact on the transition strategy are ill-founded. The change of MTU to 1280 has no impact on the strategy that cannot be overcome by reconfiguration on the part of some small number of ISPs. It would be wrong to emasculate v6 because of a problem that can be overcome with minimal effort. Not to make the change (ie to stick with 576) will impact the effectiveness of many things we want to do, not least multicasting. Regards Peter Curran TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 09:53:31 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA18719 for ipng-dist; Mon, 17 Nov 1997 09:45:50 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA18712 for ; Mon, 17 Nov 1997 09:45:43 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id JAA12879 for ; Mon, 17 Nov 1997 09:45:42 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06575; Mon, 17 Nov 1997 09:45:31 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id EAA17490 for ; Sun, 16 Nov 1997 04:33:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA29777 for ; Sun, 16 Nov 1997 04:33:30 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA12040 for ; Sun, 16 Nov 1997 04:33:30 -0800 (PST) Received: (from peter@localhost) by gate.ticl.co.uk (8.8.5/8.8.5) id MAA24010; Sun, 16 Nov 1997 12:32:06 GMT From: Peter Curran Message-Id: <199711161232.MAA24010@gate.ticl.co.uk> Subject: (IPng 4857) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: <199711132358.RAA16001@gungnir.fnal.gov> from Matt Crawford at "Nov 13, 97 05:58:01 pm" To: crawdad@fnal.gov (Matt Crawford) Date: Sun, 16 Nov 1997 12:32:06 +0000 (GMT) Cc: iesg@ietf.org, deering@cisco.com, hinden@ipsilon.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@eng.sun.com Precedence: bulk Matt > I think we, the IPNG working group, may have made a poor > choice in deciding to complement the universal/local bit > when forming an IPv6 address from an EUI-64 identifier. > (For details, see draft-ietf-ipngwg-addr-arch-v2-05.txt > or draft-ietf-ipngwg-trans-ethernet-04.txt.) It's a poor > choice I could live with, but I'm hoping it can be > scrutinized first by individuals who weren't involved in > the choice. As long as the point is examined, any > outcome will be acceptable. I am an individual, I wasn't involved in the choice (I did not voice and opinion at the time) and I have scrutinised the result of the decision. I may have missed something important here (probably :-), but I think that you have misconstrued an important point. The fact the 64bit i/f-ID is generated from a MAC address is irrelevant. You can use whatever numbers you want, as long as they are unique on the link. Just because we have to jump through some hoops to **automatically** turn a 48-bit MAC address into a unique 64-bit value doesn't mean that the MAC->EUI-64 rules have to be used anywhere else. I agree that the logic behind flipping the G/L bit is tortuous - hell, I think it is a pretty dumb idea - but it is a done deal. > With the current documents, small integers may be freely > used as interface identifers, forming, for example, the > Subnet-Router anycast address which neatly ends with 64 > zero bits. But nodes auto-configuring their IPv6 unicast > addresses must flip a single bit in their built-in > address to form their Interface Identifier. [..... > > ....] If the spec were written the other way, so that an EUI-64 > is used directly as an Interface Identifier, the language > in the documents would be simpler, MAC addresses would be > somewhat more recognizable in packet traces or tables. > > On the down side, those small-integer identifiers would > have to look like this > 3ffe:7c0:40:9:200::0 > instead of the current > 3ffe:7c0:40:9::0 I disagree. Changing the meaning of the bit has no impact on this example. The autoconfigured address is derived from a MAC address, but the other interface is not and can use what it likes - so long as it is unique within its scope. Cheers Peter Curran TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 10:12:32 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA18921 for ipng-dist; Mon, 17 Nov 1997 10:09:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA18914 for ; Mon, 17 Nov 1997 10:09:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA04029 for ; Mon, 17 Nov 1997 10:09:26 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA22090 for ; Mon, 17 Nov 1997 10:09:22 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA27928; Mon, 17 Nov 1997 10:06:58 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199711150238.NAA26873@snowy.nsw.cmis.CSIRO.AU> References: Your message of "Fri, 14 Nov 1997 13:26:47 +0200." <199711140427.NAA12112@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Nov 1997 10:08:06 -0800 To: Mark.Andrews@cmis.CSIRO.AU From: Steve Deering Subject: (IPng 4858) Re: message size Cc: Masataka Ohta , ipng@sunroof.eng.sun.com, namedroppers@internic.net Sender: owner-ipng@eng.sun.com Precedence: bulk At 6:38 PM -0800 11/14/97, Mark.Andrews@cmis.CSIRO.AU wrote: > All this indicates is that IPv6 need a mechanism to force > fragmentation to the IPv6 MTU, rather than doing PMTU discovery > at the socket level so that those applications that won't > benefit from, or will be aversely effected by PMTU discovery > will work. Mark, I agree that it would be good to make that a required feature of the IPv6 API, but even with such a feature, I think we should also raise the minimum IPv6 MTU as I proposed, in order that fewer packets will require IP-level fragmentation, and in order to reduce header overhead, on the many links whose MTUs are greater than 576. Wherever there's any non-negligible risk of packet loss, it is best to minimize dependence on fragmentation, e.g., by limiting to only those links that really need it, because of the really bad effects fragment loss can have on end-to-end throughput. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 10:26:58 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA19072 for ipng-dist; Mon, 17 Nov 1997 10:23:53 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id KAA19065 for ; Mon, 17 Nov 1997 10:23:48 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id KAA18769 for ; Mon, 17 Nov 1997 10:23:48 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA06727; Mon, 17 Nov 1997 10:23:37 -0800 Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id KAA19007 for ; Mon, 17 Nov 1997 10:16:21 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id KAA17594 for ; Mon, 17 Nov 1997 10:16:20 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA06689; Mon, 17 Nov 1997 10:16:09 -0800 Date: Mon, 17 Nov 1997 10:16:09 -0800 From: John.Hird@eng.sun.com (John Hird) Message-Id: <199711171816.KAA06689@stinker.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4860) IP - ATM - Frameraly X-Sun-Charset: US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk ----- Begin Included Message ----- From hureleget2@hotmail.com Mon Nov 17 09:05:29 1997 Date: Mon, 17 Nov 1997 18:09:59 +0100 From: tsil Mime-Version: 1.0 To: ipng-approval@sunroof.eng.sun.com Subject: IP - ATM - Frameraly Content-Transfer-Encoding: 7bit Hi ! Maybe this is sent to wrong address, if so could you forward it to someone you think is proporiate please. I am working in the Telecommunication company in Norway, I am a little bit confused about the transport network for IP. My question is: Are there any other alternatives then to use ATM switches for transporting IPng in a country size network ? Okey, thanks for taking your time, Best regards, Torbjorn email: tsil@hotmail.com ----- End Included Message ----- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 12:40:31 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA19516 for ipng-dist; Mon, 17 Nov 1997 12:35:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA19509 for ; Mon, 17 Nov 1997 12:34:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA17857; Mon, 17 Nov 1997 12:33:43 -0800 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA10187; Mon, 17 Nov 1997 12:33:41 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id PAA26506; Mon, 17 Nov 1997 15:33:37 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA24124; Mon, 17 Nov 1997 15:33:24 -0500 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19552; Mon, 17 Nov 1997 15:33:17 -0500 Message-Id: <9711172033.AA19552@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Cc: nordmark@Eng (Erik Nordmark), John Gilmore Subject: (IPng 4861) RAs with 0 lifetime prefix (take II) Date: Mon, 17 Nov 1997 15:33:17 -0500 From: Thomas Narten Sender: owner-ipng@eng.sun.com Precedence: bulk Folks, I've been wrestling with the 0 Lifetime problem for some time and in conversations with a number of folks, two solutions appear to be the most popular. The rest of this note discusses the issues, and proposes that we choose one of 2 approaches. Here is a summary of the issues: Problem: Bogus Router Advertisments (RAs) containing (improperly) short lifetimes must be validated before processing, to prevent a bad guy from bringing down the entire network with a single packet. By bring down the network, I mean that a client that receives an RA containing a Prefix option with a valid Lifetime of 0 will immediately expire the address and all existing connections using that address would break. I view this as an attack that is an order of magnitude (or more) worse than anything IPv4 has today, and it needs to get fixed. By validation, I mean a client should verify that the "bogus" lifetime is indeed legitimate. That could be done through one of several ways, including: - cryptographically verifying the legitimacy of the received RA - delaying acting upon the allegedly bogus RA for a long enough time period that other legitimate routers have a chance to send out RAs with correct Lifetime information, i.e., cancelling the bogus one. There may be other ways, but I believe all other variations ultimately are variations on one of these two. In previous discussions, a "short" Lifetime has been defined as one less than 2 hours. The 2 hour figure comes from the fact that a router may sent advertisements out as infrequently as once every 30 minutes. If we allow for the possibility of occasional losses, 2 hours corresponds to missing 4 consecutive RAs. If we haven't received an update in 4 consecutive RAs, it seems unlikely that we will receive one anytime soon. Note: the exact time (e.g., 2 hours) can be changed and isn't important for the rest of this discussion. The following discusses some specific proposals: Proposal 1) Upon receipt of an RA with a Lifetime < 2 hours, attempt to prompt the real routers to send valid RAs. That is, send out a multicast RS to force the other routers to send RAs. If those RAs confirm the low lifetime, it is legit, otherwise, ignore it. Pros: will get answer quickly (i.e., seconds or minutes) rather than having to wait 2 hours. Cons: Relies on predictable (and correct) behavior from other nodes, which may leave door open for attacks based on thwarting the required behavior of others. For example, a denial-of-service (DOS) attack (e.g., flooding) on the legitimate router may prevent it from receiving the client RS, in which case the router won't send out a RA, and the client ultimately accepts the bogus RA as valid. At the same time, it should be noted that the additional DOS attack that is needed here raises the bar to exploit the original vulnerability, and makes it easier to track down the source of the attacker. I.e., it takes more than one packet, and the attacker has to stay around longer, increasing its chances of being caught. Consequently, maybe now the problem isn't really much worse than other types of DOS attacks that we have chosen not to address. Leads to multicast storm, since all hosts will do the same thing. Some additional protocol complexity would be needed to deal with this case. Requires client have some notion of how long a router will delay responses. Currently handled by having client retransmit several times. We probably do want to have client retransmit, to insure robustness in the face of DOS attacks aimed at overwhelming the legitimate router. Client will have to hold the received RA for some time, process it later (i.e., after the client concludes that no other RA with a longer Lifetime is coming). Current implementations don't need to do anything like this. They always process a packet in its entirety when they get it, and then toss it. So this (potentially) increases complexity of implementation. It has been suggested that the implementation complexity here isn't really that much. For example, we could define a new NUD state (e.g., CHALLENGE) that holds the received lifetime. Proposal 2) If an RA arrives with a Lifetime less than 2 hours, *and* less than the Lifetime it received previously, ignore the prefix entirely. Pros: Easy to implement. Cons: Prevents a sys admin from quickly lowering a Lifetime below 2 hours. For example, if the Lifetimes that had been advertised were one week (or month), one couldn't set them to 0, since they would be ignored. In order to expire a prefix, a router would first need to advertise the prefix at a value just above 2 hours. It would need to do this long enough for *all* (for some approximation of all) clients to recieve the RA, so that they all update their stored Lifetimes to the lower value. Once this has been done, the router can then start lowering the Lifetime below 2 hours and clients will time out the prefixes. Note that there is a practical problem here in that routers need to advertise prefixes with the 2+ hour Lifetime for a while, because once they lower their advertisement below 2 hours, it will be ignored by clients who (for whatever reason) didn't receive any of the RAs with the Lifetime of 2+ hours. Note that in this scenario, 0 Lifetimes would be ignored, which is problematic. Proposal 3) If an RA arrives with a Lifetime less than 2 hours, *and* less than the Lifetime it received previously (i.e, the Lifetime it has stored), bump the Lifetime up slightly, i.e., to the VALUE=minimum(2 hours, stored value), and process the Prefix Option as if it had been received with a Lifetime of VALUE. Specifically, something like the following: LifetimeNew = lifetime in received entry LifetimeStored = remaining lifetime of stored entry (i.e., lifetime in previously received RA minus the elapsed time since RA was received). if ((LifetimeNew > 0) & no_stored_entry_for_address) accept LifetimeNew /* let UNH create entries w/short lifetime */ else if ((LifetimeNew >= 2 hours) or (LifetimeNew > LifetimeStored)) accept LifetimeNew else if (LifetimeStored <= 2 hours) and (LifetimeNew < LifetimeStored)) ignore entry /* continue counting down, don't bump up to 2 hours */ else reset LifetimeNew to 2 hours, process normally. Pros: Relatively easy to implement, though not quite as simple as proposal 2). Allows system administrator to set Lifetime=0 and the right thing more-or-less happens as expected. Note that some nodes (i.e., those that miss receiving some RAs) may bump the Lifetimes at different times, and consequently some nodes will timeout their prefixes earlier than others. Cons: There are actually 2 Lifetimes in a Prefix option: preferred and valid. If we bump up the preferred timer, we also may need to bump the valid timer. (The valid Lifetime must always be >= preferred timer). Bumping up the preferred timer may make the time difference between the preferred and valid Lifetime zero (or essentially zero), which may make for an abrupt transition when the valid timer reaches zero (i.e., lots of connections break). Proposal 4) Ignore Lifetimes < 2 hours unless they are authenticated, e.g., via IPSec Proposal 5) Leave things as they are today (i.e., leave the problem unsolved), and say IPSec should be used if you are worried. I do not believe that either 4) or 5) are prudent choices. IPSec is new technology for which we don't (yet) have much deployment experience. There are some problems that IPSec seems well positioned to be useful in, but it is not clear that ND is one of them. In particular: - it is completely unspecfied today how one uses IPSec/ISAKMP with multicast; ND is multicast oriented. Specifically, routers send RAs to the all-nodes multicast address. To use IPSec with ND requires some more work. That work does not appear to be being done today. - one could imagine manually distributing keys and somehow making IPSec work. But the environment this is most likely to be practical in is a corporate environment (less diversity of machines, more central management of infrastructure), which is probably an environment in which the 0 lifetime attack is not of highest concern. In contrast, in a more open environment (e.g., a university), the need to protect the infrastructure from this attack is greater, but the ability to deploy IPSec seems much more problematic. My initial inclination had been to go with something akin to choice 3). In discussing this with Erik Nordmark, however, he suggested we tackle the problem from a separate angle. Paraphrasing his argument (I'm sure Erik will jump in if I'm misrepresenting his position): 1) Have the IP layer treat received RAs with small lifetimes just as is done today. Specifically, don't bump the lifetime if it is too short, don't ignore 0 lifetimes. Of course, a node that has an address expired is no longer allowed to originate datagrams with an expired source address. Consequently, the IP layer has to black hole packets that are being sent by upper layers with an improper source address. 2) Have upper layers (i.e., TCP, UDP) treat indications from IP that an address has just gone away suspiciously. In particular, TCP should not break connections using an address that has just been expired. That is, TCP is free to continue trying to retransmit, under the assumption that the condition is temporary and may get rectified later (e.g., if the 0 Lifetime was the result of a DOS attack, a legitimate RA will fix things again later). Note that the ignoring of a 0 lifetime indication is somewhat similar to the ignoring of ICMP destination unreachable messages, which TCP are supposed to ignore. Only if the connection times out after retransmitting is the connection actually terminated. It is also the case that TCP would be free to attempt to use an alternate source address, if it had one. Although this can't be done with current TCP, the possibility is there that future transport protocols (or a change to TCP) may make it possible to renumber in-progress connections in certain scenarios. By having the upper layer protocols ignore the 0 lifetime indication, we've effectively lowered the severity of the 0 lifetime DOS attack to other DOS attacks (e.g., pretending to be a router when in fact you are blackholing traffic) that we've chosen not to do anything special for. What do others think? Should we go with Erik's suggestion, Choice 3) above, or something completely different? Note: in the unlikely event that noone has strong feelings here, I'll reissue the addrconf draft with Erik's suggestion. It requires the fewest wording changes. :-) Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 14:48:13 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA19744 for ipng-dist; Mon, 17 Nov 1997 14:45:22 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id OAA19736 for ; Mon, 17 Nov 1997 14:45:11 -0800 (PST) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.0/8.8.7) with SMTP id OAA03781; Mon, 17 Nov 1997 14:45:10 -0800 (PST) Date: Mon, 17 Nov 1997 14:43:32 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4863) Re: RAs with 0 lifetime prefix (take II) To: Thomas Narten Cc: ipng@sunroof.eng.sun.com, Erik Nordmark , John Gilmore In-Reply-To: "Your message with ID" <9711172033.AA19552@cichlid.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Some clarifications and expansions on my idea. The approach is to try to avoid adding specific mechanisms to handle the zero prefix lifetime denial of service attack but instead rely on the robustness of the transport protocols. We have existing denial of service attacks in IPv4 today (such as using ARP or ICMP router discovery to black-hole all packets from a subnet) and more or less the same DoS attacks exist in IPv6. Transports (e.g. TCP) are robust in the face of such changes since they keep on retransmitting for a long time even if the packets are black holed or they receive ICMP unreachable errors. In these cases the packets are dropped by some other node. With the zero prefix lifetime it would be the IP on the sending node which would drop the packets after explicitely checking that the IP source address is an invalid address (i.e. not in the list of valid source addresses). But if the transports view this packet drop by the IP layer just like other packet drops in the network we can made the zero prefix lifetime DoS attack be no worse than the other DoS attacks available to neighbors on the link. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 18:11:12 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id SAA19994 for ipng-dist; Mon, 17 Nov 1997 18:05:02 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA19987 for ; Mon, 17 Nov 1997 18:04:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA19461 for ; Mon, 17 Nov 1997 18:04:37 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA19352 for ; Mon, 17 Nov 1997 18:04:20 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA13866; Mon, 17 Nov 1997 18:04:17 -0800 Message-Id: <3.0.3.32.19971117180341.007a77c0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 17 Nov 1997 18:03:41 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4864) IPng Request for Agenda Items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk The IPng working group will meet for three sessions at the Washington, DC IETF. They are: Monday 15:30-17:30 Thursday 09:00-11:30 Friday 09:00-11:30 Please send Steve Deering and myself proposed agenda items including topic description and length of time required. Thanks, Bob Hinden / Steve Deering IPng Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 18:26:19 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id SAA20015 for ipng-dist; Mon, 17 Nov 1997 18:21:28 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA20008 for ; Mon, 17 Nov 1997 18:21:13 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA22998 for ; Mon, 17 Nov 1997 18:21:07 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA25803 for ; Mon, 17 Nov 1997 18:20:51 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id VAA04830; Mon, 17 Nov 1997 21:14:35 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA21580; Mon, 17 Nov 1997 21:14:22 -0500 Message-Id: <199711180214.AA21580@wasted.zk3.dec.com> To: Sally Floyd Cc: ipng@sunroof.eng.sun.com, kkrama@research.att.com Subject: (IPng 4865) Re: Internet Draft on Explicit Congestion Notification (ECN) In-Reply-To: Your message of "Sun, 16 Nov 1997 21:30:02 PST." <199711170530.VAA03819@owl.ee.lbl.gov> Date: Mon, 17 Nov 1997 21:14:22 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Sally/KK, This is a smart thing to add to IPv6 header, thanks for doing this work. I think we should abopt this for the next base spec. The only issue is that you say you can do it with one bit but its easier to explain with two bits. I don't mind using up two bits if it will make the implementation and execution clearer and better, but not just for clarity of explaining the behavior. I think each bit we have in the class is precious. If we can do it with one lets do that is my input given my questions above. One suggestion for e2e list (I am not on that one anymore) is that in Section 4, 3rd paragraph: having several alternatives could cause different behaviors, the exponential moving average of the queue seems to be working and nailing down how to estimate the avg que lgth would be a good idea, instead of multiple options. I also could never figure out the math on this one but can understand it from code (your RED white paper). Love to understand the math on this one "offline" some time I got lost on the Integral!!! thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 17 23:02:44 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id XAA20164 for ipng-dist; Mon, 17 Nov 1997 23:00:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id XAA20156 for ; Mon, 17 Nov 1997 23:00:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA00517 for ; Mon, 17 Nov 1997 23:00:00 -0800 Received: from santacruz.org (santacruz.org [207.86.120.165]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA22823 for ; Mon, 17 Nov 1997 22:59:53 -0800 (PST) Received: from localhost (jest@localhost) by santacruz.org (8.8.7/8.8.5) with SMTP id XAA02927; Mon, 17 Nov 1997 23:13:33 -0800 Date: Mon, 17 Nov 1997 23:13:29 -0800 (PST) From: Gregory Taylor To: Peter Curran cc: Matt Crawford , iesg@ietf.org, deering@cisco.com, hinden@ipsilon.com, ipng@sunroof.eng.sun.com Subject: (IPng 4866) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: <199711161232.MAA24010@gate.ticl.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Patches for the ip_fragment bug (tear.c) can be located at www.rootshell.com, thank route for the patch to this error... new versions of linux and BSD will feature the patch already in the newest kernels. Thank You, Gregory Taylor Owner Resourceful Network Solutions, Inc. (253) 475-1227 jest@santacruz.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 02:12:53 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id CAA20280 for ipng-dist; Tue, 18 Nov 1997 02:10:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id CAA20273 for ; Tue, 18 Nov 1997 02:10:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA18338 for ; Tue, 18 Nov 1997 02:10:08 -0800 Received: from arthur.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id CAB20993 for ; Tue, 18 Nov 1997 02:09:59 -0800 (PST) Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by arthur.axion.bt.co.uk with SMTP (PP); Tue, 18 Nov 1997 10:09:34 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA08483; Tue, 18 Nov 1997 10:08:48 GMT Date: Tue, 18 Nov 1997 10:08:48 +0000 (GMT) From: George Tsirtsis To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4867) Re: message size In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk Dear all, Am I correct to assume that most of the traffic on the Internet is that of minimum MTU size packets (even more in IPv6 with compalsory PMTU discovery)? If yes,and as a colleague of mine pointed out to me, what is the effect of smaller or bigger packets on the Internet backbone? Eg.With bigger MTU (thus bigger avarage size of packets on the Net) we should see some reduction on ACKs? On the other hand congestion will have different effect because bigger packets will be lost... Has anyone studied this aspect of minimum MTU? If yes could you please point out or extrapolate? Thanks George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 06:22:46 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA20399 for ipng-dist; Tue, 18 Nov 1997 06:20:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA20392 for ; Tue, 18 Nov 1997 06:20:05 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA06867; Tue, 18 Nov 1997 06:19:57 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA12656; Tue, 18 Nov 1997 06:19:53 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA01573; Tue, 18 Nov 1997 08:58:50 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09361; Tue, 18 Nov 1997 08:58:48 -0500 Message-Id: <199711181358.AA09361@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com, nordmark@Eng (Erik Nordmark), John Gilmore , bound@zk3.dec.com Subject: (IPng 4868) Re: RAs with 0 lifetime prefix (take II) In-Reply-To: Your message of "Mon, 17 Nov 1997 15:33:17 EST." <9711172033.AA19552@cichlid.raleigh.ibm.com> Date: Tue, 18 Nov 1997 08:58:48 -0500 X-Mts: smtp Sender: owner-ipng@eng.sun.com Precedence: bulk Thomas, I don't think we have a great choice with number 3 but it may be the only choice. With #3 if an admin sends lifetime of 2 hours they can't then use RA's to get it to zero. But I don't think we have to fix all admin errors either or we will never get done with IPv6. I support choice #3. If it is bad enough the node admin will ifconfig delete the address off the interface. This has ramifications to the idea of letting connections persist with an invalid address which I discuss next. On permitting connections to persist once the valid lifetime is zero, I think is not an optimal idea for four reasons: 1. The transport should not send packets using an invalid address. I feel this is architecturally impure for IPv6. 2. The implementation protocol control blocks (PCBs) may still have the address and the interface may still be found there or as per host route (ND dst cache) from the route table, but once the lifetime is zero, it will not be associated with an interface. I think sending packets over an interface where the address has been deleted is very negligent from an implementation perspective. 3. The solution will not work for applications where UDP has not bound the address, when it won't have a PCB entry. So the solution is geared to TCP not UDP. The future will use Multicast as a means to develop distributed applications using new protocols like RTSP for reliability over UDP. I think we need to be cautious here for the future too. 4. We have built renumbering into the IPv6 architecture and have provided some flexibility. But, at the end of the day to make it really work there must be some rules. I have always believed that when an address becomes invalid (via the valid lifetime becoming zero) that the connection breaks. We have the preferred timer to prevent such occurrences and several of us are busy at work determining a means to dynamically renumber a connection on the fly, but I think we must adhere to what a zero lifetime means. The address is invalid. "you can't have your cake and eat to"...... Also if the node admin ifconfig deletes an address from an interface should transport connections continue? Its the same principal. I don't think so is my input. As I was also part of this offline discussion I think the ipngwg should also hear a compromise suggested too as a result of brainstorming from Richard Draves and myself on Eric's idea: When a connection is awaiting a response (TCP or UDP) and it knows that the address has become invalid, it MAY send a SHUTDOWN (I am adding this now) or a future message that the node is now using a new address. This permits a graceful end to the connection and permits us in the future to dyanmically renumber the connection at the very last minute if the node missed the opportunity to renumber during the addr conf deprcated state. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 06:34:02 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA20417 for ipng-dist; Tue, 18 Nov 1997 06:29:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA20410 for ; Tue, 18 Nov 1997 06:28:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA03745 for ; Tue, 18 Nov 1997 05:45:12 -0800 Received: from dent.axion.bt.co.uk (dent.axion.bt.co.uk [132.146.16.161]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA29840 for ; Tue, 18 Nov 1997 05:45:02 -0800 (PST) Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by dent.axion.bt.co.uk with SMTP (PP); Tue, 18 Nov 1997 13:44:30 +0000 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA08715; Tue, 18 Nov 1997 13:43:37 GMT Date: Tue, 18 Nov 1997 13:43:36 +0000 (GMT) From: George Tsirtsis To: ipng@sunroof.eng.sun.com Subject: (IPng 4869) Re: message size (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@eng.sun.com Precedence: bulk I forgot to copy that to the list... George ---------- Forwarded message ---------- Date: Tue, 18 Nov 1997 13:40:16 +0000 (GMT) From: George Tsirtsis To: "Hunter, Ray" Cc: 'George Tsirtsis' Subject: RE: (IPng 4867) Re: message size Ray, First not to be misunderstood, personally, I do not disagree with the proposed increase in minMTU size. I believe, however, that we may see an increase in minMTU sized packets in IPv6, because of large/mcast servers etc.. that do not want to do PMTU discovery and thus prefer to send minMTU sized packets and that may or may not have. Apart from that your analysis was very helpful and I thank you for that. regards George On Tue, 18 Nov 1997, Hunter, Ray wrote: > >---------- > >From: George Tsirtsis[SMTP:george@gideon.bt.co.uk] > >Sent: 18 November 1997 11:08 > >To: Steve Deering > >Cc: ipng@sunroof.Eng.Sun.COM > >Subject: (IPng 4867) Re: message size > > > >Dear all, > > > >Am I correct to assume that most of the traffic on the Internet is that of > >minimum MTU size packets (even more in IPv6 with compalsory PMTU > >discovery)? > > Why should this be the case? > > I mean people FTP and send email. That generates large packets. > > FYI The Cisco default is a 1500 byte MTU on serial links. > > Ethernet also has an MTU of 1500 bytes today. > > > In IPv6 if people implement path MTU discovery, they can use larger > packets... > regardless of what the minumum MTU is set to. > > I think the worry is that PMTU may not be widely implemented because it > requires > effort, and for large/multicast servers it may not be practical to > discover all paths > to all the clients. > > >If yes,and as a colleague of mine pointed out to me, what > >is the effect of smaller or bigger packets on the Internet backbone? > > > >Eg.With bigger MTU (thus bigger avarage size of packets on the Net) we > >should see some reduction on ACKs? On the other hand congestion will have > >different effect because bigger packets will be lost... > > > I do not believe you will see less ACKs. ACKs are a TCP mechanism > independent of whether you sent 1 large packet, 1 large packet > fragmented into > multiple small packets, or multiple small complete packets. > > > > > Also since re-transmission occurs at the TCP layer, I fail to see how > this > will have a significant effect when you have similar packet loss rate at > the IP layer > when related to the payload size of that frame.... > > > bearing in mind the go back n protocol of TCP retransmission, and to > transmit > a 1500 byte Ethernet MTU packet needs 3 of the current IPv6 576 MTU > packets. > > The means you would have to retransmit all 3 small packets if the first > one of a group > of 3 was dropped. > > You could argue that that is unlikely to happen to the first packet of a > sequence. > > However that must be offset against the fact that the surviving > fragments of a fragmented > frame or the small packets of a group of small frames must still get > sent all the way > to the receiving end node even though they will never be used by TCP. > > > > e.g. given random drop mechanism of an internet, and that the > probability > of one of a group of small frames being dropped is equal to that of a > single > large frame being dropped. > > Say there is an equal spread of which of 3 frames making up a 1500 byte > frame..... > P(1st dropped)=33% > P(2nd dropped)=33% > P(3rd dropped)=33% > > -> average result transmitted to the host when a frame is dropped > = 33%*1 retransmit + 2 good frames > 33% * 2 retransmit + 1 good frame + 1 bad frame > 33% * 3 retransmit + 0 good frame + 2 bad frames > = (3+4+5) *.3333 = an average of 6 small frames transmitted on an error > = same data as one big frame being retransmitted. > > > > = 6 frames transmitted on average given one is dropped > = 2 large frames transmitted on average given the first is dropped > > > > > Larger MTU's _would_ mean more frame re-transmissions given a certain > BER. > (Bit Error Rate) [whether this is due to restransmission on the link > with say LAPB > , or end to end via TCP retransmit] > > However, technology trends say that BER is effectively a thing of the > past due > to digital trunk circuits.... Instead of a Bit Error Rate, you get block > errors, > and complete failure, which are MTU indepedent. > > Hence the development of frame relay et al. > > > > Counterbalancing this, you have the argument that a given processor can > switch > a given number of packets [data is generally not copied within a router, > just pointers to buffers are exchanged]. This means that the prob of one > of a group > of three being dropped is proportionately higher than a single large > frame being dropped, > breaking the assumptions above, and making larger packets more > effective. > > > > On balance I feel larger packets mean more nett throughput > for a given size switching mechanism, and _less_ congestion in the > backbone. > > > > > > Also as of today, the effective packet size is limited by people sending > on to an Ethernet > at the end node, I fail to see how increasing MTU will negatively affect > router performance > when ipv6 enters an ipV4 network with limited MTU..... > > If you leave routers with the default behaviour, they'll use MTU of 1500 > bytes > (Cisco default) so nothing changes here. > > If for some obscure reason you have decided that your network will only > carry > 576 byte packets I again don't see how this affects the argument, > because > fragmentation will be occuring today when the packets leave the LAN.... > so you already have all the ineffieciency of fragmenting at the entry > point to the > IPV4 network. Unless of course you change the default of every single > end node too! > > > > >Has anyone studied this aspect of minimum MTU? If yes could you please > >point out or extrapolate? > > > >Thanks > > > >George > >----------------------------- > >Internet Transport Research | > >BTLABS | > >-------------------------------------------------------------------------- > >Notice: This contribution is the personal view of the author and does not > >necessarily reflect the technical nor commercial direction of British > >Telecommunications plc. > >-------------------------------------------------------------------------- > > > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > best regards, > > > George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 06:41:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA20434 for ipng-dist; Tue, 18 Nov 1997 06:39:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA20427 for ; Tue, 18 Nov 1997 06:38:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA10181 for ; Tue, 18 Nov 1997 06:38:56 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA20387 for ; Tue, 18 Nov 1997 06:38:51 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA06076; Tue, 18 Nov 1997 09:38:46 -0500 (EST) Message-Id: <199711181438.JAA06076@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4870) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-03.txt Date: Tue, 18 Nov 1997 09:38:45 -0500 Sender: owner-ipng@eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-03.txt Pages : 14 Date : 17-Nov-97 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-ipv6-over-ppp-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971117161903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-over-ppp-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971117161903.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 10:03:02 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA20741 for ipng-dist; Tue, 18 Nov 1997 09:59:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA20734 for ; Tue, 18 Nov 1997 09:59:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA08982 for ; Tue, 18 Nov 1997 09:59:31 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA03188 for ; Tue, 18 Nov 1997 09:58:25 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id LAA24598; Tue, 18 Nov 1997 11:55:25 -0600 Message-Id: <199711181755.LAA24598@gungnir.fnal.gov> To: George Tsirtsis Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4871) Re: message size In-reply-to: Your message of Tue, 18 Nov 1997 10:08:48 GMT. Date: Tue, 18 Nov 1997 11:55:25 -0600 Sender: owner-ipng@eng.sun.com Precedence: bulk > Am I correct to assume that most of the traffic on the Internet is that of > minimum MTU size packets? No. Remember the oft-forgotten fact that the MTU-floor for IPv4 is 68, count 'em, sixty-eight bytes. Looking at the data sample at http://www.nlanr.net/NA/Learn/packetsizes.html you can see that packets of exactly this size constitute a half-percent of all packets and a tenth-percent of all bytes. Looking instead at the 576 byte packets corresponding to the default TCP MSS, those are about 5% of all packets in the sample and 8% of the bytes. The 1500 byte packets, which for many users are both the PMTU size and the size corresponding to the peer's TCP MSS, account for 11.5% of the packets and almost 50% of the bytes. I include an augmented table derived from http://www.nlanr.net/NA/Learn/plen.970625.hist at the end of this message so anyone who wants to discuss packet sizes will have it available. The data comes from: when: 25 jun 97, around 16:00 EDT how long: 5 minute sample packet trace where: an oc3 link on MCI's backbone PLEASE delete the table from any included-text replies! > Eg.With bigger MTU (thus bigger avarage size of packets on the Net) we > should see some reduction on ACKs? On the other hand congestion will have > different effect because bigger packets will be lost... TCP in a low-loss steady state will have one ACK for two data packets. If you increase the size of the payloads by a factor X, you reduce the number of data packets by 1/X and the number of ACKs by 1/X. The total number of bytes carried by the network is reduced by a much smaller factor: about [1-0.1(1-1/X)] if you're considering increases from 576. To put it more clearly, as you consider increases in MTU from 576 bytes, you're going after a savings which asymptotically approaches 1.5 IP+TCP headers per TCP segment. This is a diminishing return. Matt size packets %pkts %bytes cum%pkts cum%bytes 23 2 0.000011 0.000001 0.000011 0.000001 25 4 0.000021 0.000001 0.000032 0.000002 26 1 0.000005 0.000000 0.000037 0.000003 28 931 0.004918 0.000389 0.004955 0.000391 29 7655 0.040440 0.003309 0.045396 0.003700 30 675 0.003566 0.000302 0.048962 0.004002 31 8 0.000042 0.000004 0.049004 0.004005 32 13291 0.070214 0.006339 0.119218 0.010344 33 7240 0.038248 0.003561 0.157466 0.013905 34 35612 0.188133 0.018046 0.345599 0.031951 35 2724 0.014391 0.001421 0.359990 0.033372 36 24073 0.127174 0.012916 0.487164 0.046289 37 1131 0.005975 0.000624 0.493139 0.046912 38 22402 0.118347 0.012688 0.611486 0.059600 39 27392 0.144708 0.015922 0.756194 0.075522 40 7364848 38.907460 4.390685 39.663654 4.466207 41 108025 0.570681 0.066011 40.234335 4.532218 42 36876 0.194811 0.023083 40.429146 4.555302 43 24516 0.129515 0.015712 40.558660 4.571014 44 1147082 6.059874 0.752239 46.618534 5.323252 45 19668 0.103903 0.013191 46.722437 5.336444 46 42982 0.227068 0.029468 46.949505 5.365912 47 31424 0.166009 0.022012 47.115514 5.387924 48 89372 0.472140 0.063937 47.587653 5.451861 49 26847 0.141829 0.019607 47.729482 5.471467 50 60478 0.319497 0.045069 48.048979 5.516536 51 37931 0.200384 0.028832 48.249363 5.545368 52 210671 1.112945 0.163274 49.362309 5.708642 53 32697 0.172734 0.025828 49.535042 5.734470 54 54863 0.289834 0.044155 49.824876 5.778625 55 30248 0.159796 0.024795 49.984672 5.803421 56 108240 0.571817 0.090341 50.556489 5.893761 57 41990 0.221827 0.035672 50.778316 5.929434 58 37222 0.196639 0.032176 50.974954 5.961610 59 26614 0.140598 0.023403 51.115552 5.985013 60 81809 0.432185 0.073158 51.547738 6.058171 61 125068 0.660717 0.113706 52.208455 6.171877 62 28168 0.148808 0.026029 52.357262 6.197906 63 88168 0.465779 0.082787 52.823041 6.280693 64 31503 0.166426 0.030050 52.989467 6.310742 65 26828 0.141729 0.025990 53.131196 6.336732 66 27088 0.143102 0.026646 53.274298 6.363378 67 18594 0.098229 0.018568 53.372528 6.381946 68 92613 0.489262 0.093862 53.861789 6.475808 69 21012 0.111003 0.021609 53.972793 6.497416 70 21323 0.112646 0.022246 54.085439 6.519663 71 29962 0.158285 0.031706 54.243724 6.551368 72 48728 0.257423 0.052290 54.501147 6.603658 73 33640 0.177715 0.036601 54.678863 6.640259 74 24422 0.129018 0.026935 54.807881 6.667194 75 17608 0.093021 0.019682 54.900901 6.686877 76 27575 0.145675 0.031235 55.046576 6.718111 77 19015 0.100454 0.021822 55.147030 6.739933 78 29208 0.154302 0.033955 55.301331 6.773889 79 13828 0.073051 0.016282 55.374383 6.790170 80 17479 0.092339 0.020841 55.466722 6.811011 81 10745 0.056764 0.012972 55.523486 6.823983 82 14710 0.077711 0.017978 55.601197 6.841960 83 11517 0.060843 0.014247 55.662040 6.856207 84 24518 0.129525 0.030695 55.791565 6.886903 85 11919 0.062966 0.015100 55.854531 6.902003 86 16343 0.086338 0.020948 55.940869 6.922950 87 10617 0.056088 0.013767 55.996957 6.936717 88 13554 0.071604 0.017777 56.068561 6.954494 89 10040 0.053040 0.013318 56.121601 6.967812 90 18277 0.096555 0.024516 56.218156 6.992328 91 11439 0.060431 0.015515 56.278587 7.007843 92 13012 0.068741 0.017842 56.347327 7.025685 93 10690 0.056474 0.014817 56.403801 7.040502 94 10700 0.056527 0.014991 56.460327 7.055493 95 10993 0.058074 0.015565 56.518402 7.071057 96 12658 0.066870 0.018111 56.585272 7.089169 97 9520 0.050293 0.013763 56.635565 7.102932 98 8841 0.046706 0.012913 56.682271 7.115845 99 8864 0.046827 0.013079 56.729098 7.128924 100 19233 0.101605 0.028665 56.830704 7.157589 101 19359 0.102271 0.029142 56.932974 7.186731 102 9629 0.050869 0.014638 56.983843 7.201369 103 8782 0.046394 0.013482 57.030237 7.214851 104 13834 0.073083 0.021443 57.103320 7.236294 105 9799 0.051767 0.015335 57.155087 7.251629 106 12278 0.064863 0.019397 57.219950 7.271026 107 10453 0.055222 0.016670 57.275172 7.287696 108 10675 0.056395 0.017183 57.331566 7.304879 109 7519 0.039722 0.012215 57.371288 7.317094 110 7761 0.041000 0.012724 57.412288 7.329818 111 8285 0.043768 0.013706 57.456057 7.343524 112 29836 0.157619 0.049804 57.613676 7.393329 113 6823 0.036045 0.011491 57.649721 7.404820 114 6959 0.036763 0.011824 57.686485 7.416644 115 7059 0.037292 0.012099 57.723776 7.428743 116 17070 0.090178 0.029512 57.813955 7.458255 117 6377 0.033689 0.011120 57.847643 7.469375 118 7955 0.042025 0.013990 57.889669 7.483365 119 7445 0.039331 0.013204 57.929000 7.496570 120 9544 0.050420 0.017069 57.979419 7.513639 121 7560 0.039938 0.013634 58.019358 7.527273 122 6135 0.032410 0.011155 58.051768 7.538428 123 6213 0.032822 0.011390 58.084590 7.549818 124 7447 0.039341 0.013763 58.123932 7.563581 125 7015 0.037059 0.013069 58.160991 7.576650 126 6517 0.034428 0.012238 58.195419 7.588889 127 6945 0.036689 0.013146 58.232109 7.602034 128 15293 0.080791 0.029175 58.312900 7.631209 129 6493 0.034302 0.012484 58.347201 7.643693 130 5581 0.029484 0.010813 58.376685 7.654506 131 6485 0.034259 0.012662 58.410944 7.667168 132 5799 0.030635 0.011409 58.441580 7.678577 133 5090 0.026890 0.010090 58.468469 7.688667 134 5247 0.027719 0.010479 58.496188 7.699146 135 5172 0.027323 0.010406 58.523511 7.709552 136 8400 0.044376 0.017027 58.567887 7.726579 137 11848 0.062591 0.024192 58.630479 7.750771 138 8405 0.044402 0.017287 58.674881 7.768058 139 6065 0.032041 0.012565 58.706922 7.780623 140 27232 0.143863 0.056822 58.850785 7.837445 141 8233 0.043494 0.017302 58.894278 7.854746 142 7686 0.040604 0.016267 58.934882 7.871013 143 9068 0.047905 0.019327 58.982787 7.890339 144 39734 0.209909 0.085277 59.192697 7.975617 145 4343 0.022943 0.009386 59.215640 7.985002 146 6230 0.032912 0.013557 59.248552 7.998559 147 5155 0.027233 0.011294 59.275785 8.009853 148 9286 0.049057 0.020483 59.324842 8.030336 149 13015 0.068756 0.028903 59.393598 8.059239 150 6837 0.036119 0.015285 59.429717 8.074524 151 5837 0.030836 0.013136 59.460553 8.087661 152 11734 0.061989 0.026583 59.522543 8.114243 153 4807 0.025395 0.010962 59.547937 8.125205 154 6328 0.033430 0.014524 59.581367 8.139729 155 10063 0.053161 0.023247 59.634529 8.162976 156 6162 0.032553 0.014327 59.667082 8.177303 157 7301 0.038570 0.017084 59.705652 8.194387 158 6123 0.032347 0.014419 59.737999 8.208806 159 4593 0.024264 0.010884 59.762263 8.219690 160 5473 0.028913 0.013051 59.791176 8.232742 161 6152 0.032500 0.014762 59.823676 8.247504 162 10912 0.057647 0.026347 59.881323 8.273851 163 8258 0.043626 0.020062 59.924949 8.293912 164 4399 0.023239 0.010752 59.948188 8.304665 165 17897 0.094547 0.044012 60.042735 8.348677 166 9123 0.048196 0.022571 60.090931 8.371248 167 3616 0.019103 0.009000 60.110034 8.380248 168 5932 0.031338 0.014853 60.141371 8.395102 169 4382 0.023149 0.011037 60.164521 8.406139 170 4514 0.023847 0.011437 60.188368 8.417576 171 3584 0.018934 0.009134 60.207302 8.426710 172 4435 0.023429 0.011369 60.230731 8.438080 173 4500 0.023773 0.011603 60.254504 8.449683 174 4372 0.023097 0.011338 60.277601 8.461021 175 6089 0.032167 0.015882 60.309768 8.476902 176 7982 0.042168 0.020938 60.351936 8.497840 177 7393 0.039056 0.019503 60.390992 8.517343 178 3992 0.021089 0.010591 60.412081 8.527934 179 4130 0.021818 0.011018 60.433899 8.538952 180 5004 0.026435 0.013425 60.460335 8.552376 181 3274 0.017296 0.008832 60.477631 8.561209 182 3030 0.016007 0.008219 60.493638 8.569428 183 3212 0.016969 0.008761 60.510606 8.578188 184 13827 0.073046 0.037919 60.583652 8.616107 185 3210 0.016958 0.008851 60.600610 8.624958 186 3330 0.017592 0.009231 60.618202 8.634189 187 2701 0.014269 0.007528 60.632471 8.641717 188 2847 0.015040 0.007977 60.647512 8.649694 189 2866 0.015141 0.008073 60.662652 8.657768 190 2956 0.015616 0.008371 60.678268 8.666138 191 3515 0.018569 0.010006 60.696838 8.676145 192 15782 0.083374 0.045162 60.780212 8.721306 193 3101 0.016382 0.008920 60.796594 8.730227 194 3627 0.019161 0.010487 60.815755 8.740714 195 2879 0.015209 0.008367 60.830964 8.749081 196 3779 0.019964 0.011039 60.850928 8.760120 197 3455 0.018252 0.010144 60.869180 8.770265 198 2544 0.013440 0.007507 60.882620 8.777772 199 2966 0.015669 0.008797 60.898289 8.786569 200 4513 0.023842 0.013453 60.922131 8.800022 201 2751 0.014533 0.008241 60.936664 8.808263 202 3113 0.016446 0.009372 60.953109 8.817635 203 3049 0.016107 0.009225 60.969217 8.826860 204 3605 0.019045 0.010961 60.988261 8.837821 205 3789 0.020017 0.011577 61.008278 8.849397 206 7022 0.037096 0.021559 61.045374 8.870957 207 5574 0.029447 0.017197 61.074821 8.888154 208 23024 0.121633 0.071376 61.196454 8.959530 209 2581 0.013635 0.008040 61.210089 8.967569 210 4681 0.024729 0.014651 61.234818 8.982220 211 3607 0.019055 0.011343 61.253873 8.993564 212 6563 0.034671 0.020737 61.288544 9.014301 213 5239 0.027677 0.016632 61.316221 9.030932 214 5640 0.029795 0.017989 61.346017 9.048921 215 4377 0.023123 0.014026 61.369140 9.062947 216 6081 0.032125 0.019577 61.401265 9.082523 217 3885 0.020524 0.012565 61.421789 9.095088 218 3427 0.018104 0.011135 61.439893 9.106223 219 3391 0.017914 0.011068 61.457807 9.117291 220 3141 0.016593 0.010299 61.474401 9.127590 221 3094 0.016345 0.010191 61.490746 9.137782 222 3644 0.019251 0.012057 61.509997 9.149839 223 5020 0.026520 0.016685 61.536517 9.166523 224 6750 0.035659 0.022535 61.572176 9.189058 225 8699 0.045956 0.029172 61.618132 9.218230 226 7887 0.041666 0.026566 61.659797 9.244796 227 7975 0.042131 0.026981 61.701928 9.271778 228 7719 0.040778 0.026230 61.742707 9.298008 229 6626 0.035004 0.022615 61.777711 9.320623 230 4659 0.024613 0.015971 61.802324 9.336594 231 5397 0.028512 0.018581 61.830835 9.355175 232 10515 0.055549 0.036358 61.886385 9.391533 233 6083 0.032136 0.021124 61.918520 9.412658 234 5452 0.028802 0.019014 61.947322 9.431672 235 3643 0.019245 0.012760 61.966568 9.444432 236 3906 0.020635 0.013739 61.987203 9.458170 237 3083 0.016287 0.010890 62.003490 9.469061 238 4443 0.023472 0.015760 62.026961 9.484821 239 3417 0.018052 0.012172 62.045013 9.496992 240 11865 0.062681 0.042441 62.107694 9.539434 241 2445 0.012917 0.008782 62.120611 9.548216 242 11655 0.061572 0.042037 62.182182 9.590253 243 2833 0.014966 0.010260 62.197149 9.600514 244 5136 0.027133 0.018678 62.224282 9.619191 245 9114 0.048148 0.033280 62.272430 9.652471 246 5220 0.027577 0.019139 62.300006 9.671610 247 4138 0.021860 0.015233 62.321867 9.686843 248 3835 0.020260 0.014175 62.342126 9.701019 249 2966 0.015669 0.011007 62.357795 9.712026 250 2769 0.014628 0.010317 62.372424 9.722343 251 2453 0.012959 0.009177 62.385382 9.731520 252 19136 0.101093 0.071872 62.486475 9.803392 253 3023 0.015970 0.011399 62.502445 9.814791 254 4255 0.022479 0.016108 62.524924 9.830899 255 3351 0.017703 0.012736 62.542627 9.843635 256 11665 0.061625 0.044508 62.604251 9.888142 257 3257 0.017206 0.012476 62.621458 9.900618 258 2951 0.015590 0.011347 62.637047 9.911965 259 3272 0.017286 0.012631 62.654333 9.924596 260 4375 0.023113 0.016954 62.677445 9.941549 261 6750 0.035659 0.026257 62.713105 9.967807 262 9187 0.048534 0.035874 62.761638 10.003681 263 6534 0.034518 0.025612 62.796156 10.029293 264 5974 0.031560 0.023506 62.827716 10.052799 265 9007 0.047583 0.035574 62.875299 10.088373 266 18006 0.095123 0.071385 62.970422 10.159758 267 35863 0.189459 0.142714 63.159881 10.302472 268 21337 0.112720 0.085227 63.272602 10.387699 269 13893 0.073395 0.055700 63.345997 10.443399 270 9919 0.052401 0.039915 63.398397 10.483315 271 11704 0.061831 0.047273 63.460228 10.530587 272 9707 0.051281 0.039352 63.511509 10.569939 273 3964 0.020941 0.016129 63.532450 10.586068 274 5012 0.026478 0.020468 63.558927 10.606536 275 4990 0.026361 0.020452 63.585289 10.626988 276 6527 0.034481 0.026849 63.619770 10.653837 277 5550 0.029320 0.022913 63.649090 10.676750 278 5387 0.028459 0.022320 63.677549 10.699070 279 26370 0.139309 0.109654 63.816858 10.808724 280 8994 0.047514 0.037534 63.864372 10.846258 281 5169 0.027307 0.021648 63.891679 10.867906 282 9107 0.048111 0.038277 63.939790 10.906182 283 7443 0.039320 0.031394 63.979110 10.937576 284 6677 0.035274 0.028262 64.014384 10.965838 285 4380 0.023139 0.018605 64.037523 10.984443 286 4294 0.022685 0.018304 64.060207 11.002747 287 4452 0.023519 0.019043 64.083727 11.021790 288 4695 0.024803 0.020153 64.108530 11.041943 289 4443 0.023472 0.019137 64.132002 11.061081 290 4959 0.026198 0.021434 64.158199 11.082515 291 4391 0.023197 0.019044 64.181396 11.101559 292 5034 0.026594 0.021908 64.207990 11.123467 293 4112 0.021723 0.017957 64.229713 11.141424 294 6410 0.033863 0.028088 64.263576 11.169511 295 7968 0.042094 0.035033 64.305670 11.204544 296 63649 0.336249 0.280797 64.641919 11.485341 297 4609 0.024349 0.020402 64.666268 11.505743 298 4591 0.024254 0.020391 64.690521 11.526134 299 3759 0.019858 0.016751 64.710380 11.542885 300 3939 0.020809 0.017612 64.731189 11.560497 301 3342 0.017655 0.014993 64.748844 11.575490 302 3548 0.018744 0.015970 64.767588 11.591460 303 3565 0.018833 0.016099 64.786421 11.607559 304 3832 0.020244 0.017362 64.806665 11.624922 305 3636 0.019208 0.016528 64.825874 11.641450 306 3562 0.018818 0.016245 64.844691 11.657695 307 5706 0.030144 0.026108 64.874835 11.683804 308 6624 0.034994 0.030407 64.909829 11.714211 309 3179 0.016794 0.014641 64.926623 11.728852 310 4104 0.021681 0.018962 64.948304 11.747813 311 3154 0.016662 0.014619 64.964966 11.762433 312 3375 0.017830 0.015694 64.982796 11.778127 313 3472 0.018342 0.016197 65.001138 11.794324 314 3232 0.017074 0.015125 65.018212 11.809449 315 3838 0.020276 0.018019 65.038487 11.827468 316 3538 0.018691 0.016663 65.057178 11.844131 317 70259 0.371168 0.331948 65.428347 12.176079 318 6201 0.032759 0.029390 65.461106 12.205469 319 3617 0.019108 0.017197 65.480214 12.222665 320 4110 0.021713 0.019602 65.501926 12.242267 321 3905 0.020630 0.018682 65.522556 12.260950 322 3346 0.017676 0.016058 65.540232 12.277008 323 3345 0.017671 0.016103 65.557904 12.293111 324 6768 0.035754 0.032682 65.593658 12.325793 325 3752 0.019821 0.018174 65.613479 12.343968 326 3595 0.018992 0.017467 65.632471 12.361435 327 3478 0.018374 0.016951 65.650845 12.378385 328 4444 0.023477 0.021725 65.674322 12.400110 329 3585 0.018939 0.017579 65.693261 12.417689 330 3501 0.018495 0.017219 65.711756 12.434909 331 3597 0.019002 0.017745 65.730759 12.452654 332 3607 0.019055 0.017848 65.749814 12.470502 333 3312 0.017497 0.016438 65.767311 12.486939 334 3427 0.018104 0.017060 65.785415 12.503999 335 3212 0.016969 0.016037 65.802384 12.520036 336 4163 0.021993 0.020848 65.824376 12.540884 337 3432 0.018131 0.017238 65.842507 12.558122 338 3258 0.017212 0.016413 65.859719 12.574534 339 2894 0.015289 0.014622 65.875007 12.589156 340 3617 0.019108 0.018329 65.894115 12.607485 341 3150 0.016641 0.016009 65.910756 12.623495 342 3304 0.017455 0.016841 65.928211 12.640336 343 3306 0.017465 0.016901 65.945676 12.657237 344 6814 0.035997 0.034936 65.981673 12.692172 345 3265 0.017249 0.016788 65.998922 12.708961 346 3397 0.017946 0.017518 66.016868 12.726478 347 3166 0.016726 0.016374 66.033593 12.742852 348 3287 0.017365 0.017049 66.050958 12.759901 349 3336 0.017624 0.017352 66.068582 12.777253 350 3100 0.016377 0.016171 66.084959 12.793424 351 3021 0.015960 0.015804 66.100918 12.809228 352 3040 0.016060 0.015949 66.116978 12.825177 353 3116 0.016461 0.016394 66.133439 12.841571 354 3149 0.016636 0.016614 66.150075 12.858185 355 2905 0.015347 0.015370 66.165422 12.873556 356 2833 0.014966 0.015032 66.180388 12.888587 357 3133 0.016551 0.016670 66.196939 12.905257 358 2948 0.015574 0.015730 66.212513 12.920987 359 2909 0.015368 0.015565 66.227881 12.936552 360 4259 0.022500 0.022852 66.250381 12.959403 361 3352 0.017708 0.018035 66.268089 12.977439 362 3140 0.016588 0.016941 66.284677 12.994380 363 4145 0.021897 0.022425 66.306575 13.016805 364 18944 0.100078 0.102774 66.406653 13.119579 365 3712 0.019610 0.020193 66.426263 13.139772 366 4639 0.024507 0.025305 66.450770 13.165078 367 2964 0.015658 0.016213 66.466429 13.181290 368 4526 0.023910 0.024824 66.490339 13.206114 369 2937 0.015516 0.016152 66.505855 13.222267 370 3091 0.016329 0.017045 66.522184 13.239312 371 2856 0.015088 0.015792 66.537272 13.255104 372 2828 0.014940 0.015679 66.552212 13.270784 373 3712 0.019610 0.020636 66.571822 13.291420 374 2894 0.015289 0.016132 66.587110 13.307551 375 3141 0.016593 0.017555 66.603704 13.325107 376 3680 0.019441 0.020623 66.623145 13.345729 377 3270 0.017275 0.018374 66.640420 13.364103 378 6207 0.032791 0.034969 66.673210 13.399072 379 2797 0.014776 0.015799 66.687987 13.414871 380 3524 0.018617 0.019959 66.706603 13.434830 381 3481 0.018390 0.019767 66.724993 13.454597 382 3018 0.015944 0.017183 66.740937 13.471779 383 3160 0.016694 0.018038 66.757630 13.489818 384 13561 0.071641 0.077612 66.829271 13.567430 385 3070 0.016218 0.017616 66.845490 13.585046 386 3383 0.017872 0.019462 66.863362 13.604509 387 7143 0.037735 0.041200 66.901097 13.645709 388 3962 0.020931 0.022912 66.922028 13.668620 389 3457 0.018263 0.020043 66.940291 13.688663 390 3814 0.020149 0.022169 66.960439 13.710833 391 3342 0.017655 0.019476 66.978095 13.730308 392 3714 0.019621 0.021699 66.997715 13.752007 393 3679 0.019436 0.021549 67.017151 13.773556 394 3566 0.018839 0.020940 67.035990 13.794497 395 3829 0.020228 0.022542 67.056218 13.817039 396 4170 0.022030 0.024612 67.078247 13.841650 397 3861 0.020397 0.022845 67.098644 13.864496 398 4075 0.021528 0.024172 67.120172 13.888668 399 4008 0.021174 0.023835 67.141346 13.912503 400 4481 0.023672 0.026714 67.165018 13.939217 401 3779 0.019964 0.022586 67.184982 13.961803 402 4059 0.021443 0.024319 67.206425 13.986122 403 3909 0.020651 0.023479 67.227076 14.009601 404 4230 0.022346 0.025470 67.249422 14.035071 405 3966 0.020952 0.023940 67.270374 14.059011 406 4354 0.023002 0.026347 67.293376 14.085357 407 3733 0.019721 0.022644 67.313097 14.108001 408 3836 0.020265 0.023326 67.333362 14.131328 409 3557 0.018791 0.021683 67.352153 14.153011 410 4028 0.021279 0.024614 67.373432 14.177625 411 3788 0.020011 0.023204 67.393444 14.200829 412 5079 0.026832 0.031188 67.420275 14.232016 413 3559 0.018802 0.021907 67.439077 14.253923 414 3642 0.019240 0.022472 67.458317 14.276396 415 3811 0.020133 0.023572 67.478450 14.299968 416 3798 0.020064 0.023548 67.498515 14.323516 417 3656 0.019314 0.022722 67.517829 14.346238 418 3817 0.020165 0.023780 67.537993 14.370018 419 3480 0.018384 0.021732 67.556378 14.391750 420 3247 0.017153 0.020325 67.573531 14.412075 421 3437 0.018157 0.021566 67.591688 14.433641 422 3548 0.018744 0.022315 67.610432 14.455957 423 3411 0.018020 0.021505 67.628452 14.477461 424 9100 0.048074 0.057506 67.676526 14.534968 425 3324 0.017560 0.021055 67.694086 14.556023 426 3035 0.016033 0.019270 67.710120 14.575293 427 2732 0.014433 0.017387 67.724552 14.592679 428 3276 0.017307 0.020898 67.741859 14.613577 429 2967 0.015674 0.018971 67.757533 14.632548 430 2960 0.015637 0.018970 67.773170 14.651518 431 2563 0.013540 0.016464 67.786710 14.667982 432 3202 0.016916 0.020616 67.803626 14.688598 433 2612 0.013799 0.016857 67.817425 14.705455 434 2881 0.015220 0.018636 67.832645 14.724090 435 2992 0.015806 0.019398 67.848451 14.743488 436 3302 0.017444 0.021457 67.865895 14.764946 437 2649 0.013994 0.017253 67.879890 14.782199 438 2673 0.014121 0.017449 67.894011 14.799648 439 2633 0.013910 0.017228 67.907920 14.816876 440 2979 0.015738 0.019536 67.923658 14.836412 441 2927 0.015463 0.019238 67.939121 14.855650 442 4613 0.024370 0.030389 67.963491 14.886039 443 2322 0.012267 0.015331 67.975758 14.901370 444 2761 0.014586 0.018271 67.990344 14.919641 445 2356 0.012446 0.015626 68.002790 14.935267 446 2663 0.014068 0.017702 68.016858 14.952968 447 2216 0.011707 0.014763 68.028565 14.967732 448 2844 0.015024 0.018990 68.043590 14.986721 449 2361 0.012473 0.015800 68.056062 15.002521 450 3346 0.017676 0.022441 68.073739 15.024962 451 2286 0.012077 0.015366 68.085815 15.040329 452 2558 0.013514 0.017232 68.099329 15.057561 453 2399 0.012674 0.016197 68.112003 15.073758 454 2404 0.012700 0.016267 68.124703 15.090025 455 2381 0.012578 0.016147 68.137281 15.106171 456 2777 0.014671 0.018873 68.151952 15.125045 457 2358 0.012457 0.016061 68.164409 15.141105 458 2593 0.013698 0.017700 68.178107 15.158806 459 2671 0.014111 0.018272 68.192217 15.177078 460 2714 0.014338 0.018607 68.206555 15.195685 461 2343 0.012378 0.016098 68.218933 15.211783 462 2282 0.012055 0.015713 68.230988 15.227497 463 2191 0.011575 0.015119 68.242563 15.242616 464 4050 0.021396 0.028008 68.263959 15.270624 465 2336 0.012341 0.016190 68.276299 15.286813 466 2069 0.010930 0.014370 68.287230 15.301183 467 2179 0.011511 0.015166 68.298741 15.316350 468 2999 0.015843 0.020919 68.314584 15.337268 469 2116 0.011179 0.014791 68.325763 15.352059 470 2155 0.011385 0.015096 68.337147 15.367155 471 2036 0.010756 0.014292 68.347903 15.381447 472 2283 0.012061 0.016060 68.359964 15.397508 473 2328 0.012298 0.016412 68.372263 15.413920 474 2209 0.011670 0.015606 68.383932 15.429525 475 1998 0.010555 0.014145 68.394488 15.443670 476 2416 0.012763 0.017140 68.407251 15.460810 477 2215 0.011702 0.015747 68.418953 15.476557 478 4541 0.023989 0.032351 68.442942 15.508908 479 2483 0.013117 0.017726 68.456059 15.526635 480 3987 0.021063 0.028523 68.477122 15.555158 481 2167 0.011448 0.015535 68.488570 15.570693 482 2174 0.011485 0.015618 68.500055 15.586310 483 1997 0.010550 0.014376 68.510605 15.600686 484 2260 0.011939 0.016303 68.522544 15.616989 485 1868 0.009868 0.013503 68.532413 15.630492 486 1939 0.010243 0.014045 68.542656 15.644537 487 1857 0.009810 0.013479 68.552466 15.658016 488 13666 0.072196 0.099396 68.624662 15.757412 489 7861 0.041529 0.057292 68.666190 15.814704 490 2026 0.010703 0.014796 68.676893 15.829500 491 1953 0.010317 0.014292 68.687211 15.843792 492 2019 0.010666 0.014805 68.697877 15.858597 493 1580 0.008347 0.011609 68.706224 15.870207 494 1864 0.009847 0.013724 68.716071 15.883931 495 1676 0.008854 0.012365 68.724925 15.896295 496 2104 0.011115 0.015554 68.736040 15.911849 497 1573 0.008310 0.011652 68.744350 15.923501 498 1631 0.008616 0.012106 68.752967 15.935607 499 1707 0.009018 0.012695 68.761984 15.948302 500 3763 0.019879 0.028042 68.781864 15.976344 501 1547 0.008173 0.011551 68.790036 15.987896 502 1690 0.008928 0.012644 68.798965 16.000540 503 1577 0.008331 0.011822 68.807296 16.012363 504 2151 0.011363 0.016158 68.818659 16.028520 505 1638 0.008653 0.012329 68.827312 16.040849 506 1686 0.008907 0.012715 68.836219 16.053564 507 1453 0.007676 0.010979 68.843895 16.064543 508 3275 0.017301 0.024796 68.861197 16.089340 509 1484 0.007840 0.011258 68.869036 16.100597 510 1580 0.008347 0.012010 68.877383 16.112607 511 1622 0.008569 0.012353 68.885952 16.124961 512 36562 0.193152 0.279003 69.079104 16.403963 513 1834 0.009689 0.014022 69.088793 16.417986 514 1592 0.008410 0.012196 69.097203 16.430182 515 1473 0.007782 0.011306 69.104985 16.441488 516 1641 0.008669 0.012620 69.113654 16.454108 517 1542 0.008146 0.011882 69.121800 16.465990 518 1480 0.007819 0.011426 69.129619 16.477416 519 17412 0.091985 0.134687 69.221604 16.612103 520 1750 0.009245 0.013563 69.230849 16.625666 521 1313 0.006936 0.010196 69.237785 16.635861 522 1530 0.008083 0.011903 69.245868 16.647765 523 3160 0.016694 0.024632 69.262562 16.672396 524 2269 0.011987 0.017720 69.274549 16.690117 525 1590 0.008400 0.012441 69.282948 16.702558 526 2994 0.015817 0.023472 69.298765 16.726030 527 1808 0.009551 0.014201 69.308317 16.740231 528 3015 0.015928 0.023726 69.324245 16.763957 529 1525 0.008056 0.012024 69.332301 16.775981 530 1400 0.007396 0.011059 69.339697 16.787040 531 1573 0.008310 0.012449 69.348007 16.799489 532 2236 0.011812 0.017729 69.359819 16.817218 533 1566 0.008273 0.012440 69.368092 16.829658 534 1665 0.008796 0.013251 69.376888 16.842910 535 2069 0.010930 0.016498 69.387818 16.859407 536 1640 0.008664 0.013101 69.396482 16.872509 537 1239 0.006545 0.009916 69.403028 16.882425 538 1988 0.010502 0.015941 69.413530 16.898366 539 1195 0.006313 0.009600 69.419843 16.907966 540 9623 0.050837 0.077448 69.470680 16.985414 541 1321 0.006979 0.010651 69.477659 16.996065 542 1255 0.006630 0.010138 69.484289 17.006203 543 1387 0.007327 0.011225 69.491616 17.017428 544 12099 0.063917 0.098097 69.555533 17.115526 545 1210 0.006392 0.009829 69.561926 17.125354 546 1268 0.006699 0.010319 69.568624 17.135673 547 1277 0.006746 0.010411 69.575371 17.146084 548 1177 0.006218 0.009613 69.581589 17.155697 549 1189 0.006281 0.009729 69.587870 17.165426 550 1259 0.006651 0.010320 69.594521 17.175746 551 2079 0.010983 0.017073 69.605504 17.192819 552 1915878 10.121315 15.762151 79.726819 32.954970 553 861 0.004549 0.007096 79.731368 32.962066 554 1205 0.006366 0.009950 79.737733 32.972016 555 858 0.004533 0.007097 79.742266 32.979113 556 1209 0.006387 0.010019 79.748653 32.989132 557 4801 0.025363 0.039856 79.774016 33.028988 558 1014 0.005357 0.008433 79.779373 33.037421 559 1021 0.005394 0.008506 79.784767 33.045927 560 991 0.005235 0.008271 79.790002 33.054199 561 793 0.004189 0.006630 79.794191 33.060829 562 1050 0.005547 0.008795 79.799738 33.069624 563 782 0.004131 0.006562 79.803870 33.076186 564 37787 0.199623 0.317636 80.003493 33.393822 565 759 0.004010 0.006391 80.007503 33.400214 566 801 0.004232 0.006757 80.011734 33.406971 567 1348 0.007121 0.011392 80.018856 33.418362 568 2606 0.013767 0.022061 80.032623 33.440424 569 902 0.004765 0.007649 80.037388 33.448073 570 684 0.003613 0.005811 80.041001 33.453884 571 804 0.004247 0.006842 80.045249 33.460726 572 1824 0.009636 0.015550 80.054885 33.476276 573 758 0.004004 0.006473 80.058889 33.482749 574 779 0.004115 0.006664 80.063004 33.489414 575 799 0.004221 0.006847 80.067225 33.496261 576 925516 4.889371 7.945385 84.956597 41.441646 577 474 0.002504 0.004076 84.959101 41.445723 578 623 0.003291 0.005367 84.962392 41.451090 579 576 0.003043 0.004971 84.965435 41.456060 580 690 0.003645 0.005965 84.969080 41.462025 581 485 0.002562 0.004200 84.971642 41.466225 582 492 0.002599 0.004268 84.974242 41.470492 583 610 0.003223 0.005300 84.977464 41.475793 584 697 0.003682 0.006067 84.981146 41.481860 585 732 0.003867 0.006382 84.985013 41.488242 586 3872 0.020455 0.033818 85.005469 41.522059 587 569 0.003006 0.004978 85.008474 41.527037 588 1265 0.006683 0.011086 85.015157 41.538123 589 580 0.003064 0.005092 85.018221 41.543215 590 463 0.002446 0.004071 85.020667 41.547286 591 539 0.002847 0.004748 85.023515 41.552034 592 554 0.002927 0.004888 85.026442 41.556922 593 502 0.002652 0.004437 85.029094 41.561359 594 519 0.002742 0.004595 85.031835 41.565954 595 645 0.003407 0.005720 85.035243 41.571674 596 647 0.003418 0.005747 85.038661 41.577421 597 492 0.002599 0.004378 85.041260 41.581798 598 446 0.002356 0.003975 85.043616 41.585774 599 524 0.002768 0.004678 85.046384 41.590452 600 547 0.002890 0.004892 85.049274 41.595343 601 653 0.003450 0.005849 85.052724 41.601192 602 687 0.003629 0.006164 85.056353 41.607356 603 417 0.002203 0.003748 85.058556 41.611104 604 503 0.002657 0.004528 85.061213 41.615632 605 419 0.002214 0.003778 85.063427 41.619410 606 531 0.002805 0.004796 85.066232 41.624206 607 492 0.002599 0.004451 85.068831 41.628657 608 9497 0.050171 0.086059 85.119002 41.714717 609 1526 0.008062 0.013851 85.127064 41.728568 610 442 0.002335 0.004018 85.129399 41.732586 611 508 0.002684 0.004626 85.132083 41.737212 612 833 0.004401 0.007598 85.136483 41.744810 613 367 0.001939 0.003353 85.138422 41.748163 614 514 0.002715 0.004704 85.141138 41.752867 615 439 0.002319 0.004024 85.143457 41.756891 616 1397 0.007380 0.012826 85.150837 41.769717 617 486 0.002567 0.004469 85.153404 41.774186 618 485 0.002562 0.004467 85.155967 41.778653 619 407 0.002150 0.003755 85.158117 41.782408 620 8359 0.044159 0.077242 85.202276 41.859650 621 390 0.002060 0.003610 85.204337 41.863260 622 419 0.002214 0.003884 85.206550 41.867144 623 567 0.002995 0.005265 85.209545 41.872409 624 959 0.005066 0.008919 85.214612 41.881328 625 353 0.001865 0.003288 85.216477 41.884616 626 417 0.002203 0.003891 85.218679 41.888507 627 5068 0.026774 0.047360 85.245453 41.935867 628 41394 0.218679 0.387441 85.464132 42.323308 629 485 0.002562 0.004547 85.466694 42.327855 630 462 0.002441 0.004338 85.469135 42.332193 631 2036 0.010756 0.019148 85.479891 42.351340 632 563 0.002974 0.005303 85.482865 42.356643 633 437 0.002309 0.004123 85.485173 42.360766 634 501 0.002647 0.004734 85.487820 42.365500 635 444 0.002346 0.004202 85.490166 42.369702 636 780 0.004121 0.007394 85.494286 42.377096 637 403 0.002129 0.003826 85.496415 42.380922 638 411 0.002171 0.003908 85.498587 42.384830 639 459 0.002425 0.004371 85.501011 42.389202 640 456 0.002409 0.004350 85.503420 42.393551 641 353 0.001865 0.003372 85.505285 42.396924 642 458 0.002420 0.004382 85.507705 42.401306 643 500 0.002641 0.004792 85.510346 42.406098 644 522 0.002758 0.005010 85.513104 42.411108 645 411 0.002171 0.003951 85.515275 42.415059 646 379 0.002002 0.003649 85.517277 42.418708 647 489 0.002583 0.004715 85.519861 42.423424 648 1816 0.009594 0.017539 85.529454 42.440962 649 400 0.002113 0.003869 85.531567 42.444832 650 437 0.002309 0.004234 85.533876 42.449065 651 424 0.002240 0.004114 85.536116 42.453179 652 496 0.002620 0.004820 85.538736 42.457999 653 432 0.002282 0.004204 85.541018 42.462203 654 1108 0.005853 0.010800 85.546872 42.473003 655 428 0.002261 0.004178 85.549133 42.477182 656 367 0.001939 0.003588 85.551072 42.480770 657 367 0.001939 0.003594 85.553011 42.484364 658 361 0.001907 0.003540 85.554918 42.487904 659 401 0.002118 0.003939 85.557036 42.491842 660 595 0.003143 0.005853 85.560179 42.497695 661 378 0.001997 0.003724 85.562176 42.501419 662 347 0.001833 0.003424 85.564009 42.504843 663 331 0.001749 0.003271 85.565758 42.508114 664 432 0.002282 0.004275 85.568040 42.512389 665 383 0.002023 0.003796 85.570064 42.516185 666 407 0.002150 0.004040 85.572214 42.520225 667 399 0.002108 0.003966 85.574322 42.524191 668 364 0.001923 0.003624 85.576245 42.527815 669 329 0.001738 0.003280 85.577983 42.531096 670 446 0.002356 0.004454 85.580339 42.535550 671 346 0.001828 0.003460 85.582167 42.539010 672 326 0.001722 0.003265 85.583889 42.542275 673 309 0.001632 0.003099 85.585521 42.545374 674 341 0.001801 0.003425 85.587323 42.548800 675 380 0.002007 0.003823 85.589330 42.552623 676 444 0.002346 0.004473 85.591676 42.557096 677 328 0.001733 0.003310 85.593409 42.560406 678 431 0.002277 0.004355 85.595686 42.564761 679 355 0.001875 0.003593 85.597561 42.568354 680 440 0.002324 0.004459 85.599885 42.572813 681 361 0.001907 0.003664 85.601792 42.576477 682 365 0.001928 0.003710 85.603721 42.580187 683 363 0.001918 0.003695 85.605638 42.583882 684 372 0.001965 0.003792 85.607604 42.587675 685 404 0.002134 0.004125 85.609738 42.591799 686 373 0.001971 0.003814 85.611708 42.595613 687 382 0.002018 0.003911 85.613726 42.599524 688 2806 0.014824 0.028773 85.628550 42.628297 689 426 0.002250 0.004375 85.630801 42.632672 690 380 0.002007 0.003908 85.632808 42.636580 691 379 0.002002 0.003903 85.634810 42.640483 692 944 0.004987 0.009736 85.639797 42.650219 693 436 0.002303 0.004503 85.642101 42.654722 694 294 0.001553 0.003041 85.643654 42.657763 695 335 0.001770 0.003470 85.645424 42.661233 696 306 0.001617 0.003174 85.647040 42.664408 697 325 0.001717 0.003376 85.648757 42.667784 698 273 0.001442 0.002840 85.650199 42.670624 699 339 0.001791 0.003532 85.651990 42.674156 700 6614 0.034941 0.069003 85.686931 42.743159 701 370 0.001955 0.003866 85.688886 42.747025 702 332 0.001754 0.003474 85.690640 42.750498 703 369 0.001949 0.003866 85.692589 42.754365 704 375 0.001981 0.003935 85.694570 42.758299 705 311 0.001643 0.003268 85.696213 42.761567 706 688 0.003635 0.007239 85.699848 42.768806 707 251 0.001326 0.002645 85.701174 42.771451 708 535 0.002826 0.005645 85.704000 42.777097 709 385 0.002034 0.004068 85.706034 42.781165 710 336 0.001775 0.003556 85.707809 42.784721 711 488 0.002578 0.005171 85.710387 42.789892 712 333 0.001759 0.003534 85.712146 42.793426 713 340 0.001796 0.003613 85.713942 42.797039 714 301 0.001590 0.003203 85.715532 42.800242 715 308 0.001627 0.003282 85.717160 42.803524 716 343 0.001812 0.003660 85.718972 42.807184 717 309 0.001632 0.003302 85.720604 42.810486 718 293 0.001548 0.003135 85.722152 42.813622 719 265 0.001400 0.002840 85.723552 42.816462 720 335 0.001770 0.003595 85.725322 42.820056 721 295 0.001558 0.003170 85.726880 42.823227 722 443 0.002340 0.004767 85.729220 42.827994 723 358 0.001891 0.003858 85.731112 42.831851 724 297 0.001569 0.003205 85.732681 42.835056 725 225 0.001189 0.002431 85.733869 42.837487 726 275 0.001453 0.002976 85.735322 42.840463 727 285 0.001506 0.003088 85.736828 42.843551 728 902 0.004765 0.009787 85.741593 42.853338 729 331 0.001749 0.003596 85.743341 42.856934 730 302 0.001595 0.003286 85.744937 42.860220 731 349 0.001844 0.003802 85.746781 42.864022 732 300 0.001585 0.003273 85.748365 42.867295 733 304 0.001606 0.003321 85.749971 42.870617 734 282 0.001490 0.003085 85.751461 42.873702 735 348 0.001838 0.003812 85.753300 42.877514 736 361 0.001907 0.003960 85.755207 42.881474 737 343 0.001812 0.003768 85.757019 42.885241 738 262 0.001384 0.002882 85.758403 42.888123 739 461 0.002435 0.005078 85.760838 42.893201 740 1647 0.008701 0.018165 85.769539 42.911366 741 331 0.001749 0.003656 85.771288 42.915021 742 428 0.002261 0.004733 85.773549 42.919754 743 323 0.001706 0.003577 85.775255 42.923331 744 314 0.001659 0.003482 85.776914 42.926813 745 292 0.001543 0.003242 85.778457 42.930055 746 304 0.001606 0.003380 85.780063 42.933435 747 304 0.001606 0.003385 85.781669 42.936820 748 422 0.002229 0.004705 85.783898 42.941525 749 260 0.001374 0.002902 85.785272 42.944427 750 5064 0.026752 0.056606 85.812024 43.001033 751 331 0.001749 0.003705 85.813773 43.004738 752 404 0.002134 0.004528 85.815907 43.009266 753 283 0.001495 0.003176 85.817402 43.012442 754 281 0.001484 0.003158 85.818886 43.015600 755 437 0.002309 0.004917 85.821195 43.020517 756 354 0.001870 0.003989 85.823065 43.024506 757 294 0.001553 0.003317 85.824618 43.027823 758 265 0.001400 0.002994 85.826018 43.030817 759 297 0.001569 0.003360 85.827587 43.034177 760 333 0.001759 0.003772 85.829346 43.037949 761 264 0.001395 0.002994 85.830741 43.040943 762 333 0.001759 0.003782 85.832500 43.044725 763 245 0.001294 0.002786 85.833795 43.047511 764 249 0.001315 0.002835 85.835110 43.050346 765 318 0.001680 0.003626 85.836790 43.053972 766 286 0.001511 0.003265 85.838301 43.057237 767 374 0.001976 0.004275 85.840277 43.061513 768 1707 0.009018 0.019539 85.849294 43.081052 769 759 0.004010 0.008699 85.853304 43.089751 770 3086 0.016303 0.035416 85.869607 43.125166 771 305 0.001611 0.003505 85.871218 43.128671 772 475 0.002509 0.005465 85.873728 43.134137 773 323 0.001706 0.003721 85.875434 43.137858 774 281 0.001484 0.003242 85.876919 43.141099 775 266 0.001405 0.003072 85.878324 43.144172 776 285 0.001506 0.003296 85.879829 43.147468 777 267 0.001411 0.003092 85.881240 43.150560 778 474 0.002504 0.005496 85.883744 43.156056 779 233 0.001231 0.002705 85.884975 43.158762 780 607 0.003207 0.007057 85.888182 43.165818 781 252 0.001331 0.002933 85.889513 43.168751 782 248 0.001310 0.002890 85.890823 43.171642 783 292 0.001543 0.003408 85.892366 43.175050 784 307 0.001622 0.003587 85.893987 43.178637 785 310 0.001638 0.003627 85.895625 43.182264 786 352 0.001860 0.004124 85.897485 43.186387 787 297 0.001569 0.003484 85.899054 43.189871 788 1125 0.005943 0.013213 85.904997 43.203084 789 274 0.001448 0.003222 85.906444 43.206306 790 318 0.001680 0.003744 85.908124 43.210050 791 266 0.001405 0.003136 85.909530 43.213186 792 362 0.001912 0.004273 85.911442 43.217459 793 251 0.001326 0.002967 85.912768 43.220426 794 301 0.001590 0.003562 85.914358 43.223988 795 312 0.001648 0.003697 85.916006 43.227684 796 299 0.001580 0.003547 85.917586 43.231232 797 296 0.001564 0.003516 85.919150 43.234748 798 278 0.001469 0.003306 85.920618 43.238054 799 306 0.001617 0.003644 85.922235 43.241698 800 30743 0.162411 0.366560 86.084646 43.608258 801 314 0.001659 0.003749 86.086305 43.612006 802 320 0.001691 0.003825 86.087995 43.615831 803 223 0.001178 0.002669 86.089173 43.618500 804 213 0.001125 0.002552 86.090299 43.621053 805 283 0.001495 0.003395 86.091794 43.624448 806 253 0.001337 0.003039 86.093130 43.627487 807 320 0.001691 0.003849 86.094821 43.631336 808 310 0.001638 0.003733 86.096458 43.635069 809 261 0.001379 0.003147 86.097837 43.638216 810 254 0.001342 0.003066 86.099179 43.641283 811 309 0.001632 0.003735 86.100811 43.645018 812 290 0.001532 0.003510 86.102343 43.648527 813 224 0.001183 0.002714 86.103527 43.651242 814 327 0.001727 0.003967 86.105254 43.655209 815 260 0.001374 0.003158 86.106628 43.658367 816 256 0.001352 0.003113 86.107980 43.661480 817 290 0.001532 0.003531 86.109512 43.665012 818 275 0.001453 0.003353 86.110965 43.668364 819 270 0.001426 0.003296 86.112391 43.671660 820 302 0.001595 0.003691 86.113987 43.675351 821 315 0.001664 0.003854 86.115651 43.679206 822 358 0.001891 0.004386 86.117542 43.683591 823 371 0.001960 0.004551 86.119502 43.688142 824 430 0.002272 0.005281 86.121774 43.693423 825 406 0.002145 0.004992 86.123919 43.698415 826 350 0.001849 0.004309 86.125768 43.702724 827 448 0.002367 0.005522 86.128134 43.708246 828 439 0.002319 0.005418 86.130454 43.713664 829 407 0.002150 0.005029 86.132604 43.718692 830 500 0.002641 0.006185 86.135245 43.724877 831 525 0.002774 0.006502 86.138019 43.731380 832 530 0.002800 0.006572 86.140819 43.737952 833 468 0.002472 0.005810 86.143291 43.743762 834 590 0.003117 0.007334 86.146408 43.751096 835 639 0.003376 0.007952 86.149784 43.759048 836 560 0.002958 0.006978 86.152742 43.766026 837 642 0.003392 0.008009 86.156134 43.774035 838 661 0.003492 0.008256 86.159626 43.782290 839 675 0.003566 0.008441 86.163191 43.790731 840 729 0.003851 0.009127 86.167043 43.799858 841 695 0.003672 0.008711 86.170714 43.808569 842 715 0.003777 0.008973 86.174491 43.817542 843 726 0.003835 0.009122 86.178327 43.826664 844 707 0.003735 0.008893 86.182062 43.835557 845 759 0.004010 0.009559 86.186072 43.845116 846 878 0.004638 0.011071 86.190710 43.856187 847 710 0.003751 0.008963 86.194461 43.865150 848 712 0.003761 0.008999 86.198222 43.874148 849 922 0.004871 0.011667 86.203093 43.885815 850 869 0.004591 0.011009 86.207684 43.896824 851 716 0.003783 0.009081 86.211466 43.905905 852 2486 0.013133 0.031568 86.224599 43.937474 853 768 0.004057 0.009764 86.228657 43.947237 854 691 0.003650 0.008795 86.232307 43.956033 855 651 0.003439 0.008296 86.235746 43.964328 856 523 0.002763 0.006672 86.238509 43.971001 857 271 0.001432 0.003461 86.239941 43.974462 858 322 0.001701 0.004118 86.241642 43.978580 859 258 0.001363 0.003303 86.243005 43.981883 860 393 0.002076 0.005037 86.245081 43.986920 861 294 0.001553 0.003773 86.246634 43.990693 862 252 0.001331 0.003238 86.247966 43.993931 863 319 0.001685 0.004103 86.249651 43.998034 864 249 0.001315 0.003206 86.250966 44.001240 865 245 0.001294 0.003159 86.252260 44.004399 866 221 0.001168 0.002852 86.253428 44.007251 867 265 0.001400 0.003424 86.254828 44.010675 868 226 0.001194 0.002924 86.256022 44.013599 869 267 0.001411 0.003458 86.257432 44.017057 870 262 0.001384 0.003397 86.258816 44.020455 871 255 0.001347 0.003310 86.260164 44.023765 872 838 0.004427 0.010891 86.264591 44.034656 873 266 0.001405 0.003461 86.265996 44.038117 874 224 0.001183 0.002918 86.267179 44.041035 875 263 0.001389 0.003430 86.268569 44.044465 876 291 0.001537 0.003799 86.270106 44.048264 877 217 0.001146 0.002836 86.271252 44.051100 878 1145 0.006049 0.014983 86.277301 44.066084 879 258 0.001363 0.003380 86.278664 44.069464 880 287 0.001516 0.003764 86.280180 44.073228 881 215 0.001136 0.002823 86.281316 44.076051 882 286 0.001511 0.003760 86.282827 44.079811 883 702 0.003709 0.009239 86.286536 44.089049 884 227 0.001199 0.002991 86.287735 44.092040 885 236 0.001247 0.003113 86.288982 44.095153 886 297 0.001569 0.003922 86.290551 44.099075 887 253 0.001337 0.003345 86.291887 44.102419 888 327 0.001727 0.004328 86.293615 44.106747 889 227 0.001199 0.003008 86.294814 44.109755 890 266 0.001405 0.003528 86.296219 44.113283 891 285 0.001506 0.003785 86.297725 44.117068 892 491 0.002594 0.006528 86.300319 44.123596 893 261 0.001379 0.003474 86.301697 44.127069 894 312 0.001648 0.004157 86.303346 44.131227 895 276 0.001458 0.003682 86.304804 44.134908 896 280 0.001479 0.003739 86.306283 44.138647 897 232 0.001226 0.003102 86.307509 44.141749 898 294 0.001553 0.003935 86.309062 44.145684 899 269 0.001421 0.003604 86.310483 44.149288 900 271 0.001432 0.003635 86.311915 44.152923 901 304 0.001606 0.004082 86.313521 44.157006 902 249 0.001315 0.003347 86.314836 44.160353 903 273 0.001442 0.003674 86.316278 44.164027 904 253 0.001337 0.003409 86.317615 44.167436 905 214 0.001131 0.002886 86.318745 44.170323 906 266 0.001405 0.003592 86.320151 44.173914 907 352 0.001860 0.004758 86.322010 44.178673 908 312 0.001648 0.004222 86.323658 44.182895 909 229 0.001210 0.003102 86.324868 44.185998 910 256 0.001352 0.003472 86.326221 44.189470 911 281 0.001484 0.003815 86.327705 44.193285 912 1377 0.007274 0.018717 86.334979 44.212002 913 298 0.001574 0.004055 86.336554 44.216057 914 281 0.001484 0.003828 86.338038 44.219885 915 236 0.001247 0.003218 86.339285 44.223103 916 6062 0.032025 0.082760 86.371310 44.305863 917 260 0.001374 0.003553 86.372683 44.309417 918 267 0.001411 0.003653 86.374094 44.313070 919 266 0.001405 0.003643 86.375499 44.316713 920 303 0.001601 0.004155 86.377100 44.320868 921 357 0.001886 0.004900 86.378986 44.325768 922 237 0.001252 0.003257 86.380238 44.329025 923 247 0.001305 0.003398 86.381543 44.332423 924 299 0.001580 0.004118 86.383122 44.336541 925 245 0.001294 0.003378 86.384416 44.339918 926 234 0.001236 0.003230 86.385653 44.343148 927 291 0.001537 0.004021 86.387190 44.347168 928 346 0.001828 0.004786 86.389018 44.351954 929 252 0.001331 0.003489 86.390349 44.355443 930 213 0.001125 0.002952 86.391474 44.358396 931 507 0.002678 0.007035 86.394153 44.365431 932 64226 0.339297 0.892145 86.733450 45.257575 933 226 0.001194 0.003143 86.734644 45.260718 934 252 0.001331 0.003508 86.735975 45.264226 935 284 0.001500 0.003958 86.737475 45.268184 936 355 0.001875 0.004952 86.739351 45.273136 937 259 0.001368 0.003617 86.740719 45.276753 938 226 0.001194 0.003160 86.741913 45.279913 939 245 0.001294 0.003429 86.743207 45.283341 940 581 0.003069 0.008140 86.746277 45.291481 941 224 0.001183 0.003142 86.747460 45.294623 942 216 0.001141 0.003033 86.748601 45.297655 943 222 0.001173 0.003120 86.749774 45.300775 944 275 0.001453 0.003869 86.751227 45.304645 945 374 0.001976 0.005268 86.753202 45.309912 946 231 0.001220 0.003257 86.754423 45.313169 947 384 0.002029 0.005420 86.756451 45.318589 948 267 0.001411 0.003772 86.757862 45.322361 949 225 0.001189 0.003182 86.759051 45.325544 950 474 0.002504 0.006711 86.761555 45.332255 951 312 0.001648 0.004422 86.763203 45.336677 952 446 0.002356 0.006328 86.765559 45.343006 953 275 0.001453 0.003906 86.767012 45.346912 954 316 0.001669 0.004493 86.768681 45.351405 955 272 0.001437 0.003872 86.770118 45.355276 956 239 0.001263 0.003405 86.771381 45.358682 957 391 0.002066 0.005577 86.773446 45.364259 958 218 0.001152 0.003113 86.774598 45.367371 959 317 0.001675 0.004531 86.776273 45.371902 960 5959 0.031481 0.085262 86.807753 45.457164 961 259 0.001368 0.003710 86.809121 45.460873 962 240 0.001268 0.003441 86.810389 45.464314 963 266 0.001405 0.003818 86.811795 45.468132 964 1465 0.007739 0.021049 86.819534 45.489181 965 400 0.002113 0.005753 86.821647 45.494934 966 292 0.001543 0.004204 86.823190 45.499138 967 375 0.001981 0.005405 86.825171 45.504543 968 266 0.001405 0.003838 86.826576 45.508380 969 310 0.001638 0.004477 86.828214 45.512857 970 245 0.001294 0.003542 86.829508 45.516399 971 469 0.002478 0.006787 86.831986 45.523187 972 528 0.002789 0.007649 86.834775 45.530836 973 317 0.001675 0.004597 86.836450 45.535433 974 263 0.001389 0.003818 86.837839 45.539251 975 257 0.001358 0.003735 86.839197 45.542985 976 321 0.001696 0.004669 86.840893 45.547655 977 279 0.001474 0.004063 86.842366 45.551717 978 243 0.001284 0.003542 86.843650 45.555259 979 268 0.001416 0.003910 86.845066 45.559170 980 381 0.002013 0.005565 86.847079 45.564735 981 258 0.001363 0.003772 86.848442 45.568507 982 370 0.001955 0.005415 86.850396 45.573922 983 257 0.001358 0.003765 86.851754 45.577688 984 290 0.001532 0.004253 86.853286 45.581941 985 267 0.001411 0.003920 86.854697 45.585860 986 328 0.001733 0.004820 86.856429 45.590680 987 278 0.001469 0.004090 86.857898 45.594770 988 277 0.001463 0.004079 86.859361 45.598849 989 336 0.001775 0.004953 86.861136 45.603802 990 326 0.001722 0.004810 86.862859 45.608612 991 259 0.001368 0.003825 86.864227 45.612437 992 389 0.002055 0.005751 86.866282 45.618189 993 317 0.001675 0.004692 86.867957 45.622880 994 293 0.001548 0.004341 86.869505 45.627221 995 264 0.001395 0.003915 86.870899 45.631136 996 346 0.001828 0.005136 86.872727 45.636272 997 237 0.001252 0.003522 86.873979 45.639794 998 286 0.001511 0.004254 86.875490 45.644048 999 281 0.001484 0.004184 86.876975 45.648232 1000 3650 0.019282 0.054400 86.896257 45.702632 1001 469 0.002478 0.006997 86.898735 45.709629 1002 292 0.001543 0.004361 86.900277 45.713990 1003 284 0.001500 0.004245 86.901778 45.718235 1004 840 0.004438 0.012570 86.906215 45.730805 1005 277 0.001463 0.004149 86.907678 45.734954 1006 9553 0.050467 0.143234 86.958146 45.878188 1007 350 0.001849 0.005253 86.959995 45.883441 1008 350 0.001849 0.005258 86.961844 45.888699 1009 323 0.001706 0.004857 86.963550 45.893557 1010 301 0.001590 0.004531 86.965140 45.898088 1011 391 0.002066 0.005892 86.967206 45.903979 1012 998 0.005272 0.015053 86.972478 45.919032 1013 296 0.001564 0.004469 86.974042 45.923501 1014 395 0.002087 0.005970 86.976128 45.929471 1015 280 0.001479 0.004236 86.977608 45.933707 1016 458 0.002420 0.006935 86.980027 45.940642 1017 274 0.001448 0.004153 86.981475 45.944795 1018 989 0.005225 0.015006 86.986700 45.959801 1019 292 0.001543 0.004435 86.988242 45.964235 1020 550 0.002906 0.008361 86.991148 45.972597 1021 297 0.001569 0.004520 86.992717 45.977116 1022 301 0.001590 0.004585 86.994307 45.981701 1023 339 0.001791 0.005169 86.996098 45.986870 1024 3467 0.018316 0.052913 87.014413 46.039783 1025 311 0.001643 0.004751 87.016056 46.044534 1026 280 0.001479 0.004282 87.017536 46.048815 1027 3177 0.016784 0.048629 87.034319 46.097445 1028 291 0.001537 0.004459 87.035857 46.101903 1029 379 0.002002 0.005813 87.037859 46.107716 1030 385 0.002034 0.005910 87.039893 46.113626 1031 354 0.001870 0.005440 87.041763 46.119066 1032 594 0.003138 0.009136 87.044901 46.128202 1033 416 0.002198 0.006405 87.047098 46.134607 1034 441 0.002330 0.006796 87.049428 46.141403 1035 332 0.001754 0.005121 87.051182 46.146524 1036 300 0.001585 0.004632 87.052767 46.151157 1037 458 0.002420 0.007079 87.055186 46.158235 1038 450 0.002377 0.006962 87.057564 46.165197 1039 437 0.002309 0.006767 87.059872 46.171964 1040 404 0.002134 0.006262 87.062007 46.178226 1041 424 0.002240 0.006578 87.064247 46.184805 1042 397 0.002097 0.006165 87.066344 46.190970 1043 402 0.002124 0.006249 87.068468 46.197219 1044 402 0.002124 0.006255 87.070591 46.203474 1045 395 0.002087 0.006152 87.072678 46.209627 1046 383 0.002023 0.005971 87.074701 46.215597 1047 392 0.002071 0.006117 87.076772 46.221714 1048 474 0.002504 0.007404 87.079276 46.229118 1049 424 0.002240 0.006629 87.081516 46.235747 1050 413 0.002182 0.006463 87.083698 46.242210 1051 398 0.002103 0.006234 87.085801 46.248445 1052 2330 0.012309 0.036533 87.098110 46.284977 1053 450 0.002377 0.007062 87.100487 46.292040 1054 472 0.002494 0.007415 87.102981 46.299454 1055 490 0.002589 0.007705 87.105569 46.307159 1056 524 0.002768 0.008247 87.108337 46.315406 1057 426 0.002250 0.006711 87.110588 46.322117 1058 530 0.002800 0.008357 87.113388 46.330475 1059 547 0.002890 0.008634 87.116277 46.339108 1060 2296 0.012129 0.036273 87.128407 46.375382 1061 596 0.003149 0.009425 87.131556 46.384806 1062 553 0.002921 0.008753 87.134477 46.393559 1063 883 0.004665 0.013990 87.139142 46.407549 1064 19202 0.101441 0.304507 87.240583 46.712055 1065 828 0.004374 0.013143 87.244957 46.725198 1066 794 0.004195 0.012615 87.249152 46.737813 1067 1711 0.009039 0.027210 87.258191 46.765023 1068 1976 0.010439 0.031453 87.268630 46.796476 1069 837 0.004422 0.013336 87.273052 46.809812 1070 785 0.004147 0.012519 87.277199 46.822330 1071 792 0.004184 0.012642 87.281383 46.834973 1072 848 0.004480 0.013549 87.285863 46.848521 1073 272 0.001437 0.004350 87.287300 46.852871 1074 454 0.002398 0.007267 87.289698 46.860139 1075 293 0.001548 0.004694 87.291246 46.864833 1076 293 0.001548 0.004699 87.292794 46.869532 1077 224 0.001183 0.003596 87.293977 46.873127 1078 234 0.001236 0.003760 87.295213 46.876887 1079 265 0.001400 0.004262 87.296613 46.881149 1080 260 0.001374 0.004185 87.297987 46.885334 1081 222 0.001173 0.003577 87.299160 46.888911 1082 280 0.001479 0.004515 87.300639 46.893426 1083 306 0.001617 0.004939 87.302255 46.898365 1084 256 0.001352 0.004136 87.303608 46.902501 1085 259 0.001368 0.004188 87.304976 46.906689 1086 243 0.001284 0.003933 87.306260 46.910623 1087 255 0.001347 0.004131 87.307607 46.914754 1088 285 0.001506 0.004621 87.309112 46.919375 1089 253 0.001337 0.004106 87.310449 46.923482 1090 607 0.003207 0.009861 87.313656 46.933343 1091 227 0.001199 0.003691 87.314855 46.937034 1092 320 0.001691 0.005208 87.316545 46.942242 1093 270 0.001426 0.004398 87.317972 46.946640 1094 546 0.002884 0.008903 87.320856 46.955543 1095 225 0.001189 0.003672 87.322045 46.959215 1096 329 0.001738 0.005374 87.323783 46.964589 1097 301 0.001590 0.004921 87.325373 46.969511 1098 218 0.001152 0.003568 87.326525 46.973078 1099 266 0.001405 0.004357 87.327930 46.977435 1100 281 0.001484 0.004607 87.329414 46.982042 1101 230 0.001215 0.003774 87.330630 46.985816 1102 254 0.001342 0.004172 87.331971 46.989988 1103 235 0.001241 0.003863 87.333213 46.993851 1104 267 0.001411 0.004393 87.334623 46.998244 1105 187 0.000988 0.003080 87.335611 47.001324 1106 190 0.001004 0.003132 87.336615 47.004456 1107 230 0.001215 0.003795 87.337830 47.008251 1108 251 0.001326 0.004145 87.339156 47.012396 1109 281 0.001484 0.004645 87.340641 47.017040 1110 232 0.001226 0.003838 87.341866 47.020879 1111 244 0.001289 0.004040 87.343155 47.024919 1112 188 0.000993 0.003116 87.344148 47.028035 1113 232 0.001226 0.003849 87.345374 47.031883 1114 218 0.001152 0.003620 87.346526 47.035503 1115 238 0.001257 0.003955 87.347783 47.039458 1116 218 0.001152 0.003626 87.348935 47.043084 1117 295 0.001558 0.004911 87.350493 47.047995 1118 211 0.001115 0.003516 87.351608 47.051511 1119 241 0.001273 0.004019 87.352881 47.055530 1120 373 0.001971 0.006226 87.354851 47.061757 1121 213 0.001125 0.003559 87.355977 47.065315 1122 232 0.001226 0.003880 87.357202 47.069195 1123 220 0.001162 0.003682 87.358365 47.072877 1124 259 0.001368 0.004339 87.359733 47.077216 1125 236 0.001247 0.003957 87.360980 47.081173 1126 223 0.001178 0.003742 87.362158 47.084916 1127 284 0.001500 0.004770 87.363658 47.089686 1128 249 0.001315 0.004186 87.364973 47.093872 1129 233 0.001231 0.003921 87.366204 47.097793 1130 228 0.001204 0.003840 87.367409 47.101633 1131 243 0.001284 0.004096 87.368693 47.105729 1132 459 0.002425 0.007744 87.371117 47.113473 1133 211 0.001115 0.003563 87.372232 47.117036 1134 197 0.001041 0.003330 87.373273 47.120365 1135 249 0.001315 0.004212 87.374588 47.124578 1136 306 0.001617 0.005181 87.376205 47.129759 1137 242 0.001278 0.004101 87.377483 47.133859 1138 273 0.001442 0.004630 87.378925 47.138490 1139 230 0.001215 0.003904 87.380140 47.142394 1140 245 0.001294 0.004163 87.381435 47.146557 1141 232 0.001226 0.003945 87.382660 47.150502 1142 280 0.001479 0.004766 87.384140 47.155268 1143 201 0.001062 0.003424 87.385201 47.158692 1144 296 0.001564 0.005047 87.386765 47.163739 1145 249 0.001315 0.004249 87.388081 47.167988 1146 269 0.001421 0.004595 87.389502 47.172583 1147 259 0.001368 0.004428 87.390870 47.177011 1148 254 0.001342 0.004346 87.392212 47.181357 1149 251 0.001326 0.004298 87.393538 47.185655 1150 213 0.001125 0.003651 87.394663 47.189306 1151 232 0.001226 0.003980 87.395889 47.193286 1152 293 0.001548 0.005031 87.397437 47.198316 1153 227 0.001199 0.003901 87.398636 47.202217 1154 239 0.001263 0.004111 87.399898 47.206328 1155 278 0.001469 0.004786 87.401367 47.211113 1156 338 0.001786 0.005823 87.403153 47.216937 1157 254 0.001342 0.004380 87.404494 47.221317 1158 233 0.001231 0.004021 87.405725 47.225338 1159 256 0.001352 0.004422 87.407078 47.229760 1160 227 0.001199 0.003925 87.408277 47.233685 1161 275 0.001453 0.004759 87.409730 47.238444 1162 222 0.001173 0.003845 87.410903 47.242288 1163 190 0.001004 0.003293 87.411906 47.245582 1164 690 0.003645 0.011970 87.415552 47.257552 1165 183 0.000967 0.003178 87.416518 47.260730 1166 231 0.001220 0.004014 87.417739 47.264744 1167 244 0.001289 0.004244 87.419028 47.268988 1168 296 0.001564 0.005153 87.420591 47.274141 1169 144 0.000761 0.002509 87.421352 47.276650 1170 232 0.001226 0.004046 87.422578 47.280695 1171 217 0.001146 0.003787 87.423724 47.284483 1172 241 0.001273 0.004210 87.424997 47.288692 1173 186 0.000983 0.003252 87.425980 47.291944 1174 256 0.001352 0.004479 87.427332 47.296423 1175 263 0.001389 0.004606 87.428722 47.301029 1176 10659 0.056310 0.186824 87.485032 47.487853 1177 281 0.001484 0.004929 87.486516 47.492782 1178 244 0.001289 0.004284 87.487805 47.497066 1179 235 0.001241 0.004129 87.489047 47.501196 1180 234 0.001236 0.004115 87.490283 47.505311 1181 196 0.001035 0.003450 87.491318 47.508761 1182 193 0.001020 0.003400 87.492338 47.512161 1183 219 0.001157 0.003861 87.493495 47.516022 1184 221 0.001168 0.003900 87.494662 47.519922 1185 251 0.001326 0.004433 87.495988 47.524355 1186 286 0.001511 0.005055 87.497499 47.529411 1187 245 0.001294 0.004334 87.498794 47.533745 1188 567 0.002995 0.010039 87.501789 47.543785 1189 198 0.001046 0.003509 87.502835 47.547293 1190 230 0.001215 0.004079 87.504050 47.551373 1191 218 0.001152 0.003870 87.505202 47.555242 1192 233 0.001231 0.004139 87.506433 47.559382 1193 198 0.001046 0.003521 87.507479 47.562902 1194 258 0.001363 0.004591 87.508842 47.567494 1195 189 0.000998 0.003366 87.509840 47.570860 1196 284 0.001500 0.005062 87.511340 47.575922 1197 251 0.001326 0.004478 87.512666 47.580400 1198 425 0.002245 0.007588 87.514912 47.587989 1199 228 0.001204 0.004074 87.516116 47.592063 1200 1083 0.005721 0.019369 87.521837 47.611432 1201 251 0.001326 0.004493 87.523163 47.615925 1202 221 0.001168 0.003959 87.524331 47.619885 1203 225 0.001189 0.004034 87.525520 47.623919 1204 312 0.001648 0.005599 87.527168 47.629517 1205 260 0.001374 0.004669 87.528541 47.634187 1206 232 0.001226 0.004170 87.529767 47.638357 1207 203 0.001072 0.003652 87.530839 47.642009 1208 273 0.001442 0.004915 87.532282 47.646924 1209 229 0.001210 0.004126 87.533491 47.651050 1210 201 0.001062 0.003625 87.534553 47.654675 1211 234 0.001236 0.004223 87.535789 47.658899 1212 346 0.001828 0.006250 87.537617 47.665149 1213 310 0.001638 0.005604 87.539255 47.670753 1214 322 0.001701 0.005826 87.540956 47.676579 1215 634 0.003349 0.011481 87.544305 47.688060 1216 47812 0.252584 0.866521 87.796889 48.554581 1217 289 0.001527 0.005242 87.798416 48.559823 1218 210 0.001109 0.003812 87.799526 48.563635 1219 314 0.001659 0.005705 87.801184 48.569340 1220 331 0.001749 0.006019 87.802933 48.575359 1221 194 0.001025 0.003530 87.803958 48.578889 1222 293 0.001548 0.005336 87.805506 48.584226 1223 206 0.001088 0.003755 87.806594 48.587981 1224 203 0.001072 0.003703 87.807666 48.591684 1225 209 0.001104 0.003816 87.808771 48.595500 1226 204 0.001078 0.003728 87.809848 48.599227 1227 202 0.001067 0.003694 87.810915 48.602921 1228 177 0.000935 0.003240 87.811851 48.606161 1229 228 0.001204 0.004176 87.813055 48.610337 1230 277 0.001463 0.005078 87.814518 48.615415 1231 225 0.001189 0.004128 87.815707 48.619543 1232 208 0.001099 0.003819 87.816806 48.623363 1233 228 0.001204 0.004190 87.818010 48.627552 1234 270 0.001426 0.004966 87.819437 48.632518 1235 237 0.001252 0.004362 87.820689 48.636881 1236 484 0.002557 0.008916 87.823246 48.645797 1237 295 0.001558 0.005439 87.824804 48.651235 1238 257 0.001358 0.004742 87.826162 48.655977 1239 236 0.001247 0.004358 87.827409 48.660335 1240 540 0.002853 0.009980 87.830261 48.670315 1241 294 0.001553 0.005438 87.831814 48.675753 1242 311 0.001643 0.005757 87.833457 48.681510 1243 206 0.001088 0.003816 87.834546 48.685326 1244 227 0.001199 0.004209 87.835745 48.689535 1245 165 0.000872 0.003062 87.836617 48.692597 1246 292 0.001543 0.005423 87.838159 48.698020 1247 257 0.001358 0.004776 87.839517 48.702796 1248 228 0.001204 0.004241 87.840721 48.707037 1249 292 0.001543 0.005436 87.842264 48.712473 1250 243 0.001284 0.004527 87.843548 48.717000 1251 196 0.001035 0.003654 87.844583 48.720654 1252 237 0.001252 0.004422 87.845835 48.725077 1253 210 0.001109 0.003922 87.846945 48.728998 1254 286 0.001511 0.005345 87.848455 48.734344 1255 342 0.001807 0.006397 87.850262 48.740741 1256 3354 0.017719 0.062786 87.867981 48.803526 1257 370 0.001955 0.006932 87.869936 48.810458 1258 353 0.001865 0.006619 87.871800 48.817077 1259 199 0.001051 0.003734 87.872852 48.820811 1260 254 0.001342 0.004770 87.874194 48.825581 1261 211 0.001115 0.003966 87.875308 48.829546 1262 215 0.001136 0.004044 87.876444 48.833590 1263 190 0.001004 0.003577 87.877448 48.837167 1264 324 0.001712 0.006104 87.879159 48.843271 1265 189 0.000998 0.003563 87.880158 48.846834 1266 180 0.000951 0.003396 87.881109 48.850231 1267 192 0.001014 0.003626 87.882123 48.853856 1268 263 0.001389 0.004970 87.883513 48.858826 1269 238 0.001257 0.004501 87.884770 48.863328 1270 275 0.001453 0.005205 87.886223 48.868533 1271 275 0.001453 0.005209 87.887675 48.873743 1272 247 0.001305 0.004683 87.888980 48.878425 1273 504 0.002663 0.009562 87.891643 48.887988 1274 351 0.001854 0.006665 87.893497 48.894652 1275 233 0.001231 0.004428 87.894728 48.899080 1276 264 0.001395 0.005021 87.896123 48.904101 1277 277 0.001463 0.005272 87.897586 48.909373 1278 291 0.001537 0.005543 87.899123 48.914916 1279 156 0.000824 0.002974 87.899947 48.917889 1280 242 0.001278 0.004617 87.901226 48.922506 1281 239 0.001263 0.004563 87.902489 48.927069 1282 257 0.001358 0.004911 87.903846 48.931980 1283 241 0.001273 0.004608 87.905119 48.936588 1284 209 0.001104 0.004000 87.906224 48.940588 1285 294 0.001553 0.005631 87.907777 48.946218 1286 274 0.001448 0.005252 87.909224 48.951470 1287 343 0.001812 0.006579 87.911036 48.958049 1288 405 0.002140 0.007775 87.913176 48.965824 1289 154 0.000814 0.002959 87.913989 48.968783 1290 238 0.001257 0.004576 87.915247 48.973359 1291 203 0.001072 0.003906 87.916319 48.977265 1292 265 0.001400 0.005103 87.917719 48.982367 1293 236 0.001247 0.004548 87.918966 48.986915 1294 265 0.001400 0.005111 87.920366 48.992026 1295 463 0.002446 0.008936 87.922812 49.000963 1296 338 0.001786 0.006529 87.924597 49.007491 1297 228 0.001204 0.004407 87.925802 49.011899 1298 256 0.001352 0.004952 87.927154 49.016851 1299 183 0.000967 0.003543 87.928121 49.020394 1300 472 0.002494 0.009145 87.930614 49.029539 1301 381 0.002013 0.007388 87.932627 49.036927 1302 716 0.003783 0.013894 87.936410 49.050821 1303 211 0.001115 0.004098 87.937524 49.054919 1304 224 0.001183 0.004353 87.938708 49.059272 1305 221 0.001168 0.004298 87.939875 49.063571 1306 234 0.001236 0.004555 87.941112 49.068126 1307 253 0.001337 0.004928 87.942448 49.073054 1308 170 0.000898 0.003314 87.943346 49.076368 1309 227 0.001199 0.004429 87.944545 49.080797 1310 255 0.001347 0.004979 87.945893 49.085776 1311 280 0.001479 0.005471 87.947372 49.091247 1312 376 0.001986 0.007352 87.949358 49.098599 1313 315 0.001664 0.006164 87.951022 49.104763 1314 242 0.001278 0.004739 87.952301 49.109503 1315 197 0.001041 0.003861 87.953341 49.113364 1316 191 0.001009 0.003746 87.954350 49.117110 1317 402 0.002124 0.007891 87.956474 49.125001 1318 169 0.000893 0.003320 87.957367 49.128320 1319 265 0.001400 0.005210 87.958767 49.133530 1320 299 0.001580 0.005882 87.960346 49.139412 1321 196 0.001035 0.003859 87.961382 49.143271 1322 194 0.001025 0.003822 87.962407 49.147094 1323 204 0.001078 0.004023 87.963484 49.151116 1324 265 0.001400 0.005229 87.964884 49.156346 1325 214 0.001131 0.004226 87.966015 49.160572 1326 199 0.001051 0.003933 87.967066 49.164504 1327 175 0.000925 0.003461 87.967991 49.167966 1328 192 0.001014 0.003800 87.969005 49.171766 1329 189 0.000998 0.003744 87.970003 49.175509 1330 257 0.001358 0.005094 87.971361 49.180604 1331 200 0.001057 0.003967 87.972418 49.184571 1332 213 0.001125 0.004229 87.973543 49.188800 1333 179 0.000946 0.003556 87.974489 49.192356 1334 263 0.001389 0.005229 87.975878 49.197585 1335 234 0.001236 0.004656 87.977114 49.202241 1336 391 0.002066 0.007786 87.979180 49.210027 1337 233 0.001231 0.004643 87.980411 49.214670 1338 807 0.004263 0.016093 87.984674 49.230763 1339 433 0.002287 0.008641 87.986961 49.239404 1340 291 0.001537 0.005812 87.988499 49.245216 1341 216 0.001141 0.004317 87.989640 49.249533 1342 249 0.001315 0.004980 87.990955 49.254513 1343 254 0.001342 0.005084 87.992297 49.259597 1344 440 0.002324 0.008814 87.994622 49.268411 1345 261 0.001379 0.005232 87.996000 49.273643 1346 217 0.001146 0.004353 87.997147 49.277996 1347 204 0.001078 0.004095 87.998225 49.282092 1348 238 0.001257 0.004782 87.999482 49.286873 1349 333 0.001759 0.006695 88.001241 49.293569 1350 199 0.001051 0.004004 88.002292 49.297573 1351 243 0.001284 0.004893 88.003576 49.302466 1352 263 0.001389 0.005300 88.004965 49.307765 1353 201 0.001062 0.004053 88.006027 49.311818 1354 572 0.003022 0.011543 88.009049 49.323362 1355 171 0.000903 0.003453 88.009952 49.326815 1356 219 0.001157 0.004426 88.011109 49.331241 1357 164 0.000866 0.003317 88.011976 49.334558 1358 556 0.002937 0.011253 88.014913 49.345811 1359 182 0.000961 0.003686 88.015875 49.349498 1360 235 0.001241 0.004763 88.017116 49.354261 1361 227 0.001199 0.004605 88.018315 49.358866 1362 225 0.001189 0.004567 88.019504 49.363433 1363 147 0.000777 0.002986 88.020280 49.366419 1364 198 0.001046 0.004025 88.021326 49.370444 1365 236 0.001247 0.004801 88.022573 49.375246 1366 7060 0.037297 0.143735 88.059870 49.518981 1367 271 0.001432 0.005521 88.061302 49.524503 1368 344 0.001817 0.007014 88.063119 49.531516 1369 221 0.001168 0.004509 88.064287 49.536026 1370 252 0.001331 0.005146 88.065618 49.541171 1371 247 0.001305 0.005047 88.066923 49.546218 1372 227 0.001199 0.004642 88.068122 49.550860 1373 243 0.001284 0.004973 88.069406 49.555833 1374 171 0.000903 0.003502 88.070309 49.559334 1375 219 0.001157 0.004488 88.071466 49.563822 1376 269 0.001421 0.005517 88.072887 49.569339 1377 247 0.001305 0.005069 88.074192 49.574408 1378 213 0.001125 0.004375 88.075317 49.578783 1379 252 0.001331 0.005179 88.076649 49.583962 1380 272 0.001437 0.005594 88.078086 49.589557 1381 336 0.001775 0.006916 88.079861 49.596473 1382 253 0.001337 0.005211 88.081197 49.601684 1383 295 0.001558 0.006081 88.082756 49.607764 1384 256 0.001352 0.005281 88.084108 49.613045 1385 350 0.001849 0.007225 88.085957 49.620270 1386 2818 0.014887 0.058212 88.100844 49.678482 1387 554 0.002927 0.011452 88.103771 49.689934 1388 899 0.004749 0.018598 88.108520 49.708532 1389 733 0.003872 0.015175 88.112392 49.723706 1390 258 0.001363 0.005345 88.113755 49.729051 1391 305 0.001611 0.006323 88.115367 49.735374 1392 563 0.002974 0.011680 88.118341 49.747055 1393 236 0.001247 0.004900 88.119588 49.751955 1394 217 0.001146 0.004508 88.120734 49.756463 1395 243 0.001284 0.005052 88.122018 49.761515 1396 697 0.003682 0.014502 88.125700 49.776017 1397 235 0.001241 0.004893 88.126941 49.780910 1398 263 0.001389 0.005480 88.128331 49.786390 1399 190 0.001004 0.003962 88.129335 49.790352 1400 448 0.002367 0.009348 88.131701 49.799700 1401 224 0.001183 0.004677 88.132885 49.804377 1402 374 0.001976 0.007815 88.134860 49.812192 1403 277 0.001463 0.005792 88.136324 49.817984 1404 222 0.001173 0.004645 88.137497 49.822630 1405 221 0.001168 0.004628 88.138664 49.827258 1406 312 0.001648 0.006538 88.140312 49.833796 1407 184 0.000972 0.003859 88.141284 49.837654 1408 216 0.001141 0.004533 88.142425 49.842187 1409 240 0.001268 0.005040 88.143693 49.847227 1410 215 0.001136 0.004518 88.144829 49.851745 1411 222 0.001173 0.004669 88.146002 49.856414 1412 248 0.001310 0.005219 88.147312 49.861633 1413 219 0.001157 0.004612 88.148469 49.866245 1414 232 0.001226 0.004889 88.149695 49.871134 1415 237 0.001252 0.004998 88.150947 49.876132 1416 366 0.001934 0.007724 88.152880 49.883857 1417 719 0.003798 0.015185 88.156679 49.899041 1418 1151 0.006081 0.024325 88.162759 49.923367 1419 264 0.001395 0.005583 88.164154 49.928950 1420 546 0.002884 0.011556 88.167038 49.940506 1421 251 0.001326 0.005316 88.168364 49.945821 1422 185 0.000977 0.003921 88.169342 49.949742 1423 196 0.001035 0.004157 88.170377 49.953899 1424 244 0.001289 0.005179 88.171666 49.959078 1425 191 0.001009 0.004057 88.172675 49.963134 1426 247 0.001305 0.005250 88.173980 49.968384 1427 208 0.001099 0.004424 88.175079 49.972808 1428 367 0.001939 0.007811 88.177018 49.980619 1429 235 0.001241 0.005005 88.178259 49.985624 1430 182 0.000961 0.003879 88.179221 49.989503 1431 192 0.001014 0.004095 88.180235 49.993598 1432 235 0.001241 0.005016 88.181476 49.998613 1433 189 0.000998 0.004037 88.182475 50.002650 1434 218 0.001152 0.004659 88.183627 50.007309 1435 183 0.000967 0.003914 88.184593 50.011223 1436 3375 0.017830 0.072233 88.202423 50.083456 1437 201 0.001062 0.004305 88.203485 50.087761 1438 311 0.001643 0.006665 88.205128 50.094426 1439 371 0.001960 0.007957 88.207088 50.102383 1440 618 0.003265 0.013264 88.210352 50.115647 1441 203 0.001072 0.004360 88.211425 50.120007 1442 226 0.001194 0.004857 88.212619 50.124864 1443 231 0.001220 0.004968 88.213839 50.129832 1444 223 0.001178 0.004799 88.215017 50.134631 1445 232 0.001226 0.004996 88.216243 50.139628 1446 365 0.001928 0.007866 88.218171 50.147494 1447 201 0.001062 0.004335 88.219233 50.151829 1448 242 0.001278 0.005223 88.220511 50.157052 1449 214 0.001131 0.004622 88.221642 50.161673 1450 322 0.001701 0.006959 88.223343 50.168632 1451 191 0.001009 0.004131 88.224352 50.172762 1452 522 0.002758 0.011297 88.227110 50.184059 1453 324 0.001712 0.007016 88.228821 50.191075 1454 247 0.001305 0.005353 88.230126 50.196428 1455 206 0.001088 0.004467 88.231215 50.200895 1456 1384 0.007311 0.030034 88.238526 50.230929 1457 535 0.002826 0.011618 88.241352 50.242547 1458 1211 0.006398 0.026315 88.247750 50.268862 1459 1357 0.007169 0.029508 88.254919 50.298370 1460 2005 0.010592 0.043629 88.265511 50.341999 1461 1003 0.005299 0.021840 88.270810 50.363840 1462 628 0.003318 0.013684 88.274127 50.377524 1463 285 0.001506 0.006214 88.275633 50.383738 1464 293 0.001548 0.006393 88.277181 50.390131 1465 224 0.001183 0.004891 88.278364 50.395022 1466 337 0.001780 0.007363 88.280144 50.402386 1467 187 0.000988 0.004089 88.281132 50.406474 1468 2245 0.011860 0.049119 88.292992 50.455593 1469 258 0.001363 0.005649 88.294355 50.461242 1470 719 0.003798 0.015753 88.298154 50.476995 1471 285 0.001506 0.006248 88.299659 50.483243 1472 1420 0.007502 0.031153 88.307161 50.514397 1473 247 0.001305 0.005423 88.308466 50.519819 1474 270 0.001426 0.005932 88.309892 50.525751 1475 196 0.001035 0.004309 88.310928 50.530059 1476 1000 0.005283 0.021999 88.316210 50.552058 1477 228 0.001204 0.005019 88.317415 50.557077 1478 314 0.001659 0.006917 88.319074 50.563994 1479 3569 0.018855 0.078673 88.337928 50.642667 1480 8827 0.046632 0.194708 88.384560 50.837374 1481 209 0.001104 0.004613 88.385664 50.841988 1482 237 0.001252 0.005235 88.386916 50.847223 1483 546 0.002884 0.012068 88.389801 50.859291 1484 311 0.001643 0.006879 88.391444 50.866169 1485 209 0.001104 0.004626 88.392548 50.870795 1486 242 0.001278 0.005360 88.393826 50.876155 1487 227 0.001199 0.005031 88.395025 50.881186 1488 2578 0.013619 0.057173 88.408645 50.938359 1489 1593 0.008416 0.035352 88.417060 50.973712 1490 1983 0.010476 0.044037 88.427536 51.017749 1491 267 0.001411 0.005933 88.428947 51.023682 1492 2283 0.012061 0.050767 88.441007 51.074449 1493 281 0.001484 0.006253 88.442492 51.080702 1494 462 0.002441 0.010287 88.444933 51.090989 1495 842 0.004448 0.018761 88.449381 51.109751 1496 2520 0.013313 0.056188 88.462694 51.165938 1497 3743 0.019774 0.083512 88.482467 51.249450 1498 797 0.004210 0.017794 88.486678 51.267245 1499 675 0.003566 0.015080 88.490244 51.282325 1500 2176532 11.498314 48.659189 99.988557 99.941514 1504 692 0.003656 0.015512 99.992213 99.957026 1505 1 0.000005 0.000022 99.992218 99.957048 1506 1 0.000005 0.000022 99.992224 99.957070 1509 1 0.000005 0.000022 99.992229 99.957093 1517 2 0.000011 0.000045 99.992239 99.957138 1519 1 0.000005 0.000023 99.992245 99.957161 1524 928 0.004902 0.021079 99.997147 99.978239 1541 1 0.000005 0.000023 99.997153 99.978262 1546 1 0.000005 0.000023 99.997158 99.978285 1553 1 0.000005 0.000023 99.997163 99.978309 1568 1 0.000005 0.000023 99.997168 99.978332 1576 1 0.000005 0.000023 99.997174 99.978355 1582 1 0.000005 0.000024 99.997179 99.978379 1596 1 0.000005 0.000024 99.997184 99.978403 1599 1 0.000005 0.000024 99.997190 99.978427 1600 3 0.000016 0.000072 99.997205 99.978498 1613 1 0.000005 0.000024 99.997211 99.978522 1619 1 0.000005 0.000024 99.997216 99.978546 1623 2 0.000011 0.000048 99.997226 99.978595 1685 1 0.000005 0.000025 99.997232 99.978620 1697 2 0.000011 0.000051 99.997242 99.978670 1698 2 0.000011 0.000051 99.997253 99.978721 1738 1 0.000005 0.000026 99.997258 99.978747 1748 1 0.000005 0.000026 99.997263 99.978773 1756 1 0.000005 0.000026 99.997269 99.978799 1768 5 0.000026 0.000132 99.997295 99.978931 1827 1 0.000005 0.000027 99.997300 99.978958 1838 1 0.000005 0.000027 99.997306 99.978986 1863 1 0.000005 0.000028 99.997311 99.979013 1890 1 0.000005 0.000028 99.997316 99.979041 1895 1 0.000005 0.000028 99.997322 99.979070 1946 1 0.000005 0.000029 99.997327 99.979099 1994 1 0.000005 0.000030 99.997332 99.979128 2000 2 0.000011 0.000060 99.997343 99.979188 2022 1 0.000005 0.000030 99.997348 99.979218 2029 1 0.000005 0.000030 99.997353 99.979248 2045 1 0.000005 0.000030 99.997359 99.979279 2055 1 0.000005 0.000031 99.997364 99.979310 2059 1 0.000005 0.000031 99.997369 99.979340 2061 1 0.000005 0.000031 99.997374 99.979371 2070 1 0.000005 0.000031 99.997380 99.979402 2087 8 0.000042 0.000249 99.997422 99.979651 2088 2 0.000011 0.000062 99.997433 99.979713 2116 278 0.001469 0.008767 99.998901 99.988480 2133 5 0.000026 0.000159 99.998928 99.988639 2141 1 0.000005 0.000032 99.998933 99.988671 2171 1 0.000005 0.000032 99.998938 99.988703 2184 1 0.000005 0.000033 99.998943 99.988736 2227 1 0.000005 0.000033 99.998949 99.988769 2230 2 0.000011 0.000066 99.998959 99.988836 2282 1 0.000005 0.000034 99.998965 99.988870 2368 3 0.000016 0.000106 99.998980 99.988976 2399 1 0.000005 0.000036 99.998986 99.989011 2420 1 0.000005 0.000036 99.998991 99.989047 2489 2 0.000011 0.000074 99.999002 99.989122 2555 1 0.000005 0.000038 99.999007 99.989160 2568 1 0.000005 0.000038 99.999012 99.989198 2573 1 0.000005 0.000038 99.999017 99.989236 2632 1 0.000005 0.000039 99.999023 99.989275 2643 1 0.000005 0.000039 99.999028 99.989315 2658 1 0.000005 0.000040 99.999033 99.989354 2678 1 0.000005 0.000040 99.999039 99.989394 2688 1 0.000005 0.000040 99.999044 99.989434 2756 3 0.000016 0.000123 99.999060 99.989558 2781 1 0.000005 0.000041 99.999065 99.989599 2803 1 0.000005 0.000042 99.999070 99.989641 2807 1 0.000005 0.000042 99.999075 99.989683 2820 1 0.000005 0.000042 99.999081 99.989725 2857 1 0.000005 0.000043 99.999086 99.989767 2862 1 0.000005 0.000043 99.999091 99.989810 2919 1 0.000005 0.000044 99.999097 99.989854 2922 1 0.000005 0.000044 99.999102 99.989897 2935 1 0.000005 0.000044 99.999107 99.989941 2958 1 0.000005 0.000044 99.999112 99.989985 2961 1 0.000005 0.000044 99.999118 99.990029 2977 1 0.000005 0.000044 99.999123 99.990073 3002 2 0.000011 0.000089 99.999134 99.990163 3040 1 0.000005 0.000045 99.999139 99.990208 3050 1 0.000005 0.000045 99.999144 99.990254 3065 2 0.000011 0.000091 99.999155 99.990345 3075 1 0.000005 0.000046 99.999160 99.990391 3090 1 0.000005 0.000046 99.999165 99.990437 3098 1 0.000005 0.000046 99.999171 99.990483 3154 1 0.000005 0.000047 99.999176 99.990530 3163 2 0.000011 0.000094 99.999186 99.990624 3260 1 0.000005 0.000049 99.999192 99.990673 3355 1 0.000005 0.000050 99.999197 99.990723 3356 1 0.000005 0.000050 99.999202 99.990773 3373 1 0.000005 0.000050 99.999208 99.990823 3430 1 0.000005 0.000051 99.999213 99.990874 3469 2 0.000011 0.000103 99.999223 99.990978 3590 1 0.000005 0.000054 99.999229 99.991031 3656 1 0.000005 0.000054 99.999234 99.991086 3744 1 0.000005 0.000056 99.999239 99.991142 3786 2 0.000011 0.000113 99.999250 99.991254 3823 1 0.000005 0.000057 99.999255 99.991311 3882 1 0.000005 0.000058 99.999260 99.991369 3920 2 0.000011 0.000117 99.999271 99.991486 3929 6 0.000032 0.000351 99.999303 99.991837 3953 1 0.000005 0.000059 99.999308 99.991896 4020 1 0.000005 0.000060 99.999313 99.991956 4040 4 0.000021 0.000241 99.999334 99.992197 4050 2 0.000011 0.000121 99.999345 99.992318 4056 40 0.000211 0.002418 99.999556 99.994736 4109 2 0.000011 0.000122 99.999567 99.994858 4124 25 0.000132 0.001537 99.999699 99.996395 4136 34 0.000180 0.002096 99.999878 99.998491 4176 1 0.000005 0.000062 99.999884 99.998553 4191 1 0.000005 0.000062 99.999889 99.998616 4247 1 0.000005 0.000063 99.999894 99.998679 4352 20 0.000106 0.001297 100.000000 99.999976 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 10:14:19 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA20805 for ipng-dist; Tue, 18 Nov 1997 10:11:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA20798 for ; Tue, 18 Nov 1997 10:11:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA12845 for ; Tue, 18 Nov 1997 10:11:04 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA10518 for ; Tue, 18 Nov 1997 10:10:50 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA11883; Tue, 18 Nov 1997 10:09:03 -0800 Message-Id: <3.0.3.32.19971118100833.009e2a40@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 18 Nov 1997 10:08:33 -0800 To: Jeffrey Burgan From: Bob Hinden Subject: (IPng 4872) Request to Advance "Transmission of IPv6 Packets over Token Ring Networks" Cc: narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : T. Narten, M. Crawford, S. Thomas Filename : draft-ietf-ipngwg-trans-tokenring-04.txt Pages : 10 Date : 06-Nov-97 A working group last call for this document was completed on November 17, 1997. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 14:54:52 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA21413 for ipng-dist; Tue, 18 Nov 1997 14:51:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA21406 for ; Tue, 18 Nov 1997 14:51:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA05508 for ; Tue, 18 Nov 1997 14:51:47 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA06915 for ; Tue, 18 Nov 1997 14:51:40 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA24548; Tue, 18 Nov 1997 14:50:29 -0800 Message-Id: <3.0.3.32.19971118145002.00811750@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 18 Nov 1997 14:50:02 -0800 To: Jeffrey Burgan From: Bob Hinden Subject: (IPng 4874) Request to Advance "IP Version 6 over PPP" Cc: narten@raleigh.ibm.com, scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@eng.sun.com Precedence: bulk Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-03.txt Pages : 14 Date : 17-Nov-97 This document replaces RFC 2023 "IP Version 6 over PPP"'. This RFC will become historic. A working group last call for this document was completed on August 13, 1997 and the document was discussed at the Munich IETF IPng session. This draft incorporates changes based on comments received during the w.g. last call and IPng session discussion. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 15:10:48 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA21466 for ipng-dist; Tue, 18 Nov 1997 15:07:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA21458 for ; Tue, 18 Nov 1997 15:06:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA10878 for ; Tue, 18 Nov 1997 15:06:55 -0800 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA14674 for ; Tue, 18 Nov 1997 15:06:44 -0800 (PST) Received: by mail4.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Tue, 18 Nov 1997 14:56:17 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810D02218@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Thomas Narten'" , ipng@sunroof.eng.sun.com Cc: nordmark@Eng, John Gilmore Subject: (IPng 4875) RE: RAs with 0 lifetime prefix (take II) Date: Tue, 18 Nov 1997 14:33:30 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@eng.sun.com Precedence: bulk > What do others think? Should we go with Erik's suggestion, Choice 3) > above, or something completely different? > [Richard Draves] I vote for choice 3). I think Erik's suggestion should be an implementation choice. As far as I can see, it doesn't affect interoperability, so why not allow implementations to take different stances on how address expiration affects upper layers. As long as the implementation doesn't externally send packets with bad source addresses, it shouldn't matter if they are being black-holed within the implementation or not. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 15:35:53 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA21527 for ipng-dist; Tue, 18 Nov 1997 15:29:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA21520 for ; Tue, 18 Nov 1997 15:29:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA17628 for ; Tue, 18 Nov 1997 15:28:55 -0800 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA25239 for ; Tue, 18 Nov 1997 15:28:48 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA17285; Tue, 18 Nov 97 15:26:46 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA04748; Tue, 18 Nov 1997 15:29:30 -0800 Date: Tue, 18 Nov 1997 15:29:30 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199711182329.PAA04748@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4876) Re: RAs with 0 lifetime prefix (take II) X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > > > What do others think? Should we go with Erik's suggestion, Choice 3) > > above, or something completely different? > > > [Richard Draves] I vote for choice 3). > > I think Erik's suggestion should be an implementation choice. As far > as I can see, it doesn't affect interoperability, so why not allow > implementations to take different stances on how address expiration affects > upper layers. As long as the implementation doesn't externally send packets > with bad source addresses, it shouldn't matter if they are being black-holed > within the implementation or not. > I have been meaning to suggest this compromise. This would be acceptable to me. If customers care they will let us know. If they don't care then each implementor can do as they please based on the trade-offs of their own implementation. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 15:39:13 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA21548 for ipng-dist; Tue, 18 Nov 1997 15:36:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA21538 for ; Tue, 18 Nov 1997 15:35:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA19388 for ; Tue, 18 Nov 1997 15:35:23 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA28171 for ; Tue, 18 Nov 1997 15:35:00 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA25506; Tue, 18 Nov 1997 17:34:11 -0600 Message-Id: <199711182334.RAA25506@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4877) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-reply-to: Your message of Wed, 12 Nov 1997 09:33:58 EST. <199711121433.JAA18578@ietf.org> Date: Tue, 18 Nov 1997 17:34:11 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a few comments based on very careful reading of draft-ietf-ipngwg-aaaa-00.txt. First of all, to use the same name ("AAAA") and code point (28) for this new record type will be disasterous to the 6bone and all other IPv6 deployment to date. But I expect the authors know that. For the rest of this message I'm going to call the proposed new record an ASP (address suffix & pointer). The mentions of "possibly compressed" domain names is incorrect, since names in class-specific RDATA must not be compressed [RFC1035 4.1.4]. Does the additional processing for an ASP query include all ASP records in a chain leading to a record with prefix length = 0? I'm assuming that the intent is to indirect through records held by one's ISP, which in turn indirect to records held by the organization that manages a TLA, possibly with another layer or two of ISP in the middle. (If you don't do this indirection but instead reference only other records within your own administrative control, then the complexity has bought you only functions that could have been achieved by running your zone files through a macro pre-processor.) For example, I'm imagining that a system's address might be determined by a string of ASP records (in various zones) like the following, gungnir.fnal.gov. ASP 64 0a00:20ff:fe81:2b32 cd.subnet.fnal.gov. cd.subnet.fnal.gov. ASP 48 0009:0:0:0:0 fnal.net.es.net. fnal.net.es.net. ASP 32 0040:0:0:0:0:0 esnet.net.fnc.gov. esnet.net.fnc.gov. ASP 0 3005:1234:0:0:0:0:0:0 (I'm making the simplifying assumption that anything assigned by the TLA administrator doesn't need to be indirected to the TLA's prefix -- that a TLA won't be renumbered; it will be left alone, dissolved, or reassigned to another administrator with its number unchanged.) These records together would be the set necessary to derive one IPv6 address of my system. These records burn up something like 250 bytes or so in a DNS packet. That's quite a bit, but no big problem until we consider: Do we include as additional data all the ASP's needed to construct all the addresses of all the hosts named in the response to a TYPE=MX query? There will be a lot of overlap in the ASP records that lead to the addresses of various exchangers for a single domain name, but still I think we're going to bust the UDP packet limit more often than not. Four different SIG records by three different signers will be quite costly to verify and will take up around 800 bytes, typcially. (Over 800 bytes EACH, worst case, but I'm try to look at the average case!) If you posit a solution to the DNS packet length problem, you're still looking at a lot of cycles spent fetching all those KEYs and checking all those SIGs! I suggest a change. Let AAAA records be generated semi-dynamically by the owning zone *and signed*, if that zone is secure. By semi-dynamically I don't mean synthesized in response to requests, but rather just before the zone file is loaded (or signed). The generated AAAA's would have their TTLs set to the minimum of the TTLs of the ASP records from which they were generated. They'd have to be checked for validity and possibly regenerated when any of those ASPs expires and is gone from its respecitve zone. If the zone is secure, the signature expiration time of the generated AAAA records would be set to the earliest of the expiration times of all the supporting ASPs. The signing zone is, in effect, vouching for the signatures on all the ASPs the contribute to its IPv6 addresses, but it's relying on those records to be correct in any case, so This automatic generation of AAAA records from ASP records would be a large blister on the side of existing DNS servers, or an extra program invoked before loading (or signing) a zone file -- and possibly periodically thereafter. But at least all this complexity is dropped on the primary server only, and it saves a *lot* of work for the resolvers, which outnumber primary servers by a factor of roughly infinity. I find less to criticize in DBIT records, except for the flaw that no cacheable intermediate results are useful for subsequent lookups of any different address, however nearly equal to the first address. I don't see an obvious solution right away, but it seems like one must exist. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 20:07:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id UAA21816 for ipng-dist; Tue, 18 Nov 1997 20:04:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id UAA21809 for ; Tue, 18 Nov 1997 20:04:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA27859 for ; Tue, 18 Nov 1997 20:04:03 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id UAA00296 for ; Tue, 18 Nov 1997 20:03:39 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA18023; Wed, 19 Nov 1997 15:02:32 +1100 (from kre@munnari.OZ.AU) To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4878) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: "Matt Crawford"'s message of "Tue, 18 Nov 1997 17:34:11 -0600." References: <199711182334.RAA25506@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Nov 1997 15:02:30 +1100 Message-Id: <9095.879912150@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 18 Nov 1997 17:34:11 -0600 From: "Matt Crawford" Message-ID: <199711182334.RAA25506@gungnir.fnal.gov> | The mentions of "possibly compressed" domain names is incorrect, | since names in class-specific RDATA must not be compressed [RFC1035 | 4.1.4]. The question of name compression in the DNS is a current issue. The restriction you mention, while nice in theory, vanished from practical use back in the dark ages (consider MX records...) | Does the additional processing for an ASP query include all ASP | records in a chain leading to a record with prefix length = 0? It could - but we all need to remember that additional section processing is an optimisation, and isn't required. Packet size blowouts certainly aren't an issue there, anything that doesn't fit is omitted. While including all the records in the chain would be nice, if they don't fit, omitting later ones is of little loss, as in many cases those are going to be of "large" address spaces, and the resolver will often have them cached already, from some other lookup. Much the same can be said of signature processing - keys only need be verified once, after that simple comparison will indicate that the same key is being used again, and within its TTL, need not be further verified. Similarly, the signature of any record that has previously been verified as correct need not be verified again. So, while there is undoutably a cost here, I think the scaling properties work well, and the cost is entirely reasonable. As to the work of the resolvers, this is an issue with all DNSSEC processing, I don't think this really makes it notably worse - and is why the TSIG proposal, for allowing the resolvers to use simple authentication with their local servers, the local server does the DNSSEC validation, the resolvers (via TSIG) trust the local servers and don't have to repeat all of that, so while the resolver will end up composing the address from its components, I doubt that in practice many will be doing much dnssec authentication of their own. That is, from the DNS point of view, the resolver is at the local server, and shared by many clients which are each too dumb to do anything significant for themselves (this doesn't affect the DNS model at all, but does mean that the "factor of roughly infinity" doesn't apply to the hard work). | (If you don't do this indirection but instead reference only | other records within your own administrative control, then | the complexity has bought you only functions that could have | been achieved by running your zone files through a macro | pre-processor.) Not entirely - making the records be variable length should often save DNS packet space, and overall traffic loads (so, this isn't much of a saving, but it isn't nothing either). The packet addresses are better fixed length, because of the way they're processed, addresses in DNS packets already lose any benefit they could possibly achieve because of the total lack of any kind of predictable alignment - they may as well be variable length and gain the small saving. | I suggest a change. Let AAAA records be generated semi-dynamically | by the owning zone *and signed*, if that zone is secure. By | semi-dynamically I don't mean synthesized in response to requests, | but rather just before the zone file is loaded (or signed). I have a certain sympathy to this, as there are a lot of things I think that servers could usefully do as they load zone files, to better validate the data they're loading (and fix it where possible). On the other hand, zone load time is a real problem. Further, I'm not sure you've thought through the implications of TTL expiry here, and just how the TTL of the generated records will really be affected by TTL changes of the records from which they were generated. And then there's the issue of just what gets transferred to secondary servers (I presume your signed AAAA records, as I doubt the secondary server could sign them). If that happens, knowledge of how the TTLs were generated must be lost. Beyond that, but still related to secondaries, is zone change validation, especially using IXFR. If the address in one of the higher level records changes, does the serial number on the zones which derive addresses from it all change, and do the servers for those zones all manage to construct IXFR lists for the final address records that need to be reloaded at secondaries? While your scheme seems simple, I suspect that its complexities, and getting them all worked out and correct, will turn out to be far more complex than the proposal as it was written. You will (all) note that I have avoided using the name of these records anywhere here, the issue of usurping the current AAAA name and code, or of inventing a new record type is, I think, one much better discussed in person, with many affected people, than in e-mail (it is just one of those issues that it is easier to get a handle on in a group discussion). | I find less to criticize in DBIT records, except for the flaw that | no cacheable intermediate results are useful for subsequent lookups I believe we'll see a new DBIT proposal, which I think doesn't have that problem, but is even more different, sometime quite soon. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 18 20:40:05 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id UAA21864 for ipng-dist; Tue, 18 Nov 1997 20:37:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id UAA21857 for ; Tue, 18 Nov 1997 20:37:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA03469 for ; Tue, 18 Nov 1997 20:37:28 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA12710 for ; Tue, 18 Nov 1997 20:37:25 -0800 (PST) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA25467 for ; Tue, 18 Nov 1997 20:35:57 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Nov 1997 20:37:05 -0800 To: IPng Working Group From: Steve Deering Subject: (IPng 4879) Re: increasing the IPv6 minimum MTU Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [sorry if this is a duplicate -- I'm getting bounce messages from sunroof.] Most of those who commented on my proposal to raise the IPv6 minimum MTU to 1280 bytes appear to be in favor of the change (including Peter Curran, who was one of the few folks originally opposed) and there is no evidence of a groundswell of opposition to the change, so I will go ahead and make that change to the base IPv6 spec, to be submitted as an ID in the next day or two. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 06:29:39 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA22190 for ipng-dist; Wed, 19 Nov 1997 06:23:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA22183 for ; Wed, 19 Nov 1997 06:22:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA11142 for ; Wed, 19 Nov 1997 06:22:22 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA08232 for ; Wed, 19 Nov 1997 06:21:57 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id JAA12795; Wed, 19 Nov 1997 09:21:55 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id JAA09162; Wed, 19 Nov 1997 09:21:54 -0500 (EST) Date: Wed, 19 Nov 1997 09:21:54 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971119092154.ZM9160@seawind.bellcore.com> In-Reply-To: "Matt Crawford" "(IPng 4877) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt" (Nov 18, 5:34pm) References: <199711182334.RAA25506@gungnir.fnal.gov> X-Mailer: Z-Mail (5.0.0 30July97) To: "Matt Crawford" Subject: (IPng 4880) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Nov 18, 5:34pm, Matt Crawford wrote: > Subject: (IPng 4877) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt > I have a few comments based on very careful reading of > draft-ietf-ipngwg-aaaa-00.txt. > > First of all, to use the same name ("AAAA") and code point (28) for > this new record type will be disasterous to the 6bone and all other > IPv6 deployment to date. But I expect the authors know that. For > the rest of this message I'm going to call the proposed new record an > ASP (address suffix & pointer). Matt, I mulled this for quite some time. My original proposal, back in August, was for an "upward compatible change", which would simply "grow a tail to the existing AAAA records. The new record would then have: 128 bits of address. 8 bits of prefix length, optional, default value being 128. a domain name, only present if the prefix length is lower than 128. That way, the existing AAAA records, which are present in the MBONE, would be readable by all "updated" DNS implementations. This would allow for a gradual update of the 6Bone: 1) first, update the name to address resolvers to recognize the new format. Only deploy the new format in some very limited way, i.e. for a test domain. 2) once the new resolvers have been resolved, allow operators to grow a tail to the AAAA records, whenever they see fit. In fact, a compatible format would allow domain managers to keep using the "old" format for an indefinite length of time. The choice of a pointer format vs. a full listing could be left to the appreciation of the manager. Those who beleive in sound data base organizations would pick the pointer syntax. Robert argued against this strategy, and for the use of a more compressed format, losing the upward compatibility. I think this should be debated in the WG. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 09:23:18 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA22395 for ipng-dist; Wed, 19 Nov 1997 09:20:32 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA22388 for ; Wed, 19 Nov 1997 09:20:23 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA06736 for ; Wed, 19 Nov 1997 09:20:19 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA14098 for ; Wed, 19 Nov 1997 09:20:00 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA24723; Wed, 19 Nov 1997 12:06:10 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA26475; Wed, 19 Nov 1997 12:06:05 -0500 Message-Id: <199711191706.AA26475@wasted.zk3.dec.com> To: huitema@bellcore.com (Christian Huitema) Cc: "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: (IPng 4882) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: Your message of "Wed, 19 Nov 1997 09:21:54 EST." <971119092154.ZM9160@seawind.bellcore.com> Date: Wed, 19 Nov 1997 12:06:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, I think after this mail it should be revisted too. But we have promised renumbering with IPv6 too. So we need to make sure that in fact is the case. I think we need to test an assumption here in the WG. Do we feel its a worthwhile engineering trade-off to consider upwards compatibility with existing AAAA records in defining a DNS-REC that will support dynamic renumbering with our new addressing architecture supporting Aggregators as prefixes down to the EUI 64bit node identifier? Why or Why Not: One benefit of compatibility is that RFC 1886 can move to Draft Standard and this keeps IPv6 moving forward. IMO think this is valid. Another benefit is that the 6bone is deployed world wide and there are 28 implementations at least. This is momentum and a valid test bed of IPv6, we should seriously consider not disrupting the 6bone. Should we start a new mail subject thread for this? If so can you do it? DNS REC Assumptions or some such title. Flushing this out a little on mail before Wash D.C. I think is wise. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 10:35:36 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA22484 for ipng-dist; Wed, 19 Nov 1997 10:30:24 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id KAA22477 for ; Wed, 19 Nov 1997 10:30:19 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id KAA03397 for ; Wed, 19 Nov 1997 10:30:18 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA10104; Wed, 19 Nov 1997 10:30:07 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA22231 for ; Wed, 19 Nov 1997 07:17:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA28604 for ; Wed, 19 Nov 1997 07:17:53 -0800 Received: from ayax.uniandes.edu.co (Ayax.uniandes.edu.co [157.253.50.3]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id HAA05698 for ; Wed, 19 Nov 1997 07:17:35 -0800 (PST) Received: from isis.uniandes.edu.co by ayax.uniandes.edu.co (SMI-8.6/SMI-SVR4) id KAA00011; Wed, 19 Nov 1997 10:37:01 +0500 Date: Wed, 19 Nov 1997 10:10:15 +0500 (GMT) From: Yezid Enrique Donoso Meisel To: ipng@sunroof.eng.sun.com Subject: (IPng 4883) Question about fragmentation end-to-end in IPv6 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 Hi, in this moment i need to know why the fragmentation end-to-end in IPv6 ? Why, the routers cannot fragment the packages IP ? I think that cannot fragment because this procedure congestion the network and because the size of the buffer in the routers ? Is it right or is it wrong ? Thank you very much ******************************************************** *** Ing. Yezid Enrique Donoso Meisel *** *** Magister Ing. de Sistemas y Computacion *** *** E-Mail : y-donoso@isis.uniandes.edu.co *** *** Universidad de los Andes *** *** Bogota, Colombia *** ******************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 11:28:32 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA22604 for ipng-dist; Wed, 19 Nov 1997 11:25:48 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id LAA22597 for ; Wed, 19 Nov 1997 11:25:37 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id LAA12743; Wed, 19 Nov 1997 11:25:34 -0800 (PST) Date: Wed, 19 Nov 1997 11:23:48 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4884) Re: Terminology of Address Translation To: Pyda Srisuresh Cc: George Tsirtsis , roque@cisco.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199711131832.KAA07095@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm catching up on mail. > The draft assumes that > V4 to V6 and vice versa address mapping is outside the scope of > packet/protocol translation and considers the V4-to-V6 packet > translators to be stateless. As pointed out by George below, NAT/PTs > focus on "Protocol translation". Not correct. The draft specifies exactly how the addresses in the IPvx packet is set from the IPvy (x != y) packet in section 4.1 and 5.1. This specification assumes that the IPv6-only node has been assigned an IPv4 compatible address. What the draft explicitely does not specify is how the IPv6-only node can acquire such an address when it needs it. However, there is nothing to prevent anybody from using the header translation rules in the draft and a different (DNS driven? table driven?) mechanism for mapping the addresses. However, that is not the intent of the draft as written. (Doing anything but the specified translation will affect the TCP/UDP pseudo-header checksum, the FTP port/lport command requiring adjusting the TCP sequence numbers, etc, i.e. it will run into much of the same issues as the v4/v4 NAT.) > So, I would like to suggest that term "NAT" or "NATs" be used > strictly in the context on V4-to-V4 address translations and that > V4-to-V6 translation be referred to as "NAT/PT" or some other > appropriate term that reflects its function as distinguished from > NATs. I believe, this will prevent obfuscation of semantics. Thanks. I think we need to distingiush the even further. I think using NAT for misses the point that there is no actual network address translation going on. There is merely adding and removing of fixed 96 bit address prefixes when going between IPv4 and IPv6 which does not require the TCP/UDP checksums to be modified. To the extent a better name would help clarify you can view the header translator as IP (and ICMP) protocol translator Fixed address mapping A NAT box does at least DNS/table driven address translation IP (and ICMP) address translation TCP/UDP pseudo header checksum modification FTP port modification (resulting in TCP sequence number modifications for the remainder of the connection) Thus it might make sense to call the header translator a "stateless IP/ICMP translator" (SIIT). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 11:59:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA22662 for ipng-dist; Wed, 19 Nov 1997 11:56:15 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id LAA22655 for ; Wed, 19 Nov 1997 11:56:05 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id LAA29540 for ; Wed, 19 Nov 1997 11:56:04 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10324; Wed, 19 Nov 1997 11:55:52 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA22642 for ; Wed, 19 Nov 1997 11:52:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA01372 for ; Wed, 19 Nov 1997 11:52:54 -0800 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA15287 for ; Wed, 19 Nov 1997 11:52:44 -0800 (PST) Message-Id: <199711191952.LAA15287@saturn.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA210879090; Wed, 19 Nov 1997 14:51:30 -0500 To: Steve Deering Cc: IPng Working Group Subject: (IPng 4886) Re: increasing the IPv6 minimum MTU In-Reply-To: Your message of "Tue, 18 Nov 1997 20:37:05 EST." Date: Wed, 19 Nov 1997 14:51:29 -0500 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Steve Deering writes: > Most of those who commented on my proposal to raise the IPv6 minimum MTU > to 1280 bytes appear to be in favor of the change (including Peter Curran, > who was one of the few folks originally opposed) and there is no evidence > of a groundswell of opposition to the change, so I will go ahead and make > that change to the base IPv6 spec, to be submitted as an ID in the next day > or two. Though I think there was consensus on raising the MTU, I don't think there was consensus on raising it to 1280. The reason you gave for making it 1280 instead of 1500 was that the extra space would give room for two levels of tunnel encapsulation and encryption. Are most IPv6 packets going to be tunneled? If the answer is "no", then I think 1500 would be a better choice. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 12:38:42 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA22801 for ipng-dist; Wed, 19 Nov 1997 12:34:40 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA22792 for ; Wed, 19 Nov 1997 12:34:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA13885 for ; Wed, 19 Nov 1997 12:34:27 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA08439 for ; Wed, 19 Nov 1997 12:34:23 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA21055; Wed, 19 Nov 1997 12:26:32 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199711191706.AA26475@wasted.zk3.dec.com> References: Your message of "Wed, 19 Nov 1997 09:21:54 EST." <971119092154.ZM9160@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Nov 1997 12:25:42 -0800 To: bound@zk3.dec.com From: Steve Deering Subject: (IPng 4887) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Cc: huitema@bellcore.com (Christian Huitema), "Matt Crawford" , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:06 AM -0800 11/19/97, bound@zk3.dec.com wrote: > But we have promised renumbering with IPv6 too. Jim, Trying to prevent misunderstandings, I'd like to point out that what you say is not strictly true. We've promised to *try* to make renumbering with IPv6 transparent and effortless, but since we don't even know what all the problems are in doing that (it never having been tried before), we can't very well *promise* that we'll solve them all. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 12:58:35 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA22844 for ipng-dist; Wed, 19 Nov 1997 12:50:17 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id MAA22837 for ; Wed, 19 Nov 1997 12:50:07 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id MAA13248; Wed, 19 Nov 1997 12:49:02 -0800 (PST) Date: Wed, 19 Nov 1997 12:47:16 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4888) Re: increasing the IPv6 minimum MTU To: Steve Soule Cc: Steve Deering , IPng Working Group In-Reply-To: "Your message with ID" <199711191952.LAA15287@saturn.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Though I think there was consensus on raising the MTU, I don't think > there was consensus on raising it to 1280. > > The reason you gave for making it 1280 instead of 1500 was that the > extra space would give room for two levels of tunnel encapsulation > and encryption. Are most IPv6 packets going to be tunneled? If the > answer is "no", then I think 1500 would be a better choice. I think 1280 is a reasonable number and it is much better than 1500. Most IPv6 implementations will use path MTU discovery to discover the maximum usable MTU (be it 1500, 4k or 8k) thus the 1280 number only applies to applications and transports where path MTU discovery is not a good idea (such as multicast traffic). Allowing encapsulation of such packets (e.g. for secure VPNs) without forcing the decapsulating router and the end of the VPN to reassemble is very worth while even is a small fraction of the IPv6 packets are actually encapsulated. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 12:59:35 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA22884 for ipng-dist; Wed, 19 Nov 1997 12:56:12 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id MAA22877 for ; Wed, 19 Nov 1997 12:56:05 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id MAA14321 for ; Wed, 19 Nov 1997 12:56:05 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10537; Wed, 19 Nov 1997 12:55:53 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA22847 for ; Wed, 19 Nov 1997 12:51:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA17784 for ; Wed, 19 Nov 1997 12:50:29 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA16396 for ; Wed, 19 Nov 1997 12:50:26 -0800 (PST) Received: from dashub2.das.dec.com (dashub2.das.dec.com [16.136.64.63]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA18768 for ; Wed, 19 Nov 1997 15:38:04 -0500 (EST) Received: by dashub2.das.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35) id <01BCF501.1DDB1240@dashub2.das.dec.com>; Wed, 19 Nov 1997 15:38:00 -0500 Message-ID: From: Ken Powell To: "'Thomas Narten'" Cc: "'ipng@sunroof.Eng.Sun.COM'" , "'nordmark@Eng.Sun.COM'" , "'John Gilmore'" , "'bound@zk3.dec.com'" Subject: (IPng 4890) RE: RAs with 0 lifetime prefix (take II) Date: Wed, 19 Nov 1997 15:37:57 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I still don't like the idea of forcing a network manager to wait hours to back out a mistake. Making option 3 "implementation optional" does not solve the problem. Any implementation that fails to clear an invalid address will cause trouble. What happened to Dimitry Haskin's proposal? Was there a serious problem with it that I missed? >> 1) a host should not lower lifetimes of a priorly >> known prefix as the result of receiving of a >> directed (unicast) RA. >> >> 2) if a host receives a multicast RA with a prefix >> lifetime of less than 10 seconds (or pick another >> reasonable period), it should delay deprecation >> of the prefix for 10 seconds. >> >> 3) if a router receives a multicast RA with a prefix >> that has a lifetime lower than the receiving router >> advertises for this prefix, it should immediately >> send own multicast RA. >> >> 4) a host receiving RAs from multiple routers should >> use a higher lifetime for the same prefix. The idea being that hosts play a passive role. They only delay reaction to a zero lifetime prefix for a short period. This gives routers a chance to identify and reverse the attack without a broadcast storm. A host simply follows the latest update it receives. Given that unsolicited RA's go to the all-nodes multicast address, routers do receive each other's Router Advertisements. There is no need for hosts to notify routers that a questionable advertisement existed. A router could monitor the network for itself. I think Dimitry had a very good start. There was a problem with dropped RAs and RAs storms. I would change Dimitry's proposal to the following to correct this: 1) a host should not lower lifetimes of a priorly known prefix as the result of receiving of a directed (unicast) RA. 2) if a host receives a multicast RA with prefix lifetime of less than 3 * MAX_INITIAL_RTR_ ADVERT_INTERVAL (3 * 16 seconds), it should interpret the lifetime as 3 * MAX_INITIAL_ RTR_ADVERT_INTERVAL. 3) If a router receives a multicast RA with a prefix that has a lifetime lower than the receiving router advertises for this prefix, it should set its interface timer for unsolicited RA transmissions to MAX_INITIAL_RTR_ADVERT_INTERVAL and follow the procedures defined in the ND specification section 6.2.4 for sending the first few advertisements. Section 6.2.4 defines that the router sends its first few RAs at an accelerated rate and with proper randomization on timing. I dropped item 4 from Dimitry's proposal because the spec already requires the right behavior. Hosts use the lifetime from the last applicable advertisement received. Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 15:35:55 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA23326 for ipng-dist; Wed, 19 Nov 1997 15:29:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA23318; Wed, 19 Nov 1997 15:28:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA25475; Wed, 19 Nov 1997 15:28:52 -0800 Received: from snoopy.lucentmmit.com (smtp.Lucentmmit.com [38.160.171.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA05571; Wed, 19 Nov 1997 15:28:41 -0800 (PST) Received: by SNOOPY with Internet Mail Service (5.0.1457.3) id ; Wed, 19 Nov 1997 18:35:41 -0500 Message-ID: From: "Conta, Alex" To: "'owner-ipng@sunroof.Eng.Sun.COM'" , ipng@sunroof.eng.sun.com Subject: (IPng 4891) RE: IP - ATM - Frameraly Date: Wed, 19 Nov 1997 18:35:38 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Torbjorn, IPv6 over PPP has been specified - search for "draft-ietf-ipngwg-*ppp*.txt" - sorry, I do not recall the exact name of the latest version, but the wild card search will do. IPv6 over Frame Relay will be resubmitted in the ION group in a day or two: search for "draft-ietf-ion-ipv6-fr-00.txt". They document alternatives to using ATM in the WAN. Alex --------------- Hi ! Maybe this is sent to wrong address, if so could you forward it to someone you think is proporiate please. I am working in the Telecommunication company in Norway, I am a little bit confused about the transport network for IP. My question is: Are there any other alternatives then to use ATM switches for transporting IPng in a country size network ? Okey, thanks for taking your time, Best regards, Torbjorn email: tsil@hotmail.com ----- End Included Message ----- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 16:22:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA23395 for ipng-dist; Wed, 19 Nov 1997 16:18:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA23388 for ; Wed, 19 Nov 1997 16:18:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA11562 for ; Wed, 19 Nov 1997 16:18:34 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA03412 for ; Wed, 19 Nov 1997 16:18:32 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id AAA00751; Thu, 20 Nov 1997 00:11:09 GMT From: "Peter Curran" To: "Steve Deering" , "Steve Soule" Cc: "IPng Working Group" Subject: (IPng 4892) Re: increasing the IPv6 minimum MTU Date: Thu, 20 Nov 1997 00:25:42 -0000 Message-ID: <01bcf54a$d5c2cdf0$0f0120c1@desktop.ticl.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve >In message , Steve Deering writes: >> Most of those who commented on my proposal to raise the IPv6 minimum MTU >> to 1280 bytes appear to be in favor of the change (including Peter Curran, >> who was one of the few folks originally opposed) and there is no evidence >> of a groundswell of opposition to the change, so I will go ahead and make >> that change to the base IPv6 spec, to be submitted as an ID in the next day >> or two. > >Though I think there was consensus on raising the MTU, I don't think >there was consensus on raising it to 1280. > >The reason you gave for making it 1280 instead of 1500 was that the >extra space would give room for two levels of tunnel encapsulation >and encryption. Are most IPv6 packets going to be tunneled? If the >answer is "no", then I think 1500 would be a better choice. > If we use a min MTU of 1500 then I would have to raise my 'objection' flag again, for the same reason as last time. I am happy to accept that we can make an assumption that virtually all Internet paths are, or could be made to be, 1500 bytes. If you set the min MTU to 1500 then every packet tunneled via the transition strategy would have to be fragmented - a hell of a hit on the v4 routers. Also, the explanation offered by Steve Deering for the 1280 value makes a lot of sense, given the likely use of ESP and end-to-end v6-in-v6 tunnels for things like mobile IP. Besides, if everybody uses PMTU discovery then it only really effects the multicast traffic as a correct MTU will be determined in most cases. Cheers Peter Curran -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 16:37:01 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA23435 for ipng-dist; Wed, 19 Nov 1997 16:34:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA23428 for ; Wed, 19 Nov 1997 16:33:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA15980 for ; Wed, 19 Nov 1997 16:33:55 -0800 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA11054 for ; Wed, 19 Nov 1997 16:33:55 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by trix.cisco.com (8.6.12/8.6.5) with ESMTP id QAA13076; Wed, 19 Nov 1997 16:33:53 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA21962; Wed, 19 Nov 1997 16:33:53 -0800 (PST) Date: Wed, 19 Nov 1997 16:33:53 -0800 (PST) Message-Id: <199711200033.QAA21962@pedrom-ultra.cisco.com> From: Pedro Marques To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4893) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: <199711182334.RAA25506@gungnir.fnal.gov> References: <199711121433.JAA18578@ietf.org> <199711182334.RAA25506@gungnir.fnal.gov> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Matt" == Matt Crawford writes: Matt> I suggest a change. Let AAAA records be generated Matt> semi-dynamically by the owning zone *and signed*, if that Matt> zone is secure. By semi-dynamically I don't mean Matt> synthesized in response to requests, but rather just before Matt> the zone file is loaded (or signed). The generated AAAA's Matt> would have their TTLs set to the minimum of the TTLs of the Matt> ASP records from which they were generated. They'd have to Matt> be checked for validity and possibly regenerated when any of Matt> those ASPs expires and is gone from its respecitve zone. If Matt> the zone is secure, the signature expiration time of the Matt> generated AAAA records would be set to the earliest of the Matt> expiration times of all the supporting ASPs. Just to support Matt's comment... I personally think it is a mistake to tie the actual information (quad-A record needed by the client) with the way the information is generated. I've been looking through the draft and there seems to be no justification on why the authors propose to change the current quad-A record (which can be easily interpreted by clients) to this new scheme. It is the IETF job to define what gets sent on the wire between DNS servers and clients. It isn't, imho, the ietfs job to define how DNS server implementations should generate the information itself (which seems to be the goal here). I think it is painly obvious for everyone that it isn't pratical for the user to type in the prefix a thousand times in a config file or that forward (A & quad-A) and reverse (PTR) records should be generated simultaneously from the user input but those issues are, imho, completly outside the scope of this WG. I hope the current AAAA record specification is left unchanged... it works. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 16:52:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA23479 for ipng-dist; Wed, 19 Nov 1997 16:49:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA23472 for ; Wed, 19 Nov 1997 16:49:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA21089 for ; Wed, 19 Nov 1997 16:48:59 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA10348 for ; Wed, 19 Nov 1997 13:36:09 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA27397; Wed, 19 Nov 1997 13:36:02 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199711191952.LAA15287@saturn.sun.com> References: Your message of "Tue, 18 Nov 1997 20:37:05 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Nov 1997 13:35:12 -0800 To: Steve Soule From: Steve Deering Subject: (IPng 4894) Re: increasing the IPv6 minimum MTU Cc: IPng Working Group Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:51 AM -0800 11/19/97, Steve Soule wrote: > Though I think there was consensus on raising the MTU, I don't think > there was consensus on raising it to 1280. In the discussion in Munich, I proposed a minimum MTU of "about 1300", and that's the proposal on which a show-of-hands was taken. In my email describing the proposal last week, I got more concrete and suggested 1280 specifically, which I think you will agree is "about 1300", and until your message no one had opposed either "about 1300" or "exactly 1280". I interpreted the lack of opposition as assent, though the reason for posting my conclusion was to flush out any latent opposition that had not yet surfaced. So thanks for your message. > The reason you gave for making it 1280 instead of 1500 was that the > extra space would give room for two levels of tunnel encapsulation > and encryption. Are most IPv6 packets going to be tunneled? If the > answer is "no", then I think 1500 would be a better choice. I don't know if *most* packets are going to be tunneled, but I predict, based on the growing use of tunneling in the IPv4 world, that *many* packets will be tunneled, whether for security, mobility, traffic engineering, virtual- private-networking, feature-transition, or some combination of those reasons. I also predict that many tunnels will traverse paths whose physical MTU is 1500, given the current and likely future ubiquity of (10M, 100M, 1G,...) Ethernet. By choosing a minimum MTU that allows room for tunneling headers on 1500-byte-MTU links, we reduce the probablity that IP-level fragmentation will have to be performed between tunnel entry point and tunnel exit point. I won't bother repeating the arguments here as to why minimizing the use of multi-hop fragmentation at layers below the retransmission layer (typically, that's the transport layer) is very desirable. Note that IPv6 sources are still expected to use Path MTU Discovery and, on 1500-byte-MTU paths where no tunnels are being used, to send IPv6 packets up to 1500 bytes long. And for that traffic for which PMTU Discovery doesn't work well, such as multicast video or DNS responses, the relatively small delta in bandwidth efficiency that would be achieved with 1500 byte, rather than 1280 byte, packets does not, in my opinion, balance the potential harmful effects of forcing fragmentation over many (most?) tunnels. But that's just my opinion. If others on this mailing list think 1500 would be a better choice than 1280, please speak up now, and explain why. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 17:03:34 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA23511 for ipng-dist; Wed, 19 Nov 1997 16:59:43 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA23504 for ; Wed, 19 Nov 1997 16:59:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA24582; Wed, 19 Nov 1997 16:59:25 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA24406; Wed, 19 Nov 1997 14:03:36 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA28147; Wed, 19 Nov 1997 15:52:26 -0600 Message-Id: <199711192152.PAA28147@gungnir.fnal.gov> To: Ken Powell Cc: "'Thomas Narten'" , "'ipng@sunroof.Eng.Sun.COM'" , "'nordmark@Eng.Sun.COM'" , "'John Gilmore'" , "'bound@zk3.dec.com'" From: "Matt Crawford" Subject: (IPng 4896) Re: RAs with 0 lifetime prefix (take II) In-reply-to: Your message of Wed, 19 Nov 1997 15:37:57 EST. Date: Wed, 19 Nov 1997 15:52:26 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I still don't like the idea of forcing a network > manager to wait hours to back out a mistake. Making > option 3 "implementation optional" does not solve > the problem. Any implementation that fails to clear > an invalid address will cause trouble. How about keeping a two hour floor for sudden decreases of the valid timer, but putting a much lower floor under the preferred timer? Say, five or ten minutes? Then the interval during which hosts might attempt to initiate a connection from an "oops" address will be short. If all the addresses of a node become deprecated due to a DOS attack, addrconf still permits those addresses to be used. The language is: New communication (e.g., the opening of a new TCP connection) should use a preferred address when possible. > 1) a host should not lower lifetimes of a priorly > known prefix as the result of receiving of a > directed (unicast) RA. Be careful. If I'm in a bad mood, I can wrap a multicast IPv6 packet in a unicast MAC header and send it to you. Then what is it, unicast or multicast? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 17:03:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA23502 for ipng-dist; Wed, 19 Nov 1997 16:59:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA23495 for ; Wed, 19 Nov 1997 16:59:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA24493 for ; Wed, 19 Nov 1997 16:59:07 -0800 Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA23256 for ; Wed, 19 Nov 1997 16:59:06 -0800 (PST) Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id QAA27545; Wed, 19 Nov 1997 16:59:00 -0800 (PST) X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <199711170530.VAA03819@owl.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Nov 1997 15:36:38 -0800 To: Sally Floyd From: Fred Baker Subject: (IPng 4895) Re: Internet Draft on Explicit Congestion Notification (ECN) Cc: ipng@sunroof.eng.sun.com, kkrama@research.att.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sally, is there perhaps a simpler approach? First, it seems to me that if the transport is ignoring something, there is no reason either to set or not set it - whatever one does will have the same effect. So it makes no sense to me to have an ECN-capable bit in IP6, only an ECN bit. Second, I wonder if the feedback loop can be shortened. It seems to me that TCP never sends more than it has credit to send, and so a simple way that the receiver can control the sender's rate is to reduce its window. OK, suppose that we do this: The router works much as you describe - it does the RED game, and sets ECN flags on some subset of the traffic that crosses it. The sender works as it works today - slow start and all. When the receiver gets a message with ECN set, it notes a desire on the part of the network to reduce its window. It therefore notes the current sequence number it is acknowledging and the credit it is currently granting, and calculates from that the sequence number of the start of the next window. It also notes that there is a desire to reduce the window. It wants to not renege on its offered grant, so in each subsequent Acknowledge it offers a credit grant calculated to hold the next window sequence number constant. This credit grant is obviously being reduced by the segment size in each successive acknowledge. This continues until the credit becomes half the value it formerly had. The TCP now grants this halved credit in each Ack until the first octet of the next window is received. At this point, the "I need to reduce my window" flag is cleared. With said flag cleared, we now have two options - during the next (halved) window, either at least one ECN flag is received or none is received. If ECN is again received, we repeat the procedure, avoiding the renege by scaling down the grant and quartering the original window. This obviously can be repeated log2(window) times. If ECN is not received during this window, we increase the credit grant in the next by one MSS. The only system that needs to be aware of ECN is the congested router and the receiving TCP, and the control behavior is essentially the same modulo the mechanism used to achieve it. I think that shortens the control loop, and it avoids a couple of flags and a negotiation. Thoughts? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Opportunity doesn't knock anymore; now it emails -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 17:48:45 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id RAA23556 for ipng-dist; Wed, 19 Nov 1997 17:46:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id RAA23549 for ; Wed, 19 Nov 1997 17:46:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA06411 for ; Wed, 19 Nov 1997 17:45:56 -0800 Received: from owl.ee.lbl.gov (owl.ee.lbl.gov [131.243.1.50]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id RAA13333 for ; Wed, 19 Nov 1997 17:45:58 -0800 (PST) Received: by owl.ee.lbl.gov (8.8.8/8.8.5) id RAA05909; Wed, 19 Nov 1997 17:45:57 -0800 (PST) Message-Id: <199711200145.RAA05909@owl.ee.lbl.gov> To: ipng@sunroof.eng.sun.com cc: bound@zk3.dec.com, kkrama@research.att.com Subject: (IPng 4897) ECN - one bit or two? Date: Wed, 19 Nov 1997 17:45:56 PST From: Sally Floyd Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim - >The only issue is >that you say you can do it with one bit but its easier to explain with >two bits. I don't mind using up two bits if it will make the >implementation and execution clearer and better, but not just for >clarity of explaining the behavior. Fair enough. (My original assumption had been that this one-bit or two-bit discussion would happen on end2end-interest, but it seems that the people who most want to have this discussion are on ipng, so I will try to have this discussion there. Clearly any detailed discussion about allocating bits for ECN in IPv6 should happen on this list, and any detailed discussion about allocating bits for ECN in IPv4 would happen on the int-serv list, and detailed discussions about adding ECN to TCP will happen on either tcplw or tcp-impl. I am hoping that more general research discussions related to ECN will happen on end2end-interest.) THE TWO-BIT APPROACH: The recent internet draft submitted by KK and myself discusses a two-bit approach to ECN: an ECN-Capable bit set by the sender, indicating to the router that the session is ECN-capable: and an ECN bit set by the router to indicate congestion to the receiver. THE ONE-BIT APPROACH: Section 9.2 of the 1994 ECN paper discusses a one-bit approach as well, where the ECN-Capable bit and the ECN bit are overloaded in a single bit. This single bit would have two values: one value to indicate "ECN-Capable", and the other value to indicate "either not ECN-Capable, or Congestion Notification". My own opinion is that that the two-bit approach is preferable to the one-bit approach, for reasons discussed below, and that the one-bit approach is preferable to no ECN at all. WHY THE ECN-CAPABLE INDICATION IS NEEDED: The need for both bits is motivated by the fact that ECN will be deployed incrementally in an Internet where some transport protocols understand ECN and some do not. With the ECN-capable bit, the router can drop packets from flows that are not ECN-capable, but can **instead** set the ECN bit in flows that **are** ECN-capable. Because ECN means that an end node can have the ECN bit set in packets instead of having the packet dropped, an end node might have some incentive to deploy ECN. A flow that advertised itself as ECN-Capable but does not respond to ECN bits is functionally equivalent to a flow that turns off congestion control; this is discussed in Section 8 of the ECN internet draft. If there is no ECN-Capable indication, and the router simply sets the ECN bit whether or not the transport protocol is ECN-Capable, then there is no incentive for end-nodes to deploy ECN, and no viable path of incremental deployment from a non-ECN world to an ECN-capable world. Consider the first stages of such an incremental deployment, where a subset of the TCP flows have end-node pairs that understand ECN. Then when there is mild congestion, the routers will only set ECN bits, rather than dropping packets. However, only those flows that are ECN-capable will respond to those ECN bits. The result is that the ECN-capable flows will back off, and the non-ECN-capable flows will be unaware of the ECN signals and will continue to open their congestion windows. In this case, there are two possible outcomes: (1) the ECN-capable flows back off, the non-ECN-capable flows get all of the bandwidth, and congestion remains mild, or (2) the ECN-capable flows back off, the non-ECN-capable flows don't, and congestion increases until the router transitions from setting the ECN bit to dropping packets. While this evens out the fairness, this means that the ECN-capable flows get no benefit from being ECN-capable, because the router has no choice but to resort to packet-dropping instead. In this world when a subset of the flows are ECN-capable, but where ECN-capable flows have no mechanism for indicating that fact to the routers, there would be less effective and less fair congestion control in the Internet, and a strong incentive for end nodes not to deploy ECN. ASSUMING THAT THE ECN-CAPABLE INDICATION IS NEEDED, THE RELATIVE ADVANTAGES OF ONE AND TWO BITS: Functionally, the one-bit approach and the two-bit approach are similar. The one-bit approach has the functional limitation that if one router sets the ECN bit in a packet that is "ECN-Capable", so that the ECN bit now represents "either not ECN-Capable, or Congestion Notification", then a second router has to assume that that packet is not ECN-Capable, and has to drop that packet if it also wants to indicate congestion to the end nodes. This seems to me like a rather minor limitation. A critical issue in the implementation of ECN is that by default, the IP header should indicate that the packet is **not** ECN-capable. (If the IP header indicates that a packet is ECN-capable while the underlying transport protocol ignores the ECN bit in received packets, this is roughly equivalent to the transport protocol "turning off" congestion control. Not acceptable behavior.) So in the two-bit approach, the requirement is that by default, the ECN-Capable bit be in the "off" position, or set to "0". This seems relatively clear and straightforward, and not likely to get mixed up, and the router should never change the value of the ECN-Capable bit in any case. In the one-bit approach, the requirement is that by default, the ECN bit be in the "either not ECN-Capable, or Congestion Notification" position. Less clear, robust, and straightforward. I assumed that it was not a show-stopper... A second issue lies in the danger that the receiver will misinterpret the received ECN signal. In the two-bit approach, an ECN-capable receiver has to respond if it receives a packet with both the ECN-Capable and the ECN bits set. This is clear. In the one-bit approach, ECN should only be used when the receiver knows in advance that the sender is sending all of its packets with the ECN bit set to "ECN-Capable". In this case, if the receiver receives a packet with the ECN bit set to "either not ECN-Capable, or Congestion Notification", then the receiver knows to interpret that as "Congestion Notification", and to respond appropriately. While this is not a problem if all ECN-capable transport protocols are implemented carefully and correctly, it is clearly less robust than the two-bit approach. In addition, the one-bit approach does not allow the sender to selectively set the ECN-Capable bit on some packets but not others, because the receiver has no way to distinguish between a packet that was sent as "not ECN-Capable", and a packet whose ECN bit was set by the router to "Congestion Notification". CONCLUSION: My conclusion would be that the two-bit approach is more robust than the one-bit approach. As far as I know, there is consensus that the two-bit approach is viable; I don't know that there is rough consensus that the one-bit approach is viable. - Sally I am putting a copy of this note on the newly-created ECN web page at: http://www-nrg.ee.lbl.gov/floyd/ecn.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 18:13:42 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id SAA23578 for ipng-dist; Wed, 19 Nov 1997 18:11:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA23571 for ; Wed, 19 Nov 1997 18:10:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA11495 for ; Wed, 19 Nov 1997 18:10:53 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA23452 for ; Wed, 19 Nov 1997 18:10:54 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id UAA28618; Wed, 19 Nov 1997 20:10:02 -0600 Message-Id: <199711200210.UAA28618@gungnir.fnal.gov> To: Fred Baker Cc: Sally Floyd , ipng@sunroof.eng.sun.com, kkrama@research.att.com From: "Matt Crawford" Subject: (IPng 4898) Re: Internet Draft on Explicit Congestion Notification (ECN) In-reply-to: Your message of Wed, 19 Nov 1997 15:36:38 PST. Date: Wed, 19 Nov 1997 20:10:02 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > First, it seems to me that if the transport is ignoring something, there is > no reason either to set or not set it - whatever one does will have the > same effect. So it makes no sense to me to have an ECN-capable bit in IP6, > only an ECN bit. But the router has another signal it could send instead of setting the ECN bit: dropping the packet. If the more efficient signal will be understood, that's what should be sent. But when in doubt, hit with the big stick. > Second, I wonder if the feedback loop can be shortened. It seems to me that > TCP never sends more than it has credit to send, and so a simple way that > the receiver can control the sender's rate is to reduce its window. > > OK, suppose that we do this: [...] I don't see how that shortens the feedback loop at all. The sender gets no different view in the congested and uncongested conditions until an ACK comes back from the receiver. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 21:10:55 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id VAA23663 for ipng-dist; Wed, 19 Nov 1997 21:08:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id VAA23656 for ; Wed, 19 Nov 1997 21:08:00 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA03789 for ; Wed, 19 Nov 1997 21:07:59 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id UAA00143 for ; Wed, 19 Nov 1997 20:06:33 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA00424; Wed, 19 Nov 1997 22:57:28 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30515; Wed, 19 Nov 1997 22:57:23 -0500 Message-Id: <199711200357.AA30515@wasted.zk3.dec.com> To: Steve Deering Cc: bound@zk3.dec.com, huitema@bellcore.com (Christian Huitema), "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: (IPng 4899) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: Your message of "Wed, 19 Nov 1997 12:25:42 PST." Date: Wed, 19 Nov 1997 22:57:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >At 9:06 AM -0800 11/19/97, bound@zk3.dec.com wrote: >> But we have promised renumbering with IPv6 too. >Trying to prevent misunderstandings, I'd like to point out that what you say >is not strictly true. We've promised to *try* to make renumbering with >IPv6 transparent and effortless, but since we don't even know what all the >problems are in doing that (it never having been tried before), we can't >very well *promise* that we'll solve them all. Good correction. I agree. But it *is* already better than IPv4 can do with what we have done and have implemented so far. So our batting average thus far is very reputable, and I feel good about it anyway. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 21:25:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id VAA23719 for ipng-dist; Wed, 19 Nov 1997 21:21:44 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id VAA23712 for ; Wed, 19 Nov 1997 21:21:36 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA08502 for ; Wed, 19 Nov 1997 21:21:34 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id TAA17166 for ; Wed, 19 Nov 1997 19:20:09 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA17343 for ; Wed, 19 Nov 1997 22:15:19 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA29686; Wed, 19 Nov 1997 22:15:18 -0500 Message-Id: <199711200315.AA29686@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4900) IPv6 Tunnel Spec Date: Wed, 19 Nov 1997 22:15:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex or Steve, What is the status of: draft-ietf-ipngwg-ipv6-tunnel-07.txt ???? I think this work is becoming more needed and obvious as we deploy IPv6 to Early Adopters. They want to tunnel IPv4 now in IPv6. This will also potentially be needed for both NAT and NNAT in NGTRANS WG too. I know we were waiting on the IESG for tunneling. I think it should move to Proposed Standard or know why not? Note that RFC 1933 and 2185 do not address IPv6 tunnels and your work is all we got as a guideline to implement and get started here. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 19 22:06:39 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id WAA23788 for ipng-dist; Wed, 19 Nov 1997 22:03:57 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id WAA23781 for ; Wed, 19 Nov 1997 22:03:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA17216 for ; Wed, 19 Nov 1997 22:03:47 -0800 Received: from poptart.corp.home.net (poptart.svr.home.net [24.0.26.24]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA05807 for ; Wed, 19 Nov 1997 22:03:48 -0800 (PST) Received: from burgan-lap.eos.home.net (burgan-ppp.corp.home.net [24.0.25.244]) by poptart.corp.home.net (Netscape Mail Server v2.02) with SMTP id AAA25102; Wed, 19 Nov 1997 22:02:59 -0800 Message-Id: <3.0.32.19971119220337.00dc7d08@poptart.corp.home.net> X-Sender: burgan@poptart.corp.home.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 19 Nov 1997 22:03:43 -0800 To: bound@zk3.dec.com From: burgan@corp.home.net (Jeffrey Burgan) Subject: (IPng 4901) Re: IPv6 Tunnel Spec Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >What is the status of: > >draft-ietf-ipngwg-ipv6-tunnel-07.txt > >???? > >I think this work is becoming more needed and obvious as we deploy IPv6 >to Early Adopters. They want to tunnel IPv4 now in IPv6. This will >also potentially be needed for both NAT and NNAT in NGTRANS WG too. > >I know we were waiting on the IESG for tunneling. I think it should >move to Proposed Standard or know why not? Is was but is not anymore. It is before the IESG at this very moment and is being balloted now. Jeff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 07:24:57 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA24089 for ipng-dist; Thu, 20 Nov 1997 07:21:50 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA24082 for ; Thu, 20 Nov 1997 07:21:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA20476 for ; Thu, 20 Nov 1997 07:21:38 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA24362 for ; Thu, 20 Nov 1997 07:21:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA23173; Thu, 20 Nov 1997 10:21:32 -0500 (EST) Message-Id: <199711201521.KAA23173@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 4903) I-D ACTION:draft-ietf-ipngwg-trans-ethernet-04.txt Date: Thu, 20 Nov 1997 10:21:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-ethernet-04.txt Pages : 7 Date : 19-Nov-97 This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. This document replaces RFC 1972, ''A Method for the Transmission of IPv6 Packets over Ethernet Networks'', which will become historic. 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-trans-ethernet-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-ethernet-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971119134028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-ethernet-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971119134028.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 07:26:41 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA24098 for ipng-dist; Thu, 20 Nov 1997 07:23:46 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA24091 for ; Thu, 20 Nov 1997 07:23:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA20964 for ; Thu, 20 Nov 1997 07:23:27 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA25063 for ; Thu, 20 Nov 1997 07:23:27 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA23217; Thu, 20 Nov 1997 10:23:22 -0500 (EST) Message-Id: <199711201523.KAA23217@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 4904) I-D ACTION:draft-ietf-ipngwg-bsd-api-new-00.txt Date: Thu, 20 Nov 1997 10:23:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, W. Stevens, J. Bound, S. Thomson Filename : draft-ietf-ipngwg-bsd-api-new-00.txt Pages : 33 Date : 19-Nov-97 The de facto standard application program interface (API) for TCP/IP applications is the ''sockets'' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [6]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-bsd-api-new-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-api-new-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971119163854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-new-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-new-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971119163854.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 09:48:27 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA24288 for ipng-dist; Thu, 20 Nov 1997 09:44:15 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA24281 for ; Thu, 20 Nov 1997 09:44:09 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA00682 for ; Thu, 20 Nov 1997 09:43:37 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12227; Thu, 20 Nov 1997 09:43:05 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA24064 for ; Thu, 20 Nov 1997 06:49:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA10351 for ; Thu, 20 Nov 1997 06:49:08 -0800 Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id GAA10269 for ; Thu, 20 Nov 1997 06:49:09 -0800 (PST) Date: Thu, 20 Nov 1997 09:49 -0400 From: VOLZ@PROCESS.COM (Bernie Volz) Message-Id: <009BD921FECD9363.2E1B@PROCESS.COM> To: IPNG@sunroof.eng.sun.com Subject: (IPng 4907) Re: Terminology of Address Translation X-VMS-To: IPNG@SUNROOF.ENG.SUN.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro Marques wrote: >To put it in another way: if you wish to connect an IPv6 network to an >IPv4 network put a nat box at the border between the two. Of, if you have some IPv4-only and IPv6-only hosts on a LAN, just put the box on the LAN. Of course, you'll pay a small price of having two packets per packet (since a packet goes to the box for translation and back out to the destination). - Bernie Volz Process Software Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 09:50:08 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA24322 for ipng-dist; Thu, 20 Nov 1997 09:46:25 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA24313 for ; Thu, 20 Nov 1997 09:46:16 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA01226 for ; Thu, 20 Nov 1997 09:46:14 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12263; Thu, 20 Nov 1997 09:46:02 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA24257 for ; Thu, 20 Nov 1997 09:38:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA24171 for ; Thu, 20 Nov 1997 09:38:20 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA12299 for ; Thu, 20 Nov 1997 09:38:06 -0800 Received: from dashub2.das.dec.com (dashub2.das.dec.com [16.136.64.63]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA29187 for ; Thu, 20 Nov 1997 12:08:22 -0500 (EST) Received: by dashub2.das.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35) id <01BCF5AC.F3C18FA0@dashub2.das.dec.com>; Thu, 20 Nov 1997 12:08:03 -0500 Message-ID: From: Ken Powell To: "'Matt Crawford'" Cc: "'Thomas Narten'" , "'ipng@sunroof.Eng.Sun.COM'" , "'nordmark@Eng.Sun.COM'" , "'John Gilmore'" , "'bound@zk3.dec.com'" Subject: (IPng 4908) Re: RAs with 0 lifetime prefix (take II) Date: Thu, 20 Nov 1997 12:08:03 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, >>> I still don't like the idea of forcing a network >>> manager to wait hours to back out a mistake. Making >>> option 3 "implementation optional" does not solve >>> the problem. Any implementation that fails to clear >>> an invalid address will cause trouble. > > How about keeping a two hour floor for sudden decreases of the valid > timer, but putting a much lower floor under the preferred timer? > Say, five or ten minutes? Then the interval during which hosts might > attempt to initiate a connection from an "oops" address will be short. Yes, this solves my concern. >>> 1) a host should not lower lifetimes of a priorly >>> known prefix as the result of receiving of a >>> directed (unicast) RA. > > Be careful. If I'm in a bad mood, I can wrap a multicast IPv6 packet > in a unicast MAC header and send it to you. Then what is it, unicast > or multicast? Good point, I see the danger now. Thanks. Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 09:51:18 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA24336 for ipng-dist; Thu, 20 Nov 1997 09:47:20 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA24329 for ; Thu, 20 Nov 1997 09:47:09 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA01452 for ; Thu, 20 Nov 1997 09:47:07 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12290; Thu, 20 Nov 1997 09:46:55 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA24257 for ; Thu, 20 Nov 1997 09:38:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA24171 for ; Thu, 20 Nov 1997 09:38:20 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA12299 for ; Thu, 20 Nov 1997 09:38:06 -0800 Received: from dashub2.das.dec.com (dashub2.das.dec.com [16.136.64.63]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA29187 for ; Thu, 20 Nov 1997 12:08:22 -0500 (EST) Received: by dashub2.das.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35) id <01BCF5AC.F3C18FA0@dashub2.das.dec.com>; Thu, 20 Nov 1997 12:08:03 -0500 Message-ID: From: Ken Powell To: "'Matt Crawford'" Cc: "'Thomas Narten'" , "'ipng@sunroof.Eng.Sun.COM'" , "'nordmark@Eng.Sun.COM'" , "'John Gilmore'" , "'bound@zk3.dec.com'" Subject: (IPng 4909) Re: RAs with 0 lifetime prefix (take II) Date: Thu, 20 Nov 1997 12:08:03 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.35 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, >>> I still don't like the idea of forcing a network >>> manager to wait hours to back out a mistake. Making >>> option 3 "implementation optional" does not solve >>> the problem. Any implementation that fails to clear >>> an invalid address will cause trouble. > > How about keeping a two hour floor for sudden decreases of the valid > timer, but putting a much lower floor under the preferred timer? > Say, five or ten minutes? Then the interval during which hosts might > attempt to initiate a connection from an "oops" address will be short. Yes, this solves my concern. >>> 1) a host should not lower lifetimes of a priorly >>> known prefix as the result of receiving of a >>> directed (unicast) RA. > > Be careful. If I'm in a bad mood, I can wrap a multicast IPv6 packet > in a unicast MAC header and send it to you. Then what is it, unicast > or multicast? Good point, I see the danger now. Thanks. Ken From owner-ipng@sunroof.eng.sun.com Thu Nov 20 09:40:20 1997 Return-Path: Received: from sunroof.eng.sun.com (sunroof [129.146.168.88]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with ESMTP id JAA00328 for ; Thu, 20 Nov 1997 09:40:19 -0800 (PST) From: owner-ipng@sunroof.eng.sun.com Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA24276; Thu, 20 Nov 1997 09:40:19 -0800 (PST) Date: Thu, 20 Nov 1997 09:40:19 -0800 (PST) Message-Id: <199711201740.JAA24276@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from [VOLZ@PROCESS.COM (Bernie Volz)] Content-Length: 1647 X-Lines: 36 Status: RO From owner-ipng Thu Nov 20 09:40:09 1997 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA24269 for ; Thu, 20 Nov 1997 09:40:07 -0800 (PST) Received: from saturn. (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA24872 for ; Thu, 20 Nov 1997 09:39:53 -0800 Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by saturn. (8.8.8/8.8.8) with SMTP id JAA17126 for ; Thu, 20 Nov 1997 09:39:45 -0800 (PST) Date: Thu, 20 Nov 1997 11:36 -0400 From: VOLZ@PROCESS.COM (Bernie Volz) Message-Id: <009BD93108AB9038.2E1B@PROCESS.COM> To: IPNG@sunroof.eng.sun.com Subject: RE: NAT X-VMS-To: IPNG@SUNROOF.ENG.SUN.COM bound@zk3.dec.com wrote: >This is correct. But IPv6 hosts speaking IPv4 is not a problem. None >of us Host vendors will ship any IPv6 products that do not support IPv6. Jim, that isn't the point. It is a question of whether you have to have that IPv4 stack enabled on each and every IPv6 system until such time that there are no more IPv4 systems in the world. If you do, what's the point of going to v6? You still need an IPv4 address, so you haven't gained in the number of systems you can have and you have the additional administrative burden of dual stacks and dual routing domains. Yes, there are probably some complex techniques one could use to dynamically assign IPv4 addresses on an as needed basis, but that still doesn't remove all of the issues. Sorry if we're rehashing old issues. - Bernie Volz Process Software Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 12:09:35 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA24649 for ipng-dist; Thu, 20 Nov 1997 12:06:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA24638 for ; Thu, 20 Nov 1997 12:06:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA14549 for ; Thu, 20 Nov 1997 12:06:32 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA16782 for ; Thu, 20 Nov 1997 12:06:30 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id PAA17737; Thu, 20 Nov 1997 15:06:31 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id PAA10223; Thu, 20 Nov 1997 15:06:30 -0500 (EST) Date: Thu, 20 Nov 1997 15:06:30 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971120150629.ZM10221@seawind.bellcore.com> In-Reply-To: Pedro Marques "(IPng 4893) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt" (Nov 19, 4:33pm) References: <199711121433.JAA18578@ietf.org> <199711182334.RAA25506@gungnir.fnal.gov> <199711200033.QAA21962@pedrom-ultra.cisco.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Pedro Marques , "Matt Crawford" Subject: (IPng 4910) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Nov 19, 4:33pm, Pedro Marques wrote: > Subject: (IPng 4893) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt > >>>>> "Matt" == Matt Crawford writes: > Just to support Matt's comment... > I personally think it is a mistake to tie the actual information (quad-A > record needed by the client) with the way the information is generated. > > I've been looking through the draft and there seems to be no justification > on why the authors propose to change the current quad-A record (which can > be easily interpreted by clients) to this new scheme. The draft just presents the mechanisms, not a justification. I did however present a justification on this list back in August. To put it simply, the two justifications are security and ease of renumbering. With the new proposal, if you renumber a network, you need to update exactly one record in the DNS. Matt's comment is that one could achieve the same result with clever organization of the DNS input files, but this is only true for the primary server. With the "pointer" format, secondaries can be renumbered with an incremental update of exactly one record. With the old format, a complete zone transfer is necessary. Then, you can also consider the effects on caching; because only one record is updated, only that record has to be replaced in all caches. This is very important when considering secure operation of the DNS, where each record is protected by an RSA or El Gamal signature. If you use full records, you must compute new signatures for all the records, while if you use the pointer format you only need to compute one signature. Computing a signature is still a relatively lengthy operation, about 1/10th of a second on a classic platform. So, renumbering a whole network could mean several minutes of computation with the old AAAA approach. Finally, there is a side effect beside security and ease of renumbering, which is the better support of multi-homing. If your network is multihomed to several providers, say 3, each host can have 3 addresses. Suppose that you have 1000 hosts in your network. If you use a pointer format, you will need 1003 records; if you use the current AAAA format, you will need 3000. > I hope the current AAAA record specification is left unchanged... it works. Let's discuss this in DC. I would actually prefer to update the draft proposal to make it upward compatible with the existing practice. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 13:02:21 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA24980 for ipng-dist; Thu, 20 Nov 1997 12:59:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA24973 for ; Thu, 20 Nov 1997 12:59:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA23330 for ; Thu, 20 Nov 1997 12:58:39 -0800 Received: from brownale.cisco.com (brownale.cisco.com [171.69.95.89]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA11777 for ; Thu, 20 Nov 1997 12:58:25 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by brownale.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id MAA23580; Thu, 20 Nov 1997 12:58:19 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA22258; Thu, 20 Nov 1997 12:58:19 -0800 (PST) Date: Thu, 20 Nov 1997 12:58:19 -0800 (PST) Message-Id: <199711202058.MAA22258@pedrom-ultra.cisco.com> From: Pedro Marques To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4911) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: <971120150629.ZM10221@seawind.bellcore.com> References: <199711121433.JAA18578@ietf.org> <199711182334.RAA25506@gungnir.fnal.gov> <199711200033.QAA21962@pedrom-ultra.cisco.com> <971120150629.ZM10221@seawind.bellcore.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Christian" == Christian Huitema writes: Christian> So, renumbering a whole Christian> network could mean several minutes of computation with Christian> the old AAAA approach. Which is perfectly ok. It's also perfectly ok if it takes several hours. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 13:25:46 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA25153 for ipng-dist; Thu, 20 Nov 1997 13:22:30 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA25146 for ; Thu, 20 Nov 1997 13:22:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA24301 for ; Thu, 20 Nov 1997 13:22:18 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA24168 for ; Thu, 20 Nov 1997 13:22:00 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA28808; Fri, 21 Nov 1997 08:15:35 +1100 (from kre@munnari.OZ.AU) To: Pedro Marques Cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com Subject: (IPng 4912) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: Pedro Marques's message of "Thu, 20 Nov 1997 12:58:19 -0800." References: <199711121433.JAA18578@ietf.org> <199711182334.RAA25506@gungnir.fnal.gov> <199711200033.QAA21962@pedrom-ultra.cisco.com> <971120150629.ZM10221@seawind.bellcore.com> <199711202058.MAA22258@pedrom-ultra.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Nov 1997 08:15:29 +1100 Message-Id: <21666.880060529@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Nov 1997 12:58:19 -0800 (PST) From: Pedro Marques Message-ID: <199711202058.MAA22258@pedrom-ultra.cisco.com> | Which is perfectly ok. It's also perfectly ok if it takes several hours. The question is really where is the appropriate place for the work to be done - ideally (ignoring the DNS for a minute) a number change should simply be passed in to me, as an end user, and happen without my being aware of it. But if I have to go re-sign things, that isn't going to happen. For security reasons, dnssec recommends that zones be signed at an unconnected host (one not on any network), and the resulting signed zone file be carried, via floppy or similar, to the DNS server. While I don't expect many people will go to those kinds of extreme lengths, it isn't reasonable to unduly penalise those who do need to achieve that level of security. If the re-signing is done only where the number change is actually caused (that is, by the human who decided that it needs to happen), then the resigning should ideally take place only there as well. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 14:12:26 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA25270 for ipng-dist; Thu, 20 Nov 1997 14:09:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA25257 for ; Thu, 20 Nov 1997 14:09:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA10898 for ; Thu, 20 Nov 1997 14:09:25 -0800 Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA17786 for ; Thu, 20 Nov 1997 14:09:18 -0800 (PST) Received: by relay.hq.tis.com; id RAA07379; Thu, 20 Nov 1997 17:08:40 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma007352; Thu, 20 Nov 97 17:08:11 -0500 Received: from english.hq.tis.com (english.hq.tis.com [10.33.40.14]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA01295; Thu, 20 Nov 1997 17:05:45 -0500 (EST) Message-Id: <3.0.5.32.19971120170618.008e0200@pop.hq.tis.com> X-Sender: ogud@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 20 Nov 1997 17:06:18 -0500 To: Pedro Marques From: Olafur Gudmundsson Subject: (IPng 4915) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199711202058.MAA22258@pedrom-ultra.cisco.com> References: <971120150629.ZM10221@seawind.bellcore.com> <199711121433.JAA18578@ietf.org> <199711182334.RAA25506@gungnir.fnal.gov> <199711200033.QAA21962@pedrom-ultra.cisco.com> <971120150629.ZM10221@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id OAA25258 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:58 PM 11/20/97 -0800, Pedro Marques wrote: >>>>>> "Christian" == Christian Huitema writes: > > Christian> So, renumbering a whole > Christian> network could mean several minutes of computation with > Christian> the old AAAA approach. > >Which is perfectly ok. It's also perfectly ok if it takes several hours. No it is not ok, both for the DNS reasons Robert described, and other. For example if site has a link added/deleted that site will want to advertise that fact as soon as possible. Also in the distant future where sites get charged by the packet a site may want to take advantage of price differences at certain times to only advertise the inexpensive links. Olafur -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-= Ólafur Guðmundsson (in ISO-8859-1) ogud@tis.com (work) Olafur Gudmundsson (in US ascii) ogud@acm.org (private) (301)-854-5700 Fax: x5363 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 14:34:35 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA25312 for ipng-dist; Thu, 20 Nov 1997 14:20:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA25305 for ; Thu, 20 Nov 1997 14:20:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14679 for ; Thu, 20 Nov 1997 14:19:58 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id MAA04195 for ; Thu, 20 Nov 1997 12:42:49 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA09099; Fri, 21 Nov 1997 07:42:46 +1100 (from kre@munnari.OZ.AU) To: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 4917) Re: RAs with 0 lifetime prefix (take II) In-Reply-To: Ken Powell's message of "Thu, 20 Nov 1997 12:08:03 -0500." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Nov 1997 07:42:45 +1100 Message-Id: <21413.880058565@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I deleted all the individuals whose names were building up in the headers. I basically support the #3 option. The reason I don't much like Eric's workaround (which is fine in itself) is that it addresses only TCP connection issues, and there is more to life than that. There are also issues relating to daemon processes (routing daemons, etc) that need to know all the addresses that exist, and when they alter. I know that some of you don't believe that anyone who listens to RA's, rather than those which generate them, should ever be running any kind of routing daemon, but I don't want to get into that discussion. Those aren't the only applications (snmp agents are probably another). Thus I feel it important to damp out effects of such very simple DoS attacks lower down the stack than transport. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 14:35:53 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA25322 for ipng-dist; Thu, 20 Nov 1997 14:26:59 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA25315 for ; Thu, 20 Nov 1997 14:26:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA16844 for ; Thu, 20 Nov 1997 14:26:37 -0800 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA26514 for ; Thu, 20 Nov 1997 14:25:33 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Thu Nov 20 17:21:42 EST 1997 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Thu Nov 20 17:23:02 EST 1997 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id RAA06525 for ; Thu, 20 Nov 1997 17:23:00 -0500 (EST) Message-Id: <199711202223.RAA06525@postal.research.att.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4918) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Date: Thu, 20 Nov 1997 17:22:59 -0500 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Which is perfectly ok. It's also perfectly ok if it takes several hours. > > The question is really where is the appropriate place for the work to > be done - ideally (ignoring the DNS for a minute) a number change should > simply be passed in to me, as an end user, and happen without my being > aware of it. > > But if I have to go re-sign things, that isn't going to happen. For security > reasons, dnssec recommends that zones be signed at an unconnected host (one not > on any network), and the resulting signed zone file be carried, via floppy or > similar, to the DNS server. While I don't expect many people will go to those > kinds of extreme lengths, it isn't reasonable to unduly penalise those who > do need to achieve that level of security. > > If the re-signing is done only where the number change is actually caused > (that is, by the human who decided that it needs to happen), then the resigning > should ideally take place only there as well. Kre is right -- we have to make it easy (and even possible) for people to do the right thing about security. I should ntoe that the high-order bits of an address -- the ones affected by renumbering -- are actually far more critical for security, since anyone who tinkers with them redirects the routing for an entire site. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 14:56:54 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA25395 for ipng-dist; Thu, 20 Nov 1997 14:53:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA25388 for ; Thu, 20 Nov 1997 14:53:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA26810 for ; Thu, 20 Nov 1997 14:53:38 -0800 Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA12148 for ; Thu, 20 Nov 1997 14:53:22 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by rhine.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05872; Thu, 20 Nov 1997 14:44:21 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA22342; Thu, 20 Nov 1997 14:53:09 -0800 (PST) Date: Thu, 20 Nov 1997 14:53:09 -0800 (PST) Message-Id: <199711202253.OAA22342@pedrom-ultra.cisco.com> From: Pedro Marques To: Olafur Gudmundsson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4919) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: <3.0.5.32.19971120170618.008e0200@pop.hq.tis.com> References: <971120150629.ZM10221@seawind.bellcore.com> <199711121433.JAA18578@ietf.org> <199711182334.RAA25506@gungnir.fnal.gov> <199711200033.QAA21962@pedrom-ultra.cisco.com> <199711202058.MAA22258@pedrom-ultra.cisco.com> <3.0.5.32.19971120170618.008e0200@pop.hq.tis.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Olafur" == Olafur Gudmundsson writes: Olafur> At 12:58 PM 11/20/97 -0800, Pedro Marques wrote: >>>>>>> "Christian" == Christian Huitema >>>>>>> writes: >> Christian> So, renumbering a whole network could mean several Christian> minutes of computation with the old AAAA approach. >> Which is perfectly ok. It's also perfectly ok if it takes >> several hours. Olafur> No it is not ok, both for the DNS reasons Robert Olafur> described, and other. For example if site has a link Olafur> added/deleted that site will want to advertise that fact Olafur> as soon as possible. Also in the distant future where Olafur> sites get charged by the packet a site may want to take Olafur> advantage of price differences at certain times to only Olafur> advertise the inexpensive links. None of the things you are talking about has anything to do with what we are discussing... basically you don't connect to a new service provider without planing so even if DNS record signing takes days there is still no operational problem. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 15:43:39 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA25438 for ipng-dist; Thu, 20 Nov 1997 15:35:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA25431 for ; Thu, 20 Nov 1997 15:35:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA10610 for ; Thu, 20 Nov 1997 15:34:56 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA02817 for ; Thu, 20 Nov 1997 15:34:47 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id SAA00245; Thu, 20 Nov 1997 18:34:46 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id SAA10408; Thu, 20 Nov 1997 18:34:45 -0500 (EST) Date: Thu, 20 Nov 1997 18:34:45 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971120183444.ZM10406@seawind.bellcore.com> In-Reply-To: Pedro Marques "(IPng 4919) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt" (Nov 20, 2:53pm) References: <971120150629.ZM10221@seawind.bellcore.com> <199711121433.JAA18578@ietf.org> <199711182334.RAA25506@gungnir.fnal.gov> <199711200033.QAA21962@pedrom-ultra.cisco.com> <199711202058.MAA22258@pedrom-ultra.cisco.com> <3.0.5.32.19971120170618.008e0200@pop.hq.tis.com> <199711202253.OAA22342@pedrom-ultra.cisco.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Pedro Marques , Olafur Gudmundsson Subject: (IPng 4920) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Nov 20, 2:53pm, Pedro Marques wrote: > > None of the things you are talking about has anything to do with what we > are discussing... basically you don't connect to a new service provider > without planing so even if DNS record signing takes days there is still > no operational problem. > That may well be where we disagree, Pedro. We really want to be able to renumber sites in a fraction of second. We may choose to not do so, but we certainly don't want to preclude it. As I said before, I would favor a compromise so that the trade-off between flexibility and simplicity will be left at a manager's appreciation. This is in fact easy to achieve with any "pointer" proposal -- a manager that does not believe in pointers can always set the prefix length to 128 in the AAAA record. But we certainly want to have the mechanism in place, and we don't want to have 10,000,000 IPv6 hosts installed before we deploy it! -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 15:51:35 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA25459 for ipng-dist; Thu, 20 Nov 1997 15:48:36 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA25452 for ; Thu, 20 Nov 1997 15:48:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA14341 for ; Thu, 20 Nov 1997 15:48:20 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA09547 for ; Thu, 20 Nov 1997 15:47:00 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id PAA01239; Thu, 20 Nov 1997 15:46:53 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA22538; Thu, 20 Nov 1997 15:46:53 -0800 (PST) Date: Thu, 20 Nov 1997 15:46:53 -0800 (PST) Message-Id: <199711202346.PAA22538@pedrom-ultra.cisco.com> From: Pedro Marques To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4921) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: <971120183444.ZM10406@seawind.bellcore.com> References: <971120150629.ZM10221@seawind.bellcore.com> <199711121433.JAA18578@ietf.org> <199711182334.RAA25506@gungnir.fnal.gov> <199711200033.QAA21962@pedrom-ultra.cisco.com> <199711202058.MAA22258@pedrom-ultra.cisco.com> <3.0.5.32.19971120170618.008e0200@pop.hq.tis.com> <199711202253.OAA22342@pedrom-ultra.cisco.com> <971120183444.ZM10406@seawind.bellcore.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Christian" == Christian Huitema writes: Christian> That may well be where we disagree, Pedro. We really Christian> want to be able to renumber sites in a fraction of Christian> second. Indeed, we disagree. Can you explain me why we would want to do such thing. Christian> We may choose to not do so, but we certainly Christian> don't want to preclude it. To me that it is an unreasonable requirement. Unreasonable both because, personally, i don't find any good reason to do it and because it creates unrealistic constrains on the protocol specification. Christian> But we certainly want to have the mechanism in place, and Christian> we don't want to have 10,000,000 IPv6 hosts installed Christian> before we deploy it! I believe we are in no risk of being in such situation anytime soon. And adding unnecessary complexity is not going to help at all... Please let's be really sure when we try to introduce requirements that they are absolutely necessary. But i'm glad we are having this argument since it would really help if the ipng WG would define it's requirements on the magic word "renumbering". Most of us use it with a completely different meaning. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 16:31:49 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA25519 for ipng-dist; Thu, 20 Nov 1997 16:28:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA25512 for ; Thu, 20 Nov 1997 16:28:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA26597 for ; Thu, 20 Nov 1997 16:28:33 -0800 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA00726 for ; Thu, 20 Nov 1997 16:28:31 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Thu Nov 20 19:24:38 EST 1997 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Thu Nov 20 19:23:43 EST 1997 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id TAA09955; Thu, 20 Nov 1997 19:23:42 -0500 (EST) Message-Id: <199711210023.TAA09955@postal.research.att.com> To: Pedro Marques cc: Olafur Gudmundsson , ipng@sunroof.eng.sun.com Subject: (IPng 4923) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Date: Thu, 20 Nov 1997 19:23:42 -0500 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk None of the things you are talking about has anything to do with what we are discussing... basically you don't connect to a new service provider without planing so even if DNS record signing takes days there is still no operational problem. But if your upstream ISP, or the one upstream of it, rehomes, they'll renumber, and progagate the renumbering requirement down to you. They may have time to plan -- but you won't. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 16:55:22 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA25579 for ipng-dist; Thu, 20 Nov 1997 16:52:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA25572 for ; Thu, 20 Nov 1997 16:52:24 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA03221 for ; Thu, 20 Nov 1997 16:52:20 -0800 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA11982 for ; Thu, 20 Nov 1997 16:52:18 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id QAA12459; Thu, 20 Nov 1997 16:52:17 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA22571; Thu, 20 Nov 1997 16:52:15 -0800 (PST) Date: Thu, 20 Nov 1997 16:52:15 -0800 (PST) Message-Id: <199711210052.QAA22571@pedrom-ultra.cisco.com> From: Pedro Marques To: Steven Bellovin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4924) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: <199711210023.TAA09955@postal.research.att.com> References: <199711210023.TAA09955@postal.research.att.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Steven" == Steven Bellovin writes: Steven> None of the things you are talking about has anything Steven> to do with what we are discussing... basically you don't Steven> connect to a new service provider without planing so even Steven> if DNS record signing takes days there is still no Steven> operational problem. Steven> But if your upstream ISP, or the one upstream of it, Steven> rehomes, they'll renumber, and progagate the renumbering Steven> requirement down to you. That is the part where i start to be extremely sceptic about... I don't really think there is any advantage at all on renumbering your tipical transit network. Essentially because transit networks tend to be interconneted at several points with different peers. Second because it's not really where your problem is... essentially aggregation is effective on the last level. I don't see any problem at all of having a route exported to the top of the hierarchy per AS... If we look back and consider the problem renumbering was supposed to solve, the holes created in provider based blocks when customers change providers, i don't see why we have to talk about multi-level renumbering at all. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 18:24:37 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id SAA25739 for ipng-dist; Thu, 20 Nov 1997 18:19:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA25732 for ; Thu, 20 Nov 1997 18:19:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA25527 for ; Thu, 20 Nov 1997 18:19:32 -0800 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA18509 for ; Thu, 20 Nov 1997 18:19:33 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Thu Nov 20 21:15:39 EST 1997 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Thu Nov 20 21:15:54 EST 1997 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id VAA12479; Thu, 20 Nov 1997 21:15:52 -0500 (EST) Message-Id: <199711210215.VAA12479@postal.research.att.com> To: Pedro Marques cc: ipng@sunroof.eng.sun.com Subject: (IPng 4925) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Date: Thu, 20 Nov 1997 21:15:52 -0500 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk That is the part where i start to be extremely sceptic about... I don't really think there is any advantage at all on renumbering your tipical transit network. Essentially because transit networks tend to be interconneted at several points with different peers. Second because it's not really where your problem is... essentially aggregation is effective on the last level. I don't see any problem at all of having a route exported to the top of the hierarchy per AS... If we look back and consider the problem renumbering was supposed to solve, the holes created in provider based blocks when customers change providers, i don't see why we have to talk about multi-level renumbering at all. "Big ISPs have little ISPs, "Upon their links to byte them, "And little ISPs have lesser ones, "And so ad infinitum." There are an amazing number of access providers who are not multihomed -- they connect between the end-user and the bigger ISPs. And the reason they have a market niche is because they can provide better customer service, or the same service at lower cost, than the big guys. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 18:34:30 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id SAA25780 for ipng-dist; Thu, 20 Nov 1997 18:31:47 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA25773 for ; Thu, 20 Nov 1997 18:31:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA27529 for ; Thu, 20 Nov 1997 18:31:34 -0800 Received: from osgroup.com ([38.229.41.6]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA22851 for ; Thu, 20 Nov 1997 18:31:35 -0800 (PST) Received: from localhost (osgroup@localhost) by osgroup.com (8.7.6/8.6.12) with SMTP id VAA17701 for ; Thu, 20 Nov 1997 21:30:46 -0600 Date: Thu, 20 Nov 1997 21:30:46 -0600 (CST) From: Engineering To: ipng@sunroof.eng.sun.com Subject: (IPng 4927) testing IPSEC Win95/NT device drivers In-Reply-To: <21666.880060529@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, we have released some Windows 95 and NT device drivers which implement IPSEC, and are interested in testing with IPSEC security gateway vendors. These drivers are compatible with the Microsoft TCP/IP stack, and work with LAN, WAN, and dial up adapters on the four diffrent versions of Windows 95, and three diffrent versions of Windows NT. We are ready to begin testing over the internet now, and would appreciate the opportunity to improve the compatibility with hardware vendors. Sincerely, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 19:19:54 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id TAA25905 for ipng-dist; Thu, 20 Nov 1997 19:11:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id TAA25897 for ; Thu, 20 Nov 1997 19:11:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA02967 for ; Thu, 20 Nov 1997 19:11:02 -0800 Received: from osgroup.com ([38.229.41.6]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id TAA06288 for ; Thu, 20 Nov 1997 19:11:02 -0800 (PST) Received: from localhost (osgroup@localhost) by osgroup.com (8.7.6/8.6.12) with SMTP id WAA17981; Thu, 20 Nov 1997 22:10:02 -0600 Date: Thu, 20 Nov 1997 22:10:01 -0600 (CST) From: Engineering To: Bryan Gleeson cc: amalis@alpo.casc.com, gja@dnrc.bell-labs.com, ion@nexen.com, ipng@sunroof.eng.sun.com, malis@alpo.casc.com Subject: (IPng 4928) Re: IPv6 over ATM encapsulation In-Reply-To: <199711210229.SAA16616@bgleeson-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, we have IPSEC drivers for Win95/NT which work with ATM adapters on Win95/NT. Also, we wrote the NT WAN drivers for ATML and tested it with these adapters. I know this is a little off the discussion track, but thought it might be useful to know. Sincerely, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * On Thu, 20 Nov 1997, Bryan Gleeson wrote: > Andy, > > >So, given your discussion, I am mostly interested in removing the use > >of null encapsulation for PVCs. However, given the restrictions in > >section 3.2.3, do you think it makes sense to support it for SVCs as > >well? > > I don't have a strong opinion on PVCs, but for SVCs I do not see a > need or benefit to changing the current IPV4/ATM and MPOA behaviour, > which allows, but does not require, a non-default encapsulation. > > The only restriction in 3.2.3. is that MARS is not allowed to > negotiate a non-default encapsulation, the rest is observations > on what happens if the null encapsulation is negotiated according > to the rules in UNI signalling. Even if that MARS restriction is > introduced, there is no need to prohibit the use of the null > encapsulation for data flows between other stations. The overhead > of the negotiation to force LLC, if that is all a station supports, > is trivial, and is needed anyway for IPV4 and MPOA. > > I'll admit that the use of the null encapsulation is probably > about the same as the use of esperanto in the real world, but > if two esperanto speakers ever meet, why prohibit them from > talking esperanto? No one is being forced to learn or speak it! > > Bryan > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 19:35:18 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id TAA26015 for ipng-dist; Thu, 20 Nov 1997 19:31:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id TAA26008 for ; Thu, 20 Nov 1997 19:31:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA06827 for ; Thu, 20 Nov 1997 19:31:22 -0800 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id TAA14360 for ; Thu, 20 Nov 1997 19:31:21 -0800 (PST) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id TAA27960; Thu, 20 Nov 1997 19:31:20 -0800 (PST) From: Bill Manning Message-Id: <199711210331.TAA27960@zephyr.isi.edu> Subject: (IPng 4929) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt To: roque@cisco.com (Pedro Marques) Date: Thu, 20 Nov 1997 19:31:19 -0800 (PST) Cc: smb@research.att.com, ipng@sunroof.eng.sun.com In-Reply-To: <199711210052.QAA22571@pedrom-ultra.cisco.com> from "Pedro Marques" at Nov 20, 97 04:52:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Steven> But if your upstream ISP, or the one upstream of it, > Steven> rehomes, they'll renumber, and progagate the renumbering > Steven> requirement down to you. > > That is the part where i start to be extremely sceptic about... > > I don't really think there is any advantage at all on renumbering your > tipical transit network. Essentially because transit networks tend to > be interconneted at several points with different peers. Second because > it's not really where your problem is... essentially aggregation is > effective on the last level. I don't see any problem at all of having > a route exported to the top of the hierarchy per AS... > > If we look back and consider the problem renumbering was supposed to solve, > the holes created in provider based blocks when customers change providers, > i don't see why we have to talk about multi-level renumbering at all. > > > Pedro. > -------------------------------------------------------------------- One interesting aspect that empirical evidence has shown is that at least in the IPv4 relm, heirarchy has remained generally at two levels. The interconnectedness of each layer is increasingly dense as is the mesh between levels. I expect that we may be forced into at least a couple more levels of heirarchy and the mesh will be even tighter as we move into larger address spaces. Transit as a concept will be reformed into partial meshes with best effort handoff past your own span of control. This is not to my liking. I see some folks trying to retain the idea of designing and engineering for true endnode to endnode transport visability. Others have been seduced by the NAT deamon (guess where my bias lies :) and are willing to proxy/renumber at their administrative edges for what become alternate IP universes. I expect that the "purer" architectural approach would be to embrace IPSEC and periodic dynamic renumbering of the Internet. This requires abandoning those techniques that promote balkenization of the Internet. Firewall and NAT techniques, which lock in users to a specific, not very portable view of how transport and network layers behave will hamper even further the promise of all that address space in IPv6. In either case, whether the renubmering is locally scoped or crosses many administrative bounds, it is an important technique to understand and exploit. Hobbling it in favor of one approach would be wrong. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 21:32:41 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id VAA26260 for ipng-dist; Thu, 20 Nov 1997 21:30:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id VAA26253 for ; Thu, 20 Nov 1997 21:29:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA21138 for ; Thu, 20 Nov 1997 21:29:56 -0800 Received: from griffon.cisco.com (griffon.cisco.com [171.69.1.179]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id VAA19590 for ; Thu, 20 Nov 1997 21:29:56 -0800 (PST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by griffon.cisco.com (8.6.12/8.6.5) with ESMTP id VAA26812; Thu, 20 Nov 1997 21:29:57 -0800 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA22693; Thu, 20 Nov 1997 21:29:57 -0800 (PST) Date: Thu, 20 Nov 1997 21:29:57 -0800 (PST) Message-Id: <199711210529.VAA22693@pedrom-ultra.cisco.com> From: Pedro Marques To: Steven Bellovin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4930) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: <199711210215.VAA12479@postal.research.att.com> References: <199711210215.VAA12479@postal.research.att.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Steven" == Steven Bellovin writes: Steven> "Big ISPs have little ISPs, "Upon their links to byte Steven> them, "And little ISPs have lesser ones, "And so ad Steven> infinitum." Steve, The way we explain things to children, while simple, doesn't always correspond to reality. :-) To give you an example, the smallest ISPs i'm familiar with typically have two international links (us and europe) and a link to a local exchange. And these are really small networks for which we would really like to avoid having top-level routing annoucements... to my knowledge, you can only accomplish that by using "unpure" solutions like NAT. Steven> There are an amazing number of access providers who are Steven> not multihomed -- they connect between the end-user and Steven> the bigger ISPs. The point is why should they be considered in the addressing game at all. If you have A, B and C where A provides transit for B and it's clients, the addresses B uses inside it's own network are pretty much irrelevant. And if B decides to change it's main transit provider he will do it by multihoming with A and a new carrier. You can effectivly reduce the problem to end clients changing top level transit network. And the impression that i got is that seldom you have a transit ISP peer with just one network. In many cases local exchanges do make sense economically and even small networks tend to adopt them. Personally, i tend to think of multihoming not as the exception but as the rule. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 20 23:50:32 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id XAA26368 for ipng-dist; Thu, 20 Nov 1997 23:48:00 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id XAA26361 for ; Thu, 20 Nov 1997 23:47:50 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA05436 for ; Thu, 20 Nov 1997 23:47:48 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id XAA00272 for ; Thu, 20 Nov 1997 23:47:48 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id CAA30274 for ; Fri, 21 Nov 1997 02:39:11 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09177; Fri, 21 Nov 1997 02:39:10 -0500 Message-Id: <199711210739.AA09177@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4931) Suggestion on DBIT Record from BIND Workers Date: Fri, 21 Nov 1997 02:39:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alan gave me permission to forward. /jim ------- Forwarded Message Return-Path: bind-workers-request@vix.com Received: from quarry.zk3.dec.com by mailhub2.zk3.dec.com (5.65v3.2/1.1.10.5/24Sep96-0323PM) id AA06632; Wed, 19 Nov 1997 22:08:52 -0500 Received: from mail11.digital.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA20613; Wed, 19 Nov 1997 22:08:33 -0500 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id VAA14947; Wed, 19 Nov 1997 21:57:35 -0500 (EST) Received: from halley@localhost by gw.home.vix.com via SMTP id SAA02506; Wed, 19 Nov 1997 18:31:37 -0800 (PST) env-from (bind-workers-request) Received: from data.pa.vix.com [204.152.184.37] by gw.home.vix.com via ESMTP id CAA11033 for ; Wed, 19 Nov 1997 02:26:17 -0800 (PST) env-from (apb@iafrica.com) Received: from L6Th4Dqc9o4m5suG8cC8ejZ/tw17qlsl@apb.iafrica.com [196.31.1.20] by data.pa.vix.com via ESMTP id CAA18750 for ; Wed, 19 Nov 1997 02:26:15 -0800 (PST) env-from (apb@iafrica.com) Received: from localhost ([[UNIX: localhost]]) by apb.iafrica.com (8.8.6/8.8.6) with SMTP id MAA20778 for ; Wed, 19 Nov 1997 12:25:46 +0200 (GMT+0200) X-Authentication-Warning: apb.iafrica.com: apb owned process doing -bs Date: Wed, 19 Nov 1997 12:25:46 +0200 (GMT+0200) From: Alan Barrett To: bind-workers@vix.com Subject: Re: IPv6 DNS proposal... lost me In-Reply-To: <199711182311.SAA02355@dbc.dnrc.bell-labs.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Reply-To: Alan Barrett > ftp://ietf.org/internet-drafts/draft-ietf-ipngwg-aaaa-00.txt It seems to me that you don't need the DBIT RR at all. Instead of *.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. DBIT 48 net.foo.bar. b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.7.0.0.0.net.foo.bar. DBIT 128 host.example. you could have *.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. CNAME *.net.foo.bar. b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.7.0.0.0.net.foo.bar. PTR host.example. This would requires a modification to the definition of tha CNAME RR, to handle wildcards on the right hand side in a sensible way. - --apb (Alan Barrett) ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 00:26:33 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id AAA26402 for ipng-dist; Fri, 21 Nov 1997 00:23:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id AAA26395 for ; Fri, 21 Nov 1997 00:23:45 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA09838 for ; Fri, 21 Nov 1997 00:23:42 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id AAA10931 for ; Fri, 21 Nov 1997 00:23:43 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id DAA32759; Fri, 21 Nov 1997 03:09:16 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09804; Fri, 21 Nov 1997 03:09:10 -0500 Message-Id: <199711210809.AA09804@wasted.zk3.dec.com> To: Pedro Marques Cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com Subject: (IPng 4932) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: Your message of "Thu, 20 Nov 1997 15:46:53 PST." <199711202346.PAA22538@pedrom-ultra.cisco.com> Date: Fri, 21 Nov 1997 03:09:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk folks...I think Pedro is saying some smart things...and we should be listening... I don't have any expectations of renumbering in a fraction of a second that is a very intense assumption. Also as Christian noted. This is going to really be hard when there is 10,000 IPv6 host running. It is already bumming out folks and I hear the ground swell. As always with IPv6 I am for moving forward. My first attempt at this split the AAAA record into to two parts. Routing and Identifier. Very simple. Could easily be backwards compatible. But if you changed any part of the prefix it had to be resigned. Is that really that bad? Also bill keeps saying he wants the ip6.int record on bit boundarys. I agree and I think everyone does. But we need a proposal. I don't think we have 6 months to discuss this and I think we need to keep moving forward. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 05:20:03 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id FAA26648 for ipng-dist; Fri, 21 Nov 1997 05:17:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id FAA26641 for ; Fri, 21 Nov 1997 05:17:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA05148 for ; Fri, 21 Nov 1997 05:17:14 -0800 Received: from att.com (cagw1.att.com [192.128.52.89]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA03644 for ; Fri, 21 Nov 1997 05:17:14 -0800 (PST) Received: by cagw1.att.com; Fri Nov 21 08:11 EST 1997 Received: from eurdirsync.be.att.com (eurdirsync.be.att.com [135.76.165.12]) by caig1.att.att.com (AT&T/GW-1.0) with SMTP id IAA28869 for ; Fri, 21 Nov 1997 08:08:09 -0500 (EST) Received: by eurdirsync.be.att.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCF688.80744560@eurdirsync.be.att.com>; Fri, 21 Nov 1997 14:19:39 +0100 Message-ID: From: "Buclin, Bertrand" To: "'Matt Crawford'" , "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 4933) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt Date: Fri, 21 Nov 1997 15:16:09 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, November 19, 1997 12:34 AM, Matt Crawford [SMTP:crawdad@fnal.gov] wrote: > > First of all, to use the same name ("AAAA") and code point (28) for > this new record type will be disasterous to the 6bone and all other > IPv6 deployment to date. But I expect the authors know that. For > the rest of this message I'm going to call the proposed new record an > ASP (address suffix & pointer). > I'm not so sure... Looking at the number of sites actually running DNS AAAA on the 6Bone, the pill shouldn't be so difficult to swallow. Also, the 6Bone just successfully went through a renumbering exercise which demonstrated, in my eyes, that dramatic changes can still be applied on this network. The only issue I could see would be if the currently deployed resolvers react badly to the new AAAA records (by crashing for example). That would be a real nuisance. But if they nicely handle it, then it should not be a problem reusing the same code point. Cheers, Bertrand _______________________________________________________ Bertrand Buclin Service & Product Development Manager AT&T Labs Europe Phone: +41 22 929 37 40 Fax: +41 22 929 39 85 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 07:28:06 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA26741 for ipng-dist; Fri, 21 Nov 1997 07:25:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA26734 for ; Fri, 21 Nov 1997 07:24:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA03814 for ; Fri, 21 Nov 1997 07:24:52 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA26554 for ; Fri, 21 Nov 1997 07:24:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA15338; Fri, 21 Nov 1997 10:24:16 -0500 (EST) Message-Id: <199711211524.KAA15338@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 4935) I-D ACTION:draft-ietf-ipngwg-trans-fddi-net-05.txt Date: Fri, 21 Nov 1997 10:24:05 -0500 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 : Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-fddi-net-05.txt Pages : 8 Date : 20-Nov-97 This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an FDDI network. This document replaces RFC 2019, ''Transmission of IPv6 Packets Over FDDI'', which will become historic. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-trans-fddi-net-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-fddi-net-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971120180241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-fddi-net-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971120180241.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 07:29:01 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA26750 for ipng-dist; Fri, 21 Nov 1997 07:26:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA26743 for ; Fri, 21 Nov 1997 07:25:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA04195 for ; Fri, 21 Nov 1997 07:25:50 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA27150 for ; Fri, 21 Nov 1997 07:25:40 -0800 (PST) Received: from kerkenna.inria.fr (kerkenna.inria.fr [128.93.3.25]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id QAA25081; Fri, 21 Nov 1997 16:25:33 +0100 (MET) Received: from kerkenna.inria.fr (kerkenna.inria.fr [128.93.3.25]) by kerkenna.inria.fr (8.7.6/8.7.3) with ESMTP id QAA13967; Fri, 21 Nov 1997 16:25:19 +0100 (MET) Message-Id: <199711211525.QAA13967@kerkenna.inria.fr> X-Mailer: exmh version 1.6.9 8/22/96 To: "Andrew G. Malis" cc: gja@dnrc.bell-labs.com, ion@nexen.com, ipng@sunroof.eng.sun.com, Francis.Dupont@inria.fr, Mohsen.Souissi@inria.fr Subject: (IPng 4936) Re: IPv6 over ATM encapsulation In-reply-to: Your message of "Fri, 21 Nov 1997 08:41:23 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Nov 1997 16:24:48 +0100 From: Mohsen Souissi Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id HAA26744 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk amalis@alpo.casc.com said: > OK, in the absence of other opinions, we'll remove null encapsulation > for PVCs but retain it as an option for SVCs. Francis Dupont and I were just discussing the possibility of removing the null encapsulation option from draft-ietf-ion-ipv6-atm-00.txt. We think that's a good idea for two reasons: - the null encapsulation is fairly limiting and useless - the less options there are, the likelier (and the better) one can interoperate Regards, Mohsen. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 09:45:32 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA26956 for ipng-dist; Fri, 21 Nov 1997 09:39:44 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA26949 for ; Fri, 21 Nov 1997 09:39:38 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA12375 for ; Fri, 21 Nov 1997 09:39:37 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01074; Fri, 21 Nov 1997 09:39:24 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA25211 for ; Thu, 20 Nov 1997 13:55:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA05136 for ; Thu, 20 Nov 1997 13:55:02 -0800 Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA10008 for ; Thu, 20 Nov 1997 13:54:22 -0800 (PST) Received: from bgleeson-ss20.cisco.com (bgleeson-ss20.cisco.com [171.69.193.208]) by rhine.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA05237; Thu, 20 Nov 1997 13:45:02 -0800 (PST) From: Bryan Gleeson Received: (bgleeson@localhost) by bgleeson-ss20.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) id NAA16441; Thu, 20 Nov 1997 13:53:49 -0800 (PST) Date: Thu, 20 Nov 1997 13:53:49 -0800 (PST) Message-Id: <199711202153.NAA16441@bgleeson-ss20.cisco.com> To: amalis@alpo.casc.com, ion@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 4937) Re: IPv6 over ATM encapsulation Cc: gja@dnrc.bell-labs.com, malis@alpo.casc.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andy, Grenville, >Grenville and I were just discussing draft-ietf-ion-ipv6-atm-00.txt on >the phone, and we talked about the possibility of removing the null >encapsulation option. I suggested removing it because it adds an >additional configuration option and complexity to the spec, and code to >implementations. In addition, it makes it more difficult to >interoperate with IPv6 over Frame Relay via FR/ATM interworking. In >fact, in the forthcoming IPv6 over FR draft, null encapsulation will >not be an option; RFC 1490 encapsulation will be required. Is this for PVCs and/or SVCs ? If for SVCs does it imply that the use of BLLI negotiation is prohibited ? For SVCs I don't think there is any point in prohibiting two co-operating systems from using it if they want to, since it adds no burden on those that only use LLC (since being the default, LLC must always be in the list of proposed encaps), and that is what the current signalling for IPV4/ATM allows. Even if the spec was silent on the matter the negotiation of non-default encapsulations would be allowed as a signalling capability. Bryan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 09:46:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA26965 for ipng-dist; Fri, 21 Nov 1997 09:40:36 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA26958 for ; Fri, 21 Nov 1997 09:40:29 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA14451 for ; Fri, 21 Nov 1997 09:40:28 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01101; Fri, 21 Nov 1997 09:40:15 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA25242 for ; Thu, 20 Nov 1997 14:07:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA10187 for ; Thu, 20 Nov 1997 14:07:40 -0800 Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA16657 for ; Thu, 20 Nov 1997 14:07:14 -0800 (PST) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id RAA29549; Thu, 20 Nov 1997 17:04:41 -0500 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id RAA04415; Thu, 20 Nov 1997 17:06:47 -0500 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id RAA01790; Thu, 20 Nov 1997 17:06:46 -0500 Date: Thu, 20 Nov 1997 17:06:46 -0500 (EST) From: "Andrew G. Malis" X-Sender: amalis@spice To: Bryan Gleeson cc: amalis@alpo.casc.com, ion@nexen.com, ipng@sunroof.eng.sun.com, gja@dnrc.bell-labs.com, malis@alpo.casc.com Subject: (IPng 4938) Re: IPv6 over ATM encapsulation In-Reply-To: <199711202153.NAA16441@bgleeson-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bryan, > >Grenville and I were just discussing draft-ietf-ion-ipv6-atm-00.txt on > >the phone, and we talked about the possibility of removing the null > >encapsulation option. > > Is this for PVCs and/or SVCs ? If for SVCs does it imply that the > use of BLLI negotiation is prohibited ? For SVCs I don't think > there is any point in prohibiting two co-operating systems from > using it if they want to, since it adds no burden on those that only > use LLC (since being the default, LLC must always be in the list of > proposed encaps), and that is what the current signalling for > IPV4/ATM allows. Even if the spec was silent on the matter the > negotiation of non-default encapsulations would be allowed as a > signalling capability. You raised some excellent points. To be frank, I primarly had section 3.1.1 (null encapsulation for PVCs) in mind. However, if you read section 3.2.3 (null encapsulation for SVCs), Grenville discusses some interesting restrictions on when null encapsulation can and cannot be used. So, given your discussion, I am mostly interested in removing the use of null encapsulation for PVCs. However, given the restrictions in section 3.2.3, do you think it makes sense to support it for SVCs as well? Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 09:47:44 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA26974 for ipng-dist; Fri, 21 Nov 1997 09:42:20 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA26967 for ; Fri, 21 Nov 1997 09:41:52 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA16206 for ; Fri, 21 Nov 1997 09:41:10 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01128; Fri, 21 Nov 1997 09:40:57 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA25292 for ; Thu, 20 Nov 1997 14:15:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA13314 for ; Thu, 20 Nov 1997 14:15:56 -0800 Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA13430 for ; Thu, 20 Nov 1997 13:01:28 -0800 (PST) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id PAA28855; Thu, 20 Nov 1997 15:58:36 -0500 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id QAA29390; Thu, 20 Nov 1997 16:00:47 -0500 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id QAA01729; Thu, 20 Nov 1997 16:00:47 -0500 Date: Thu, 20 Nov 1997 16:00:47 -0500 (EST) From: "Andrew G. Malis" X-Sender: amalis@spice Reply-To: "Andrew G. Malis" To: ion@nexen.com, ipng@sunroof.eng.sun.com cc: "Andrew G. Malis" , Grenville Armitage Subject: (IPng 4939) IPv6 over ATM encapsulation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville and I were just discussing draft-ietf-ion-ipv6-atm-00.txt on the phone, and we talked about the possibility of removing the null encapsulation option. I suggested removing it because it adds an additional configuration option and complexity to the spec, and code to implementations. In addition, it makes it more difficult to interoperate with IPv6 over Frame Relay via FR/ATM interworking. In fact, in the forthcoming IPv6 over FR draft, null encapsulation will not be an option; RFC 1490 encapsulation will be required. However, we wanted to make sure we weren't stomping over (many) existing implementations before removing it from his spec. Speak up or it will be removed from the next version of the draft. Thanks, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 09:51:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA27019 for ipng-dist; Fri, 21 Nov 1997 09:46:41 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA27012 for ; Fri, 21 Nov 1997 09:46:28 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA27290 for ; Fri, 21 Nov 1997 09:46:27 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01172; Fri, 21 Nov 1997 09:46:14 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA25470 for ; Thu, 20 Nov 1997 15:55:30 -0800 (PST) From: Mark.Andrews@cmis.CSIRO.AU Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA16410 for ; Thu, 20 Nov 1997 15:55:25 -0800 Received: from snowy.nsw.cmis.CSIRO.AU (snowy.nsw.cmis.CSIRO.AU [130.155.16.108]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA14050 for ; Thu, 20 Nov 1997 15:55:18 -0800 (PST) Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id KAA11210; Fri, 21 Nov 1997 10:54:56 +1100 Message-Id: <199711202354.KAA11210@snowy.nsw.cmis.CSIRO.AU> Received: from pride.nsw.cmis.CSIRO.AU(130.155.16.4) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa002iu; Fri Nov 21 10:54:50 1997 To: Steve Deering cc: Masataka Ohta , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: (IPng 4940) Re: message size In-reply-to: Your message of "Mon, 17 Nov 1997 10:08:06 -0800." Date: Fri, 21 Nov 1997 10:54:49 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At 6:38 PM -0800 11/14/97, Mark.Andrews@cmis.CSIRO.AU wrote: > > All this indicates is that IPv6 need a mechanism to force > > fragmentation to the IPv6 MTU, rather than doing PMTU discovery > > at the socket level so that those applications that won't > > benefit from, or will be aversely effected by PMTU discovery > > will work. > > Mark, > > I agree that it would be good to make that a required feature of the IPv6 > API, but even with such a feature, I think we should also raise the minimum > IPv6 MTU as I proposed, in order that fewer packets will require IP-level > fragmentation, and in order to reduce header overhead, on the many links > whose MTUs are greater than 576. Wherever there's any non-negligible risk > of packet loss, it is best to minimize dependence on fragmentation, e.g., > by limiting to only those links that really need it, because of the really > bad effects fragment loss can have on end-to-end throughput. > > Steve > > > Agreed. Below is what I was going to submit a year ago but didn't actually get around to doing. It needs some work to update it. Mark INTERNET-DRAFT Mark Andrews (CSIRO) July 1996 Forcing Fragmentaion to Network MTU Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract There exists a class of applications which cannot accept Path MTU discovery [RFC-1191]. This is reccommended to be turned on by default for IPv6 [RFC-1883, 4.5, 5]. This document describes an extension to the [BSD-API] to inform the kernel when it should be fragmenting at the network MTU rather than trying to discover the path MTU. Path MTU discovery works well when there is a stream of data. However for distributed servers sending small answers larger than the network MTU to many clients the lack of fragmentation in intermediate nodes is an athema. 1 - No Path MTU Discovery Disabling path MTU. This would be a binary option, running a per socket basis. If set the kernel would fragment all IP packets generated by this Expires January 1997 [Page 1] INTERNET-DRAFT BSD FRAGMENT June 1996 socket at the network MTU (576) [RFC-1883, 5] unless it has aprior knowledge of the path MTU which it would then use. int discover = 0; if (setsockopt(s, IPPROTO_IPV6, IPV6_MTU_DISCOVER, (char*) &discover, sizeof(discover)) == -1) perror("setsockopt IPV6_MTU_DISCOVER"); 2 - Setting IP Fragmentation Size A socket option to explicity set the maximum IP fragment size for mes- sages derived from this socket. This should be used when it is known that the path MTU is greater than the network MTU. When combined with disabling path MTU discovery the resultant behaviour should be the same as if the network MTU was set to this value. size_t mtu = 576; if (setsockopt(s, IPPROTO_IPV6, IPV6_MTU, (char*) &mtu, sizeof(mtu)) == -1) perror("setsockopt IPV6_MTU"); 3 - Security Considerations This document is believed to introduce no security problems. References [RFC-1191] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990. [RFC-1883] Deering, S., and Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks, December 1995. [BSD-API] Work In Progress. Gilligan, R. E., Thomson, S., Bound, J., "Basic Socket Interface Extensions for IPv6", , Sun, Bellcore, Digital, April 1996. Expires January 1997 [Page 2] INTERNET-DRAFT BSD FRAGMENT June 1996 Authors' Addresses Mark Andrews CSIRO - Division of Mathematics and Statistics Locked Bag 17 North Ryde NSW 2113 AUSTRALIA +61 2 325 3148 Expires January 1997 [Page 3] -- Mark Andrews, CSIRO Mathematical and Information Sciences Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 9325 3148 INTERNET: Mark.Andrews@cmis.csiro.au MOBIL: +61 41 442 9884 UUCP:....!uunet!cmis.csiro.au!mark.andrews -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 09:52:18 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA27044 for ipng-dist; Fri, 21 Nov 1997 09:48:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA27037 for ; Fri, 21 Nov 1997 09:48:13 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA00662 for ; Fri, 21 Nov 1997 09:48:12 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01199; Fri, 21 Nov 1997 09:47:59 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id SAA25749 for ; Thu, 20 Nov 1997 18:29:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA27054 for ; Thu, 20 Nov 1997 18:29:16 -0800 Received: from sheltie.cisco.com (sheltie.cisco.com [171.69.219.130]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA21902 for ; Thu, 20 Nov 1997 18:29:17 -0800 (PST) Received: from bgleeson-ss20.cisco.com (bgleeson-ss20.cisco.com [171.69.193.208]) by sheltie.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id SAA24092; Thu, 20 Nov 1997 18:29:14 -0800 (PST) From: Bryan Gleeson Received: (bgleeson@localhost) by bgleeson-ss20.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) id SAA16616; Thu, 20 Nov 1997 18:29:14 -0800 (PST) Date: Thu, 20 Nov 1997 18:29:14 -0800 (PST) Message-Id: <199711210229.SAA16616@bgleeson-ss20.cisco.com> To: amalis@alpo.casc.com, bgleeson@cisco.com Subject: (IPng 4941) Re: IPv6 over ATM encapsulation Cc: gja@dnrc.bell-labs.com, ion@nexen.com, ipng@sunroof.eng.sun.com, malis@alpo.casc.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andy, >So, given your discussion, I am mostly interested in removing the use >of null encapsulation for PVCs. However, given the restrictions in >section 3.2.3, do you think it makes sense to support it for SVCs as >well? I don't have a strong opinion on PVCs, but for SVCs I do not see a need or benefit to changing the current IPV4/ATM and MPOA behaviour, which allows, but does not require, a non-default encapsulation. The only restriction in 3.2.3. is that MARS is not allowed to negotiate a non-default encapsulation, the rest is observations on what happens if the null encapsulation is negotiated according to the rules in UNI signalling. Even if that MARS restriction is introduced, there is no need to prohibit the use of the null encapsulation for data flows between other stations. The overhead of the negotiation to force LLC, if that is all a station supports, is trivial, and is needed anyway for IPV4 and MPOA. I'll admit that the use of the null encapsulation is probably about the same as the use of esperanto in the real world, but if two esperanto speakers ever meet, why prohibit them from talking esperanto? No one is being forced to learn or speak it! Bryan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 10:01:16 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA27087 for ipng-dist; Fri, 21 Nov 1997 09:58:39 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA27080 for ; Fri, 21 Nov 1997 09:58:33 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA20316 for ; Fri, 21 Nov 1997 09:58:32 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01240; Fri, 21 Nov 1997 09:58:20 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id FAA26682 for ; Fri, 21 Nov 1997 05:41:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA07346 for ; Fri, 21 Nov 1997 05:41:42 -0800 Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id FAA11649 for ; Fri, 21 Nov 1997 05:41:42 -0800 (PST) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id IAA01350; Fri, 21 Nov 1997 08:39:08 -0500 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id IAA05278; Fri, 21 Nov 1997 08:41:25 -0500 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id IAA02031; Fri, 21 Nov 1997 08:41:24 -0500 Date: Fri, 21 Nov 1997 08:41:23 -0500 (EST) From: "Andrew G. Malis" X-Sender: amalis@spice To: Bryan Gleeson cc: amalis@alpo.casc.com, gja@dnrc.bell-labs.com, ion@nexen.com, ipng@sunroof.eng.sun.com, malis@alpo.casc.com Subject: (IPng 4942) Re: IPv6 over ATM encapsulation In-Reply-To: <199711210229.SAA16616@bgleeson-ss20.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bryan, > I'll admit that the use of the null encapsulation is probably > about the same as the use of esperanto in the real world, but > if two esperanto speakers ever meet, why prohibit them from > talking esperanto? No one is being forced to learn or speak it! OK, in the absence of other opinions, we'll remove null encapsulation for PVCs but retain it as an option for SVCs. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 10:12:49 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA27123 for ipng-dist; Fri, 21 Nov 1997 10:09:31 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA27116 for ; Fri, 21 Nov 1997 10:09:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA22361 for ; Fri, 21 Nov 1997 10:09:18 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA23828 for ; Fri, 21 Nov 1997 10:08:17 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA15524 for ; Fri, 21 Nov 1997 12:46:44 -0500 (EST) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA02736; Fri, 21 Nov 1997 12:46:42 -0500 Date: Fri, 21 Nov 1997 12:46:42 -0500 From: Jack McCann Message-Id: <199711211746.AA02736@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4943) comments on bsd-api-new-00 Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to suggest a slightly different take on the default behavior of gethostbyname3() (i.e. when flags == 0). The default (flags == 0) behavior should be: - returns a pointer to a buffer of the same type as gethostbyname(), be that static or per-thread static or whatever else today's implementations might be doing; the caller must set a flag e.g. AI_ALLOC to cause gethostbyname3() to return dynamically allocated memory, and only then is the caller required to free the pointer using freehostent() - if the 'af' argument is AF_INET6, gethostbyname3() may return IPv4-mapped IPv6 addresses and non-IPv4-mapped IPv6 addresses; the choice of when to return a v4-mapped address or a non-v4-mapped IPv6 address is left to the implementation; the caller must set a flag e.g. AI_NOV4MAPPED to restrict the returned addresses to non-v4-mapped IPv6 addresses This provides a simple port from gethostbyname to gethostbyname3 for programs using AF_INET6 sockets: gethostbyname(host) -> gethostbyname3(host, AF_INET6, 0) Perhaps AI_V6ADDRCONFIG should be the default behavior as well, and require the caller to set a flag e.g. AI_IGNORE_ADDR_CONFIG that says "I want the address(es) for this name regardless of the types of addresses configured on the system". In any event such a flag should not be limited to IPv6 addresses, one might also find an A record for a node but have no IPv4 stack (or address) and therefore not bother returning the IPv4 address. As for gethostbyaddr(), I don't think we should simply change the function to return dynamically allocated memory by default. We must consider source and binary compatibility for existing users of gethostbyaddr(). We should either define a new function (ow! I feel a flags argument coming on :-) or define a compile time option that forces the new behavior. I'm not fond of either but gethostbyaddrwithflags() sounds better at the moment. Or dare I say just use getnameinfo() if you want thread safety? In section 6.2 there are references to "PTR" queries. Given the current discussions around DBIT et.al., and with a nod to non-DNS lookups, I'd like to see this text: 2. If af is AF_INET, then query for a PTR record in the in- addr.arpa domain. 3. If af is AF_INET6, then query for a PTR record in the ip6.int domain. changed to something akin to: 2. If af is AF_INET, perform an IPv4 address-to-name lookup. 3. If af is AF_INET6, perform an IPv6 address-to-name lookup. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 11:59:24 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA27224 for ipng-dist; Fri, 21 Nov 1997 11:56:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA27217 for ; Fri, 21 Nov 1997 11:56:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA25856 for ; Fri, 21 Nov 1997 11:56:11 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA24265 for ; Fri, 21 Nov 1997 11:55:58 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA13095; Sat, 22 Nov 1997 06:55:51 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.eng.sun.com Subject: (IPng 4944) Re: I-D ACTION: draft-ietf-ipngwg-aaaa-00.txt In-Reply-To: Pedro Marques's message of "Thu, 20 Nov 1997 21:29:57 -0800." References: <199711210215.VAA12479@postal.research.att.com> <199711210529.VAA22693@pedrom-ultra.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Nov 1997 06:55:49 +1100 Message-Id: <29003.880142149@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Nov 1997 21:29:57 -0800 (PST) From: Pedro Marques Message-ID: <199711210529.VAA22693@pedrom-ultra.cisco.com> | To give you an example, the smallest ISPs i'm familiar with typically have | two international links (us and europe) and a link to a local exchange. Are you serious? Maybe in the US that is true. maybe. Here only the very biggest ISPs have international links, and I think only a couple have more than one, and I doubt any is acting as transit for anyone (outside AU). That is, they're all at least one level down from the biggest ISPs. Below that there are a bunch of national AU only ISPs, with no international connectivity at all, and below those are a whole bunch of regional ISPs that serve just one area (maybe large, but much less than all of AU). Below those are a bunch more who call themselves ISPs but are really irrelevant to this discussion (everyone who connects to them renumbers every time they connect anyway). And then there are the customers with the end systems. | The point is why should they be considered in the addressing game at | all. If you have A, B and C where A provides transit for B and it's | clients, the addresses B uses inside it's own network are pretty much | irrelevant. And if B decides to change it's main transit provider he | will do it by multihoming with A and a new carrier. You can effectivly | reduce the problem to end clients changing top level transit network. The global problems we have today (routing table size problems) will soon become problems within the bigger ISPs (ignoring what other ISPs are advertising to them). They'll have to aggregate internally, as well as in what is advertised (and I suspect that many already do). Sometime later, the medium sized ISPs are going to get into exactly the same situation, and they're going to have to watch how they handle their internal addressing as well (within the constrained spaces they are given to use by their parent ISPs). By "their addressing" I mean all addresses advertised in their net of course, not the numbers they give their routers. Just imagine all the smart houses in China, with internal networks, linked to regional providers, with a million or so customers each, and a million or so of those regional providers - and that's just in one country, before we start getting international. That's not about to happen this week, or even this century, but it is very likely to within the lifespan of IPv6. And no, NAT is not the answer. Personally, I'm not sure I expect to see very rapid renumbering anytime soon, so renumbering half the world at a few seconds notice isn't something I worry about too much - on the other hand, I'm really not prepared to claim that that will never be a requirement, so if we can implement things in a way that it might be possible to make rapid large scale renumbering work, then good. What I do worry about is any renumbering. Or rather, I want to not worry about any renumbering. That I want taken care of by people who spend a lot of time investigating routing problems, network stability, etc - and I want to give them the freedom to renumber networks when they need to to keep the net functioning better. Similarly, I don't want to care about financial issues, I want the finance people to look at that, and when they can get better connectivity for less from some other ISP than they picked last month, I want them to be able to make that decision. And I don't care how much notice they give me that those kinds of changes are aboutto happen, minutes, days, months, even years - I don't want to be bothered by them at all. If they're going to make me work every time they see a benefit, I'm going to tell them I don't care abouttheir benefits (this is routing and net stability overall, or organisation wide costs) at all, only mine, and if I have to work to allow them to make things better, then I am goingto need at the very least a lot of justification, and probably some financial incentives to offset my costs. As I said last time, I'd much rather simply never even know the change happened. But if I have to resign anything, I will have to know about it. So, these things have to be able to be done without end user types having to do any work at all, regardless of how much time they would have to do it. It would be a lot easier to discuss this proposal if there were some technical arguments we could have, instead of these gut feeling noise fests. Aside from the obvious code point, and compatability issues, does anyone see any technical problems with the proposal? If we could at least get to the stage where we could all agree "this will work", then might be the right time for "but is it needed?" It seems silly to waste lots of time on arguments for which we know we can never find an absolute answer when we still haven't really investigated those issues for which we might get basic answers. So, is anyone prepared to claim that the AAAA part (at least) of Christian's proposal won't work, or won't scale, or is insecure, or ... (some technical objection) ?? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 12:03:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA27241 for ipng-dist; Fri, 21 Nov 1997 12:00:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA27234 for ; Fri, 21 Nov 1997 12:00:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA27134 for ; Fri, 21 Nov 1997 12:00:08 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA26367 for ; Fri, 21 Nov 1997 11:59:50 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA12218; Sat, 22 Nov 1997 06:59:42 +1100 (from kre@munnari.OZ.AU) To: ipng@sunroof.eng.sun.com Cc: Alan Barrett Subject: (IPng 4945) Re: Suggestion on DBIT Record from BIND Workers In-Reply-To: A message of "Fri, 21 Nov 1997 02:39:10 -0500." References: <199711210739.AA09177@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Nov 1997 06:59:41 +1100 Message-Id: <29019.880142381@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | Date: Wed, 19 Nov 1997 12:25:46 +0200 (GMT+0200) | From: Alan Barrett | To: bind-workers@vix.com | Message-Id: | It seems to me that you don't need the DBIT RR at all. [...] | This would requires a modification to the definition of tha CNAME RR, to | handle wildcards on the right hand side in a sensible way. There should be a new, different, DBIT proposal soon (I believe, I have seen the first rough draft, Jim probably has too). But changing CNAME as an alternative isn't attractive at all, that would be much harder to get deployed than a new record type. It also doesn't allow delegations on arbitrary bit boundaries, which is one of the things that the DBIT proposal (both of them actually) are attempting to achieve (no fixed 4 or 8 bit slices that need the CNAME stuff from the classless-inaddr draft to work around). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 14:06:49 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA27514 for ipng-dist; Fri, 21 Nov 1997 14:01:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA27507 for ; Fri, 21 Nov 1997 14:01:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA01940 for ; Fri, 21 Nov 1997 14:01:42 -0800 Received: from ux5.sp.cs.cmu.edu (UX5.SP.CS.CMU.EDU [128.2.198.221]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA27637 for ; Fri, 21 Nov 1997 14:01:36 -0800 (PST) Received: from localhost by ux5.sp.cs.cmu.edu id aa05798; 21 Nov 97 17:01 EST To: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com From: Dave Johnson Reply-To: Dave Johnson Subject: (IPng 4946) New Mobile IPv6 Internet-Draft submitted Date: Fri, 21 Nov 1997 17:01:04 -0500 Message-ID: <5796.880149664@ux5.sp.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have submitted a new version of the Mobile IPv6 Internet-Draft for publication before the Washington, DC IETF meeting. This will be draft-ietf-mobileip-ipv6-04.txt. This version cleans up a number of important things here and there in both the protocol and its presentation. The major differences between this version and the previous version include: - Added a statement of some non-goals of the protocol in Section 1. - Added definition for "home link" and "home subnet prefix", replacing the old term "home subnet". The new terms "foreign link" and "foreign subnet prefix" likewise replace the old term "foreign subnet". This change is more in line with current IPv6 terminology. - Moved the "Comparison with Mobile IP for IPv4" section (now Section 2) to earlier in the document to allow those familiar with Mobile IPv4 to quickly see the major differences. - Added specific language in Section overview listing the fields conceptually present in each Binding Cache entry and in each Binding Update List entry. - Changed the Option Type values for the Binding Acknowledgement and Binding Request options such that they now indicate that the option should be ignored if not recognized, rather than returning an ICMP error message as they were previously defined. - Increased the Lifetime field in a Binding Update from 16 bits to 32 bits, to allow consistency with other lifetime values used in IPv6 (e.g., the lifetime of a subnet prefix in Neighbor Discovery [11]). Similarly increased the Lifetime and Refresh fields in the Binding Acknowledgement from 16 bits to 32 bits. - Replaced the Home Link-Local Address Present (L) bit and the Home Link-Local Address field in the Binding Update with a new mechanism implemented by the ID Length field in the Binding Update. By specifying the length of the interface identifier in its home address in this field, the mobile node can request its home agent to essentially fully participate in Neighbor Discovery on the home link as a proxy for the mobile node, while the mobile node is away from home. - Clarified that packets addressed to a mobile node's link-local address or site-local address are not forwarded to the mobile node while away from home. When intercepted by the mobile node's home agent, such packets now cause the home agent to return an ICMP Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address). As the use of link-local addresses or site-local addresses evolves over time in IPv6, this disposition of such packets may need to change, however. - Added a discussion of sending Binding Requests in Section 7.6, and added a discussion of receiving Binding Requests in Section 9.11. - Change the requirement for sending a Binding Update to a mobile node's previous default router in Section 9.6 from "SHOULD" to "MAY". - Added Section 12 on "IANA Considerations". - Replaced the description of specification language keywords, "MUST", "MAY", "SHOULD", etc., in Section 3.3 with the new standard reference to RFC 2119. - Updated the References to point to the most recent version of each cited RFC or Internet-Draft. I have also put a copy of this draft on my ftp server, so you can get it before it works its way through to the official directories. The new version of the draft is available at ftp://ftp.monarch.cs.cmu.edu/pub/internet-drafts/ draft-ietf-mobileip-ipv6-04.txt Comments on this draft should be sent to the Mobile IP mailing list at mobile-ip@SmallWorks.COM. We will be discussing this draft during IETF at the Mobile IP working group meeting on Monday evening, December 8, 7:30-10:00 pm. Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 14:52:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA27570 for ipng-dist; Fri, 21 Nov 1997 14:49:22 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA27560 for ; Fri, 21 Nov 1997 14:49:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA16980 for ; Fri, 21 Nov 1997 14:49:08 -0800 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA03318 for ; Fri, 21 Nov 1997 14:49:06 -0800 Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA15328 for ; Fri, 21 Nov 1997 14:45:10 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Nov 1997 14:46:18 -0800 To: IPng Working Group From: Steve Deering Subject: (IPng 4947) new draft of base IPv6 spec submitted Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new version of the base IPv6 spec was submitted this morning. Below is the list of changes from the previous (July 30, 1997) draft. If the new draft doesn't show up soon in the ID directories, I'll make it available on a public FTP server. Steve ------ 01) In section 3, changed field name "Class" to "Traffic Class" and increased its size from 4 to 8 bits. Decreased size of Flow Label field from 24 to 20 bits to compensate for increase in Traffic Class field. 01) In section 4.1, restored the order of the Authentication Header and the ESP header, which were mistakenly swapped in the 00 version of this draft. 01) In section 4.4, deleted the Strict/Loose Bit Map field and the strict routing functionality from the Type 0 Routing header, and removed the restriction on number of addresses that may be carried in the Type 0 Routing header (was limited to 23 addresses, because of the size of the strict/loose bit map). 01) In section 5, changed the minimum IPv6 MTU from 576 to 1280 octets, and added a recommendation that links with configurable MTU (e.g., PPP links) be configured to have an MTU of at least 1500 octets. 01) In section 5, deleted the requirement that a node must not send fragmented packets that reassemble to more than 1500 octets without knowledge of the destination reassembly buffer size, and replaced it with a recommendation that upper-layer protocols or applications should not do that. 01) Replaced reference to the IPv4 Path MTU Discovery spec (RFC-1191) with reference to the IPv6 Path MTU Discovery spec (RFC-1981), and deleted the Notes at the end of section 5 regarding Path MTU Discovery, since those details are now covered by RFC-1981. 01) In section 6, deleted specification of "opportunistic" flow set- up, and removed all references to the 6-second maximum lifetime for opportunistically established flow state. 01) In section 7, deleted the provisional description of the internal structure and semantics of the Traffic Class field, and specified that such descriptions be provided in separate documents. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 21 16:02:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA27807 for ipng-dist; Fri, 21 Nov 1997 15:59:38 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA27800 for ; Fri, 21 Nov 1997 15:59:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA17990 for ; Fri, 21 Nov 1997 15:59:26 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA18856 for ; Fri, 21 Nov 1997 15:59:26 -0800 (PST) Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA23818 for ; Fri, 21 Nov 1997 15:59:25 -0800 Message-Id: <3.0.3.32.19971121155856.008d6220@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 21 Nov 1997 15:58:56 -0800 To: IPng Working Group From: Bob Hinden Subject: (IPng 4948) Re: new draft of base IPv6 spec submitted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >A new version of the base IPv6 spec was submitted this morning. Below is >the list of changes from the previous (July 30, 1997) draft. If the >new draft doesn't show up soon in the ID directories, I'll make it available >on a public FTP server. I copy can now be found as: ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-ipv6-spec-v2-01.txt Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 22 04:45:06 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id EAA28672 for ipng-dist; Sat, 22 Nov 1997 04:42:28 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id EAA28665 for ; Sat, 22 Nov 1997 04:42:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA03794 for ; Sat, 22 Nov 1997 04:42:15 -0800 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA03431 for ; Sat, 22 Nov 1997 04:42:15 -0800 (PST) Received: from rodan.UU.NET by relay3.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdqtm06726; Sat, 22 Nov 1997 07:42:17 -0500 (EST) Received: by rodan.UU.NET id QQdqtm24584; Sat, 22 Nov 1997 07:42:05 -0500 (EST) Date: Sat, 22 Nov 1997 07:42:05 -0500 (EST) From: mo@UU.NET (Mike O'Dell) Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 4949) change IPv6 DNS records.... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the fact that people are already imagining "deployed base" arguments against fixing fundamental problems is pretty scary, not to mention complete nonsense the 6bone is an EXPERIMENT - the intent is that it change and evolve so we know what to do if and when it really deploys if you aren't willing to make such important changes, then you are already doomed -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 23 09:49:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA29464 for ipng-dist; Sun, 23 Nov 1997 09:47:11 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA29457 for ; Sun, 23 Nov 1997 09:47:02 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA21968 for ; Sun, 23 Nov 1997 09:46:59 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA00677 for ; Sun, 23 Nov 1997 09:47:00 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA02336; Sun, 23 Nov 1997 12:43:12 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA02331; Sun, 23 Nov 1997 12:43:10 -0500 Message-Id: <199711231743.AA02331@wasted.zk3.dec.com> To: Sally Floyd Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com, kkrama@research.att.com Subject: (IPng 4952) Re: ECN - one bit or two? In-Reply-To: Your message of "Wed, 19 Nov 1997 17:45:56 PST." <199711200145.RAA05909@owl.ee.lbl.gov> Date: Sun, 23 Nov 1997 12:43:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >CONCLUSION: >My conclusion would be that the two-bit approach is more robust >than the one-bit approach. As far as I know, there is consensus that >the two-bit approach is viable; I don't know that there is rough >consensus that the one-bit approach is viable. I conncur with this after your mail. Implementations also I believe have a better chance of implementing this and having it work with two bits. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 23 22:50:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id WAA29860 for ipng-dist; Sun, 23 Nov 1997 22:47:56 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id WAA29853 for ; Sun, 23 Nov 1997 22:47:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA22081 for ; Sun, 23 Nov 1997 22:47:40 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id WAA16351 for ; Sun, 23 Nov 1997 22:47:44 -0800 (PST) Received: from spruce.ipsilon.com ([205.226.22.76]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id WAA25969; Sun, 23 Nov 1997 22:46:36 -0800 Message-Id: <3.0.3.32.19971123224535.009337b0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 23 Nov 1997 22:45:35 -0800 To: Jeffrey Burgan From: Bob Hinden Subject: (IPng 4955) Request to Advance "IP Header Compression" Cc: narten@raleigh.ibm.com, scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IP Header Compression Author(s) : S. Pink, M. Degermark, B. Nordgren Filename : draft-degermark-ipv6-hc-04.txt Pages : 45 Date : 20-Nov-97 This document is a product of the IPng working group. A working group last call for this document was completed and the document was discussed at the Munich IETF IPng session. This draft incorporates changes based on comments received during the w.g. last call and IPng session discussion. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 09:49:36 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA00297 for ipng-dist; Mon, 24 Nov 1997 09:46:15 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA00290 for ; Mon, 24 Nov 1997 09:46:04 -0800 (PST) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA08304; Mon, 24 Nov 1997 09:46:02 -0800 (PST) Date: Mon, 24 Nov 1997 09:46:02 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4956) Re: change IPv6 DNS records.... To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > the fact that people are already imagining "deployed base" > arguments against fixing fundamental problems is pretty scary, > not to mention complete nonsense > > the 6bone is an EXPERIMENT - the intent is that it change and evolve > so we know what to do if and when it really deploys > > if you aren't willing to make such important changes, then you are > already doomed I agree that be must be able to change things based on experience. But ... I don't know if this applies to the proposed DNS changes but we should try to avoid a flag day on the 6bone and also avoid all the vendors having to update their implementatations in a coordinated fashion. We already have some problems with this for the changed to the solicited node multicast address range which forced the vendors to update their implementations in consert in order to maintain interoperability. As the number of 6bone sites as well as the number of IPv6 vendors increase we have to spend some more time thinking about incremental deployment of changes to IPv6. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 10:50:20 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id KAA00471 for ipng-dist; Mon, 24 Nov 1997 10:47:03 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id KAA00464 for ; Mon, 24 Nov 1997 10:46:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA18629 for ; Mon, 24 Nov 1997 10:46:48 -0800 Received: from Argus.montgomerybell.com (argus.montgomerybell.com [207.234.44.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA28271 for ; Mon, 24 Nov 1997 10:46:26 -0800 (PST) Received: from localhost (halacha@localhost) by Argus.montgomerybell.com (8.8.7/8.8.7) with SMTP id MAA02502 for ; Mon, 24 Nov 1997 12:46:22 -0600 (CST) Date: Mon, 24 Nov 1997 12:46:22 -0600 (CST) From: Alan Halachmi X-Sender: halacha@Argus cc: ipng@sunroof.eng.sun.com Subject: (IPng 4957) Re: change IPv6 DNS records.... 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 This may be a very narrow minded view: It is important for the 6bone to develop into something that all of us know will last a long time. However, if the changing never winds down at some point (in the near future), the standards will come later in the game, and, as a result, the process of moving the rest of the Internet over will be more difficult and more haphazard. Alan Halachmi, Head of Internet Services Solaris Administrator/ Web Design Montgomery Bell Academy mailto:HalachA@MontgomeryBell.com http://www.montgomerybell.com On Mon, 24 Nov 1997, Erik Nordmark wrote: > > > > the fact that people are already imagining "deployed base" > > arguments against fixing fundamental problems is pretty scary, > > not to mention complete nonsense > > > > the 6bone is an EXPERIMENT - the intent is that it change and evolve > > so we know what to do if and when it really deploys > > > > if you aren't willing to make such important changes, then you are > > already doomed > > I agree that be must be able to change things based on experience. But ... > > I don't know if this applies to the proposed DNS changes but we should try > to avoid a flag day on the 6bone and also avoid all the vendors having to > update their implementatations in a coordinated fashion. > > We already have some problems with this for the changed to the solicited > node multicast address range which forced the vendors to update their > implementations in consert in order to maintain interoperability. > > As the number of 6bone sites as well as the number of IPv6 vendors increase > we have to spend some more time thinking about incremental deployment of > changes to IPv6. > > Erik > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 11:25:29 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA00586 for ipng-dist; Mon, 24 Nov 1997 11:22:16 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id LAA00579 for ; Mon, 24 Nov 1997 11:22:11 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id LAA29130 for ; Mon, 24 Nov 1997 11:22:10 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06394; Mon, 24 Nov 1997 11:21:56 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id WAA29828 for ; Sun, 23 Nov 1997 22:02:40 -0800 (PST) From: bgleeson@cisco.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA19004 for ; Sun, 23 Nov 1997 22:02:38 -0800 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA04728 for ; Sun, 23 Nov 1997 22:02:40 -0800 (PST) Received: from bgleeson-ss20.cisco.com (bgleeson-ss20.cisco.com [171.69.193.208]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id WAA05616; Sun, 23 Nov 1997 22:02:39 -0800 (PST) Received: (bgleeson@localhost) by bgleeson-ss20.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.WS.1.2) id WAA17936; Sun, 23 Nov 1997 22:02:38 -0800 (PST) Date: Sun, 23 Nov 1997 22:02:38 -0800 (PST) Message-Id: <199711240602.WAA17936@bgleeson-ss20.cisco.com> To: Mohsen.Souissi@inria.fr, amalis@alpo.casc.com Subject: (IPng 4959) Re: IPv6 over ATM encapsulation Cc: Francis.Dupont@inria.fr, gja@dnrc.bell-labs.com, ion@nexen.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Francis Dupont and I were just discussing the possibility of removing the= >null >encapsulation option from draft-ietf-ion-ipv6-atm-00.txt. >We think that's a good idea for two reasons: >- the null encapsulation is fairly limiting and useless = >- the less options there are, the likelier (and the better) one can = >interoperate I will make two points about interoperability 1) If there is a default (and there is - LLC) which is mandatory to implement then there is no interoperability problem. 2) Systems today are required to assume that a remote party may try to negotiate the encapsulation. That is, a system cannot assume that in a SETUP there will only be one BLLI element, or that the first BLLI element will indicate LLC. It can assume that one of the BLLI elements will indicate LLC, otherwise there is a protocol error. If the negotiation of an alternate encapsulation is prohibited then this may lead to implementations that assume there will only be one BLLI element and that it is LLC. This introduces a change in the IPV4/ATM and IPV6/ATM behaviours which is likely to cause interoperability problems rather than diminish them, given that there are likely to be systems that speak both IPV4 and IPV6 and use the same signalling stack. Bryan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 11:36:48 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id LAA00705 for ipng-dist; Mon, 24 Nov 1997 11:33:49 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id LAA00698 for ; Mon, 24 Nov 1997 11:33:35 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id LAA00737 for ; Mon, 24 Nov 1997 11:33:19 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06465; Mon, 24 Nov 1997 11:32:45 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id LAA00516 for ; Mon, 24 Nov 1997 11:06:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA25305 for ; Mon, 24 Nov 1997 11:06:52 -0800 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA11032 for ; Mon, 24 Nov 1997 11:06:42 -0800 (PST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id NAA04922; Mon, 24 Nov 1997 13:06:01 -0600 (CST) Comments: ( Received on motgate.mot.com from client mothost.mot.com, sender dan@dma.isg.mot.com ) Received: from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by mothost.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id NAA24654; Mon, 24 Nov 1997 13:05:44 -0600 (CST) Received: from dma.isg.mot.com (data.dma.isg.mot.com [150.20.50.34]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id OAA26237; Mon, 24 Nov 1997 14:05:41 -0500 (EST) Message-Id: <199711241905.OAA26237@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.9 8/22/96 To: bgleeson@cisco.com cc: Mohsen.Souissi@inria.fr, amalis@alpo.casc.com, Francis.Dupont@inria.fr, gja@dnrc.bell-labs.com, ion@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 4960) Re: IPv6 over ATM encapsulation In-reply-to: Your message of "Sun, 23 Nov 1997 22:02:38 EST." <199711240602.WAA17936@bgleeson-ss20.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Nov 1997 14:06:16 -0500 From: Dan Grossman Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Francis Dupont and I were just discussing the possibility of removing the= > >null > >encapsulation option from draft-ietf-ion-ipv6-atm-00.txt. > >We think that's a good idea for two reasons: > >- the null encapsulation is fairly limiting and useless = > >- the less options there are, the likelier (and the better) one can = > >interoperate > > I will make two points about interoperability > > 1) If there is a default (and there is - LLC) which is mandatory > to implement then there is no interoperability problem. > > 2) Systems today are required to assume that a remote party may > try to negotiate the encapsulation. That is, a system cannot assume > that in a SETUP there will only be one BLLI element, or that the > first BLLI element will indicate LLC. It can assume that one of the > BLLI elements will indicate LLC, otherwise there is a protocol error. > If the negotiation of an alternate encapsulation is prohibited > then this may lead to implementations that assume there will only > be one BLLI element and that it is LLC. This introduces a change > in the IPV4/ATM and IPV6/ATM behaviours which is likely to cause > interoperability problems rather than diminish them, given that > there are likely to be systems that speak both IPV4 and IPV6 > and use the same signalling stack. > > Bryan > We put null encapsulation in RFC 1483 for a reason. The reason was that for ATM VCs that only carry IPV4, a TCP SYN, FIN or ACK will exactly fit into one ATM cell (taking into account the AAL5 trailer) if no TCP or IP options are turned on. Obviously, an IPV6 header barely fits into an ATM cell, even if no extension headers are used. However, has anybody taken a look at whether there are frequent three-cell scenarios which could become two-cell scenarios by removing the SNAP header (common combinations of IPV6 extension headers, TCP options and/or very common user data that add up to 82-88 bytes?) There was a thread earlier (which unfortunately got dropped) on the possibility of header compression for IPV4; if we did something like that for IPV6, could we get TCP ACKs back down to one cell? It seems that some people in the IP community snipe at ATM for the alleged cell tax. If this is a sincere concern, then perhaps we ought to be looking not to preclude ways of reducing overhead to avoid crossing cell boundaries. I'd like to see the null encapsulation retained for both PVCs and SVCs. Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 12:10:08 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA00764 for ipng-dist; Mon, 24 Nov 1997 12:07:28 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id MAA00757 for ; Mon, 24 Nov 1997 12:07:23 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id MAA05679 for ; Mon, 24 Nov 1997 12:07:23 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA06560; Mon, 24 Nov 1997 12:07:08 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA00745 for ; Mon, 24 Nov 1997 12:05:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA13239 for ; Mon, 24 Nov 1997 12:05:18 -0800 Received: from dawn.bna.boeing.com (dawn.bna.boeing.com [129.172.51.52]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA14817 for ; Mon, 24 Nov 1997 12:05:16 -0800 (PST) Received: from arl.bna.boeing.com (rk6735.arl.bna.boeing.com [199.191.48.148]) by dawn.bna.boeing.com (8.8.5/8.8.5) with ESMTP id MAA00366; Mon, 24 Nov 1997 12:00:21 -0800 (PST) Message-ID: <3479DD1C.85F75E4D@arl.bna.boeing.com> Date: Mon, 24 Nov 1997 15:01:32 -0500 From: Albert Manfredi Organization: Boeing North American X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Dan Grossman CC: ion@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 4962) Re: IPv6 over ATM encapsulation References: <199711241905.OAA26237@prospero.dma.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan Grossman wrote: [ ... ] > It seems that some people in the IP community snipe at ATM for the alleged > cell tax. If this is a sincere concern, then perhaps we ought to be looking > not to preclude ways of reducing overhead to avoid crossing cell boundaries. > > I'd like to see the null encapsulation retained for both PVCs and SVCs. Seems to me that the "ATM cell tax" is a specious concern. Not that reducing overhead isn't by itself A Good Thing, but to do this based on "cell tax" doesn't stand the test of common sense. Compare the individual clock pulses required of IP over ATM compared with IP over 10Base-T Ethernet (or 10Base-anything, i.e. Manchester), and ATM almost always wins out. This _includes_ ACK frames. The problem here is one of semantics in marketing, not real world. To keep the playing field even, OC-3-based ATM should always have been called "135 Mb/s." Alternatively, 10 Mb/s Ethernet should always have been called 20Base-whatever, and FDDI should have been called 125 Mb/s. If an excess of complication is added only to appease the "cell tax" contingent, perhaps I'm saying it's not justified by real arguments. Cell tax is either small or non-existent compared with "4B/5B tax" or "Manchester encoding" tax. Ultimately, one pays for baud rate, not net bit rate. Bert manfredi@arl.bna.boeing.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 12:56:24 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id MAA00796 for ipng-dist; Mon, 24 Nov 1997 12:51:29 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id MAA00788 for ; Mon, 24 Nov 1997 12:48:37 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA23897 for ; Mon, 24 Nov 1997 12:47:57 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA06215 for ; Mon, 24 Nov 1997 12:47:59 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id PAA25424; Mon, 24 Nov 1997 15:47:55 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id PAA12538; Mon, 24 Nov 1997 15:47:55 -0500 (EST) Date: Mon, 24 Nov 1997 15:47:55 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971124154754.ZM12536@seawind.bellcore.com> In-Reply-To: Albert Manfredi "(IPng 4962) Re: IPv6 over ATM encapsulation" (Nov 24, 3:01pm) References: <199711241905.OAA26237@prospero.dma.isg.mot.com> <3479DD1C.85F75E4D@arl.bna.boeing.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Albert Manfredi , Dan Grossman Subject: (IPng 4963) Re: IPv6 over ATM encapsulation Cc: ion@nexen.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The problem here is one of semantics in marketing, not real world. > To keep the playing field even, OC-3-based ATM should always have > been called "135 Mb/s." Alternatively, 10 Mb/s Ethernet should > always have been called 20Base-whatever, and FDDI should have been > called 125 Mb/s. Uh? the "cell tax" argument usually refer to the comparison of two well defined stacks, IP>PPP>Sonet and IP>PPP>ATM>Sonet. A classic case of whether the overhead (cell) is worth the functionality (switching). Opinions are known to vary. In any case, this discussion has only a minimal relation to the design and implementation of IPv6. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 13:28:23 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA00900 for ipng-dist; Mon, 24 Nov 1997 13:22:27 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id NAA00891 for ; Mon, 24 Nov 1997 13:22:11 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id NAA15222 for ; Mon, 24 Nov 1997 13:22:03 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA06867; Mon, 24 Nov 1997 13:20:34 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA00846 for ; Mon, 24 Nov 1997 13:12:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA29771 for ; Mon, 24 Nov 1997 13:12:35 -0800 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA18429 for ; Mon, 24 Nov 1997 13:12:37 -0800 (PST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id PAA21376; Mon, 24 Nov 1997 15:05:40 -0600 (CST) Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender dan@dma.isg.mot.com ) Received: from prospero.dma.isg.mot.com (prospero.dma.isg.mot.com [150.20.1.20]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id PAA17678; Mon, 24 Nov 1997 15:05:34 -0600 (CST) Received: from dma.isg.mot.com (data.dma.isg.mot.com [150.20.50.34]) by prospero.dma.isg.mot.com (8.7.5/8.6.12) with ESMTP id QAA02533; Mon, 24 Nov 1997 16:05:08 -0500 (EST) Message-Id: <199711242105.QAA02533@prospero.dma.isg.mot.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Albert Manfredi cc: ion@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 4967) Re: IPv6 over ATM encapsulation In-reply-to: Your message of "Mon, 24 Nov 1997 15:01:32 EST." <3479DD1C.85F75E4D@arl.bna.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 24 Nov 1997 16:05:43 -0500 From: Dan Grossman Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Dan Grossman wrote: > > [ ... ] > > > It seems that some people in the IP community snipe at ATM for the alleged > > cell tax. If this is a sincere concern, then perhaps we ought to be looking > > not to preclude ways of reducing overhead to avoid crossing cell boundaries. > > > > I'd like to see the null encapsulation retained for both PVCs and SVCs. > > Seems to me that the "ATM cell tax" is a specious concern. Not that I agree. But there are some people who make an issue of it. > reducing overhead isn't by itself A Good Thing, but to do this based > on "cell tax" doesn't stand the test of common sense. Well, ok, I think we can agree that reducing overhead is a Good Thing. I would add that one reason is it's a good thing is that there are some who have unfounded concerns about ATM efficiency that should be addressed. > > Compare the individual clock pulses required of IP over ATM compared > with IP over 10Base-T Ethernet (or 10Base-anything, i.e. ... and Gigabit Ethernet > Manchester), and ATM almost always wins out. This _includes_ ACK > frames. > > The problem here is one of semantics in marketing, not real world. > To keep the playing field even, OC-3-based ATM should always have > been called "135 Mb/s." Alternatively, 10 Mb/s Ethernet should > always have been called 20Base-whatever, and FDDI should have been > called 125 Mb/s. The marketing issue is a real one: it makes for nice ad-hominem attacks. And the 135 Mbit/s number assumes full utilization of the ATM cell payload: a 46 byte datagram has 43% efficiency, while a 40 byte datagram has 90% efficiency. > > If an excess of complication is added only to appease the "cell tax" > contingent, perhaps I'm saying it's not justified by real arguments. > Cell tax is either small or non-existent compared with "4B/5B tax" > or "Manchester encoding" tax. Ultimately, one pays for baud rate, > not net bit rate. I don't think it adds a lot of complexity. The negotiation machinery is part of everybody's portable signalling software, and once it's in place, it's probably just a test and branch in the driver. I think this little complexity is justified a) by taking an argument away from the ATM haters b) by the fact that I don't think anybody's done for IPV6 any analysis along the lines of Ramon Caceres' thesis on the effects of SAR on IPV4. and c) Bryan's interoperability arguments. Rgds Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 13:28:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA00911 for ipng-dist; Mon, 24 Nov 1997 13:22:33 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id NAA00899 for ; Mon, 24 Nov 1997 13:22:25 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id NAA15206 for ; Mon, 24 Nov 1997 13:21:59 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA06894; Mon, 24 Nov 1997 13:21:25 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA00858 for ; Mon, 24 Nov 1997 13:15:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA00693 for ; Mon, 24 Nov 1997 13:15:49 -0800 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA20073 for ; Mon, 24 Nov 1997 13:15:50 -0800 (PST) Received: (from smap@localhost) by ns.newbridge.com (8.8.8/8.6.12) id QAA28106; Mon, 24 Nov 1997 16:15:48 -0500 (EST) Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma028035; Mon Nov 24 16:15:37 1997 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 24 Nov 1997 21:15:36 UT Received: (from smap@localhost) by ca.newbridge.com. (8.8.6/8.8.6) id QAA14381; Mon, 24 Nov 1997 16:15:36 -0500 (EST) Received: from thor121.ca.newbridge.com(138.120.121.43) by kanmaster.ca.newbridge.com via smap (V1.3) id sma014155; Mon Nov 24 16:14:29 1997 Received: from pcswbdesk.us.newbridge.com ([192.168.102.106]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id QAA28094; Mon, 24 Nov 1997 16:14:28 -0500 Message-Id: <199711242114.QAA28094@thor.ca.newbridge.com> X-Sender: swb@thor.ca.newbridge.com X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 2 (build 233) Date: Mon, 24 Nov 1997 16:02:42 -0500 To: ion@nexen.com, ipng@sunroof.eng.sun.com From: Scott W Brim Subject: (IPng 4968) Re: IPv6 over ATM encapsulation In-Reply-To: <971124154754.ZM12536@seawind.bellcore.com> References: <199711241905.OAA26237@prospero.dma.isg.mot.com> <3479DD1C.85F75E4D@arl.bna.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:47 PM 11/24/97 -0500, Christian Huitema wrote: >In any case, this discussion has only a minimal relation to the design and >implementation of IPv6. Right. Please. ...Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 13:29:01 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id NAA00916 for ipng-dist; Mon, 24 Nov 1997 13:22:51 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id NAA00903 for ; Mon, 24 Nov 1997 13:22:28 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id NAA15241 for ; Mon, 24 Nov 1997 13:22:11 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA06921; Mon, 24 Nov 1997 13:21:56 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id NAA00863 for ; Mon, 24 Nov 1997 13:15:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA00706 for ; Mon, 24 Nov 1997 13:15:52 -0800 Received: from dawn.bna.boeing.com (dawn.bna.boeing.com [129.172.51.52]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA20106 for ; Mon, 24 Nov 1997 13:15:54 -0800 (PST) Received: from arl.bna.boeing.com (rk6735.arl.bna.boeing.com [199.191.48.148]) by dawn.bna.boeing.com (8.8.5/8.8.5) with ESMTP id NAA03440; Mon, 24 Nov 1997 13:12:46 -0800 (PST) Message-ID: <3479EE14.2664070D@arl.bna.boeing.com> Date: Mon, 24 Nov 1997 16:13:56 -0500 From: Albert Manfredi Organization: Boeing North American X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Christian Huitema CC: ion@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 4969) Re: IPv6 over ATM encapsulation References: <199711241905.OAA26237@prospero.dma.isg.mot.com> <3479DD1C.85F75E4D@arl.bna.boeing.com> <971124154754.ZM12536@seawind.bellcore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Placed in order of importance, Christian Huitema wrote: > In any case, this discussion has only a minimal relation to the design and > implementation of IPv6. True enough. > > The problem here is one of semantics in marketing, not real world. > > To keep the playing field even, OC-3-based ATM should always have > > been called "135 Mb/s." Alternatively, 10 Mb/s Ethernet should > > always have been called 20Base-whatever, and FDDI should have been > > called 125 Mb/s. > > Uh? the "cell tax" argument usually refer to the comparison of two well > defined stacks, IP>PPP>Sonet and IP>PPP>ATM>Sonet. A classic case of > whether the overhead (cell) is worth the functionality (switching). > Opinions are known to vary. Right, Christian. I know. Let's look at the complete overhead picture, IP over Manchester, IP over FDDI (4B/5B), and IP over ATM/SONET. IP over Manchester = 50 percent overhead, + Ethernet + IP overhead. Manchester requires two clocks per data bit. IP over FDDI = 20 percent overhead, + FDDI + LLC + IP overhead. 4B/5B requires frive clocks for 4 data bits. IP over ATM/SONET at OC-3 = 12.8 percent overhead + LLC + IP overhead. ATM and SONET use scrambling to ensure a low DC content, rather than extra clocks. Even if you point just to the ACK frames, compared with Manchester, ATM does better. Bert manfredi@arl.bna.boeing.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 14:09:50 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA01086 for ipng-dist; Mon, 24 Nov 1997 14:06:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA01079 for ; Mon, 24 Nov 1997 14:06:26 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14175 for ; Mon, 24 Nov 1997 14:06:24 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA15656 for ; Mon, 24 Nov 1997 14:06:26 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id QAA25921 for ; Mon, 24 Nov 1997 16:56:07 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00467; Mon, 24 Nov 1997 16:56:06 -0500 Message-Id: <199711242156.AA00467@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4970) New DHCPv6 Specs fyi (stateful addr conf) Date: Mon, 24 Nov 1997 16:56:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- Forwarded Message Return-Path: dhcp-v6@bucknell.edu Received: from quarry.zk3.dec.com by mailhub2.zk3.dec.com (5.65v3.2/1.1.10.5/24Sep96-0323PM) id AA25728; Mon, 24 Nov 1997 14:34:23 -0500 Received: from mail12.digital.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA24991; Mon, 24 Nov 1997 14:33:56 -0500 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id OAA05666; Mon, 24 Nov 1997 14:29:35 -0500 (EST) Received: from reef.bucknell.edu (reef.bucknell.edu [134.82.7.6]) by mail.bucknell.edu (8.8.8/8.8.8) with SMTP id OAA18608; Mon, 24 Nov 1997 14:24:56 -0500 (EST) Date: Mon, 24 Nov 1997 14:24:56 -0500 (EST) Message-Id: <199711241843.KAA02144@hsmpka.eng.sun.com> Errors-To: droms@bucknell.edu Reply-To: dhcp-v6@bucknell.edu Originator: dhcp-v6@bucknell.edu Sender: dhcp-v6@bucknell.edu Precedence: bulk From: Charles Perkins To: Multiple recipients of list Subject: DHCPv6 drafts X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Discussion list for DHCPv6 internet protocol. X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii Mime-Version: 1.0 Folks, I looked this morning and the new DHCPv6 Internet Drafts have not yet shown up on the standard websites, even though they were submitted with hundreds of billions of nanoseconds left to spare before the deadline. For people interested in getting copies of the drafts sooner, they are available at the following URLs: http://www.svrloc.org/~charliep/txt/dhcpv6/dhcpv6.txt and http://www.svrloc.org/~charliep/txt/dhcpv6/dhcpv6ext.txt If you have any problem retrieving these files, please let me know and I'll happily send them out. Regards, Charlie P. ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 24 14:15:32 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA01105 for ipng-dist; Mon, 24 Nov 1997 14:10:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA01096 for ; Mon, 24 Nov 1997 14:09:49 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA15266 for ; Mon, 24 Nov 1997 14:09:46 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA17345 for ; Mon, 24 Nov 1997 14:09:45 -0800 (PST) Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id QAA08826; Mon, 24 Nov 1997 16:50:23 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA32564; Mon, 24 Nov 1997 16:50:16 -0500 Message-Id: <199711242150.AA32564@wasted.zk3.dec.com> To: Alan Halachmi Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4971) Re: change IPv6 DNS records.... In-Reply-To: Your message of "Mon, 24 Nov 1997 12:46:22 CST." Date: Mon, 24 Nov 1997 16:50:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This may be a very narrow minded view: Not at all. Its an intelligent view from anyone who believes customers want IPv6 as soon as possible. Not everyone on this list agrees with that and thats fine. But I think we all have an "equal" voice here as Working Group members. So I don't think any comment is narrow minded and anyone who would say that is not being just or fair. > It is important for the 6bone to develop into something that all >of us know will last a long time. However, if the changing never >winds down at some point (in the near future), the standards will come >later in the game, and, as a result, the process of moving the rest of the >Internet over will be more difficult and more haphazard. There is nothing wrong with this request. I think Erik Nordmark responded in a very farir manner. I think we need to draw a line at some point and say this is what is and we implement. Then we work in the IETF to improve upon what we have. I highly suggest at this point we move 1886 to Draft Standard and if the work gets updated with a new DNS record so be it. But 1886 is deployed by over 25 implementations, is running in well over 400 sites, and the market has clearly told us vendors that they want IPv6. RFC 1886 should move to Draft Standard. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 25 06:56:38 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA02030 for ipng-dist; Tue, 25 Nov 1997 06:53:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA02023 for ; Tue, 25 Nov 1997 06:53:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA26511 for ; Tue, 25 Nov 1997 06:53:35 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA27657 for ; Tue, 25 Nov 1997 06:53:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA08429; Tue, 25 Nov 1997 09:53:31 -0500 (EST) Message-Id: <199711251453.JAA08429@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 4973) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-04.txt Date: Tue, 25 Nov 1997 09:53:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-04.txt Pages : 14 Date : 24-Nov-97 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-ipv6-over-ppp-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971124134705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-over-ppp-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971124134705.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 25 07:38:30 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id HAA02060 for ipng-dist; Tue, 25 Nov 1997 07:35:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id HAA02053 for ; Tue, 25 Nov 1997 07:35:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA11710 for ; Tue, 25 Nov 1997 07:35:38 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA18238 for ; Tue, 25 Nov 1997 07:35:39 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA10346; Tue, 25 Nov 1997 10:35:31 -0500 (EST) Message-Id: <199711251535.KAA10346@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 4974) I-D ACTION:draft-ietf-ipngwg-site-prefixes-01.txt Date: Tue, 25 Nov 1997 10:35:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Site prefixes in Neighbor Discovery Author(s) : E. Nordmark Filename : draft-ietf-ipngwg-site-prefixes-01.txt Pages : 15 Date : 24-Nov-97 This document specifies extensions to IPv6 Neighbor Discovery to carry site prefixes. The site prefixes are used to reduce the effect of site renumbering by ensuring that the communication inside a site uses site-local addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-site-prefixes-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-site-prefixes-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971124161546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-site-prefixes-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971124161546.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 25 09:05:00 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA02166 for ipng-dist; Tue, 25 Nov 1997 09:02:24 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA02159 for ; Tue, 25 Nov 1997 09:02:18 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA12259 for ; Tue, 25 Nov 1997 09:02:18 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07484; Tue, 25 Nov 1997 09:02:03 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA02011 for ; Tue, 25 Nov 1997 06:51:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA25997 for ; Tue, 25 Nov 1997 06:51:56 -0800 Received: from charity.harvard.net (charity.harvard.net [206.137.222.16]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA26905 for ; Tue, 25 Nov 1997 06:51:57 -0800 (PST) Received: from xedia.com (madway.xedia.com [198.202.232.199]) by charity.harvard.net (8.8.7/8.7.3) with SMTP id JAA26686; Tue, 25 Nov 1997 09:52:33 -0500 (EST) Received: from kona. by xedia.com (4.1/SMI-4.1) id AA25470; Tue, 25 Nov 97 09:50:21 EST Received: by kona. (5.x/SMI-SVR4) id AA08615; Tue, 25 Nov 1997 09:51:11 -0500 Date: Tue, 25 Nov 1997 09:51:11 -0500 Message-Id: <9711251451.AA08615@kona.> From: Paul Koning To: dan@dma.isg.mot.com Cc: manfredi@arl.bna.boeing.com, ion@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 4976) Re: IPv6 over ATM encapsulation References: <3479DD1C.85F75E4D@arl.bna.boeing.com> <199711242105.QAA02533@prospero.dma.isg.mot.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "FFFFDan" == Dan Grossman writes: >> If an excess of complication is added only to appease the "cell >> tax" contingent, perhaps I'm saying it's not justified by real >> arguments. Cell tax is either small or non-existent compared with >> "4B/5B tax" or "Manchester encoding" tax. Ultimately, one pays for >> baud rate, not net bit rate. FFFFDan> I don't think it adds a lot of complexity. The negotiation FFFFDan> machinery is part of everybody's portable signalling FFFFDan> software, and once it's in place, it's probably just a test FFFFDan> and branch in the driver. I think this little complexity is FFFFDan> justified a) by taking an argument away from the ATM haters FFFFDan> b) by the fact that I don't think anybody's done for IPV6 FFFFDan> any analysis along the lines of Ramon Caceres' thesis on the FFFFDan> effects of SAR on IPV4. and c) Bryan's interoperability FFFFDan> arguments. The complexity issue isn't in the negotiation or configuration. It is in the fact that it introduces a second format in the fastpath. Ok, so it's optional, but that's beside the point. Either it's useful, in which case I should use it (and take the performance hit in the fastpath) or it's not useful, in which case it would be preferable not to have it exist. The interesting question is: if it's useful to have null encapsulation, why isn't it the default? I've never heard of anyone running anything other than IP over 1483 LLC encapsulation, so that doesn't seem like the issue. On the other hand, there is one thing one does run alongside IP, i.e., ARP. Which brings up another question: is the option of null encapsulation actually meaningless because 1577 doensn't work if you tried to use it? paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 25 09:09:07 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA02217 for ipng-dist; Tue, 25 Nov 1997 09:06:39 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA02210 for ; Tue, 25 Nov 1997 09:06:33 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA12947 for ; Tue, 25 Nov 1997 09:06:33 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07529; Tue, 25 Nov 1997 09:06:18 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id IAA02113 for ; Tue, 25 Nov 1997 08:12:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA24284 for ; Tue, 25 Nov 1997 08:12:52 -0800 Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA07173 for ; Tue, 25 Nov 1997 08:12:49 -0800 (PST) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id LAA15719; Tue, 25 Nov 1997 11:06:33 -0500 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id LAA17289; Tue, 25 Nov 1997 11:08:53 -0500 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id LAA00585; Tue, 25 Nov 1997 11:08:52 -0500 Date: Tue, 25 Nov 1997 11:08:52 -0500 (EST) From: "Andrew G. Malis" X-Sender: amalis@spice Reply-To: "Andrew G. Malis" To: Dan Grossman cc: bgleeson@cisco.com, Mohsen.Souissi@inria.fr, amalis@alpo.casc.com, Francis.Dupont@inria.fr, gja@dnrc.bell-labs.com, ion@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 4977) Re: IPv6 over ATM encapsulation In-Reply-To: <199711241905.OAA26237@prospero.dma.isg.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, > Obviously, an IPV6 header barely fits into an ATM cell, even if no extension > headers are used. However, has anybody taken a look at whether there are > frequent three-cell scenarios which could become two-cell scenarios by > removing the SNAP header (common combinations of IPV6 extension headers, TCP > options and/or very common user data that add up to 82-88 bytes?) There was a > thread earlier (which unfortunately got dropped) on the possibility of header > compression for IPV4; if we did something like that for IPV6, could we get > TCP ACKs back down to one cell? IPv6 header compression, as specified in draft-degermark-ipv6-hc-04.txt, has the goal of compressing the IPv6 and UDP/TCP headers down to 4-7 octets. However, it is really aimed at "low- and medium-speed links", to quote the draft, and you certainly wouldn't want to have to be doing the compression and decompression in software at OC3+ rates, or have to build hardware to do it. Uncompressed TCP acks will fit in two cells whether or not LLC/SNAP headers are used. I'm not close enough into an IPv6 implementation to say if there are any common packets that are exactly 82-88 octets in length, but I would tend to doubt it. I would prefer to keep implementations and configuration simpler by not including null encapsulation on PVCs. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 25 14:54:40 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id OAA00694 for ipng-dist; Tue, 25 Nov 1997 14:51:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id OAA00687 for ; Tue, 25 Nov 1997 14:51:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA21929 for ; Tue, 25 Nov 1997 14:51:20 -0800 Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA12151 for ; Tue, 25 Nov 1997 14:51:13 -0800 (PST) Received: from rodan.UU.NET by relay7.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdrgd08286; Tue, 25 Nov 1997 17:51:09 -0500 (EST) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdrgd19724; Tue, 25 Nov 1997 17:51:08 -0500 (EST) Message-Id: To: bound@zk3.dec.com cc: Alan Halachmi , ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 4978) Re: change IPv6 DNS records.... In-reply-to: Your message of "Mon, 24 Nov 1997 16:50:16 EST." <199711242150.AA32564@wasted.zk3.dec.com> Date: Tue, 25 Nov 1997 17:51:08 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk No, it should not move to Draft with known serious scaling problems. that is one of the things V6 is supposed to address -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 25 15:39:12 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id PAA00766 for ipng-dist; Tue, 25 Nov 1997 15:36:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id PAA00759 for ; Tue, 25 Nov 1997 15:36:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA05672 for ; Tue, 25 Nov 1997 15:36:06 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id PAA04710 for ; Tue, 25 Nov 1997 15:36:07 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA17147; Tue, 25 Nov 1997 17:35:05 -0600 Message-Id: <199711252335.RAA17147@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4979) Router Renumbering Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mimeprimaryboundary Date: Tue, 25 Nov 1997 17:35:05 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain I told the chairs that if the draft didn't make it through the i-d- queue by Tuesday, I'd send a pointer, so here it is. This is the first version of Router Renumbering that could charitably be called complete. It's certainly not final, but the only major part missing is usage examples. So if you're keen to have a look before the draft gets through the queue (I'm sure it made the deadline), you can fetch a copy. Matt (Of course, now that I've sent this, it will pop up in the next hour.) --mimeprimaryboundary Content-Type: Message/External-body; name="router-renumber-02.txt"; site="berserk.fnal.gov"; access-type="anon-ftp"; directory="pub" Content-Type: text/plain Content-ID: <19971125172033.17104@gungnir.fnal.gov> --mimeprimaryboundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 25 23:46:22 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id XAA01392 for ipng-dist; Tue, 25 Nov 1997 23:43:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id XAA01385 for ; Tue, 25 Nov 1997 23:43:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA27519 for ; Tue, 25 Nov 1997 23:43:39 -0800 Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id XAA00861 for ; Tue, 25 Nov 1997 23:43:43 -0800 (PST) Received: from athira.india.hp.com (athira.india.hp.com [15.10.45.157]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id XAA07370 for ; Tue, 25 Nov 1997 23:43:34 -0800 (PST) Message-Id: <199711260743.XAA07370@palrel3.hp.com> Received: by athira.india.hp.com (1.40.112.12/16.2) id AA102790945; Wed, 26 Nov 1997 13:25:45 +0530 From: Divya H V Subject: (IPng 4981) Q: IPv4/IPv6 interoperability To: ipng@sunroof.eng.sun.com Date: Wed, 26 Nov 1997 13:25:44 +0530 (IST) Cc: hdivya@athira.india.hp.com (Divya H V) X-Mailer: ELM [Revision: 213.1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am working on an investigation on the code changes required for implementing IPv6 support for a server - in particular, the server should be able to support requests from both IPv4 as well IPv6 clients. We are using the Sockets API as defined in RFC 2133 for our investigation. RFC 2133 Section 3.7 : "Compatibility with IPv4 Nodes " mentions the following : "Applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect() or sendto() call. When applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way." Based on the above, Can the PF_INET6 sockets be used to service both the IPv4 as well as IPv6 clients? Or,does the server application need to open separate PF_INET and PF_INET6 sockets - PF_INET to service IPv4(only) nodes and PF_INET6 to service IPv6 nodes ? Thanks. Best Regards, Divya -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 26 06:47:09 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id GAA01648 for ipng-dist; Wed, 26 Nov 1997 06:44:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id GAA01641 for ; Wed, 26 Nov 1997 06:44:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA16603 for ; Wed, 26 Nov 1997 06:44:29 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA07393 for ; Wed, 26 Nov 1997 06:44:27 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.6/8.8.6) with ESMTP id JAA18335; Wed, 26 Nov 1997 09:44:23 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.5/8.6.12) id JAA01330; Wed, 26 Nov 1997 09:44:23 -0500 (EST) Date: Wed, 26 Nov 1997 09:44:23 -0500 (EST) From: huitema@bellcore.com (Christian Huitema) Message-Id: <971126094422.ZM1328@seawind.bellcore.com> In-Reply-To: "Mike O'Dell" "(IPng 4978) Re: change IPv6 DNS records...." (Nov 25, 5:51pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: "Mike O'Dell" Subject: (IPng 4982) Re: change IPv6 DNS records.... 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 Nov 25, 5:51pm, Mike O'Dell wrote: > Subject: (IPng 4978) Re: change IPv6 DNS records.... > > No, it should not move to Draft with known serious scaling problems. > > that is one of the things V6 is supposed to address Let's debate this in DC. What the draft proposes, in the new AAAA part, is the best possible support of network renumbering -- I can actually demonstrate that we cannot do better than meeting the "store a prefix exactly once" property. But it also proposes an automic support of multihoming, a point that seem to be lost when I hear arguments such as "but my ISP is multihomed." Let's be clear. Short of generalized address rewriting inside the network, there are three ways to support ISP multihoming: 1) allocate a single routing prefix to every multihomed ISP, regardless of its size. 2) implement geographic addressing. 3) allocate several routing prefixes to multihomed ISP, and derive from these prefixes an equal number of addresses for their customers. Solution number 1 is, by and large, what we are doing with IPv4. We have experience there, and the experience is ugly: the solution simply does not scale. Think of it: my coop board is installinga router to serve the building's resident. It thus become, de facto, a tiny ISP. And it will very probably multi-home. Solution 1, without a limit to the ISP size, would lead to "one entry in the global routing table per appartment building." Do you really like it? Solution 2 requires a massive investment in geographical exchanges, which will turn in de facto local monopolies. This may or may not happen in the future. I would not bet on it, let alone mandate it. Solution 3 is actually supported by IPv6 address configuration mechanisms, which can routinely assign several prefixes to a link and generate several addresses per interface. It places the burden where it should be, that is on the fringes of the network, in the stations. This is not an infinite burden -- merely handling a list of addresses. What the DNS draft proposes is to complement a three piece architecture comprised of: * address configuration, either automatic or through DHCP, * router renumbering, * support of automatic multihoming in the DNS. Now, supporting this is not equivalent to mandating it. ISP, at some point, may grow sufficiently and graduate to the "top" division; they will then get a top level address. And some governments may well mandate the use of monopolistic local exchanges. Who knows? the soviet mode of organizing society may stage a come back :-). But we are not in the business of policing the allocation of addresses, let alone mandating societal changes (specially that one). We are in the business of engineering IPv6. My position has not changed since August. I believe that we should implement the proposed change. I also believe that we should tweak the proposal to make it "upward compatible", in order to avoid a flag day on the 6Bone. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 26 09:34:49 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA01874 for ipng-dist; Wed, 26 Nov 1997 09:32:08 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with ESMTP id JAA01867 for ; Wed, 26 Nov 1997 09:32:02 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun.Beta.4/8.8.8) with SMTP id JAA04278 for ; Wed, 26 Nov 1997 09:32:01 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10164; Wed, 26 Nov 1997 09:31:46 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA01819 for ; Wed, 26 Nov 1997 09:06:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA00450 for ; Wed, 26 Nov 1997 09:06:36 -0800 Received: from ncc.ripe.net (ncc.ripe.net [193.0.0.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA20226 for ; Wed, 26 Nov 1997 09:06:15 -0800 (PST) Received: from kantoor.ripe.net by ncc.ripe.net with SMTP id AA03735 (5.65a/NCC-2.41); Wed, 26 Nov 1997 18:05:04 +0100 Message-Id: <9711261705.AA03735@ncc.ripe.net> To: iesg@ietf.org Cc: ipng@sunroof.eng.sun.com, RIPE Local Internet Registries WG , RIPE IPv6 WG , Rob Blokzijl Cc: hinden@ipsilon.com, "Mike O'Dell" , deering@cisco.com Cc: Kim Hubbard , David Conrad , Jon Postel Subject: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of Wed, 12 Nov 1997 18:30:53 EST. <199711122330.SAA27435@ietf.org> References: <199711122330.SAA27435@ietf.org> From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 Date: Wed, 26 Nov 1997 18:05:00 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Authors Robert Blokzijl RIPE Chair Daniel Karrenberg RIPE NCC General Manager Background RIPE is an organisation founded in 1989 wich aims to ensure the technical and administrative coordination necessary for the operation of the Internet in Europe [ripe-01]. The RIPE NCC performs activities for the benefit of the Internet service providers (ISPs) in Europe and the surrounding areas; primarily activities that the ISPs need to organise as a group, although they may be competing with each other in other areas. In particular the RIPE NCC, as Regional Internet Registry, allocates and assigns IPv4 address space in Europe and surrounding areas [ripe-162]. The RIPE NCC started operations in 1992. It currently allocates address space to more than 800 local Internet Registries almost all of which are operated by ISPs. The number of local IRs is expected to reach 1250 in 1998. There are currently no indications that the number of local IRs will stop growing. The authors have contributed significantly to the development of the distributed Internet registry system which is used for the allocation and assignment of provider based IPv4 address space today. As such they have ample experience with the development of address space allocation and assignment policies. One important element of current policies is that the size of address space allocations is determined by previous justified use of address space. A prerequisite for this policy is that the size of allocations can start small and increase or decrease according to previous justified usage [ripe-159]. Argument We believe is critically flawed because it standardises address aggregation boundaries without any explicit technical justification. In particular the length of the TLA and NLA fields are proposed to be standardised as fixed at prarticular values with no technical justification for either the fact that these lengths need to be fixed nor for the particular values chosen. The lack of technical justification is significant because the standardisation of TLA and NLA lengths directly influences many elements of Internet operations including address space allocation policies. In particular the TLA being fixed at 13bit length makes only 8K TLAs available per FP. Consequently Internet Registries will not be able to use proven allocation policies but rather engage in regulatory practises. The rules proposed in are clear evidence of this. Broad acceptance of such rules and their implementation is extremely unlikely unless there is convincing technical reasoning behind the constraints that necessitate the rules. Because of this critical flaw we request that the IESG not advance and to proposed standard yet. We suggest that the IESG refer these documents back to the authors and the WG with the request to provide technical justification for the placement of aggregation boundaries and to consider making these boundaries variable where technically feasible. References The referenced RIPE documents can be accessed at http://www.ripe.net/docs/ripe-xxx.html HTML ftp://ftp.ripe.net/ripe/docs/ripe-xxx.txt ASCII ftp://ftp.ripe.net/ripe/docs/ripe-xxx.ps PostScript -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 26 09:44:22 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA01900 for ipng-dist; Wed, 26 Nov 1997 09:37:14 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA01893 for ; Wed, 26 Nov 1997 09:36:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA08425 for ; Wed, 26 Nov 1997 09:34:48 -0800 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA05693 for ; Wed, 26 Nov 1997 09:34:30 -0800 (PST) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id KAA02155; Wed, 26 Nov 1997 10:34:26 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id KAA29178; Wed, 26 Nov 1997 10:34:25 -0700 (MST) Message-Id: <199711261734.KAA29178@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 26 Nov 1997 10:34:25 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Divya H V , ipng@sunroof.eng.sun.com Subject: (IPng 4985) Re: Q: IPv4/IPv6 interoperability Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Nov 26, 1:25pm you write:] > > Based on the above, Can the PF_INET6 sockets be used to service both > the IPv4 as well as IPv6 clients? Absolutely. IPv6 client addresses are returned as IPv6 addresses and IPv4 client addresses are returned as IPv4-mapped IPv6 addresses. This assumes the server bind()s the wildcard address. If the server needs to create multiple sockets and bind() a different local address to each socket, then different sockets for IPv6 and IPv4 will probably be needed. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 26 09:58:04 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id JAA01933 for ipng-dist; Wed, 26 Nov 1997 09:55:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id JAA01926 for ; Wed, 26 Nov 1997 09:55:10 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA14821 for ; Wed, 26 Nov 1997 09:55:07 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA16666 for ; Wed, 26 Nov 1997 09:55:08 -0800 (PST) Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA11385; Wed, 26 Nov 1997 12:44:04 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07837; Wed, 26 Nov 1997 12:44:00 -0500 Message-Id: <199711261744.AA07837@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, Alan Halachmi , ipng@sunroof.eng.sun.com Subject: (IPng 4986) Re: change IPv6 DNS records.... In-Reply-To: Your message of "Tue, 25 Nov 1997 17:51:08 EST." Date: Wed, 26 Nov 1997 12:44:00 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, >No, it should not move to Draft with known serious scaling problems. > >that is one of the things V6 is supposed to address AAAA Records have no scaling problems. They can move forward. Other work can make them more distributed for renumbering. These are two separate issues and AAAA Records are working fine for the reqs to move to draft standard. We have met all criteria. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 26 17:02:25 1997 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) id QAA02447 for ipng-dist; Wed, 26 Nov 1997 16:59:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA02440 for ; Wed, 26 Nov 1997 16:59:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA27664 for ; Wed, 26 Nov 1997 16:59:10 -0800 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id OAA26530 for ; Wed, 26 Nov 1997 14:02:00 -0800 (PST) Received: from rodan.UU.NET by relay3.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdrjs01361; Wed, 26 Nov 1997 17:01:25 -0500 (EST) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdrjs09271; Wed, 26 Nov 1997 17:01:46 -0500 (EST) Message-Id: To: bound@zk3.dec.com cc: "Mike O'Dell" , Alan Halachmi , ipng@sunroof.eng.sun.com Subject: (IPng 4987) Re: change IPv6 DNS records.... In-reply-to: Your message of "Wed, 26 Nov 1997 12:44:00 EST." <199711261744.AA07837@wasted.zk3.dec.com> Date: Wed, 26 Nov 1997 17:01:45 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i believe AAAA records represent an immense scaling problem -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------