From owner-ipng@sunroof.eng.sun.com Wed Jul 1 01:15:53 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id BAA02230 for ipng-dist; Wed, 1 Jul 1998 01:12:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id BAA02223 for ; Wed, 1 Jul 1998 01:12:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA25878 for ; Wed, 1 Jul 1998 01:12:47 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id BAA19582 for ; Wed, 1 Jul 1998 01:12:47 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2328.0) id <3B284B9B>; Wed, 1 Jul 1998 01:12:47 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100583252A@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'aconta@lucent.com'" , "'deering@cisco.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5957) RE: icmp rate limiting Date: Wed, 1 Jul 1998 01:12:46 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I never saw a reply to Maryann's questions below. These issues are important to implementations, so a response would be appreciated... Another question - draft-ietf-ipngwg-icmp-v2-00.txt says that the maximum size for an ICMP error packet should be 576 octets. Should this be raised to the new minimum MTU, 1280 octets? Thanks, Rich > -----Original Message----- > From: Maryann Perez Maher [mailto:perez@EAST.ISI.EDU] > Sent: Tuesday, May 26, 1998 8:24 AM > To: ipng@sunroof.Eng.Sun.COM > Cc: perez@EAST.ISI.EDU > Subject: (IPng 5852) icmp rate limiting > > > > Folks, > > The current ICMPv6-v2 draft (draft-ietf-ipngwg-icmp-v2-00.txt) states > that ICMP rate limiting should be done for informational replies as > well as error messages (section 2.4). This statement might suggest > that ND and MLD ICMP reply messages, along echo replies, should be > rate limited, which is probably not the intention. Or is > there some reason > why they should be? If not, this should be made clear in the text. > Btw, this is a change from RFC 1885, where it is mandatory to > rate limit > only error messages. > > Also, if echo replies are to be rate limited, the suggestion of a > 1/second default is probably not so appropriate since most echo > requests (pings) are usally sent per second. > > > Maryann -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 1 01:34:20 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id BAA02262 for ipng-dist; Wed, 1 Jul 1998 01:30:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id BAA02255 for ; Wed, 1 Jul 1998 01:30:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA27460 for ; Wed, 1 Jul 1998 01:30:35 -0700 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by earth.sun.com (8.8.8/8.8.8) with SMTP id BAA24342 for ; Wed, 1 Jul 1998 01:30:34 -0700 (PDT) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 1 Jul 1998 09:30:22 +0100 To: Richard Draves cc: "'aconta@lucent.com'" , "'deering@cisco.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 5958) Re: icmp rate limiting In-reply-to: Your message of "Wed, 01 Jul 1998 01:12:46 PDT." <4D0A23B3F74DD111ACCD00805F31D8100583252A@red-msg-50.dns.microsoft.com> Date: Wed, 01 Jul 1998 09:30:19 +0100 Message-ID: <1170.899281819@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4D0A23B3F74DD111ACCD00805F31D8100583252A@red-msg-50.dns.microsoft.c om>, Richard Draves typed: >>I never saw a reply to Maryann's questions below. These issues are important >>to implementations, so a response would be appreciated... yes, but the way (f.1 and f.2) specify the rate limits is primative - i'd prefer somethign that specifies an int-serv flow spec as a function of output interface link speed.....we could still get useful performance hints out of ICMP then.... >>Another question - draft-ietf-ipngwg-icmp-v2-00.txt says that the maximum >>size for an ICMP error packet should be 576 octets. Should this be raised to >>the new minimum MTU, 1280 octets? >> >>Thanks, >>Rich >> >>> -----Original Message----- >>> From: Maryann Perez Maher [mailto:perez@EAST.ISI.EDU] >>> Sent: Tuesday, May 26, 1998 8:24 AM >>> To: ipng@sunroof.Eng.Sun.COM >>> Cc: perez@EAST.ISI.EDU >>> Subject: (IPng 5852) icmp rate limiting >>> >>> >>> >>> Folks, >>> >>> The current ICMPv6-v2 draft (draft-ietf-ipngwg-icmp-v2-00.txt) states >>> that ICMP rate limiting should be done for informational replies as >>> well as error messages (section 2.4). This statement might suggest >>> that ND and MLD ICMP reply messages, along echo replies, should be >>> rate limited, which is probably not the intention. Or is >>> there some reason >>> why they should be? If not, this should be made clear in the text. >>> Btw, this is a change from RFC 1885, where it is mandatory to >>> rate limit >>> only error messages. >>> >>> Also, if echo replies are to be rate limited, the suggestion of a >>> 1/second default is probably not so appropriate since most echo >>> requests (pings) are usally sent per second. >>> >>> >>> Maryann >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- cheers jon -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 1 02:14:43 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id CAA02391 for ipng-dist; Wed, 1 Jul 1998 02:11:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id CAA02384 for ; Wed, 1 Jul 1998 02:10:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA00599 for ; Wed, 1 Jul 1998 02:10:47 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id CAA04529 for ; Wed, 1 Jul 1998 02:10:47 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2328.0) id <3BJQ9RCK>; Wed, 1 Jul 1998 02:10:47 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100583252C@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Jon Crowcroft'" Cc: "'aconta@lucent.com'" , "'deering@cisco.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 5959) Re: icmp rate limiting Date: Wed, 1 Jul 1998 02:10:46 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > yes, but the way (f.1 and f.2) specify the rate limits is primative - > i'd prefer somethign that specifies an int-serv flow spec as a > function of output interface link speed.....we could still get useful > performance hints out of ICMP then.... I think it's important to allow for very simple implementations of ICMP rate limiting, while not precluding the fancier implementations that you desire. However this is a distraction from my questions, which have to do with the introduction of rate limiting of informational replies and the 576-octet limit for ICMP error messages. Thanks, 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 Wed Jul 1 02:40:32 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id CAA02423 for ipng-dist; Wed, 1 Jul 1998 02:37:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id CAA02416 for ; Wed, 1 Jul 1998 02:37:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA02554 for ; Wed, 1 Jul 1998 02:37:03 -0700 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by earth.sun.com (8.8.8/8.8.8) with SMTP id CAA13781 for ; Wed, 1 Jul 1998 02:37:02 -0700 (PDT) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 1 Jul 1998 10:35:30 +0100 To: Richard Draves cc: "'aconta@lucent.com'" , "'deering@cisco.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 5960) Re: icmp rate limiting In-reply-to: Your message of "Wed, 01 Jul 1998 02:10:46 PDT." <4D0A23B3F74DD111ACCD00805F31D8100583252C@red-msg-50.dns.microsoft.com> Date: Wed, 01 Jul 1998 10:35:28 +0100 Message-ID: <1383.899285728@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4D0A23B3F74DD111ACCD00805F31D8100583252C@red-msg-50.dns.microsoft.c om>, Richard Draves typed: >>> yes, but the way (f.1 and f.2) specify the rate limits is primative - >>> i'd prefer somethign that specifies an int-serv flow spec as a >>> function of output interface link speed.....we could still get useful >>> performance hints out of ICMP then.... >>I think it's important to allow for very simple implementations of ICMP rate >>limiting, while not precluding the fancier implementations that you desire. a flowspec _specification_ does NOT imply a complex implementation - it just gives a more accurate idea of how ICMP rate limiting will behave. >>However this is a distraction from my questions, which have to do with the >>introduction of rate limiting of informational replies and the 576-octet >>limit for ICMP error messages. seems you might want to worry about v6/v4 icmp interworking, and a >576 reply might break an ICMP querier that had buffer space only for a current mtu...... cheers jon -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 1 07:31:56 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id HAA02617 for ipng-dist; Wed, 1 Jul 1998 07:29:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id HAA02610 for ; Wed, 1 Jul 1998 07:29:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29960 for ; Wed, 1 Jul 1998 07:29:01 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA20744 for ; Wed, 1 Jul 1998 07:29:02 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA09167; Wed, 1 Jul 1998 10:28:59 -0400 (EDT) Message-Id: <199807011428.KAA09167@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 5961) I-D ACTION:draft-ietf-ipngwg-addr-arch-v2-07.txt Date: Wed, 01 Jul 1998 10:28:58 -0400 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 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-07.txt Pages : 25 Date : 30-Jun-98 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-07.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980630161641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v2-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980630161641.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 Jul 1 19:33:42 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id TAA03735 for ipng-dist; Wed, 1 Jul 1998 19:29:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id TAA03728 for ; Wed, 1 Jul 1998 19:29:13 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA27301 for ; Wed, 1 Jul 1998 19:29:13 -0700 Received: from imo22.mx.aol.com (imo22.mx.aol.com [198.81.17.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA24250 for ; Wed, 1 Jul 1998 19:29:13 -0700 (PDT) Received: from Telford001@aol.com by imo22.mx.aol.com (IMOv14_b1.1) id SAJJa22301; Wed, 1 Jul 1998 22:28:36 +2000 (EDT) Message-ID: Date: Wed, 1 Jul 1998 22:28:36 EDT To: thomas.eklund@era.ericsson.se, brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5963) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 6/29/98 5:27:17 PM Eastern Daylight Time, thomas.eklund@era.ericsson.se writes: > I posted for one and a half year ago results from peformance measurements on > these issues and a lot of other people responded that they have noticed the > same behaviour, that v6 has sligtly better perfomance over a LAN than v4 - and I > think this is a really strong argument if this is a common behaviour over other > links... The claim is puzzling because with properly crafted code we always found accesses to memory to be the performance limiting factor. As the source and destination addresses in IPv6 are 32 bytes altogether, IPv6 headers should take longer to process. In performance optimizing several router implementations (including the Solensky version of the Constellation LSB router which we simply completely rewrote), I found poor checksum calculations and unnecessary multiple accesses to memory to be killing performance. However, once the header processing was fixed, memory access was the overwhelming performance concern. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 1 19:34:54 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id TAA03758 for ipng-dist; Wed, 1 Jul 1998 19:32:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id TAA03751 for ; Wed, 1 Jul 1998 19:32:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA27776 for ; Wed, 1 Jul 1998 19:32:11 -0700 Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA25342 for ; Wed, 1 Jul 1998 19:32:11 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id VAA28658 for ; Wed, 1 Jul 1998 21:32:11 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id VAA27823; Wed, 1 Jul 1998 21:32:10 -0500 (CDT) Message-ID: <19980701213210.03239@mcs.net> Date: Wed, 1 Jul 1998 21:32:10 -0500 From: Karl Denninger To: ipng@sunroof.eng.sun.com Subject: (IPng 5964) Request - has anyone read (and can I get comments on) the draft that I posted ~6 months back on address allocation for IPv6? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The subject says it all. For those who might not still have it, here is the document: INTERNET DRAFT K. Denninger Expires 10 May 1998 10 November 1997 IPV6 NUMBER ASSIGNMENT PROTOCOL Rev 0.1 draft-denninger-ipv6number-00.txt Status ====== 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 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 ======== This memorandum shall be entitled "IPV6 NUMBER ASSIGNMENT PROTOCOL", and describes a proposed policy, procedure and control structure for the allocation of IPV6 Internet addresses. This memorandum discusses the issues surrounding IPV6 numbering on a hierarchial structure and overview. It also presents, where possible and relevant, justification for the positions expressed in this paper. Distribution is unlimited and comments are invited. Revisions ========= As a draft, this document may be revised at any time. The revision number of the document in question is displayed at the top of the masthead, and should be referred to when commenting on the proposal contained in this draft. Operating Assumptions ===================== This draft is written under the following assumptions: 1) The IPv6 number space, as a 128-bit entity, is virtually unlimited in scope. 2) It is required that we utilize the IPv6 space in a hierarchial manner since full destination-level routing of a 128-bit space would require 2^128 lookup table entries - prohibitive for any device now existant or envisioned to be available in the forseeable future. 3) The size of the address space at 128 bits requires reasonable assumptions to be made about end node addresses and devices, but does not functionally limit the number of known networks, nor should the protocol for assignment of numbers artifically impose constraints on the number of possible autonomous systems. 4) An Autonomous System, or "AS" in today's terminology, is one routing entity with a consolidated policy and procedure for exchanging traffic with others. 5) Historically multiple AS numbers have been assigned to single entities. It is desirable to reduce or eliminate this practice such that a given AS uniquely identifies an organization for administrative purposes, but the functionality of multiple geographic regions which function independantly cannot be lost. 6) It is desirable to permit every man, woman, child, toaster, automobile or other vehicle and light switch if desired to have its own unique end-point identifier on the global Internet. 7) It is desired that backward-compatibility with IPv4 assignments be maintained to the greatest possible degree such that gateways to allow IPv4 and IPv6 to co-exist during a transition period, expected to last several years, are possible to construct in an efficient and functional manner. Since these gateways are required to operate at wire speeds, which today may reach or exceed 155mbps (and in the future will run at higher data rates) the simplicity of the mapping function is a paramount design consideration. 8) A function to provide unique IPv4-compatible endpoint identifiers is desired by the community during the transition period, and for user-friendly end-point identifiers on a permanent basis (including after IPv4 is considered deprecated). 9) Since 128 bits of address constitutes more space than we can envision needing for the forseeable (and even beyond) future, we will make certain assumptions about potential future uses which aren't realistic or even possible at the present time given the state of science in the late 1990s. Items Not Addressed =================== The following item is intentionally omitted from discussion in this draft: "Command and control structures" necessary to implement assumption #8. This draft does not attempt to set political agendas or create policy bodies. Definitions =========== Autonomous System (AS): An Autonomous System, for the purposes of this draft, is a network which is (1) connected to more than one other network, (2) assigns addresses to end users or other providers of network services, and (3) announces its network presence to more than one other network over the connections defined in (1). End Customer: An End Customer (EC) is any entity which (1) does not fit the definition of an AS above, and which (2) consumes or uses IPv6 addresses. Allocation Framework ==================== IPv6 numbers are 128-bit integers. To maintain a hierarchial structure over assignment, we must break down these numbers into fields which are either assigned by a numbering authority under delegation or which are controlled by the autonomous system and assigned ultimately to customers. To meet to goals and assumptions in the above section, this draft attempts to detail "automatic" fields which are assigned by virtue of either location or an entities status as an autonomous system. To break down the allocation of IPv6 numbers, we therefore define the following field names, uses, and bit placements, counting from the LEFT of the address field. Note that the first 64 bits of the address are defined as *assigned* and the second 64 bits are defined as *provider dependant*, giving each AS 2^64 addresses to assign to customers. Bits Len Name Use ===================================================================== 0 - 7 8 GALAXY Reserved for when subspace and/or other worlds (ie: the moon) become viable destinations. As the scope of our transmission and reception capability increases, we can increase the "reach" of a given value in this field. For the purposes of the Earth-based communication we use today, this value shall be zero (0). 8 - 17 10 COUNTRY Represents the country code of the designee. This permits 1024 countries to be represented on each planet (well above what we have today on Earth). Numbering for these to be taken from ISO in order of "creation" of the country in question. Country codes represent geographies; if a country renames itself or changes government system this does not change its designated code. A country which splits into two or more independant nations "creates" new country codes for the new, independant entities (with the original fragment, as close as can be determined, being left in existance). Absent cataclysmic events (ie: a country disappearing into the sea) country codes are never destroyed. 18 - 43 26 RESVC Reserved for future use. 44 - 47 4 REGION Reserved for use by an AS in specifying regional routing policy *within* a country. 48 - 63 16 ASN Provider's AS Number. Note that we currently have 2194 ASNs in the GLOBAL routing system. As such, this should be more than sufficient space. If it is not, then we can encroach on or redefine the RESVC and REGION fields as needed. --------------- End ASSIGNED addresses 64 - 95 32 RESVA Reserved for future use by the provider when IPv4 compatibility no longer is necessary, OR for use at their discretion in the current instance (ie: "overloading" if an address needs to be mapped which already exists in the IPv4 space). 96 - 127 IPV4 Existing IPv4 address space compatibility zone. Authorities Designating Fields ============================== GALAXY Assigned by whatever intergalactic or interplanetary authority might come to exist in the future. Currently zero (Earth) and not modifyable since no such authority currently exists. COUNTRY Tracks ISO country code designation system automatically. Existing and new country codes are assigned by an automated mapping process which does not require decisions by any standards body. REGION For organizations which have multiple autonomous routing zones within a country, they can use this field (16 possible values) to designate multiple routing policy domains within a country. Note that under NO circumstance should this field be used as a substitute for country designations. ASN AS Numbers are assigned by existing delegation processes, with one exception - only one ASN may be assigned to a given organization. In the event that multiple ASNs are required for a given organization the organization should use the multiple REGION designations where appropriate. RESVA & IPV4 Assignable by the ASN holder as they deem fit. Route Exchange ============== Routers which are attempting to set up peering sessions for the exchange of routes must agree on the position and size of the following fields: GALAXY COUNTRY RESVC REGION ASN An attaching router MUST obtain the other end's designations for these parameters. A router may (1) configure itself to match the existing mesh's idea of these fields, (2) refuse to establish a peering session if it has hard-coded values which disagree, or (3) CHANGE its field designations PROVIDED that no data existant in the current tables conflicts with the newly-desired defaults. Routers may specify some connections as MASTER and some as SLAVE; MASTER peering connections must choose actions (1) and (2) as the only possible outcome of configuration exchange, while SLAVE connections may take step (3) if it is possible. This permits a dynamically-configured Internet where the sizes and positions of fields may be changed by mutual agreement. Characteristics Of This Delegation Method ========================================= This delegation scheme has the following important characteristics which will make hierarchial routing more efficient in the Internet of tomorrow under the IPv6 addressing scheme: 1) Easy routing. End-node ASNs which wish to make full routing decisions within a region of a country will only need to care about the "ASN" field. They can safely ignore the REGION and COUNTRY designations. Any national ASN can choose to ignore the REGION designation (potentially at its peril). This gives a current route table size for FULL route exchange of just over 2,000 entries. Regional ASNs compute and carry a table of "best" COUNTRY and GALAXY exit points and forward traffic to those as appropriate. Note that recomputation of GALAXY and COUNTRY exits may be deemed a very low priority task at the discretion of the ASN. This design gives low-end providers in a given region a maximum route table size of 65,536 entries, and a current route table size of just over 2,000. 2) Multinational ASNs must use the COUNTRY, REGION and ASN fields to make routing decisions. Multinational ASNs which wish to use only one ASN per country do not need multiple REGION codes. Those which do wish to sub-divide countries may use a REGION code within those countries, but not elsewhere. 3) Growth of the Internet in a given country does not impact the route table size for non-multinational providers outside of that country. Multinational providers see impact no worse than they have to cope with today under IPv4 addressing. 4) All "address assignment" policies which could be used to restrain trade disappear; each provider has a 64-bit address space to themselves, which is more than enough to accomodate every possible device attached to that provider. (64 bits of address give you 18,446,744,073,709,551,616 possible addresses). We can therefore address every man, woman, child, dog, cat, and light switch under this scheme and never even come close to running out. 5) IPV4 mapping at the low order end gives us very easy NAT capability between IPV6 and IPV4. Specifically, if two ASNs cooperate through either themselves or a third party, they can set policies on the allocation of the IPV4 field which will insure uniqueness (similar to what IANA does now) - allowing full end-user IPV4 portability. Transport to the full IPV6 layer for backbone routing is now an index function in most of today's CPUs - a one-clock-cycle operation. This byte-alignment is important to maintain high performance in the gateway function, as these devices will have to run at wire speeds. Author's Address ================ Karl Denninger Email: Voice: [+1 312 803-MCS1] Fax: [+1 312 248-9865] draft-denninger-ipv6number-00.txt Expires 10 May 1998 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 1 20:06:00 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id TAA03824 for ipng-dist; Wed, 1 Jul 1998 19:57:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id TAA03817 for ; Wed, 1 Jul 1998 19:57:17 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA00553 for ; Wed, 1 Jul 1998 19:57:17 -0700 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA03144 for ; Wed, 1 Jul 1998 19:57:17 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA18256; Wed, 1 Jul 1998 19:57:05 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA15455; Wed, 1 Jul 1998 19:57:04 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA75279; Wed, 1 Jul 1998 19:56:24 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199807020256.TAA75279@bossette.engr.sgi.com> Subject: (IPng 5965) Re: IPv6 questions In-Reply-To: from "Telford001@aol.com" at "Jul 1, 98 10:28:36 pm" To: Telford001@aol.com Date: Wed, 1 Jul 1998 19:56:23 -0700 (PDT) Cc: thomas.eklund@era.ericsson.se, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In a message dated 6/29/98 5:27:17 PM Eastern Daylight Time, > thomas.eklund@era.ericsson.se writes: > > > I posted for one and a half year ago results from peformance measurements on > > these issues and a lot of other people responded that they have noticed the > > same behaviour, that v6 has sligtly better perfomance over a LAN than v4 - > and I > > think this is a really strong argument if this is a common behaviour over > other > > links... > > The claim is puzzling because with properly crafted code we always found > accesses to memory to be the performance limiting factor. I think the key word here is `slightly' better performance. Copying bigger addresses around and processing bigger headers is unlikely to make a very noticable difference to performance. A new v6 stack implementation however, with different localities of reference and subsequent cache performance could well result in a slight improvement in performance compared to some old v4 code. -- Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 2 04:56:09 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id EAA04387 for ipng-dist; Thu, 2 Jul 1998 04:49:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id EAA04380 for ; Thu, 2 Jul 1998 04:49:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA00302 for ; Thu, 2 Jul 1998 04:49:37 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA21952 for ; Thu, 2 Jul 1998 04:49:37 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA80132; Thu, 2 Jul 1998 07:49:25 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA61410; Thu, 2 Jul 1998 07:49:26 -0400 Received: from hygro.raleigh.ibm.com (lig32-224-57-167.us.lig-dial.ibm.com [32.224.57.167]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id HAA16396; Thu, 2 Jul 1998 07:49:23 -0400 (EDT) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id HAA00711; Thu, 2 Jul 1998 07:40:32 -0400 Message-Id: <199807021140.HAA00711@hygro.raleigh.ibm.com> To: Karl Denninger cc: ipng@sunroof.eng.sun.com Subject: (IPng 5966) Re: Request - has anyone read (and can I get comments on) the draft that I posted ~6 months back on address allocation for IPv6? In-reply-to: Your message of "Wed, 01 Jul 1998 21:32:10 CDT." <19980701213210.03239@mcs.net> Date: Thu, 02 Jul 1998 07:40:32 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karl, What kind of comments do you want? Here's two. 1) It's hard to see the relevance of this to reality. Your format reserves 8 bits to indicate what galaxy one is in. Will IPv6 still be in use on earth at the time the first IP packets reach a neighboring galaxy? Last I checked, the speed-of-light barrier has only been broken on Star Trek. And once sub-space transmission becomes possible, will 8 bits be enough to number all the galaxies? 2) The format described is totally incompatable with the existing IPv6 specs (e.g., 64-bit interface identifiers). Have you even read them? If you attempt to revise your document, you should at least read the IPv6 addressing documents. 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 Thu Jul 2 07:20:29 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id HAA04491 for ipng-dist; Thu, 2 Jul 1998 07:11:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id HAA04484 for ; Thu, 2 Jul 1998 07:11:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA15855 for ; Thu, 2 Jul 1998 07:11:46 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA16400 for ; Thu, 2 Jul 1998 07:11:46 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA17899; Thu, 2 Jul 1998 09:11:44 -0500 Message-Id: <199807021411.JAA17899@gungnir.fnal.gov> To: Karl Denninger Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5967) Re: Request - has anyone read (and can I get comments on) the draft that I posted ~6 months back on address allocation for IPv6? In-reply-to: Your message of Wed, 01 Jul 1998 21:32:10 CDT. <19980701213210.03239@mcs.net> Date: Thu, 02 Jul 1998 09:11:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I didn't know it was intended to be taken seriously. If it was, I'll limit myself to two comments: Multicast is missing. Serverless autoconfiguration is destroyed by this proposal. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 07:21:10 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id HAA04514 for ipng-dist; Thu, 2 Jul 1998 07:14:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id HAA04507 for ; Thu, 2 Jul 1998 07:14:25 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA16221 for ; Thu, 2 Jul 1998 07:14:24 -0700 Received: from imo13.mx.aol.com (imo13.mx.aol.com [198.81.17.3]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA17554 for ; Thu, 2 Jul 1998 07:14:24 -0700 (PDT) Received: from Telford001@aol.com by imo13.mx.aol.com (IMOv14_b1.1) id SGEOa11436; Thu, 2 Jul 1998 10:13:37 -0400 (EDT) Message-ID: <9c92ac2d.359b9592@aol.com> Date: Thu, 2 Jul 1998 10:13:37 EDT To: thomas.eklund@era.ericsson.se Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5968) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII X-Mailer: AOL 3.0 for Windows 95 sub 62 X-MIME-Autoconverted: from 8bit to quoted-printable by earth.sun.com id HAA17554 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id HAA04508 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-06-29 16:54:56 EDT, thomas.eklund@era.ericsson.se writes: > > ... > > > And I dont see the difference if you have a NAT/FW that it makes a > > > radical change if you have v6 internally instead of v4? If one has one's own complete private internet, why bother with IPv6? > > A major argument for v6 was the need for a larger address space. Adding > > NAT provides a larger address space. If only the larger address space > > was needed, the new address formats, unproven host and router > > implementations, silly ways of doing address resolution, lack of adequate > > checksumming etc. represent fairly radical changes and large risks. > Lack adquate checksumming... Dont see that as a radical change - rather a > big improvement:-) Why would anyone claim such a thing? The IP header checksum was a fairly weak checksum, but it was rarely used on more than 20 bytes and never on more than sixty. In any case with reasonable coding it, cost essentially nothing in performance. But given the massive amounts of data being moved around today, given the lack of hardware error detection on memory, busses and fifos in most packet switching devices and given the potentially huge sizes of IPv6 headers, why enable bad packets to propagate through the network when there is no reason for such propagation to be allowed? In any case, lack of adequate checksumming is only one of a plethora of problems associated with IPv6. > I dont say that NAT has it places in a big network - what I am > saying is that it no solution to the address problem in the near future... > Dont agree either that v6 is a radical change - I mean it is still the Internet > Protocol!!! Much of the code in the kernel can be reused... How is it still the Internet Protocol? IPX is probably closer to IPv4 than IPv6, and the (Unix?) kernel code at least since 4.3BSD has been pretty much multiprotocol capable so that implementations of Appletalk, IPX and DECNET can share a lode of the IPv4 code base. > > More to the point the cost of receiving packets to memory > > and then transmitting them from memory overwhelms the > > time spent in header processing. Spending a few man-years > > to put table lookups and some header processing into an > > ASIC is pointless > I will never agree on this:-) There is though other worlds than tradional > TCP based datacom networks... Ever heard about wireless??? I'm not meaning to be > offensive ehre just stating that there exsist other types of networks which > has other requirements on delay and processing capacity... The system is either doing statistically multiplexed packet switching, or it is not. If the system is not doing statically multiplexed packet switching, it is not relevant. > > 1) because a good software implementation gets the > > benefit of man-millennia of development spent on > > contemporary processors and > > 2) because unless memory is being implemented > > in the ASIC the main problem of high performance > > packet switching remains unaddressed. > Had never said anything else:-) For Instance Pink et Al and their Luleå > algoritm has shown indredible result in of improving routing lookups in SW > and there are others... Lots of researchers are showing similar results. Improvements in processor performance and cache design have rendered ASIC-based packet switching approaches misguided in the general case. > > (*)Internet address lookup is a challenging problem > > because of increasing routing table sizes, increased > > traffic, higher speed links, and the migration to 128 > > bit IPv6 addresses. IP routing lookup requires > > computing the best matching prefix, for which > > standard solutions like hashing were believed to be > > inapplicable. The best existing solution we know of, > > BSD radix tries, scales badly as IP moves to 128 bit > > addresses. Our paper describes a new algorithm for > > best matching prefix using binary search on hash tables > > organized by prefix lengths. Our scheme scales very > > well as address and routing table sizes increase: > > independent of the table size, it requires a worst > > case time of log(address bits) hash lookups; thus > > only 5 hash lookups are needed for IPv4 and 7 for > > IPv6. We also introduce Mutating Binary Search > > and other optimizations that, for a typical IPv4 > > backbone router with over 33,000 entries, > > considerably reduce the average number of > > hashes to less than 2, of which one hash can > > be simplified to an indexed array access. We > > expect similar average case behavior for IPv6. > Interesting is the result documented anywhere? The referenced paper appeared in Computer Communication Review, a publication of ACM SIGCOMM, volume 27, number 4, October 1997. ISSN # 0146-4833. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 2 08:26:11 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id IAA04718 for ipng-dist; Thu, 2 Jul 1998 08:12:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id IAA04711 for ; Thu, 2 Jul 1998 08:12:23 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAB24637 for ; Thu, 2 Jul 1998 08:12:23 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA15428 for ; Thu, 2 Jul 1998 08:12:22 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA04023; Thu, 2 Jul 1998 11:12:17 -0400 (EDT) Message-Id: <199807021512.LAA04023@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 5969) I-D ACTION:draft-ietf-ipngwg-unicast-aggr-05.txt Date: Thu, 02 Jul 1998 11:12:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : An IPv6 Aggregatable Global Unicast Address Format Author(s) : B. Hinden, M. O''Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-05.txt Pages : 11 Date : 01-Jul-98 This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the 'IPv6 Addressing Architecture' [ARCH]. It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, 'An IPv6 Provider-Based Unicast Address Format'. RFC 2073 will become historic. The Aggregatable Global Unicast Address Format is an improvement over RFC 2073 in a number of areas. The major changes include removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-unicast-aggr-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-unicast-aggr-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: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980701132242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-aggr-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980701132242.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 Jul 2 09:11:45 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id JAA04875 for ipng-dist; Thu, 2 Jul 1998 09:06:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id JAA04865 for ; Thu, 2 Jul 1998 09:05:58 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA06060 for ; Thu, 2 Jul 1998 09:05:56 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA15290 for ; Thu, 2 Jul 1998 09:05:54 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id MAA17483; Thu, 2 Jul 1998 12:05:51 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30342; Thu, 2 Jul 1998 12:05:48 -0400 Message-Id: <199807021605.AA30342@wasted.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: Telford001@aol.com, thomas.eklund@era.ericsson.se, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 5970) Re: IPv6 questions In-Reply-To: Your message of "Wed, 01 Jul 1998 19:56:23 PDT." <199807020256.TAA75279@bossette.engr.sgi.com> Date: Thu, 02 Jul 1998 12:05:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I think the key word here is `slightly' better performance. Copying >bigger addresses around and processing bigger headers is unlikely to >make a very noticable difference to performance. A new v6 stack >implementation however, with different localities of reference >and subsequent cache performance could well result in a slight >improvement in performance compared to some old v4 code. For those who don't make a living at coding IP stacks the other point is that as we evolve tcp/ip we usually have an evolved stack and code base we work with and changing usually requires a business reason. The other reason is a major technology shift where new code is needed (e.g. multicast, mobility) or performance enhancements for the Internet via TCP, and some other reasons. But it is not often that as engineers we get the time and funding to implement a new protocol like IPv6 and when doing that one could have easily justified the time to go into the stack and clean up old architectural beliefs and datastructures. IPv6 should have afforded many engineers the opportunity to take a very close look at the IP stack and make the necessary adjustments for the 90's and view some of the good work from the research community from places like SIGCOMM and extend the paradigm to greater cohesiveness, scalability, and performance within their network subsystem within their respective OS model. IPv6 extensions are also very efficient and can be dealt with in a much more efficient manner than IPv4 similar parts. It also works very well on a 64bit architecture and that for sure will improve performance. But at the end of the day the real win is the caliber of engineer working on the code base and what they are permiited to do within X amount of time. /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 Jul 2 09:43:53 1998 Received: by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) id JAA04918 for ipng-dist; Thu, 2 Jul 1998 09:35:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1.Beta1+Sun/8.9.1.Beta1) with SMTP id JAA04911 for ; Thu, 2 Jul 1998 09:35:09 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA14113 for ; Thu, 2 Jul 1998 09:35:08 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA03290 for ; Thu, 2 Jul 1998 09:35:07 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id MAA15905; Thu, 2 Jul 1998 12:35:06 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA21210; Thu, 2 Jul 1998 12:35:05 -0400 Message-Id: <199807021635.AA21210@wasted.zk3.dec.com> To: Telford001@aol.com Cc: thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 5971) Re: IPv6 questions In-Reply-To: Your message of "Thu, 02 Jul 1998 10:13:37 EDT." <9c92ac2d.359b9592@aol.com> Date: Thu, 02 Jul 1998 12:35:05 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If one has one's own complete private internet, why bother with IPv6? First I believe private addresses and networks are evil and not useful to any evolved organization that wants to operate in a global distributed networking environment. Every customer I have who has had to use a private network does so only because they could not get the address space they need and had to make some parts of their enterprise private. Not because they like having NAT break many end-to-end functions they need (e.g. Voice over IP, IPSEC End-to-End Transport Mode). All customers I have want IPv6 and want to have it ready for the next millenium not NAT forever. But if one wants to use IPv6 Site Addresses they get the same thing for their "INTRANET" (NOTE I AM TALKING INTRA NOT INTERNET). 1. Superior Autoconfiguration with a choice of stateless or stateful. 2. Superior Mobility 3. Superior Management of their nodes across the network because of Neighbor Discovery and an avoidance of many problems with the mess in this space for IPv4. 4. Vendors MUST provide IPSEC/IKE with their stacks to be IPv6 Compliant so network layer security (that does not cause applications to change as SSL/TLS does) can be pervasive from their end-system vendors (Microsoft, Sun, Compaq, IBM, HP, Sequent, etc etc.) This is why if one or two vendors don't do IPv6 it will still happen as many vendors have already committed to IPv6 for the market. 5. Flow Label in the IPv6 Header which can be used for Intranet RSVP real business applicatons and assist with the emerging technology for bandwidth brokerage for their distributed network to support QOS. IPv4 cannot do this efficiently. 6. As many addresses as they need to support Voice over IP without network address translation. But go read: the recent IAB paper on the case for IPv6 . draft-ietf-iab-case-for-ipv6-01.txt Lots more bullets to add to mine above and business reasons for IPv6 too not just technical ones. >In any case, lack of adequate checksumming is only one >of a plethora of problems associated with IPv6. I have no clue why you say this. What are you talking about IPv6 enhanced this by requiring us to checksum UDP too. As far as removing it from the IP header I think that was a brilliant thing to do. >How is it still the Internet Protocol? IPX is probably closer >to IPv4 than IPv6, and the (Unix?) kernel code at least since 4.3BSD >has been pretty much multiprotocol capable so that implementations >of Appletalk, IPX and DECNET can share a lode of the IPv4 code >base. =20 As a BSD UNIX and IP Expert excuse me I don't think you know what your talking about. How can you possibly say IPX, Appletalk, and DECNET share more code in BSD stacks than IPv6. Without you justifying this in detail you really should not make such claims on a list where there is a shit load of BSD UNIX and IP Experts. Back this statement up please or clarify but I can't even attempt to absorb such a statement. I do agree with you that before we spend lots of money for ASIC designs to improve routing lookups we should take a hard look at how we build our datastructures and table access for the route entries, especially just for forwarding packets. I also believe that the SIGCOMM papers presented some very useful paradigms and algorithms I for one am looking at now. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 2 13:35:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA05481 for ipng-dist; Thu, 2 Jul 1998 13:23:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA05474 for ; Thu, 2 Jul 1998 13:22:58 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14906 for ; Thu, 2 Jul 1998 13:22:25 -0700 Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA13110 for ; Thu, 2 Jul 1998 13:21:55 -0700 (PDT) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id PAA04967; Thu, 2 Jul 1998 15:21:54 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id PAA25213; Thu, 2 Jul 1998 15:21:54 -0500 (CDT) Message-ID: <19980702152153.42924@mcs.net> Date: Thu, 2 Jul 1998 15:21:53 -0500 From: Karl Denninger To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5972) Re: Request - has anyone read (and can I get comments on) the draft that I posted ~6 months back on address allocation for IPv6? References: <19980701213210.03239@mcs.net> <199807021411.JAA17899@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199807021411.JAA17899@gungnir.fnal.gov>; from Matt Crawford on Thu, Jul 02, 1998 at 09:11:44AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Jul 02, 1998 at 09:11:44AM -0500, Matt Crawford wrote: > I didn't know it was intended to be taken seriously. If it was, I'll > limit myself to two comments: > > Multicast is missing. One bit in the GALAXY or RESVC field would take care of that. > Serverless autoconfiguration is destroyed by this proposal. No more than the TLA/NLA/SLA proposal does (and yes, I've read that). SOMEHOW you have to divine the "fixed" fields. If you have to do it in one proposal, you must do it in another. This is an administrative document; how you get the values of the fixed fields aren't defined in it intentionally, as it is beyond the intended scope. Either a router or gateway has to supply that information to the client stack, or a server has to supply it. TLA/NLA/SLA provides no mechanism to use *existing* attributes on the network to define address space, introduces yet more administrative crap, and artificially limits *global* routing size. Yet routing ISN'T global for 99% of the participants, and for those who ARE globally interested, most of their equipment is still country-limited with gateways between different national interests. That is, even someone like Worldcom doesn't need to have ALL of their core routers know about more than the ASN-level routing table - only those which are interconnecting between nations. Second, right now there are ~3k ASNs in the routing system. That is, this proposal, while defining NO new administrative functions, requiring NO new funding, and in fact *dismantling* all the existing address registries, their fee structures, and their politics, results in a "default free" routing table RIGHT NOW of 3,000 entries! The TLA/NLA/SLA system does not address ANY of this, and in fact creates and imposes more costs where they are not necessary. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 16:17:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA05827 for ipng-dist; Thu, 2 Jul 1998 16:11:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA05820 for ; Thu, 2 Jul 1998 16:11:27 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA25893 for ; Thu, 2 Jul 1998 16:11:26 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id QAA01493 for ; Thu, 2 Jul 1998 16:11:24 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA05584; Thu, 2 Jul 98 16:10:39 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA08424; Thu, 2 Jul 1998 16:13:11 -0700 Date: Thu, 2 Jul 1998 16:13:11 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199807022313.QAA08424@feller.mentat.com> To: richdr@microsoft.com Subject: (IPng 5973) Re: icmp rate limiting Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > > I never saw a reply to Maryann's questions below. These issues are important > to implementations, so a response would be appreciated... > > Another question - draft-ietf-ipngwg-icmp-v2-00.txt says that the maximum > size for an ICMP error packet should be 576 octets. Should this be raised to > the new minimum MTU, 1280 octets? > OK, I will chime in with an unsolicited opinion. I think that rate limiting informational messages is problematic even if you insist upon a default rate of something larger than 1/second. I just don't see how ND will continue to work correctly if the outgoing interface tosses out NUD probes periodically. There need to be some exceptions for certain types of informational messages or things are going to get bad. Rate limiting error messages at 1/second sounds fine. As far as the 576 octet limit, I would change it to 1280. Any ICMPv6 to ICMP translator is going to have a lot of work to do to translate an ICMPv6 message to an ICMP message. Discarding some of the bytes so the resulting ICMP message will fit into 576 octets will be easy relative to the rest of the translation. 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 Jul 3 16:16:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA06945 for ipng-dist; Fri, 3 Jul 1998 16:11:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA06938 for ; Fri, 3 Jul 1998 16:11:39 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA08701 for ; Fri, 3 Jul 1998 16:11:37 -0700 Received: from imo14.mx.aol.com (imo14.mx.aol.com [198.81.17.4]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA18341 for ; Fri, 3 Jul 1998 16:11:37 -0700 (PDT) Received: from Telford001@aol.com by imo14.mx.aol.com (IMOv14_b1.1) id 5OHOa13455; Fri, 3 Jul 1998 19:08:21 -0400 (EDT) Message-ID: Date: Fri, 3 Jul 1998 19:08:21 EDT To: bound@zk3.dec.com Cc: thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5974) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/2/98 12:57:00 PM Eastern Daylight Time, bound@zk3.dec.com writes: > >If one has one's own complete private internet, why bother with IPv6? > First I believe private addresses and networks are evil and not useful > to any evolved organization that wants to operate in a global > distributed networking environment. I think the example of AOL is being overlooked. > Every customer I have who has had > to use a private network does so only because they could not get the > address space they need and had to make some parts of their enterprise > private. Obviously, Bound is not dealing with AOL, which is one of Compaq-DEC's largest customers. Banks, securities companies and the military all have IP networks that will never be connected to the global network. Other security conscious companies allow a limited amount of connectivity but consider the internal allocation of IP addresses information that should not be made available to the outside world. > Not because they like having NAT break many end-to-end > functions they need (e.g. Voice over IP, IPSEC End-to-End Transport > Mode). I have to admit that I have never used anything that used IPSEC End-to-End Transport Mode, but given the prevalence of private network addressing, nat and firewalling, I think I could argue that something is wrong with IPSEC End-to-End Transport Mode if it cannot be made to work in the presence of IPv4 private network addressing+nat+firewalling. I have certainly used Voice over IP in and out of and through private IP networks connected to the global internet through NAT and a firewall. > All customers I have want IPv6 and want to have it ready for the > next millenium not NAT forever. Customers always want something, whose advocates promise that it will do everything (remember OSI -- requiescat in pace, OSI est quid IPv6 erit). > But if one wants to use IPv6 Site Addresses they get the same thing for > their "INTRANET" (NOTE I AM TALKING INTRA NOT INTERNET). > 1. Superior Autoconfiguration with a choice of stateless or stateful. > 2. Superior Mobility > 3. Superior Management of their nodes across the network because > of Neighbor Discovery and an avoidance of many problems with > the mess in this space for IPv4. I remember all these claims for OSI. I recommend Historic Debate , Debate with William Stallings, and IP vs. OSI . > 4. Vendors MUST provide IPSEC/IKE with their stacks to be IPv6 > Compliant so network layer security (that does not cause > applications to change as SSL/TLS does) can be pervasive > from their end-system vendors (Microsoft, Sun, Compaq, IBM, > HP, Sequent, etc etc.) This is why if one or two vendors > don't do IPv6 it will still happen as many vendors have > already committed to IPv6 for the market. How many vendors committed to MAP/TOP? > 5. Flow Label in the IPv6 Header which can be used for Intranet > RSVP real business applicatons and assist with the emerging > technology for bandwidth brokerage for their distributed > network to support QOS. IPv4 cannot do this efficiently. Flow Labels and RSVP are so silly that they are infra dig. of comment. > 6. As many addresses as they need to support Voice over IP > without network address translation. So? > But go read: the recent IAB paper on the case for IPv6 . > draft-ietf-iab-case-for-ipv6-01.txt > Lots more bullets to add to mine above and business reasons for IPv6 too > not just technical ones. > >In any case, lack of adequate checksumming is only one > >of a plethora of problems associated with IPv6. > I have no clue why you say this. What are you talking about IPv6 > enhanced this by requiring us to checksum UDP too. As far as removing > it from the IP header I think that was a brilliant thing to do. People keep making this claim. I cannot imagine why anyone would want to allow potentially very large amount of data to travel through the network unprotected by checksums. > >How is it still the Internet Protocol? IPX is probably closer > >to IPv4 than IPv6, and the (Unix?) kernel code at least since 4.3BSD > >has been pretty much multiprotocol capable so that implementations > >of Appletalk, IPX and DECNET can share a lode of the IPv4 code > >base. > As a BSD UNIX and IP Expert excuse me I don't think you know what your > talking about. How can you possibly say IPX, Appletalk, and DECNET > share more code in BSD stacks than IPv6. Without you justifying this > in detail you really should not make such claims on a list where there > is a shit load of BSD UNIX and IP Experts. Back this statement up > please or clarify but I can't even attempt to absorb such a statement. I have done hardware/software debugging of last resort in the 128-495, Silicon Valley, Toronto and Japan for years. I am familiar with most of the major Unix networking implementations. I have also architected and implemented a high performance multiprotocol WAN LAN VLAN router 1) that uses the Berkeley Unix networking layer, 2) that provided LAN-WAN switching as well as IP, Appletalk, DECNET and IPX routing and 3) that in one incarnation was awarded PC Magazine Editor's choice by Scott Bradner. I will concede that the Unix DECNET implementations that I saw seem to have been independent developments, but the Unix IPX that descends from a Columbia implementation looked as if it were simply minor modifications of the standard Berkeley Unix IP implementation. The more extensive Unixware implementation diverged more but even this implementation seems to have borrowed a lot from an SCO IP implementation. The Unix Appletalk implementation that descends from University of Michigan Sources borrowed a lot from the Berkeley Unix IP implementation. In addition the Mentat XTP which I believe is incorporated into DECUNIX simply duplicates lot of the standard kernel IP implementation as well as a lot of GATED. Now one can use common IP input and output routines for IPv4 and IPv6 but the actual processing of the IPv4 and IPv6 packets is quite different, and one could argue that IPv4 and IPV6 are better served by separate input and output routines. I would not call the use of common input and output packet processing routines that do one sort of processing for IPv4 frames and another sort of processing for IPv6 frames the use of common code. > I do agree with you that before we spend lots of money for ASIC designs > to improve routing lookups we should take a hard look at how we build > our datastructures and table access for the route entries, especially > just for forwarding packets. I also believe that the SIGCOMM papers > presented some very useful paradigms and algorithms I for one am looking > at now. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 4 00:21:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id AAA07253 for ipng-dist; Sat, 4 Jul 1998 00:18:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id AAA07246 for ; Sat, 4 Jul 1998 00:18:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA06850 for ; Sat, 4 Jul 1998 00:18:06 -0700 Received: from solen.ce.chalmers.se (solen.ce.chalmers.se [129.16.20.244]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id AAA06691 for ; Sat, 4 Jul 1998 00:18:05 -0700 (PDT) Received: from cepc30.ce.chalmers.se (otel@cepc30.ce.chalmers.se [129.16.20.144]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id JAA12947; Sat, 4 Jul 1998 09:11:25 +0200 (MET DST) From: Otel Florian-Daniel Received: (from otel@localhost) by cepc30.ce.chalmers.se (8.8.7/8.8.5) id JAA01421; Sat, 4 Jul 1998 09:14:30 GMT Date: Sat, 4 Jul 1998 09:14:30 GMT Message-Id: <199807040914.JAA01421@cepc30.ce.chalmers.se> To: Telford001@aol.com Cc: bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 5975) Re: IPv6 questions In-Reply-To: References: X-Mailer: VM 6.34 under 20.2 XEmacs Lucid Reply-To: otel@ce.chalmers.se Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I have no clue why you say this. What are you talking about IPv6 >> enhanced this by requiring us to checksum UDP too. As far as removing >> it from the IP header I think that was a brilliant thing to do. > People keep making this claim. I cannot imagine why > anyone would want to allow potentially very large amount > of data to travel through the network unprotected by > checksums. Sorry for interfering (i just loosely follow the thread) but I think Jim is completely right. I can give you two reasons: - The IPv4 packet processing time was traditionally dominated by moving the packet data around (i.e.copying) and checksum computing. If there is something you can do about the first in implementation-wise manner, please note the headache and the amount of work put in optimizing the second. -Think about the link-layers _usually_ used with IP. Almost all of the few that i know use some form of checksum. So, i think that "better not do it that overdo it" is a risk i am willing to take. Regards, Florian P.S: I'm not intending to be rude, but am i the only one having the feeling that this is a topic that is superfluously discussed over and over? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 02:33:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA07340 for ipng-dist; Sat, 4 Jul 1998 02:28:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA07333 for ; Sat, 4 Jul 1998 02:28:40 -0700 (PDT) From: MOSTHAVM@plcman.siemens.co.uk Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA12101 for ; Sat, 4 Jul 1998 02:28:38 -0700 Received: from ariane.sni.co.uk ([194.42.250.68]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id CAA24460 for ; Sat, 4 Jul 1998 02:28:28 -0700 (PDT) Received: from manpost001.sni.co.uk (manpost001.sni.co.uk [137.223.63.12]) by ariane.sni.co.uk (8.8.8/8.8.7) with ESMTP id KAA23858 for ; Sat, 4 Jul 1998 10:27:48 +0100 (BST) Received: by manpost001.sni.co.uk with Internet Mail Service (5.0.1460.8) id <3C79MWBM>; Sat, 4 Jul 1998 10:32:37 +0100 Message-ID: To: ipng@sunroof.eng.sun.com Subject: (IPng 5976) Re: IPv6 questions Date: Sat, 4 Jul 1998 10:32:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > P.S: I'm not intending to be rude, but am i the only one having the > feeling that this is a topic that is superfluously discussed over and > over? I absolutely aggree! On top of that I can't understand why somebody keeps quiet for years, just to block everything during last call. 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 Sat Jul 4 06:44:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA07589 for ipng-dist; Sat, 4 Jul 1998 06:41:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA07582 for ; Sat, 4 Jul 1998 06:41:17 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA24959 for ; Sat, 4 Jul 1998 06:41:13 -0700 Received: from imo20.mx.aol.com (imo20.mx.aol.com [198.81.17.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA00975 for ; Sat, 4 Jul 1998 06:41:15 -0700 (PDT) Received: from Telford001@aol.com by imo20.mx.aol.com (IMOv14_b1.1) id TBDFa19316; Sat, 4 Jul 1998 09:37:38 -0400 (EDT) Message-ID: Date: Sat, 4 Jul 1998 09:37:38 EDT To: otel@ce.chalmers.se Cc: bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5978) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-07-04 03:33:00 EDT, otel@ce.chalmers.se writes: > Sorry for interfering (i just loosely follow the thread) but I think > Jim is completely right. I can give you two reasons: > - The IPv4 packet processing time was traditionally > dominated by moving the packet data around (i.e.copying) and checksum > computing. If there is something you can do about the first in > implementation-wise manner, please note the headache and the amount of > work put in optimizing the second. Even on the slow processors available circa 1990, rendering the checksum calculation insignificant relative to the costs of other IP packet processing was something less than an afternoon of work. > -Think about the link-layers _usually_ used with IP. Almost > all of the few that i know use some form of checksum. So, i think > that "better not do it that overdo it" is a risk i am willing to take. The IP header checksum is not there to protect against bit flips on the networking medium but rather against errors that occur in the host or router because of bit errors that occur during memory, fifo or bus operations. A lot of this hardware simply has no error detection circuitry. The IP header checksum is not much, but it is better than nothing especially with the massive amounts of data that is being moved across networks today. I should also point out that the IP header checksum is done hop by hop while TCP and UDP checksums are only calculated at the end-point. Suppose the equivalent of the allied command is planning the equivalent of the invasion of Normandy. The plans get put into a packet that is sent out on the global internet (Jim Bound says private internets are evil) . A few bit flips occur and the packet gets sent to a monitor belonging to the equivalent of the Axis high command. So much for the equivalent of the invasion of Europe. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 4 11:13:41 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA07724 for ipng-dist; Sat, 4 Jul 1998 11:10:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA07717 for ; Sat, 4 Jul 1998 11:10:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA08213 for ; Sat, 4 Jul 1998 11:10:37 -0700 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA14527 for ; Sat, 4 Jul 1998 11:10:38 -0700 (PDT) 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 KAA01037; Sat, 4 Jul 1998 10:58:04 -0700 (PDT) Received: from kc.livingston.com (kc.livingston.com [149.198.32.1]) by server.livingston.com (8.8.5/8.6.9) with SMTP id LAA11389; Sat, 4 Jul 1998 11:06:33 -0700 (PDT) Received: by kc.livingston.com (SMI-8.6/SMI-SVR4) id LAA28473; Sat, 4 Jul 1998 11:08:22 -0700 From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807041808.LAA28473@kc.livingston.com> Subject: (IPng 5979) Re: IPv6 questions To: bound@zk3.dec.com Date: Sat, 4 Jul 1998 11:08:22 -0700 (PDT) Cc: Telford001@aol.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com In-Reply-To: <199807021635.AA21210@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Jul 2, 98 12:35:05 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > >If one has one's own complete private internet, why bother with IPv6? > > First I believe private addresses and networks are evil and not useful > to any evolved organization that wants to operate in a global > distributed networking environment. Every customer I have who has had > to use a private network does so only because they could not get the > address space they need and had to make some parts of their enterprise > private. Not because they like having NAT break many end-to-end > functions they need (e.g. Voice over IP, IPSEC End-to-End Transport > Mode). All customers I have want IPv6 and want to have it ready for the > next millenium not NAT forever. > Hmm... I wonder if you think PBXes in the voice world are EVIL too. PBXes allow localized private extensions within enterprises. The problems related by your customers are not all-exhaustive. Neither are the solutions you espouse. There are myriad of problems asociated with global connectivity. These include service provider charges, exposure to hacker community, need to connect disperate routing realms etc. Many people prefer proxies, private addresses and NATs for these reasons. I understand and respect your customer appreciation. But, let us not continue this line of religious wars. Thanks. Regards, 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 Sun Jul 5 07:31:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA08106 for ipng-dist; Sun, 5 Jul 1998 07:26:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA08099 for ; Sun, 5 Jul 1998 07:25:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA28030 for ; Sun, 5 Jul 1998 07:25:19 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA10573 for ; Sun, 5 Jul 1998 07:25:16 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.8.8/8.8.8) id QAA18905; Sun, 5 Jul 1998 16:22:05 +0200 (MET DST) From: Ignatios Souvatzis Message-Id: <199807051422.QAA18905@theory.cs.uni-bonn.de> Subject: (IPng 5980) Re: IPv6 questions In-Reply-To: from "Telford001@aol.com" at "Jul 4, 98 09:37:38 am" To: Telford001@aol.com Date: Sun, 5 Jul 1998 16:22:04 +0200 (MET DST) Cc: otel@ce.chalmers.se, bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joachim Martillo wrote: > > The IP header checksum is not there to protect against bit > flips on the networking medium but rather against errors > that occur in the host or router because of bit errors that > occur during memory, fifo or bus operations. A lot of this ... > Suppose the equivalent of the allied command is planning > the equivalent of the invasion of Normandy. The > plans get put into a packet that is sent out > on the global internet (Jim Bound says private > internets are evil) . A few bit flips occur and the > packet gets sent to a monitor belonging to the > equivalent of the Axis high command. So much > for the equivalent of the invasion of Europe. So, you propose to depend on correct routing for network security? You're naive. And I thought _I_ was the networking amateur. -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 5 08:14:06 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA08192 for ipng-dist; Sun, 5 Jul 1998 08:00:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA08185 for ; Sun, 5 Jul 1998 08:00:41 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA29290 for ; Sun, 5 Jul 1998 08:00:23 -0700 Received: from imo23.mx.aol.com (imo23.mx.aol.com [198.81.17.67]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA14700 for ; Sun, 5 Jul 1998 08:00:25 -0700 (PDT) Received: from Telford001@aol.com by imo23.mx.aol.com (IMOv14_b1.1) id KLBZa26052; Sun, 5 Jul 1998 10:56:47 -0400 (EDT) Message-ID: <4e026423.359f9430@aol.com> Date: Sun, 5 Jul 1998 10:56:47 EDT To: ignatios@theory.cs.uni-bonn.de Cc: otel@ce.chalmers.se, bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5981) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-07-05 10:22:29 EDT, ignatios@theory.cs.uni-bonn.de writes: > Joachim Martillo wrote: > > The IP header checksum is not there to protect against bit > > flips on the networking medium but rather against errors > > that occur in the host or router because of bit errors that > > occur during memory, fifo or bus operations. A lot of this > ... > > Suppose the equivalent of the allied command is planning > > the equivalent of the invasion of Normandy. The > > plans get put into a packet that is sent out > > on the global internet (Jim Bound says private > > internets are evil) . A few bit flips occur and the > > packet gets sent to a monitor belonging to the > > equivalent of the Axis high command. So much > > for the equivalent of the invasion of Europe. > So, you propose to depend on correct routing for network security? > You're naive. And I thought _I_ was the networking amateur. You *are* the networking amateur. So what if the data was encrypted? Of course, if it is worth it to them, the bad guys (however defined) will have sufficiently powerful hardware to break the code. If you want your network really to be secure, you do not attach it to the global internet. You isolate it in a building with no windows that is electromagnetically shielded and surround the building with guys with machine guns. But such is not the cases with which we are dealing with this forum. The system under design might be dealing with millions of weakly protected bank or credit card transactions over the internet. I do not believe in a Global Internet. But I just took some of comments that I am reading here to their logical conclusion (i.e. reductio ad absurdum). If you have problems with English and do not understand sarcasm, your time would be better spent in repeating grammar school than in taking part in this forum. BTW, if one is going to build into a system the dollar and processing cost of security, it is mindlessly stupid not to add in the minimal processing cost of data integrity. Joachim Martillo Telford Tools, Inc. PS. I put my resume on line and make examples of packet switching software and design documents available for download or reading over the web, which is a hell of a lot more than a lot of the self-proclaimed gurus do in this forum. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 5 15:28:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA08490 for ipng-dist; Sun, 5 Jul 1998 15:25:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA08483 for ; Sun, 5 Jul 1998 15:25:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA19449 for ; Sun, 5 Jul 1998 15:25:08 -0700 Received: from host.ott.igs.net (host.ott.igs.net [206.248.16.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA16586 for ; Sun, 5 Jul 1998 15:25:07 -0700 (PDT) Received: from [206.248.17.130] (ttyB0f.ott.igs.net [206.248.17.81]) by host.ott.igs.net (8.8.5/8.6.12) with ESMTP id SAA05551 for ; Sun, 5 Jul 1998 18:25:05 -0400 (EDT) X-Sender: kgk@host.igs.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 5 Jul 1998 15:46:13 -0400 To: ipng@sunroof.eng.sun.com From: Keith Knightson Subject: (IPng 5984) IPv4/IPv6 & Public/Private Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not sure I understand the debate over IP4 vs IPv6 and the relationship with address schemes for private versus public nets. The linkage seems tenuous at best. Given a large enough address space, both private and public networks can draw their addresses, unabiguously, from the same overall space. In this case the distinction between public and/or private is only a question of connectedness and routing, and has nothing to do with type of address or type of network. A big bonus of drawing all addresses (both public and private) from the same single space, presumably, is that any subsequent requirement to connect a private net to a public net is trivial. Presumably, the only reason to re-use the same space, perhaps ambiguously amongst a set of private nets, is the lack of overall space. There is nothing intrinsic to private or public networks that requires this. Have I missed something? Regards Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 5 16:18:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA08573 for ipng-dist; Sun, 5 Jul 1998 16:12:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA08566 for ; Sun, 5 Jul 1998 16:12:25 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA22009 for ; Sun, 5 Jul 1998 16:12:25 -0700 Received: from imo20.mx.aol.com (imo20.mx.aol.com [198.81.17.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA23218 for ; Sun, 5 Jul 1998 16:12:25 -0700 (PDT) Received: from Telford001@aol.com by imo20.mx.aol.com (IMOv14_b1.1) id GXFLa19316; Sun, 5 Jul 1998 19:11:49 -0400 (EDT) Message-ID: <419fd5dd.35a00836@aol.com> Date: Sun, 5 Jul 1998 19:11:49 EDT To: kgk@igs.net Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5985) Re: IPv4/IPv6 & Public/Private Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/5/98 6:39:51 PM Eastern Daylight Time, kgk@igs.net writes: > I am not sure I understand the debate over IP4 vs IPv6 and the relationship > with address schemes for private versus public nets. The linkage seems > tenuous at best. > Given a large enough address space, both private and public networks can > draw their addresses, unabiguously, from the same overall space. In this > case the distinction between public and/or private is only a question of > connectedness and routing, and has nothing to do with type of address or > type of network. > A big bonus of drawing all addresses (both public and private) from the > same single space, presumably, is that any subsequent requirement to > connect a private net to a public net is trivial. > Presumably, the only reason to re-use the same space, perhaps ambiguously > amongst a set of private nets, is the lack of overall space. There is > nothing intrinsic to private or public networks that requires this. > Have I missed something? It does not take a lot to think of reasons to use address space no matter how large. Suppose my company is a provider and it realizes how silly RSVP, INTSERV and DIFFSERV are and makes the decision to follow a completely different but tried and true model whereby it builds parallel networks with different levels of link capacity and occupancy according to how much a customer pays for his service (rather like first class, business and tourist in air travel). First class gets OC3 links with super-IMP equivalents to build the communications subnets, tourist gets low throughput X.25 links that are cram-packed with users and business class gets something in-between. Would it necessarily be desirable to have different addresses on the first class, business class and tourist class backbones? I am not sure, but I suspect not. Suppose the customer is willing to pay for first class, business class and tourist class service depending on the type of traffic. Suppose the provider wants to be able to move first class traffic onto the business class network and bump business class users down to tourist if there is a disaster in the OC3 network. The way to make such bumping quick and efficient might be to have completely parallel backbones with the same addresses appearing on each of the backbones. The bumping could just be the sending of a command to all the border routers. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 5 17:34:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA08674 for ipng-dist; Sun, 5 Jul 1998 17:32:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA08663 for ; Sun, 5 Jul 1998 17:32:13 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA25893 for ; Sun, 5 Jul 1998 17:32:13 -0700 Received: from imo12.mx.aol.com (imo12.mx.aol.com [198.81.17.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id RAA05091 for ; Sun, 5 Jul 1998 17:32:13 -0700 (PDT) Received: from Telford001@aol.com by imo12.mx.aol.com (IMOv14_b1.1) id GYUZa11469; Sun, 5 Jul 1998 20:31:19 +2000 (EDT) Message-ID: Date: Sun, 5 Jul 1998 20:31:19 EDT To: Telford001@aol.com, kgk@igs.net Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5986) Re: IPv4/IPv6 & Public/Private Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/5/98 7:30:28 PM Eastern Daylight Time, Telford001@aol.com writes: > It does not take a lot to think of reasons to use address space no matter > how large. Should have been: It does not take a lot of effort to think of reasons to *reuse* addresses no matter how large the total address space is. Joachim Carlo Santos Martillo Ajami -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 01:15:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA08909 for ipng-dist; Mon, 6 Jul 1998 01:10:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA08902 for ; Mon, 6 Jul 1998 01:10:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA25355 for ; Mon, 6 Jul 1998 01:10:40 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by earth.sun.com (8.8.8/8.8.8) with SMTP id BAA11747 for ; Mon, 6 Jul 1998 01:10:39 -0700 (PDT) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA13385; Mon, 6 Jul 1998 09:10:27 +0100 Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA93552; Mon, 6 Jul 1998 09:10:26 +0100 (BST) Message-Id: <35A0867C.913E310@hursley.ibm.com> Date: Mon, 06 Jul 1998 09:10:36 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: Keith Knightson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5987) Re: IPv4/IPv6 & Public/Private References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, Private addresses in IPv4 are a kludge to get over the difficulty of obtaining large blocks of address space (e.g. the equivalent of a Class A) from the registries. Their main limitation is that they *must not* be routed outside the private network since they are ambiguous. This difficulty, this kludge, and this limitation do not apply to IPv6. IPv6 has a completely different (repeat: completely different) facility called site-local addresses which are what they are called: they have no meaning outside the site where the node lives. Brian Keith Knightson wrote: > > I am not sure I understand the debate over IP4 vs IPv6 and the relationship > with address schemes for private versus public nets. The linkage seems > tenuous at best. > > Given a large enough address space, both private and public networks can > draw their addresses, unabiguously, from the same overall space. In this > case the distinction between public and/or private is only a question of > connectedness and routing, and has nothing to do with type of address or > type of network. > > A big bonus of drawing all addresses (both public and private) from the > same single space, presumably, is that any subsequent requirement to > connect a private net to a public net is trivial. > > Presumably, the only reason to re-use the same space, perhaps ambiguously > amongst a set of private nets, is the lack of overall space. There is > nothing intrinsic to private or public networks that requires this. > > Have I missed something? > > Regards > > Keith > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 6 04:46:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA09049 for ipng-dist; Mon, 6 Jul 1998 04:41:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA09042 for ; Mon, 6 Jul 1998 04:41:08 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA08487 for ; Mon, 6 Jul 1998 04:41:06 -0700 Received: from imo27.mx.aol.com (imo27.mx.aol.com [198.81.17.71]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA25171 for ; Mon, 6 Jul 1998 04:41:07 -0700 (PDT) Received: from Telford001@aol.com by imo27.mx.aol.com (IMOv14_b1.1) id 5LKBa06640; Mon, 6 Jul 1998 07:38:03 -0400 (EDT) Message-ID: <8ae5d267.35a0b71c@aol.com> Date: Mon, 6 Jul 1998 07:38:03 EDT To: bound@zk3.dec.com Cc: thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5988) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/2/98 12:57:00 PM Eastern Daylight Time, bound@zk3.dec.com writes: > Every customer I have who has had > to use a private network does so only because they could not get the > address space they need and had to make some parts of their enterprise > private. I have some doubts about this comment unless Jim Bound is dealing with an extremely narrow subset of DEC-Compaq customers. A very large proportion of DEC-Compaq customers are banks and financial institutions that have no need or desire for global internet connectivity. Joachim Martillo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 06:51:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA09149 for ipng-dist; Mon, 6 Jul 1998 06:45:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA09142 for ; Mon, 6 Jul 1998 06:45:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA18818 for ; Mon, 6 Jul 1998 06:45:34 -0700 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA01723 for ; Mon, 6 Jul 1998 06:45:28 -0700 (PDT) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id JAA27622; Mon, 6 Jul 1998 09:42:14 -0400 (EDT) Message-Id: <199807061342.JAA27622@jekyll.piermont.com> To: Telford001@aol.com cc: bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 5989) Re: IPv6 questions In-reply-to: Your message of "Mon, 06 Jul 1998 07:38:03 EDT." <8ae5d267.35a0b71c@aol.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 06 Jul 1998 09:42:14 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com writes: > > Every customer I have who has had > > to use a private network does so only because they could not get the > > address space they need and had to make some parts of their enterprise > > private. > > I have some doubts about this comment unless Jim Bound is > dealing with an extremely narrow subset of DEC-Compaq > customers. A very large proportion of DEC-Compaq customers > are banks and financial institutions that have no need > or desire for global internet connectivity. Boy, that's a howler. Almost all my customers are large financial institutions. Such institutions have to interconnect their networks frequently. Some of my customers have truly *huge* numbers of such connections, providing everything from market data and clearing information, to providing dedicated links to important customers. Even though such interconnections are not wide open (i.e. they are heavily firewalled), the conflicts we get in private IP spaces are often a giant pain in the buttocks. We often have to deal with the fact that machines in our DMZ networks have networks on both sides of them that they have to talk to claiming to have the same IP address space. You have no idea how many headaches would be solved for people if such institutions could always get unique IP address space. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 06:51:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA09158 for ipng-dist; Mon, 6 Jul 1998 06:47:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA09151 for ; Mon, 6 Jul 1998 06:47:47 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA18984 for ; Mon, 6 Jul 1998 06:47:45 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA02618 for ; Mon, 6 Jul 1998 06:47:46 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id JAA19792; Mon, 6 Jul 1998 09:47:43 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA24498; Mon, 6 Jul 1998 09:47:43 -0400 Message-Id: <199807061347.AA24498@wasted.zk3.dec.com> To: Telford001@aol.com Cc: bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 5990) Re: IPv6 questions In-Reply-To: Your message of "Mon, 06 Jul 1998 07:38:03 EDT." <8ae5d267.35a0b71c@aol.com> Date: Mon, 06 Jul 1998 09:47:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Every customer I have who has had >> to use a private network does so only because they could not get the >> address space they need and had to make some parts of their enterprise >> private. > >I have some doubts about this comment unless Jim Bound is >dealing with an extremely narrow subset of DEC-Compaq >customers. A very large proportion of DEC-Compaq customers >are banks and financial institutions that have no need >or desire for global internet connectivity. First it is Compaq not DEC-Compaq and your right my access is narrow as an engineer who gets called in only when they need to determine strategic direction. Unfortuneately because of us moving too slow in the IETF I cannot tell them to use IPv6 or even where to get a real IPv6 address (when I tell them use a temporary 6bone address they just laugh at me). Second none of the customers I talk to use Private Addresses for "security", they do it cause they don't have enough addresses. As far as security that is what IPSEC is for not the Internet Protocol Address of choice v4 or v6. Or they do it because they do not know how to protect themselves in other manners. Look I am going to not get into this debate I have had it many many times and your just yet another person who I guess believes private addresses are good. I don't and think they are evil and should not be used. Thats my opinion not the opinion of my company for or against. I think NAT is evil I think transaction processing with http is evil too. I have lots of opinions on lots of things technically. But what does all of this have to do with the drafts that went to IPv6 last call or the drafts we are working on. I seemed to have lost the purpose of this discussion? Whats your issue? /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 Jul 6 08:03:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA09366 for ipng-dist; Mon, 6 Jul 1998 07:58:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA09359 for ; Mon, 6 Jul 1998 07:58:05 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA28047 for ; Mon, 6 Jul 1998 07:58:03 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA02306 for ; Mon, 6 Jul 1998 07:58:04 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail11.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id KAA22399; Mon, 6 Jul 1998 10:58:02 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA29510; Mon, 6 Jul 1998 10:58:02 -0400 Message-Id: <199807061458.AA29510@wasted.zk3.dec.com> To: Telford001@aol.com Cc: bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 5993) Re: IPv6 questions In-Reply-To: Your message of "Fri, 03 Jul 1998 19:08:21 EDT." Date: Mon, 06 Jul 1998 10:58:01 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Banks, securities companies and the military all have IP networks >that will never be connected to the global network. Other security >conscious companies allow a limited amount of connectivity but >consider the internal allocation of IP addresses information that >should not be made available to the outside world. Global addresses do not mean everyone can connect to them just that they could if they wanted to. Private addresses are not secure because the address is private. > Not because they like having NAT break many end-to-end > functions they need (e.g. Voice over IP, IPSEC End-to-End Transport > Mode). >I have to admit that I have never used anything that used IPSEC >End-to-End Transport Mode, but given the prevalence of >rivate network addressing, nat and firewalling, I think I >ould argue that something is wrong with IPSEC End-to-End >Transport Mode if it cannot be made to work in the >presence of IPv4 private network addressing+nat+firewalling. >I have certainly used Voice over IP in and out of and through >private IP networks connected to the global internet >through NAT and a firewall. Go to the NAT list to discuss this. We should not go down this path here. I don't agree with you but will suggest we take this up on another list. >> All customers I have want IPv6 and want to have it ready for the >> next millenium not NAT forever. >Customers always want something, whose advocates promise >that it will do everything (remember OSI -- requiescat in pace, >OSI est quid IPv6 erit). They just don't want NAT. This is different. > But if one wants to use IPv6 Site Addresses they get the same thing for > their "INTRANET" (NOTE I AM TALKING INTRA NOT INTERNET). >> 1. Superior Autoconfiguration with a choice of stateless or stateful. >> 2. Superior Mobility >> 3. Superior Management of their nodes across the network because >> of Neighbor Discovery and an avoidance of many problems with >> the mess in this space for IPv4. >I remember all these claims for OSI. I recommend I did not see Mobility in the OSI claims but maybe I missed it. Your entitled to your opinion. I don't agree with it but thats fine. >> 4. Vendors MUST provide IPSEC/IKE with their stacks to be IPv6 >> Compliant so network layer security (that does not cause >> applications to change as SSL/TLS does) can be pervasive >> from their end-system vendors (Microsoft, Sun, Compaq, IBM, >> HP, Sequent, etc etc.) This is why if one or two vendors >> don't do IPv6 it will still happen as many vendors have >> already committed to IPv6 for the market. >How many vendors committed to MAP/TOP? Irrelevant......... >> 5. Flow Label in the IPv6 Header which can be used for Intranet >> RSVP real business applicatons and assist with the emerging >> technology for bandwidth brokerage for their distributed >> network to support QOS. IPv4 cannot do this efficiently. >Flow Labels and RSVP are so silly that they are infra dig. >of comment. Irrelevant. >> 6. As many addresses as they need to support Voice over IP >> without network address translation. >So? Exactly......... > But go read: the recent IAB paper on the case for IPv6 . > draft-ietf-iab-case-for-ipv6-01.txt > Lots more bullets to add to mine above and business reasons for IPv6 too > not just technical ones. So did you read the paper? >> >In any case, lack of adequate checksumming is only one >> >of a plethora of problems associated with IPv6. > >> I have no clue why you say this. What are you talking about IPv6 >> enhanced this by requiring us to checksum UDP too. As far as removing >> it from the IP header I think that was a brilliant thing to do. >People keep making this claim. I cannot imagine why >anyone would want to allow potentially very large amount >of data to travel through the network unprotected by >checksums. Others have responded but I will add with IPSEC you don't need the checksum either. IPSEC is mandatory for IPv6. >I will concede that the Unix DECNET implementations >that I saw seem to have been independent developments, >but the Unix IPX that descends from a Columbia implementation >looked as if it were simply minor modifications of the >standard Berkeley Unix IP implementation. The more >extensive Unixware implementation diverged more >but even this implementation seems to have borrowed >a lot from an SCO IP implementation. The Unix >Appletalk implementation that descends from >University of Michigan Sources borrowed a lot >from the Berkeley Unix IP implementation. >In addition the Mentat XTP which I believe is >incorporated into DECUNIX simply duplicates No. >lot of the standard kernel IP implementation >as well as a lot of GATED. Well that had no details which is what I asked for. >Now one can use common IP input and >output routines for IPv4 and IPv6 but the >actual processing of the IPv4 and IPv6 >packets is quite different, and one could argue More generic talk. Processing where tcpxxx, PRUxxx, or what virtual layer if we don't want to talk about actual modules from bsd 4.4. >that IPv4 and IPV6 are better served by >separate input and output routines. I would before the packet is sent to udp or tcp I agree but after I don't. >not call the use of common input and output >packet processing routines that do one >sort of processing for IPv4 frames and >another sort of processing for IPv6 >frames the use of common code. It can use some common code but not all. This would be better discussed in the ipv6imp list. I recall you at our cambridge meeting in Oct 1994 where we pretty much defined what ND should and should not do architecturally for the most part in IPv6. All you argue now existed then. Why are you now harping on so much of this 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 Mon Jul 6 08:03:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA09357 for ipng-dist; Mon, 6 Jul 1998 07:57:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA09350 for ; Mon, 6 Jul 1998 07:57:13 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA27936 for ; Mon, 6 Jul 1998 07:57:09 -0700 Received: from imo25.mx.aol.com (imo25.mx.aol.com [198.81.17.69]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA01859 for ; Mon, 6 Jul 1998 07:57:10 -0700 (PDT) Received: from Telford001@aol.com by imo25.mx.aol.com (IMOv14_b1.1) id JSJYa07259; Mon, 6 Jul 1998 10:53:51 -0400 (EDT) Message-ID: <1919280b.35a0e500@aol.com> Date: Mon, 6 Jul 1998 10:53:51 EDT To: perry@piermont.com Cc: bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5992) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/6/98 9:42:42 AM Eastern Daylight Time, perry@piermont.com writes: > Telford001@aol.com writes: > > > Every customer I have who has had > > > to use a private network does so only because they could not get the > > > address space they need and had to make some parts of their enterprise > > > private. > > I have some doubts about this comment unless Jim Bound is > > dealing with an extremely narrow subset of DEC-Compaq > > customers. A very large proportion of DEC-Compaq customers > > are banks and financial institutions that have no need > > or desire for global internet connectivity. > Boy, that's a howler. > Almost all my customers are large financial institutions. Such > institutions have to interconnect their networks frequently. Some of > my customers have truly *huge* numbers of such connections, providing > everything from market data and clearing information, to providing > dedicated links to important customers. > Even though such interconnections are not wide open (i.e. they are > heavily firewalled), the conflicts we get in private IP spaces are > often a giant pain in the buttocks. We often have to deal with the > fact that machines in our DMZ networks have networks on both sides of > them that they have to talk to claiming to have the same IP address > space. > You have no idea how many headaches would be solved for people if such > institutions could always get unique IP address space. I would argue that inadequacies of the NAT+Firewalling devices are being identified not necessarily a need for a global unique address space. In any case, this particular problem could be easily solved by the creation of an IPv4 right address extension option (subaddress) rather than going to a completely new IP protocol. I do not deal with as many banks and financial institutions as DEC, but those with whom I have dealt do not even want the outside world to know the internal distribution of IP addressess. A lot of information can be gleaned from traffic analysis. The transient binding of private addresses to global addresses is helpful to thwart traffic analysis. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 6 08:09:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA09428 for ipng-dist; Mon, 6 Jul 1998 08:06:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA09421 for ; Mon, 6 Jul 1998 08:06:35 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA29847 for ; Mon, 6 Jul 1998 08:06:34 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA07020 for ; Mon, 6 Jul 1998 08:06:33 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail12.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id LAA24856; Mon, 6 Jul 1998 11:06:32 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30441; Mon, 6 Jul 1998 11:06:30 -0400 Message-Id: <199807061506.AA30441@wasted.zk3.dec.com> To: suresh@livingston.com (Pyda Srisuresh) Cc: bound@zk3.dec.com, Telford001@aol.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 5994) Re: IPv6 questions In-Reply-To: Your message of "Sat, 04 Jul 1998 11:08:22 PDT." <199807041808.LAA28473@kc.livingston.com> Date: Mon, 06 Jul 1998 11:06:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hmm... I wonder if you think PBXes in the voice world are EVIL too. PBXes >allow localized private extensions within enterprises. Completely different paradigm. Like I told you once before your a great politician. >The problems related by your customers are not all-exhaustive. Neither >are the solutions you espouse. There are myriad of problems asociated >with global connectivity. These include service provider charges, exposure >to hacker community, need to connect disperate routing realms etc. Many >people prefer proxies, private addresses and NATs for these reasons. What!!!!!! I recall sitting on the podium with you at Las Vegas Interop and most of the audience told you and I then NAT is a bad dream we all have to live with and please give us IPv6. My point is that is the message I am hearing in my "samplings", otherwise I would stop working on IPv6. I did not say the message is to not build NAT for IPv4 we have no choice in many instances in the market today (although we are working on that in AATN world). >I understand and respect your customer appreciation. But, let us not >continue this line of religious wars. Thanks. I don't think you respect anything I just said so why say you do? And why don't you jump in before I had to respond to all this mail saying IPv6 sucks and NAT is good. But you instead wait until I send defense mail and give me the tap, go tell it to those who started the thread not me Suresh....... I can't hear you @!111!!!!!! /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 Jul 6 08:21:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA09542 for ipng-dist; Mon, 6 Jul 1998 08:17:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA09531 for ; Mon, 6 Jul 1998 08:17:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA01793 for ; Mon, 6 Jul 1998 08:17:14 -0700 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA13152 for ; Mon, 6 Jul 1998 08:17:11 -0700 (PDT) Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA28033; Mon, 6 Jul 1998 11:14:25 -0400 (EDT) Message-Id: <199807061514.LAA28033@jekyll.piermont.com> To: Telford001@aol.com cc: bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 5995) Re: IPv6 questions In-reply-to: Your message of "Mon, 06 Jul 1998 10:53:51 EDT." <1919280b.35a0e500@aol.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 06 Jul 1998 11:14:25 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com writes: > > Even though such interconnections are not wide open (i.e. they are > > heavily firewalled), the conflicts we get in private IP spaces are > > often a giant pain in the buttocks. [...] > > You have no idea how many headaches would be solved for people if such > > institutions could always get unique IP address space. > > I would argue that inadequacies of the NAT+Firewalling devices are > being identified not necessarily a need for a global unique address > space. Before, you claimed there was no need. Now, you claim the need is caused by the fact that we are using insufficiently powerful kludges. Make up your mind... > In any case, this particular problem could be easily > solved by the creation of an IPv4 right address extension > option (subaddress) rather than going to a completely new > IP protocol. As if the effort involved in that would be any smaller? Please. > I do not deal with as many banks and financial institutions as DEC, but > those with whom I have dealt do not even want the outside world to know > the internal distribution of IP addressess. That has nothing to do with the question of whether one wants those addresses to be unique or not. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 10:14:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA10122 for ipng-dist; Mon, 6 Jul 1998 10:09:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA10108 for ; Mon, 6 Jul 1998 10:09:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA29858 for ; Mon, 6 Jul 1998 10:09:12 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA13456 for ; Mon, 6 Jul 1998 10:09:09 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id KAA03447; Mon, 6 Jul 1998 10:09:03 -0700 (PDT) Message-Id: <3.0.5.32.19980706100817.00abe300@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Jul 1998 10:08:17 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 5996) Request for Agenda Topics for Chicago IETF IPng Sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng working group will meet for two sessions at the Chicago IETF. The current sessions are: Tuesday, August 25 at 1545-1800 Thursday, August 27 at 0900-1130 Please send Steve Deering and myself proposed agenda items including topic description and length of time required. Thanks, Bob Hinden / Steve Deering IPng Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 6 13:54:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA10546 for ipng-dist; Mon, 6 Jul 1998 13:46:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA10539 for ; Mon, 6 Jul 1998 13:46:02 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA28897 for ; Mon, 6 Jul 1998 13:46:00 -0700 Received: from imo20.mx.aol.com (imo20.mx.aol.com [198.81.17.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA09575 for ; Mon, 6 Jul 1998 13:46:00 -0700 (PDT) Received: from Telford001@aol.com by imo20.mx.aol.com (IMOv14_b1.1) id 5DAOa19317; Mon, 6 Jul 1998 16:41:29 -0400 (EDT) Message-ID: <92c82ba1.35a1367b@aol.com> Date: Mon, 6 Jul 1998 16:41:29 EDT To: bound@zk3.dec.com, suresh@livingston.com Cc: thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 5997) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/6/98 12:28:01 PM Eastern Daylight Time, bound@zk3.dec.com writes: > >Hmm... I wonder if you think PBXes in the voice world are EVIL too. PBXes > >allow localized private extensions within enterprises. > Completely different paradigm. Like I told you once before you are a great > politician. Why is it such a different paradigm? > >The problems related by your customers are not all-exhaustive. Neither > >are the solutions you espouse. There are myriad of problems asociated > >with global connectivity. These include service provider charges, exposure > >to hacker community, need to connect disperate routing realms etc. Many > >people prefer proxies, private addresses and NATs for these reasons. > What!!!!!! I recall sitting on the podium with you at Las Vegas > Interop and most of the audience told you and I then NAT is a bad dream > we all have to live with and please give us IPv6. IPv6 is the nightmare that will follow the bad dream. A lot of the problems associated with topological instability in the IPv4 internet relate simply to size. The bigger the internet the higher the probability that there will be instability somewhere that has a probability of propagating. IPv6 targets the building of an even larger internet with the elimination of private internets with the result that there will be an even greater probability of propagating topological instability. The designers of the two level hierarchical routing in DECNET were quite cluefull. Topological instability in a DECNET area could not propagate to the L2 routing tables and therefore could not propagate from area to area. With the addition of a left address extension (internet number) option rather than a huge topological instability prone global internet, we could have a few hundred or so moderately sized topological instability resistant internets wherein L1 routing was performed and there would be a moderately sized topological instability resistant L2 superinternet that routed between the L1 internets. > My point is that is > the message I am hearing in my "samplings", otherwise I would stop > working on IPv6. I did not say the message is to not build NAT for > IPv4 we have no choice in many instances in the market today (although > we are working on that in AATN world). Left and right address extension options would have built a better dual level hierarchical extended internet and would have facilitated private internets, NAT and firewalling yet would have represented a minor extension of existing IPv4 capabilities rather than the disaster prone radical change that IPv6 represents. > >I understand and respect your customer appreciation. But, let us not > >continue this line of religious wars. Thanks. > I don't think you respect anything I just said so why say you do? > And why don't you jump in before I had to respond to all this mail > saying IPv6 sucks and NAT is good. But you instead wait until I send > defense mail and give me the tap, go tell it to those who started the > thread not me Suresh....... I can't hear you @!111!!!!!! NAT is useful, IPv6 is a disaster in the making, IPv4 with two new options provides everything that IPv6 is supposed to provide with far less risk and facilitates useful NAT, private networking and firewalling capabilities. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 7 06:18:52 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA11583 for ipng-dist; Tue, 7 Jul 1998 06:15:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA11576 for ; Tue, 7 Jul 1998 06:15:33 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA26000 for ; Tue, 7 Jul 1998 06:15:31 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA22571 for ; Tue, 7 Jul 1998 06:15:32 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail12.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id JAA12769; Tue, 7 Jul 1998 09:15:31 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA17649; Tue, 7 Jul 1998 09:15:30 -0400 Message-Id: <199807071315.AA17649@wasted.zk3.dec.com> To: Telford001@aol.com Cc: bound@zk3.dec.com, suresh@livingston.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 5999) Re: IPv6 questions In-Reply-To: Your message of "Mon, 06 Jul 1998 16:41:29 EDT." <92c82ba1.35a1367b@aol.com> Date: Tue, 07 Jul 1998 09:15:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Why is it such a different paradigm? PBXs do not have to deal with connectionless packets at this point and the switching fabrics support what we call routing but it is not the same. >> What!!!!!! I recall sitting on the podium with you at Las Vegas >> Interop and most of the audience told you and I then NAT is a bad dream >> we all have to live with and please give us IPv6. >IPv6 is the nightmare that will follow the bad dream. A lot of the problems >associated with topological instability in the IPv4 internet relate simply >to size. The bigger the internet the higher the probability that there >will be instability somewhere that has a probability of propagating. Telling the Internet it cannot get big is naive. It will get big and thats why IPv6 is important, evolved, and will be pervasive over time. >IPv6 targets the building of an even larger internet with the elimination >of private internets with the result that there will be an even >greater probability of propagating topological instability. As somone else has told you in other mail, IPv6 does not eliminate PRIVATE Intranets (it is not an Internet if it is private per todays meaning of the term Internet). IPv6 permits lesser scoped addresses than Global. So if entities want to follow this path they can. Please do not confuse my beliefs with what IPv6 is. IPv6 will support PRIVATE Intranets out of the box and site-local addresses are one example. We are even changing the API paradigm for BSD UNIX Sockets to do this. I just think private addresses are a very bad and evil thing and this is my opinion and a very very minority opinion. I have no choice per this WG but to build IPv6 to support PRIVATE Intranets as that is consensus and help customers use and implement them. So IPv6 does not eliminate what you so desire. But IPv6 does give the market the freedom to build a big Internet too. I agree having choices is a good thing and why I support what IPv6 permits today and adhere to consensus with my colleagues working on this next generation Internet protocol. >The designers of the two level hierarchical routing in DECNET >were quite cluefull. Topological instability in a DECNET >area could not propagate to the L2 routing tables and >therefore could not propagate from area to area. I have no comment to this and don't see its relevance to IPv6? >With the addition of a left address extension (internet >number) option rather than a huge topological >instability prone global internet, we could >have a few hundred or so moderately sized >topological instability resistant internets >wherein L1 routing was performed and there >would be a moderately sized topological >instability resistant L2 superinternet >that routed between the L1 internets. Well I suggest you go start your own working group for IPv9 as I think IPv8 is taken. The IETF is enroute to standardize IPv6 and that has consensus and by the market too. Good Luck......... >> My point is that is >> the message I am hearing in my "samplings", otherwise I would stop >> working on IPv6. I did not say the message is to not build NAT for >> IPv4 we have no choice in many instances in the market today (although >> we are working on that in AATN world). >Left and right address extension options would have built >a better dual level hierarchical extended internet and >would have facilitated private internets, NAT and firewalling >yet would have represented a minor extension of >existing IPv4 capabilities rather than the >disaster prone radical change that IPv6 represents. Having sat on the IPng Directorate (see RFC 1752) this idea was kind of proposed (see RFC 1752) and did not take shape. Again if you want to gather support in the community or whatever for IPv9 then go for it, but this is not the list IMO to attempt such an effort. Most of the folks on this list are working on IPv6 and helping to get it implemented and standardized. Unless the mail points out problems in the drafts I am not clear the mail is useful IMO. If one just don't like the architecture I guess thats the breaks and I guess one could keep an I Told You So card or something, but IPv6 is moving forward. >> >I understand and respect your customer appreciation. But, let us not >> >continue this line of religious wars. Thanks. > >> I don't think you respect anything I just said so why say you do? > >> And why don't you jump in before I had to respond to all this mail >> saying IPv6 sucks and NAT is good. But you instead wait until I send >> defense mail and give me the tap, go tell it to those who started the >> thread not me Suresh....... I can't hear you @!111!!!!!! >NAT is useful, IPv6 is a disaster in the making, IPv4 with >two new options provides everything that IPv6 is supposed >to provide with far less risk and facilitates useful NAT, >private networking and firewalling capabilities. I agree NAT is useful but I also believe it has a great cost associated with using it for any customer. That has been well documented in the NAT WG and any alleviation possible is being worked on. But alternatives to NAT are also being worked on for IPv4 and IPv6, and this is useful work too. I think IPv6 is a very brilliant and efficient architecture and having implemented it I believe many of its parts (addr conf, ND, APIs, etc) are far superior to IPv4 and will result in a more reliable and useful engine for customers doing networking in the near future. I am trying to understand your issue and I think it is you think the entire architecture is wrong and not useful and even harmful to the Internet? If I am correct then your issue is far to great for me to respond to as IPv6 is enroute and moving forward and no protocol or idea or invention is without warts or perfect. At this point I will not respond to any more mail from you that does not raise issues with our present drafts or work that will benefit them being better documents to implement IPv6 with. Private philosophical discussion is fine but I am not clear it is useful on this mail list which I view as a work list to get IPv6 completed, and hence, will not participate in any further philosophical discussions on this list. /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 Jul 7 06:49:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA11616 for ipng-dist; Tue, 7 Jul 1998 06:43:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA11609 for ; Tue, 7 Jul 1998 06:43:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA29439 for ; Tue, 7 Jul 1998 06:43:00 -0700 Received: from relay9.uu.net (relay9.uu.net [192.48.96.85]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA03823 for ; Tue, 7 Jul 1998 06:43:00 -0700 (PDT) Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQewzu16447; Tue, 7 Jul 1998 09:42:59 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQewzu00600; Tue, 7 Jul 1998 09:42:59 -0400 (EDT) Message-Id: To: ipng@sunroof.eng.sun.com cc: mo@UU.NET Subject: (IPng 6000) Re: IPv6 questions In-reply-to: Your message of "Tue, 07 Jul 1998 09:15:30 EDT." <199807071315.AA17649@wasted.zk3.dec.com> Date: Tue, 07 Jul 1998 09:42:58 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, the Internet will "get big" whether or not IPv6 makes orbit. this is a biological process, *not* a result of centralized planning. Issuing dicta about "how the Internet will get big via a certain path" is rather like the Politburo order the wheat to grow taller. it's entertaining to watch but ultimately pointless. cheers, -mo "Randomness is Natures way of inducing order." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 07:21:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA11670 for ipng-dist; Tue, 7 Jul 1998 07:17:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA11663 for ; Tue, 7 Jul 1998 07:17:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA04126 for ; Tue, 7 Jul 1998 07:17:13 -0700 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA18595 for ; Tue, 7 Jul 1998 07:17:14 -0700 (PDT) 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 HAA02040; Tue, 7 Jul 1998 07:04:21 -0700 (PDT) Received: from kc.livingston.com (kc.livingston.com [149.198.32.1]) by server.livingston.com (8.8.5/8.6.9) with SMTP id HAA28496; Tue, 7 Jul 1998 07:12:53 -0700 (PDT) Received: by kc.livingston.com (SMI-8.6/SMI-SVR4) id HAA14311; Tue, 7 Jul 1998 07:14:46 -0700 From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199807071414.HAA14311@kc.livingston.com> Subject: (IPng 6001) Re: IPv6 questions To: bound@zk3.dec.com Date: Tue, 7 Jul 1998 07:14:46 -0700 (PDT) Cc: suresh@livingston.com, Telford001@aol.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com In-Reply-To: <199807061506.AA30441@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Jul 6, 98 11:06:30 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > >Hmm... I wonder if you think PBXes in the voice world are EVIL too. PBXes > >allow localized private extensions within enterprises. > > Completely different paradigm. Like I told you once before your a great > politician. PBXes in the voice world, in my mind, is a good analogy to NATs in the datacom world. I mentioned it so you could appreciate others' points of view. Instead, you chose to name calling, which I dont appreciate. > > >The problems related by your customers are not all-exhaustive. Neither > >are the solutions you espouse. There are myriad of problems asociated > >with global connectivity. These include service provider charges, exposure > >to hacker community, need to connect disperate routing realms etc. Many > >people prefer proxies, private addresses and NATs for these reasons. > > What!!!!!! I recall sitting on the podium with you at Las Vegas > Interop and most of the audience told you and I then NAT is a bad dream > we all have to live with and please give us IPv6. > Nothing I said in the above paragraph is different from what I presented in the Interop slides. Besides, my recollection of what transpired in the meeting is very different from what you say. Noone told me NAT is a bad dream. And, noone begged for V6. My recollection was that people appreciated the problem space that NATs, proxies and tunnels were addressing and the other alternate solutions you proposed. I had a very good feedback from the audience on NATs. I also recall your acknowledging the role and usefulness of NATs on the podium. > My point is that is > the message I am hearing in my "samplings", otherwise I would stop > working on IPv6. I did not say the message is to not build NAT for > IPv4 we have no choice in many instances in the market today (although > we are working on that in AATN world). OK, your sampling apparantly does not include SOHO customers, for instance. If you are not opposed to building NATs, why do you call private addresses and NATs evil (You called NATs evil in another e-mail). > >I understand and respect your customer appreciation. But, let us not > >continue this line of religious wars. Thanks. > > I don't think you respect anything I just said so why say you do? > I respect. Thats why I listen. I understand your customer concerns and havent said a word against the problem space or the solution space you present. I may differ with you on technical issues. I dont mean that to be direspectful. > And why don't you jump in before I had to respond to all this mail > saying IPv6 sucks and NAT is good. But you instead wait until I send > defense mail and give me the tap, go tell it to those who started the > thread not me Suresh....... I can't hear you @!111!!!!!! > You make it sound like I was just waiting for you to respond, so I could jump in. But, that is not the case. I jumped in only because you called private addresses EVIL. As for the arguments on NATs vs. V6, it is purely technical and I didnt see much reason for me to badge in. Hope you understand. > /jim > regards, 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 Tue Jul 7 07:50:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA11764 for ipng-dist; Tue, 7 Jul 1998 07:46:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA11757 for ; Tue, 7 Jul 1998 07:46:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA08627 for ; Tue, 7 Jul 1998 07:46:00 -0700 Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA03826 for ; Tue, 7 Jul 1998 07:46:01 -0700 (PDT) Received: from mediaone.net (loshin.ne.mediaone.net [24.128.88.99]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id KAA02105 for ; Tue, 7 Jul 1998 10:45:59 -0400 (EDT) Message-ID: <35A234A7.B6FECD24@mediaone.net> Date: Tue, 07 Jul 1998 10:45:59 -0400 From: Pete Loshin Reply-To: pete@loshin.com X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 6002) Request for readers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks. I've been working on a short (about 250-300 pp, with big print) introduction to IPv6 (called _IPv6 Clearly Explained_, to be published by AP Professional later this year). It's almost done--but it needs some beta readers to point out my errors before they sneak into print. So, if you are willing to donate an evening, plain ride, or whatever other odd moments you've got, I'd appreciate (and use wherever appropriate) your comments and corrections. In return (and at the very least) you'll get mentioned in the acknowledgments and a copy of the book when its published. Other arrangements may also be possible for someone willing to do a formal technical edit. The complete manuscript should be available in the next couple of weeks; please contact me (pete@loshin.com) if you are interested in taking a look and possibly helping out. Thanks in advance. regards, -pl +----------------------------------------------------+ | Pete Loshin pete@loshin.com | | | | Editor, Corporate Internet Strategies | | | | _Personal Encryption Clearly Explained_ (APP 1998) | | _TCP/IP Clearly Explained_ (APP 1997) | | _Extranet Design and Implementation_ (SYBEX 1997) | +----------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 07:54:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA11798 for ipng-dist; Tue, 7 Jul 1998 07:52:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA11790 for ; Tue, 7 Jul 1998 07:52:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09560 for ; Tue, 7 Jul 1998 07:52:13 -0700 Received: from saruman.sics.se (saruman.sics.se [193.10.66.131]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA06801 for ; Tue, 7 Jul 1998 07:52:10 -0700 (PDT) Received: (from lalle@localhost) by saruman.sics.se (8.8.5/8.8.5) id QAA09543; Tue, 7 Jul 1998 16:52:07 +0200 To: ipng@sunroof.eng.sun.com Subject: (IPng 6003) unrecognised next header From: Lars Albertsson Date: 07 Jul 1998 16:52:06 +0200 Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 specification says an IPv6 packet containing a Next Header value unrecognised by the node should be discarded. An ICMP Parameter Problem message should also be sent to the source. What is the definition of "unrecognised by the node" ? No raw IP socket listener to that protocol? If not, should a raw IP listener register his protocol as recognised? Or should /etc/protocols be parsed? /Lalle -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 08:05:58 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA11950 for ipng-dist; Tue, 7 Jul 1998 08:01:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA11939 for ; Tue, 7 Jul 1998 08:01:41 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA11600 for ; Tue, 7 Jul 1998 08:01:41 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA11684 for ; Tue, 7 Jul 1998 08:01:35 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA06558; Wed, 8 Jul 1998 01:01:10 +1000 (from kre@munnari.OZ.AU) To: Lars Albertsson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6004) Re: unrecognised next header In-Reply-To: Lars Albertsson's message of "07 Jul 1998 16:52:06 +0200." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Jul 1998 01:01:07 +1000 Message-Id: <8054.899823667@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 07 Jul 1998 16:52:06 +0200 From: Lars Albertsson Message-ID: | What is the definition of "unrecognised by the node" ? Any time the node has no idea what to do with the header (no-one wants to process it). | Or should /etc/protocols be parsed? No... (nor should one visit the IANA records and see if perhaps the number was just assigned and is not yet even in /etc/protocols). 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 Jul 7 08:18:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA11993 for ipng-dist; Tue, 7 Jul 1998 08:14:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA11986 for ; Tue, 7 Jul 1998 08:14:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA14112 for ; Tue, 7 Jul 1998 08:14:15 -0700 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA18639 for ; Tue, 7 Jul 1998 08:14:09 -0700 (PDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2166.0) id <3GWZPMVG>; Tue, 7 Jul 1998 08:13:54 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100583256E@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Lars Albertsson'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6005) RE: unrecognised next header Date: Tue, 7 Jul 1998 08:13:52 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The IPv6 specification says an IPv6 packet containing a Next Header > value unrecognised by the node should be discarded. An ICMP Parameter > Problem message should also be sent to the source. > > What is the definition of "unrecognised by the node" ? No raw IP > socket listener to that protocol? If not, should a raw IP listener > register his protocol as recognised? Or should /etc/protocols be > parsed? I think this has to be your judgement call as an implementor. Is the upper layer protocol specified by the next header value appropriately understood and acted upon by your system? If you have an API for adding handlers for new next header values, then you could either assume that the handler does the right thing, or you could distinguish in your API between "snooping handlers" and "real handlers". 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 Jul 7 08:44:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA12104 for ipng-dist; Tue, 7 Jul 1998 08:37:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA12096 for ; Tue, 7 Jul 1998 08:37:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA19652 for ; Tue, 7 Jul 1998 08:37:19 -0700 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA02808 for ; Tue, 7 Jul 1998 08:37:14 -0700 (PDT) Received: from truckee (128.3.9.220) by cnrmail.lbl.gov with SMTP (Eudora Internet Mail Server 2.1); Tue, 7 Jul 1998 08:37:14 -0700 X-Sender: rlfink@cnrmail.lbl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 07 Jul 1998 08:37:12 -0700 To: pete@loshin.com, ipng@sunroof.eng.sun.com From: Bob Fink Subject: (IPng 6006) Re: Request for readers In-Reply-To: <35A234A7.B6FECD24@mediaone.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <1312321862-506034010@cnrmail.lbl.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pete, At 10:45 AM 7/7/98 -0400, Pete Loshin wrote: >Hi folks. I've been working on a short (about 250-300 pp, with big >print) introduction to IPv6 (called _IPv6 Clearly Explained_, to be >published by AP Professional later this year). It's almost done--but it >needs some beta readers to point out my errors before they sneak into >print. > >So, if you are willing to donate an evening, plain ride, or whatever >other odd moments you've got, I'd appreciate (and use wherever >appropriate) your comments and corrections. In return (and at the very >least) you'll get mentioned in the acknowledgments and a copy of the >book when its published. Other arrangements may also be possible for >someone willing to do a formal technical edit. > >The complete manuscript should be available in the next couple of weeks; >please contact me (pete@loshin.com) if you are interested in taking a >look and possibly helping out. Please add me to your edit list. Thanks, 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 Tue Jul 7 09:35:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA12268 for ipng-dist; Tue, 7 Jul 1998 09:30:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA12219; Tue, 7 Jul 1998 09:28:22 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA05109; Tue, 7 Jul 1998 09:28:19 -0700 Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA02810; Tue, 7 Jul 1998 09:28:18 -0700 (PDT) Received: from classic (classic.viagenie.qc.ca [206.123.31.5]) by jazz.viagenie.qc.ca (Viagenie/8.8.8) with SMTP id MAA17029; Tue, 7 Jul 1998 12:22:21 -0400 (EDT) Message-Id: <3.0.5.32.19980707122739.00adba50@mail.viagenie.qc.ca> Prefer-Language: fr, en X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 07 Jul 1998 12:27:39 -0400 To: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU, ngtrans@sunroof.eng.sun.com From: Marc Blanchet Subject: (IPng 6007) I-D ACTION:draft-blanchet-ipaddressalloc-00.txt 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 JAA12220 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, a first cut of a draft on an allocation scheme. Comments appreciated. Regards, Marc. ---------------------------------------------------------------------------- ------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A flexible allocation scheme for IP addresses (IPv4 and IPv6) Author(s) : M. Blanchet Filename : draft-blanchet-ipaddressalloc-00.txt Pages : 5 Date : 06-Jul-98 This draft presents an IP address allocation scheme that enables the IP allocator (the organisation that allocates addresses) to postpone the final decision of prefix length by keeping space between allocated bits of the different parts of the IP address. This enables the allocator to change the different part lengths of the prefix (TLA, subTLA, SLA, ...) even after allocated spaces. This scheme is applicable to both IPv4 and IPv6 but is envisionned mainly for IPv6 where the address space is larger and more flexible. 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-blanchet-ipaddressalloc-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-blanchet-ipaddressalloc-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-blanchet-ipaddressalloc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19980706163222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-blanchet-ipaddressalloc-00.txt ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp :57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifié, Éditions Logiques, 1997 ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 09:44:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA12333 for ipng-dist; Tue, 7 Jul 1998 09:38:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA12325 for ; Tue, 7 Jul 1998 09:38:23 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA07530 for ; Tue, 7 Jul 1998 09:37:12 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA08064 for ; Tue, 7 Jul 1998 09:37:11 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail12.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id MAA26687; Tue, 7 Jul 1998 12:37:10 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA04044; Tue, 7 Jul 1998 12:37:03 -0400 Message-Id: <199807071637.AA04044@wasted.zk3.dec.com> To: suresh@livingston.com (Pyda Srisuresh) Cc: bound@zk3.dec.com, Telford001@aol.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: (IPng 6008) Re: IPv6 questions In-Reply-To: Your message of "Tue, 07 Jul 1998 07:14:46 PDT." <199807071414.HAA14311@kc.livingston.com> Date: Tue, 07 Jul 1998 12:37:03 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >PBXes in the voice world, in my mind, is a good analogy to NATs in the >datacom world. I mentioned it so you could appreciate others' points of >view. Instead, you chose to name calling, which I dont appreciate. I agree PBXes do Translation as NATs, that I agree with. I did not see the relationship to Private Addresses and still don't. I also think debating any discourse by bringing in disjoint relations is sophist and political, though it may not be the intent of the person during the debate. I should have left that comment out of my response but from my cultural background it is not name calling, sorry you took it that way. To me name calling is much different, but I can see your perspective. > >> >The problems related by your customers are not all-exhaustive. Neither >> >are the solutions you espouse. There are myriad of problems asociated >> >with global connectivity. These include service provider charges, exposure >> >to hacker community, need to connect disperate routing realms etc. Many >> >people prefer proxies, private addresses and NATs for these reasons. >> >> What!!!!!! I recall sitting on the podium with you at Las Vegas >> Interop and most of the audience told you and I then NAT is a bad dream >> we all have to live with and please give us IPv6. >> >Nothing I said in the above paragraph is different from what I presented >in the Interop slides. Besides, my recollection of what transpired in the >meeting is very different from what you say. Noone told me NAT is a bad >dream. And, noone begged for V6. My recollection was that people >appreciated the problem space that NATs, proxies and tunnels were >addressing and the other alternate solutions you proposed. I had a very >good feedback from the audience on NATs. I also recall your acknowledging >the role and usefulness of NATs on the podium. By "bad dream" I was summing up what I heard. To be specific comments like I do not want to have to do address translation, break IPSEC tomorrow, VOIP tomorrow, or have a single point of failure is more to the point. That IPv6 would avoid this was a good thing and that other alternatives are being worked on. Yes I said NATs serve a useful purpose, but I think they are evil (and that is only my opinion). I consider scorpians, leeches, and chipmunks evil too but they do serve a useful purpose. I now see the problem here it is the word "evil". I do not subscribe to the Western Culture connotation of the word evil nor accept it. But I won't go there why. Let me put it this way anytime "translation" has to be peformed within a system there is a penalty for that translation, as opposed to cases where that translation does not have to be performed. I question any case in any system before implementing a translation to make sure it is really necessary. Today because of the lack of IPv4 address space NAT is useful and for some necessary. I consider this unfortunate and believe IPv6 will make it so that this form of translation at least will not be required because of a shortage of Internet Protocol address space. >> My point is that is >> the message I am hearing in my "samplings", otherwise I would stop >> working on IPv6. I did not say the message is to not build NAT for >> IPv4 we have no choice in many instances in the market today (although >> we are working on that in AATN world). >OK, your sampling apparantly does not include SOHO customers, for instance. >If you are not opposed to building NATs, why do you call private addresses >and NATs evil (You called NATs evil in another e-mail). I think I explained that above? >> And why don't you jump in before I had to respond to all this mail >> saying IPv6 sucks and NAT is good. But you instead wait until I send >> defense mail and give me the tap, go tell it to those who started the >> thread not me Suresh....... I can't hear you @!111!!!!!! >You make it sound like I was just waiting for you to respond, so I could >jump in. But, that is not the case. I jumped in only because you called >private addresses EVIL. As for the arguments on NATs vs. V6, it is >purely technical and I didnt see much reason for me to badge in. Hope >you understand. OK. That clears that up. I will now use the word "unfortunate". But I inherently don't like translation in any form when it can be avoided or there is an alternative, NAT is just the hot one right now and in this community. There are many other cases elsewhere both technically and socially where I find translation very unfortunate. /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 Jul 8 05:02:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA13706 for ipng-dist; Wed, 8 Jul 1998 04:55:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA13699 for ; Wed, 8 Jul 1998 04:55:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA00936 for ; Wed, 8 Jul 1998 04:55:21 -0700 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA13311 for ; Wed, 8 Jul 1998 04:55:22 -0700 (PDT) Received: from era-t.ericsson.se (era-t.ericsson.se [147.214.173.8]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/glacier-1.11) with SMTP id NAA25738; Wed, 8 Jul 1998 13:55:20 +0200 (MET DST) Received: from rcur98nbn172 by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA09576; Wed, 8 Jul 1998 13:55:19 +0200 Message-Id: <3.0.32.19700101000000.009faea0@anchor.ericsson.se> X-Sender: eratekd@anchor.ericsson.se X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 01 Jan 1970 00:00:00 +0100 To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com From: Thomas Eklund Subject: (IPng 6009) Re: IPv6 questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:06 AM 7/6/98 -0400, you wrote: > >>Hmm... I wonder if you think PBXes in the voice world are EVIL too. PBXes >>allow localized private extensions within enterprises. > >Completely different paradigm. Like I told you once before your a great >politician. Must agree on this- IP has nothing to do with PBXes!!! The telephone network is a switched network and not a packet based IP network. > >>The problems related by your customers are not all-exhaustive. Neither >>are the solutions you espouse. There are myriad of problems asociated >>with global connectivity. These include service provider charges, exposure >>to hacker community, need to connect disperate routing realms etc. Many >>people prefer proxies, private addresses and NATs for these reasons. > >What!!!!!! I recall sitting on the podium with you at Las Vegas >Interop and most of the audience told you and I then NAT is a bad dream >we all have to live with and please give us IPv6. My point is that is >the message I am hearing in my "samplings", otherwise I would stop >working on IPv6. I did not say the message is to not build NAT for >IPv4 we have no choice in many instances in the market today (although >we are working on that in AATN world). > >>I understand and respect your customer appreciation. But, let us not >>continue this line of religious wars. Thanks. > >I don't think you respect anything I just said so why say you do? > >And why don't you jump in before I had to respond to all this mail >saying IPv6 sucks and NAT is good. But you instead wait until I send >defense mail and give me the tap, go tell it to those who started the >thread not me Suresh....... I can't hear you @!111!!!!!! > I think I started the thread with a couple IPv6 related questions!!! I did not start any of those religious things that people are throwing at eachother and I think that this is not the place to go on with this debate. Regard Thomas Eklund, Ericsson Radio Systems AB >/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 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 8 05:51:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA13792 for ipng-dist; Wed, 8 Jul 1998 05:46:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA13785 for ; Wed, 8 Jul 1998 05:45:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA07403 for ; Wed, 8 Jul 1998 05:45:36 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA28447 for ; Wed, 8 Jul 1998 05:45:37 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA03213; Wed, 8 Jul 1998 08:44:26 -0400 (EDT) Message-Id: <199807081244.IAA03213@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6010) I-D ACTION:draft-degermark-ipv6-hc-06.txt Date: Wed, 08 Jul 1998 08:44:26 -0400 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 Header Compression Author(s) : M. Degermark, B. Nordgren S. Pink Filename : draft-degermark-ipv6-hc-06.txt Pages : 46 Date : 07-Jul-98 This document describes how to compress multiple IP headers and TCP and UDP headers per-hop over point-to-point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. 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-degermark-ipv6-hc-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-degermark-ipv6-hc-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-degermark-ipv6-hc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980707124739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-degermark-ipv6-hc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-degermark-ipv6-hc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980707124739.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 Jul 8 10:33:06 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA14359 for ipng-dist; Wed, 8 Jul 1998 10:25:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA14352 for ; Wed, 8 Jul 1998 10:25:47 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA05578 for ; Wed, 8 Jul 1998 10:25:42 -0700 Received: from imo19.mx.aol.com (imo19.mx.aol.com [198.81.17.9]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA23858 for ; Wed, 8 Jul 1998 10:25:41 -0700 (PDT) Received: from Telford001@aol.com by imo19.mx.aol.com (IMOv14_b1.1) id SATHa04161; Wed, 8 Jul 1998 13:21:54 -0400 (EDT) Message-ID: Date: Wed, 8 Jul 1998 13:21:54 EDT To: thomas.eklund@era.ericsson.se, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Cc: Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 6011) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/8/98 8:12:45 AM Eastern Daylight Time, thomas.eklund@era.ericsson.se writes: > At 11:06 AM 7/6/98 -0400, you wrote: > >>Hmm... I wonder if you think PBXes in the voice world are EVIL too. PBXes > >>allow localized private extensions within enterprises. > >Completely different paradigm. Like I told you once before your a great > >politician. > Must agree on this- IP has nothing to do with PBXes!!! > The telephone network is a switched network and not a packet based IP > network. In point of fact, while most of the telephone network is circuit switched, beyond the local loop a large part of the signal and control network is packet switched like IP, but the signaling networks general use a different suite of protocols. While most of the voice links are circuit switched, there does exist some packet switching of voice data in the telephone network. Circuit switching and packet switching address the same problem. A lot of data comes into a communications computer (switch) on a set of incoming channels and must be directed to the right outgoing channels. The key difference is how resources are reserved on the channels and within the communications computer. In circuit switches resources on the channel are reserved absolutely for the duration of a session. Old-fashioned circuit oriented communications computers would reserve the switch's hardware resources for each session for the duration of the session. I have built circuit switches that packet switched internally. In IP packet switching systems channel and communications computer resources are only reserved for the duration of the packet transit over the link and through the communications computer. INTSERV with RSVP tries to move away from this model of IP via some rather silly and illogical misengineering. Some of the high performance packet switching systems that are more misguided in design actually use space division circuit switches as the core of the communications computer. X.25 and FR switches represent an intermediate sort of species between IP packet switches and circuit switches. In the case of X.25 and FR packet switches, soft resources within the communications computer are reserved for the duration of the session and bandwidth on the channel is reserved statistically. In many respects X.25 and X.75 gateways are packet switched equivalents of PBXs (especially when connecting a private X.25 network to a public X.25 network). An incoming call from the public network is accepted, and a VC is established if a call can be completed from the gateway to the end host within the private network. Data is moved from one VC to the other. (The scenario is more like DDI than PBX systems where a secondary number is dialed). X.25 and X.75 gateways perform a form of address translation usually on the basis of configuration tables. The address translation mapping, which maps an external VCID to an internal VCID, lasts at least for the duration of the session. The VCID mapping is precisely analogous to the time slot mapping that PBXs create. X.25 and X.75 gateways are just as much like NAT devices as they are like PBXs, the difference being that NAT devices must translate complete addresses on a per packet basis while X.25 and X.75 gateways translate once and from then one use the VCID mapping. PBXs, X.25/X.75 gateways and network layer NAT devices are all slightly different variations of the same theme. >From the perspective of the MAC layer one could argue that a router between two MAC layers of the same type carries out exactly the same sort of address translation as a NAT device. A packet comes to the router with a MAC address local to the received interface. On the basis of a little packet analysis and communications with MAC address resolution servers (end hosts via ARP perhaps), a unidirectional translation between the incoming and outgoing MAC address is established that is keyed by the destination IP address. In a sense one could argue that a router is a first order address translation device while a NAT device is a second order address device. To consider first order address translation devices good while second order address translation devices are evil is the sort of silliness that bridge (a first order packet switch) vs. router (a second order packet switch) debates used to engender. I elucidate how silly that particular debate was in Routing in a Bridged Network. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 8 13:01:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA14467 for ipng-dist; Wed, 8 Jul 1998 12:49:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA14460 for ; Wed, 8 Jul 1998 12:49:13 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16663 for ; Wed, 8 Jul 1998 12:49:10 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA18422 for ; Wed, 8 Jul 1998 12:49:10 -0700 (PDT) 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 MAA29292; Wed, 8 Jul 1998 12:48:37 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199805261534.LAA12994@east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jul 1998 12:49:31 -0700 To: perez@isi.edu From: Steve Deering Subject: (IPng 6012) Re: icmp rate limiting Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:24 AM -0700 5/26/98, Maryann Perez Maher wrote: > The current ICMPv6-v2 draft (draft-ietf-ipngwg-icmp-v2-00.txt) states > that ICMP rate limiting should be done for informational replies as > well as error messages (section 2.4). This statement might suggest > that ND and MLD ICMP reply messages, along echo replies, should be > rate limited, which is probably not the intention. Or is there some reason > why they should be? If not, this should be made clear in the text. > Btw, this is a change from RFC 1885, where it is mandatory to rate limit > only error messages. Maryann (and everyone else), Sorry for the extremely delayed response to your message above. After conferring with my co-author (Alex) and the IPng document editor (Bob), it still remains a mystery how that requirement to rate-limit non-error ICMP messages got added to the v2 draft. We believe that that was a mistake, and that mandatory rate-limiting should apply to ICMP error messages only. If someone remembers a WG decision to add mandatory rate-limiting for non-error messages, please speak up. (Alex reviewed the minutes of all the WG meetings since the RFC 1885 was published, and could find no record of such a decision being made.) Otherwise, we will delete that requirement from the draft ICMPv6 spec. 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 Jul 8 13:49:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA14687 for ipng-dist; Wed, 8 Jul 1998 13:38:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA14680 for ; Wed, 8 Jul 1998 13:38:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA27556 for ; Wed, 8 Jul 1998 13:38:29 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA14653 for ; Wed, 8 Jul 1998 13:38:30 -0700 (PDT) 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 NAA04866; Wed, 8 Jul 1998 13:38:27 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100583252A@red-msg-50.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jul 1998 13:39:20 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 6013) maximum size of ICMP error messages Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:12 AM -0700 7/1/98, Richard Draves wrote: > Another question - draft-ietf-ipngwg-icmp-v2-00.txt says that the maximum > size for an ICMP error packet should be 576 octets. Should this be raised to > the new minimum MTU, 1280 octets? Yes, not fixing that was an oversight. (However, I don't think it matters much. Probably the main reason to correct it to 1280 is to avoid having to explain "Why 576?" to every new person who reads the spec and wonders.) I think Tim is right regarding ICMPv6-to-ICMPv4 translation: it's easy enough and correct enough to just truncate ICMP error messages to 576 for the IPv4 world. Any other comments on this topic? If not, we'll go ahead and replace every reference to "576" with a reference to "the IPv6 minimum MTU [IPv6]" in the ICMPv6 draft. 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 Jul 8 14:38:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA14838 for ipng-dist; Wed, 8 Jul 1998 14:31:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA14828 for ; Wed, 8 Jul 1998 14:31:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA10842 for ; Wed, 8 Jul 1998 14:31:21 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA15296 for ; Wed, 8 Jul 1998 14:31:22 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA14109; Wed, 8 Jul 1998 17:30:48 -0400 (EDT) Message-Id: <199807082130.RAA14109@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6014) Protocol Action: IP Version 6 Addressing Architecture to Proposed Standard Date: Wed, 08 Jul 1998 17:30:48 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved 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. These documents are the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The document "IP Version 6 Addressing Architecture" specification defines the addressing architecture of the IP Version 6 protocol. This document includes the IPv6 addressing model, text representations of IPv6 addresses (which are 128 bits in length) , definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document is intended to replace RFC 1884 which will become historic. The document "An IPv6 Aggregatable Global Unicast Address Format" defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol and the IPv6 Addressing Architecture (mentioned above) and is designed to facilitate scalable Internet routing. This documented is intended to replaces RFC 2073, "An IPv6 Provider-Based Unicast Address Format" which will become historic. This document is viewed as an improvement over RFC 2073; major changes include removal of the registry bits because they are not needed for route aggregation, support of EUI-64 based interface identifiers, support of provider and exchange based aggregation, separation of public and site topology, and new aggregation based terminology. Working Group Summary These two documents have been the topic of much discussion and consideration, both within the working group and among the IANA and registries. Specifically, the Aggregatable Global Unicast Address Format document has been the subject of detailed discussions for well over a year in an attempt to come up with an address format which has the support of many in the Internet community, including the ISPs. In addition, the policies for how TLAs (the top-level prefixes) are assigned to ISPs have been moved to a separate document in order to clearly separate the technical issues from the operational aspects of how the IANA and the registries manage address space. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 9 15:21:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA16069 for ipng-dist; Thu, 9 Jul 1998 15:15:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA16062 for ; Thu, 9 Jul 1998 15:14:54 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA17453 for ; Thu, 9 Jul 1998 15:14:52 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA15954 for ; Thu, 9 Jul 1998 15:14:51 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2328.0) id <3P4381PP>; Thu, 9 Jul 1998 15:14:49 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810058325A9@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'IPng List'" Subject: (IPng 6017) tunnel fragmentation Date: Thu, 9 Jul 1998 15:14:49 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While doing testing of our MSR IPv6 implementation, I noticed some bugs with fragmentation in tunnels. This led me to look at the relevant drafts, and it seems there might be confusion in this area between "Transition Mechanisms for IPv6 Hosts and Routers" (see draft-ieft-ngtrans-mech-00.txt, Nov 19, 1997) and "Generic Packet Tunneling in IPv6" (see draft-ietf-ipngwg-ipv6-tunnel-08.txt, Jan 29, 1998). I was doing the testing with automatic tunnels, with three machines: ::131.107.65.121 - MSR IPv6 ::206.152.163.3 - Digital IPv6 ::131.178.38.97 - I don't know the implementation I can exchange 2000-byte pings with ::206.152.163.3 just fine. The MSR and Digital implementations use different values for the tunnel MTU as seen by v6 (they are both wrong: the MSR tunnel MTU is 1480, and the Digital tunnel MTU is 576), but that's not a problem in this test. They both fragment the ping packets at the v6 level, not the v4 level. I can not exchange 2000-byte pings with ::131.178.38.97. This implementation appears to use a large value for the tunnel MTU as seen by v6, so the echo replies that I receive are fragmented at the v4 level instead of the v6 level. The way the MSR v6 implementation does raw receives of v4 packets, the v4 fragments are not reassembled and the echo replies are not received properly by the v6 stack. So there are two bugs here in the MSR v6 implementation - it's using a bad value for the tunnel MTU, and it's not reassembling v4 fragments. Reassembly of v4 fragments is necessary in some situations because the v6 minimum MTU is 1280 while the v4 minimum MTU is 576, although in general I think tunnel implementations should avoid generating fragments inside the tunnel. Now turning to the relevant drafts: The Transition Mechanisms draft (section 3.2) says "the encapsulating node could view encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535 - 20 bytes to be exact..." and then goes on to talk about an optimization of doing IPv4 path MTU discovery to determine a better tunnel MTU. The Generic Packet Tunneling draft (section 6.7) says "The tunnel MTU is set dynamically to the path MTU between the tunnel entry-point and the tunnel exit-point nodes, minus the size of the tunnel headers: the maximum size of the tunnel packet payload that can be sent through the tunnel without fragmentation..." So v4 path MTU discovery is assumed. Then I find section 7.1 b) confusing: "If the original IPv6 packet is equal or smaller than the IPv6 minimum link MTU, the tunnel entry-point node encapsulates the original packet, and subsequently fragments the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the path MTU to the tunnel exit-point." Shouldn't that be "resulting IPv4 tunnel packet into IPv4 fragments"? I guess my conclusion here is that the differences between the two specs is confusing, and it would help reduce interoperability problems if the Transition Mechanisms draft just referred to the Generic Packet Tunneling draft. Thanks, 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 Thu Jul 9 15:55:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA16106 for ipng-dist; Thu, 9 Jul 1998 15:49:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA16099 for ; Thu, 9 Jul 1998 15:48:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA26098 for ; Thu, 9 Jul 1998 15:48:51 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA02618 for ; Thu, 9 Jul 1998 15:48:50 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2328.0) id <3P4RPWAH>; Thu, 9 Jul 1998 15:48:50 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810058325AB@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Steve Deering'" Cc: "'IPng List'" Subject: (IPng 6018) RE: tunnel fragmentation Date: Thu, 9 Jul 1998 15:48:27 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The difference between the two specs is: > > Transition Mechanisms specifies IPv6-over-IPv4 > > Generic Packet Tunneling specifies foo-over-IPv6 Ahh, total confusion on my part. Never mind. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 9 16:17:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA16137 for ipng-dist; Thu, 9 Jul 1998 16:10:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA16130 for ; Thu, 9 Jul 1998 16:10:22 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA03855 for ; Thu, 9 Jul 1998 16:10:21 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA00047 for ; Thu, 9 Jul 1998 15:43:25 -0700 (PDT) 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 PAA16666; Thu, 9 Jul 1998 15:43:22 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D810058325A9@red-msg-50.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Jul 1998 15:44:15 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 6019) Re: tunnel fragmentation Cc: "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, At 3:14 PM -0700 7/9/98, Richard Draves wrote: > ...Reassembly > of v4 fragments is necessary in some situations because the v6 minimum MTU > is 1280 while the v4 minimum MTU is 576,... Correction: the v4 minimum MTU is 68. (576 is the IPv4 minimum reassembly buffer size). > Then I find section 7.1 b) confusing: > "If the original IPv6 packet is equal or smaller than the IPv6 minimum link > MTU, the tunnel entry-point node encapsulates the original packet, and > subsequently fragments the resulting IPv6 tunnel packet into IPv6 fragments > that do not exceed the path MTU to the tunnel exit-point." > Shouldn't that be "resulting IPv4 tunnel packet into IPv4 fragments"? The Generic Packet Tunneling draft specifies how to tunnel foo inside of IPv6, that is, where IPv6 is the encapsulating protocol and the encapsulated protocol may be IPv6 or IPv4 or AppleTalk or whatever. The above paragraph applies specifically to tunneling IPv6 in IPv6. > I guess my conclusion here is that the differences between the two specs is > confusing, and it would help reduce interoperability problems if the > Transition Mechanisms draft just referred to the Generic Packet Tunneling > draft. The difference between the two specs is: Transition Mechanisms specifies IPv6-over-IPv4 Generic Packet Tunneling specifies foo-over-IPv6 but that's apparently not spelled out clearly enough. 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 Jul 10 06:05:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA16749 for ipng-dist; Fri, 10 Jul 1998 06:01:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA16741 for ; Fri, 10 Jul 1998 06:01:27 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA25860 for ; Fri, 10 Jul 1998 06:01:24 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA28174 for ; Fri, 10 Jul 1998 06:01:25 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA27791; Fri, 10 Jul 1998 09:01:21 -0400 (EDT) Message-Id: <199807101301.JAA27791@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6021) I-D ACTION:draft-ietf-ipngwg-ipv6-udp-mib-02.txt Date: Fri, 10 Jul 1998 09:01:20 -0400 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 Management Information Base for the User Datagram Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-udp-mib-02.txt Pages : 8 Date : 09-Jul-98 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of which IP versions underlie UDP, and only the UDP listener information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. 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-udp-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980709141144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-udp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980709141144.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 Jul 10 06:05:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA16748 for ipng-dist; Fri, 10 Jul 1998 06:01:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA16733 for ; Fri, 10 Jul 1998 06:01:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA25844 for ; Fri, 10 Jul 1998 06:01:18 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA28125 for ; Fri, 10 Jul 1998 06:01:18 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA27774; Fri, 10 Jul 1998 09:01:14 -0400 (EDT) Message-Id: <199807101301.JAA27774@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6020) I-D ACTION:draft-ietf-ipngwg-ipv6-tcp-mib-02.txt Date: Fri, 10 Jul 1998 09:01:13 -0400 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 Management Information Base for the Transmission Control Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-tcp-mib-02.txt Pages : 9 Date : 09-Jul-98 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of which IP versions underlie TCP, and only the TCP connection information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. 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-tcp-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980709141009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tcp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980709141009.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 Sat Jul 11 08:17:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA00528 for ipng-dist; Sat, 11 Jul 1998 08:14:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA00521 for ; Sat, 11 Jul 1998 08:14:13 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA23106 for ; Sat, 11 Jul 1998 08:14:12 -0700 Received: from imo14.mx.aol.com (imo14.mx.aol.com [198.81.17.4]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA07556 for ; Sat, 11 Jul 1998 08:14:11 -0700 (PDT) Received: from Telford001@aol.com by imo14.mx.aol.com (IMOv14_b1.1) id 5CWFa13455; Sat, 11 Jul 1998 11:09:53 -0400 (EDT) Message-ID: <1c448443.35a78042@aol.com> Date: Sat, 11 Jul 1998 11:09:53 EDT To: bound@zk3.dec.com, suresh@livingston.com Cc: thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6022) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/7/98 12:55:55 PM Eastern Daylight Time, bound@zk3.dec.com writes: > By "bad dream" I was summing up what I heard. To be specific comments > like I do not want to have to do address translation, break IPSEC > tomorrow, VOIP tomorrow, or have a single point of failure is more to > the point. That IPv6 would avoid this was a good thing and that other > alternatives are being worked on. Yes I said NATs serve a useful > purpose, but I think they are evil (and that is only my opinion). I > consider scorpians, leeches, and chipmunks evil too but they do serve a > useful purpose. I now see the problem here it is the word "evil". After reviewing the discussion, as far as I can tell NAT is evil because it makes IPv6 unnecessary. IPv6 is specifically supposed to address the problem of the dearth of IPv4 addresses. The rest of the aspects of IPv6 are basically fluff (theoretical elimination of router fragmentation, new method of address resolution, elimination of header checksum, redesign of header fields etc.) and certainly are not valid reasons for the IPv6 effort. NAT renders the need for a larger address space unnecessary. It would be far better to shut down the IPv6 effort and spend the engineering effort in doing NAT right. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 11 08:25:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA00545 for ipng-dist; Sat, 11 Jul 1998 08:23:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA00538 for ; Sat, 11 Jul 1998 08:23:19 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA23527 for ; Sat, 11 Jul 1998 08:23:18 -0700 Received: from imo21.mx.aol.com (imo21.mx.aol.com [198.81.17.65]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA08903 for ; Sat, 11 Jul 1998 08:23:18 -0700 (PDT) Received: from Telford001@aol.com by imo21.mx.aol.com (IMOv14_b1.1) id TMTIa12329; Sat, 11 Jul 1998 11:22:58 -0400 (EDT) Message-ID: <8f22a999.35a78353@aol.com> Date: Sat, 11 Jul 1998 11:22:58 EDT To: mo@UU.NET, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6023) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/7/98 9:59:25 AM Eastern Daylight Time, mo@UU.NET writes: > the Internet will "get big" whether or not IPv6 makes orbit. > this is a biological process, *not* a result of centralized planning. > > Issuing dicta about "how the Internet will get big via a > certain path" is rather like the Politburo order the wheat > to grow taller. it's entertaining to watch but ultimately > pointless. Especially, because the Internet obviously is getting big by the NAT path that renders IPv6 unnecessary. Rather than wasting tremendous amounts of effort in trying to stop the natural evolution and in proclaiming NAT evil, it probably makes more sense in putting this effort into making NAT as well-engineered as possible. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 11 08:36:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA00587 for ipng-dist; Sat, 11 Jul 1998 08:32:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA00580 for ; Sat, 11 Jul 1998 08:32:12 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA23923 for ; Sat, 11 Jul 1998 08:32:11 -0700 Received: from imo29.mx.aol.com (imo29.mx.aol.com [198.81.17.73]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA10268 for ; Sat, 11 Jul 1998 08:32:11 -0700 (PDT) Received: from Telford001@aol.com by imo29.mx.aol.com (IMOv14_b1.1) id 5SSLa27848; Sat, 11 Jul 1998 11:27:32 -0400 (EDT) Message-ID: Date: Sat, 11 Jul 1998 11:27:32 EDT To: bound@zk3.dec.com Cc: suresh@livingston.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6024) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/7/98 9:29:37 AM Eastern Daylight Time, bound@zk3.dec.com writes: > >IPv6 is the nightmare that will follow the bad dream. A lot of the problems > >associated with topological instability in the IPv4 internet relate simply > >to size. The bigger the internet the higher the probability that there > >will be instability somewhere that has a probability of propagating. > Telling the Internet it cannot get big is naive. It will get big and > thats why IPv6 is important, evolved, and will be pervasive over time. I am not saying that the Internet cannot get big. Rather some growth paths increase topological instability. The IPv6 growth path as Bound is recommending (no NAT because NAT is evil) guarantees increased topological instability in the core networks (which is already a problem). IPv6+NAT addresses the topological instability problem, but NAT elimates the IP address space problem, which is the only really import issue that IPv6 addresses. With NAT why bother with IPv6? Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 11 08:58:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA00639 for ipng-dist; Sat, 11 Jul 1998 08:54:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA00632 for ; Sat, 11 Jul 1998 08:54:50 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA25047 for ; Sat, 11 Jul 1998 08:54:49 -0700 Received: from imo22.mx.aol.com (imo22.mx.aol.com [198.81.17.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA13748 for ; Sat, 11 Jul 1998 08:54:49 -0700 (PDT) Received: from Telford001@aol.com by imo22.mx.aol.com (IMOv14_b1.1) id JAWIa20982; Sat, 11 Jul 1998 11:51:44 -0400 (EDT) Message-ID: <52105b6.35a78a12@aol.com> Date: Sat, 11 Jul 1998 11:51:44 EDT To: perry@piermont.com Cc: bound@zk3.dec.com, thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6025) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/6/98 11:14:32 AM Eastern Daylight Time, perry@piermont.com writes: > Telford001@aol.com writes: > > > Even though such interconnections are not wide open (i.e. they are > > > heavily firewalled), the conflicts we get in private IP spaces are > > > often a giant pain in the buttocks. > [...] > > > You have no idea how many headaches would be solved for people if such > > > institutions could always get unique IP address space. > > I would argue that inadequacies of the NAT+Firewalling devices are > > being identified not necessarily a need for a global unique address > > space. > Before, you claimed there was no need. Now, you claim the need is > caused by the fact that we are using insufficiently powerful > kludges. Make up your mind... Learn something about the engineering process. In the normal engineering process, the engineer analyses flaws in a system and incrementally fixes the flaws and makes improvements. Throwing out the original system (even if the new system is called by the same name as the old system) and ignoring all the experience learned in the development of that and related systems to start from scratch is not a normal engineering process and will not result in a perfect product (unless you are God in which case you are not doing engineering) but will rather take about as long as it took to develop the original system to get the new system to the state of effectiveness of the old system. > > In any case, this particular problem could be easily > > solved by the creation of an IPv4 right address extension > > option (subaddress) rather than going to a completely new > > IP protocol. > As if the effort involved in that would be any smaller? Please. Why would anyone think that adding one or two new options to IPv4 would take as much time as the specification of IPv6 has been taking? > > I do not deal with as many banks and financial institutions as DEC, but > > those with whom I have dealt do not even want the outside world to know > > the internal distribution of IP addressess. > That has nothing to do with the question of whether one wants those > addresses to be unique or not. If the system is going continually to remap unique local addresses to unique global addresses, why bother to keep the local addresses unique? Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 11 09:07:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA00657 for ipng-dist; Sat, 11 Jul 1998 09:05:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA00649 for ; Sat, 11 Jul 1998 09:05:17 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA25466 for ; Sat, 11 Jul 1998 09:05:16 -0700 Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA15518 for ; Sat, 11 Jul 1998 09:05:16 -0700 (PDT) Received: from Telford001@aol.com by imo28.mx.aol.com (IMOv14_b1.1) id 5CYPa17153; Sat, 11 Jul 1998 12:01:56 -0400 (EDT) Message-ID: <297331ba.35a78c76@aol.com> Date: Sat, 11 Jul 1998 12:01:56 EDT To: bound@zk3.dec.com Cc: thomas.eklund@era.ericsson.se, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6026) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/6/98 10:58:13 AM Eastern Daylight Time, bound@zk3.dec.com writes: > >> >In any case, lack of adequate checksumming is only one > >> >of a plethora of problems associated with IPv6. > >> I have no clue why you say this. What are you talking about IPv6 > >> enhanced this by requiring us to checksum UDP too. As far as removing > >> it from the IP header I think that was a brilliant thing to do. > >People keep making this claim. I cannot imagine why > >anyone would want to allow potentially very large amount > >of data to travel through the network unprotected by > >checksums. > Others have responded but I will add with IPSEC you don't need the > checksum either. IPSEC is mandatory for IPv6. I don't follow how the implementation of IPSEC would prevent a bad guy trolling for packets according the Invasion of Europe example A better argument would be that the military should have a private network with NAT and firewalls (actually it does but Bound considers such evil) or that the IPv4 header checksum is so weak that it cannot really thwart network trollers. I would make the rejoinder that any checksum is better than none or that perhaps now that headers are potentially so large considering a stronger checksum makes a lot more sense than eliminating checksums. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 11 12:12:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA00845 for ipng-dist; Sat, 11 Jul 1998 12:07:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA00838 for ; Sat, 11 Jul 1998 12:07:44 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA07320 for ; Sat, 11 Jul 1998 12:07:42 -0700 Received: from imo28.mx.aol.com (imo28.mx.aol.com [198.81.17.72]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA16437 for ; Sat, 11 Jul 1998 12:07:42 -0700 (PDT) Received: from Telford001@aol.com by imo28.mx.aol.com (IMOv14_b1.1) id FECIa17154; Sat, 11 Jul 1998 15:07:11 -0400 (EDT) Message-ID: <328805c0.35a7b7e0@aol.com> Date: Sat, 11 Jul 1998 15:07:11 EDT To: andre@pipeline.ch Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6031) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/11/98 2:36:22 PM Eastern Daylight Time, andre@pipeline.ch writes: > If you don't like IPv6 go to the IETF and whine and don't use it once > it is available and widespread. > I (and I think lots of others) can't follow your (IMO silly) NAT > argumentation. But that should be better discussed on a IPv4 mailing > list and not here. The market will choose whatever is better (or > better promoted, you should start advertising for NAT on TV and radio). The argument should be accessible to high-schoolers. It was argued that IPv6 was needed because there was a dearth of IPv4 addresses. Large corporations and enterprises have found a solution. (It does not even matter what the solution is.) Thus IPv6 is a solution in search of a problem. It seems silly to continue especially when the argument for IPv4 is being reduced to ipse dixit assertions that NAT is evil. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 11 15:13:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA00947 for ipng-dist; Sat, 11 Jul 1998 15:08:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA00940 for ; Sat, 11 Jul 1998 15:08:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA18565 for ; Sat, 11 Jul 1998 15:08:06 -0700 Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA16320 for ; Sat, 11 Jul 1998 15:08:06 -0700 (PDT) Received: from nnsp.eds.com (nnsp.eds.com [199.228.143.130] (may be forged)) by ns2.eds.com (8.8.8/8.8.8) with ESMTP id SAA18112; Sat, 11 Jul 1998 18:08:05 -0400 (EDT) Received: from info1.iscg.eds.com (info1.iscg.eds.com [130.174.18.171]) by nnsp.eds.com (8.8.8/8.8.8) with SMTP id SAA02604; Sat, 11 Jul 1998 18:07:34 -0400 (EDT) Received: by info1.iscg.eds.com (5.65/DEC-Ultrix/4.3) id AA02300; Sat, 11 Jul 1998 18:07:34 -0400 Mime-Version: 1.0 X-Sender: jcutle01@info1.iscg.eds.com Message-Id: In-Reply-To: <328805c0.35a7b7e0@aol.com> X-Mailer: Eudora Pro for Macintosh Date: Sat, 11 Jul 1998 18:05:58 -0400 To: Telford001@aol.com From: "James R. Cutler" Subject: (IPng 6032) Re: IPv6 questions Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Transfer-Encoding: quoted-printable Actually, it DOES matter what the solution is. One must always consider the= total life cost. We (a large corporation and enterprise) have learned by= experience that, even within a private intranet, unique addressing provides= capabilities that are simply not possible using NAT solutions. This= inability to deliver certain services has a business cost in and of itself. So, for us, it does matter that the solution is IPv6. One important reason= for this is the elimination of "evil" NAT.=20 Regards, JimC At 3:07 PM -0400 7/11/98, Telford001@aol.com wrote: >The argument should be accessible to high-schoolers. It was >argued that IPv6 was needed because there was a dearth >of IPv4 addresses. Large corporations and enterprises have >found a solution. (It does not even matter what the solution >is.) Thus IPv6 is a solution in search of a problem. It seems >silly to continue especially when the argument for IPv4 is=20 >being reduced to ipse dixit assertions that NAT is evil. > >Joachim Martillo >Telford Tools, Inc.=20 >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- - - James R. Cutler EDS , 800 Tower Drive, Troy, MI 48098 Phone: +1 248 265 7514 FAX: +1 248 265 7514 EDS Internal Web: World Wide Web: -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.5.3 Comment: "Eternal vigilance is the price of liberty." iQA/AwUBNafiIhBOy4QB3DjOEQLBzQCg3TMElRTKI6eSfId3lFYAwlkNPl0AoJk6 esC9qk30e35sQyVTzxkh/4g0 =cOls -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 12 07:44:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA01246 for ipng-dist; Sun, 12 Jul 1998 07:37:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA01239 for ; Sun, 12 Jul 1998 07:37:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA11159 for ; Sun, 12 Jul 1998 07:37:27 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA19313 for ; Sun, 12 Jul 1998 07:37:27 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA17135; Mon, 13 Jul 1998 00:37:11 +1000 (from kre@munnari.OZ.AU) To: Telford001@aol.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6033) Re: IPv6 questions In-Reply-To: A message of "Sat, 11 Jul 1998 11:09:53 -0400." References: <1c448443.35a78042@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Jul 1998 00:37:10 +1000 Message-Id: <16472.900254230@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 11 Jul 1998 11:09:53 EDT From: Telford001@aol.com Message-ID: <1c448443.35a78042@aol.com> I have no idea why anyone would want to keep arguing this after all this time, I certainly don't know why I am bothering to reply, I ought to be censured for it, and probably will be, but never mind. Apologies in advance to everyone (else). | After reviewing the discussion, as far as I can tell NAT is | evil because it makes IPv6 unnecessary. NAT was evil long before IPv6 was even on the horizon. And yes, that NAT lokalike that exists in some phone PBX's is just as evil - a good PBX would have none of that nonsense (eg: at my office we have a PBX, which is no big surprise, but no NAT involved, numbers are all globally unique, though if we desire (and we do) some of them can't be dialed from outside, and some phones can't dial outside - that's firewalling - the number space is part of the global phone numbering scheme however - what's more, my building PBX has two providers, and hence the phones here all have two numbers, you get to choose which you use by the number you dial, we get to choose which we use as well... all very IPv6 faimilar types of things). | IPv6 is specifically supposed to address the problem of the dearth of IPv4 | addresses. And the routing table problems - one of the less often stated advantages of IPv6 is simply that we get to start all over again with address space assignments, and do it all again in a way that makes sense, while also making it clear to everyone that the assignments must continue to make sense over time (and hence IPv6 has made it much easier to renumber than IPv4, and work is continuing to make it even easier - eventually we may have it that there's no effort involved at all). | The rest of the aspects of IPv6 are basically | fluff (theoretical elimination of router fragmentation, | new method of address resolution, elimination of header | checksum, redesign of header fields etc.) and certainly | are not valid reasons for the IPv6 effort. Of themselves, you're right, no-one would have redesigned IPv4 just for those - but since something was needed, we may as well get all the advantage we can out if it. | NAT renders the need for a larger address space unnecessary. Nonsense, the 32 bit IPv4 address space will not be big enough regardless of how much NAT we have. And if we do anything at all to IPv4 (such as "address extension" option type things, which believe it or not, were considered seriously) then we have to change the universe to make them useable (whatever we do requires changes to the universe), and if we're going to change the universe anyway, we may as well make it a change that is a quantum improvement (improve everything) not just to add some gloss around the edges. | It would | be far better to shut down the IPv6 effort and spend the | engineering effort in doing NAT right. NAT cannot be "done right". For NAT to work it has to alter the contents of packets (the headers at the very least, though in practice, in the content as well). That means that there's no way I can tell the remote end, with certainty, and knowing that it trusts me, and me alone, exactly who I am, and where I can be reached - because I wil not know the latter, someone is going to fiddle it for me. It would be akin to requesting a bank send out a bank cheque ("cashier's check" in funny language) and telling them to send it to "the address that some other random person is going to insert in this message". Really. Engineering sometimes requires one to recognise that the edifice under construction has gone as far as it can possibly go, and that it is time to tear it down and start afresh. That does not mean losing the knowledge gained in the original construction - far from it, that is the basis upon which we engineer the new. Whie I certainly don't agree with every decision that has been made in the design of IPv6, I certainly respect that they have been made based upon the combined experience and knowledge of a large number of very able engineers, and I certainly am not about to claim that my individual experience is in some way greater or better than that of the group as a whole. IPv6 was a community decision. Live with it. 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 Mon Jul 13 03:22:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA01805 for ipng-dist; Mon, 13 Jul 1998 03:16:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA01798 for ; Mon, 13 Jul 1998 03:16:36 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA04609 for ; Mon, 13 Jul 1998 03:16:33 -0700 Received: from imo27.mx.aol.com (imo27.mx.aol.com [198.81.17.71]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id DAA25164 for ; Mon, 13 Jul 1998 03:16:34 -0700 (PDT) Received: from Telford001@aol.com by imo27.mx.aol.com (IMOv14_b1.1) id FNRJa06640; Mon, 13 Jul 1998 06:16:19 -0400 (EDT) Message-ID: <37900903.35a9de74@aol.com> Date: Mon, 13 Jul 1998 06:16:19 EDT To: andre@pipeline.ch Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6035) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/11/98 2:43:50 PM Eastern Daylight Time, andre@pipeline.ch writes: > Routing instability is not a direct problem of big address spaces, > it's a problem of proper routing protocols and adequate filtering > done on the borders of a backbone. As topological instability can be caused by the continual updating of routing information, I am not sure how one can make the above claim unless complete filtering with static configuration of routes is meant. In any case, just getting big can cause instability. Consider stacking videotape cartridges. If the stack gets large enough it gets unstable. In the case at hand, suppose that over a 3 month period a router gets into a state wherein it can cause propagating topological stability with a probability of 0.00001. Assume probablistic independence for the behavior of the routers. 20000 routers implies the network will be stable 82% of the time. 10000 routers implies the network will be stable 90% of the time. 05000 routers implies the network will be stable 95% of the time. 02500 routers implies the network will be stable 98% of the time. 01000 routers implies the network will be stable 99% of the time. Only the 1000 router network is approaching the realm of provider acceptability, and the assumptions above overoptimistically unrealistic. Nevertheless under the assumptions above, if we need a twenty thousand router network, I would suggest a two level hierarchy wherein there would be 20 separate Level 1 internets each with a thousand routers (and each internet topologically stable 99% of the time) and a small number of Level 2 routers routing between 20 internets. > So NAT is not the solution, it simply freezes the current state and > structure of the Internet. No it does not. In a reasonable engineering approach, the engineer identifies the inadequacies of NAT and then makes the minor change to fix it. In this case, the engineer would identify the lack of an address extension option to identify the internet number, which would be used by the Level 2 routers. If the address extension option were 16 bits, 65,535 separate internets could be run in parallel, which would be adequate for a long time. If that number seems to small, a 32 bit address extension option could be used. > What is needed is a BGPv5, any takers? A complete lack of engineering understanding and roughly analogous to constructing a videocartridge tube in the above example. The tube might allow the videocartidges to be stacked somewhat higher, but ultimately a very tall tube is unstable. At some point common sense dictates setting up multiple stacks of videocartridges. In general, the IETF has a tendency to attack internet related problems by designing more protocols. MPLS, RSVP, INTSERV, OSPF and IPv6 are all problematic attempts to solve performance or architectural problems by designing a new protocol, which of course must itself be debugged and which is likely to be a source of new performance and architectural problems. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 13 05:31:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA01932 for ipng-dist; Mon, 13 Jul 1998 05:26:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA01925 for ; Mon, 13 Jul 1998 05:25:58 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA14712 for ; Mon, 13 Jul 1998 05:25:55 -0700 Received: from imo22.mx.aol.com (imo22.mx.aol.com [198.81.17.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA25167 for ; Mon, 13 Jul 1998 05:25:56 -0700 (PDT) Received: from Telford001@aol.com by imo22.mx.aol.com (IMOv14_b1.1) id FMKLa20982; Mon, 13 Jul 1998 08:25:01 -0400 (EDT) Message-ID: Date: Mon, 13 Jul 1998 08:25:01 EDT To: andre@pipeline.ch Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6036) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/11/98 2:57:47 PM Eastern Daylight Time, andre@pipeline.ch writes: > Telford001@aol.com wrote: > > In a message dated 7/6/98 11:14:32 AM Eastern Daylight Time, > > perry@piermont.com writes: > -snip- [and cc trimmed] > > > Before, you claimed there was no need. Now, you claim the need is > > > caused by the fact that we are using insufficiently powerful > > > kludges. Make up your mind... > > Learn something about the engineering process. In the normal > > engineering process, the engineer analyses flaws in a system > > and incrementally fixes the flaws and makes improvements. > Yea, but that is not the reason why the Internet is so widespread today. I have to ask why Opermann believes the Internet is so widespread today. I could argue that the success of the Internet has related to the willingness of the Internet community to go with what works rather than blindly accept the systems from ISO or the IETF. TCP, IP, FTP, SMTP, UDP, X, HTTP, TELNET, RIP and all the major workhorses of the internet (with perhaps the exception of PPP repugnant though it be) were developed outside of the IETF context. On the other hand, examples of incremental engineering abound in the Internet: DNS to replace /etc/hosts, CIDR, SMTP, subnetting, NAT, etc. ad infinitum. > > Throwing out the original system (even if the new system > > is called by the same name as the old system) and ignoring > > all the experience learned in the development of that and > > related systems to start from scratch is not a normal > > engineering process and will not result in a perfect > > product (unless you are God in which case you > > are not doing engineering) but will rather take > > about as long as it took to develop the original > > system to get the new system to the state of > > effectiveness of the old system. > [you have a funny way of styling your text] > You call NAT the 'perfect' solution? Unlike IPv6, NAT is an incremental improvement that can be improved incrementally. > > > > In any case, this particular problem could be easily > > > > solved by the creation of an IPv4 right address extension > > > > option (subaddress) rather than going to a completely new > > > > IP protocol. > > > As if the effort involved in that would be any smaller? Please. > > Why would anyone think that adding one or two new options > > to IPv4 would take as much time as the specification of > > IPv6 has been taking? > That was an option, you are too late. Beam yourself back to '93 and '94. I am not so sure. I spoke with Deering about the direction back then. As far as I could tell he considered IPv4 fundamentally flawed and wanted to get network layer software pervasively rewritten. It is interesting that the result is a sort of imitation of the IEEE 802 protocols. 1) larger address space than IPv4 2) no fragmentation (fortunately that as been rendered inoperative) 3) dependence on hardware checksums. One could almost achieve IPv6 with IEEE 802 by defining a way to allocate MAC addresses to allow for aggregation (a la DECNET) and define broadcast domains with the development of modified routing protocols to pass around address aggregation information. One would merely have to define a mechanism to build an logical 802 structure on top of non-802 media. It is not particularly hard. Telford Tools' VLAN Routers provide such a capability for X.25, FR and point-to-point links. > > > > I do not deal with as many banks and financial institutions as DEC, but > > > > those with whom I have dealt do not even want the outside world to know > > > > the internal distribution of IP addressess. > > > That has nothing to do with the question of whether one wants those > > > addresses to be unique or not. > > If the system is going continually to remap unique local addresses to > > unique global addresses, why bother to keep the local addresses unique? Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 13 05:32:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA01941 for ipng-dist; Mon, 13 Jul 1998 05:30:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA01934 for ; Mon, 13 Jul 1998 05:30:12 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA15151 for ; Mon, 13 Jul 1998 05:30:09 -0700 Received: from imo24.mx.aol.com (imo24.mx.aol.com [198.81.17.68]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA26505 for ; Mon, 13 Jul 1998 05:30:10 -0700 (PDT) Received: from Telford001@aol.com by imo24.mx.aol.com (IMOv14_b1.1) id FEUOa22588; Mon, 13 Jul 1998 08:29:48 -0400 (EDT) Message-ID: Date: Mon, 13 Jul 1998 08:29:48 EDT To: andre@pipeline.ch Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6037) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/11/98 3:00:32 PM Eastern Daylight Time, andre@pipeline.ch writes: > Checksums do not prevent intentional altering of packet content, they > just detect altering the content by accident. I agree. And the bigger the network and the more traffic, the more instances of non-intentional alteration of packet content. > Authentication and authorization do not belong to the transport layer. Why not? Authentication and authorization can be done at any layer -- wherever they make sense. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 13 05:37:58 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA01974 for ipng-dist; Mon, 13 Jul 1998 05:36:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA01967 for ; Mon, 13 Jul 1998 05:36:00 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA15884 for ; Mon, 13 Jul 1998 05:35:57 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA28370 for ; Mon, 13 Jul 1998 05:35:58 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA20750; Mon, 13 Jul 1998 08:35:54 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA61318; Mon, 13 Jul 1998 08:35:50 -0400 Received: from hygro.raleigh.ibm.com (lig32-225-17-225.us.lig-dial.ibm.com [32.225.17.225]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id IAA17600; Mon, 13 Jul 1998 08:35:47 -0400 (EDT) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id HAA12235; Mon, 13 Jul 1998 07:11:20 -0400 Message-Id: <199807131111.HAA12235@hygro.raleigh.ibm.com> To: Telford001@aol.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 6038) Re: IPv6 questions In-reply-to: Your message of "Sat, 11 Jul 1998 11:09:53 EDT." <1c448443.35a78042@aol.com> Date: Mon, 13 Jul 1998 07:11:20 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com writes: > It would be far better to shut down the IPv6 effort and spend the > engineering effort in doing NAT right. Some people would argue that IPv6 is precisely that -- trying to do NAT right (yes, I know that IPv6 work started before NATs became prevalent). NAT is a fundamental paradigm shift. Having NAT boxes change addresses without the end node's involvement fundamentally breaks some end-to-end properties that are non-trivial to do without. IPSec is the most obvious example. Although it is a commonly held view that the way to fix things is to do NAT "right", or to make the world more "NAT-friendly", the reality is that this is very hard to do, and may simply not be possible. You either have NAT (with all of its problems) or you don't; it's just not possible to have it a "little bit" with only a "little bit" of the negatives. 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 Jul 13 05:43:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA02001 for ipng-dist; Mon, 13 Jul 1998 05:39:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA01994 for ; Mon, 13 Jul 1998 05:39:06 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA16134 for ; Mon, 13 Jul 1998 05:39:03 -0700 Received: from imo14.mx.aol.com (imo14.mx.aol.com [198.81.17.4]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA29408 for ; Mon, 13 Jul 1998 05:39:04 -0700 (PDT) Received: from Telford001@aol.com by imo14.mx.aol.com (IMOv14_b1.1) id RKUNa13455; Mon, 13 Jul 1998 08:38:08 -0400 (EDT) Message-ID: <4a1b9e98.35a9ffb2@aol.com> Date: Mon, 13 Jul 1998 08:38:08 EDT To: jcutle01@iscg.eds.com Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6039) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/11/98 6:27:31 PM Eastern Daylight Time, jcutle01@iscg.eds.com writes: > Actually, it DOES matter what the solution is. One must always consider the > total life cost. We (a large corporation and enterprise) have learned by > experience that, even within a private intranet, unique addressing provides > capabilities that are simply not possible using NAT solutions. This > inability to deliver certain services has a business cost in and of itself. > So, for us, it does matter that the solution is IPv6. One important reason > for this is the elimination of "evil" NAT. The public phone network has tons of non-uniqueness in addresses. The same (USA) seven digit number occurs repeatedly throughout the USA. A simple 3 digit address extension creates uniqueness when needed. Adding a left address extension option (internet number) would have solved the problem effectively and easily. Existing routers would become Level 1 IP routers, while upgraded routers could provide Level 1 IP routing within internets and Level 2 IP routing between internets. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 13 05:54:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA02109 for ipng-dist; Mon, 13 Jul 1998 05:49:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA02102 for ; Mon, 13 Jul 1998 05:49:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA17367 for ; Mon, 13 Jul 1998 05:49:07 -0700 Received: from sonusdc1.sonusnet.com (sonusdc1.sonusnet.com [208.227.153.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA03024 for ; Mon, 13 Jul 1998 05:49:08 -0700 (PDT) Received: by sonusdc1 with Internet Mail Service (5.0.1458.49) id ; Mon, 13 Jul 1998 08:44:39 -0400 Message-ID: <817B0B6F9966D1119B3000805FCBDF600DB989@sonusdc1> From: "Goodman, Todd" To: "'Telford001@aol.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6040) Re: IPv6 questions Date: Mon, 13 Jul 1998 08:44:37 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Telford001@aol.com [mailto:Telford001@aol.com] > Sent: Monday, July 13, 1998 6:16 AM > To: andre@pipeline.ch > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6035) Re: IPv6 questions > > > In a message dated 7/11/98 2:43:50 PM Eastern Daylight Time, > andre@pipeline.ch > writes: > > > Routing instability is not a direct problem of big address spaces, > > it's a problem of proper routing protocols and adequate filtering > > done on the borders of a backbone. > > As topological instability can be caused by the continual updating > of routing information, I am not sure how one can make the above > claim unless complete filtering with static configuration of > routes is > meant. > > In any case, just getting big can cause instability. > Consider stacking > videotape cartridges. If the stack gets large enough it gets > unstable. > > In the case at hand, suppose that over a 3 month period a router > gets into a state wherein it can cause propagating > topological stability with a probability of 0.00001. > Assume probablistic independence for the behavior of the > routers. > > 20000 routers implies the network will be stable 82% of the time. > 10000 routers implies the network will be stable 90% of the time. > 05000 routers implies the network will be stable 95% of the time. > 02500 routers implies the network will be stable 98% of the time. > 01000 routers implies the network will be stable 99% of the time. > > Only the 1000 router network is approaching the realm of provider > acceptability, and the assumptions above overoptimistically > unrealistic. > > Nevertheless under the assumptions above, if we need a twenty > thousand router network, I would suggest a two level hierarchy > wherein there would be 20 separate Level 1 internets each > with a thousand routers (and each internet topologically > stable 99% of the time) and a small number of Level 2 routers > routing between 20 internets. Excuse me for interrupting, but I've been watching you make this point a number of times and I'm honestly trying to understand the motivation. What specifically in the IPV6 protocol prohibits a hierarchical routing protocol from being implemented? > > > So NAT is not the solution, it simply freezes the current state and > > structure of the Internet. > > No it does not. In a reasonable engineering approach, the engineer > identifies the inadequacies of NAT and then makes the minor > change to fix it. In this case, the engineer would identify > the lack of an address extension option to identify the > internet number, which would be used by the Level 2 routers. > If the address extension option were 16 bits, 65,535 separate > internets could be run in parallel, which would be adequate > for a long time. If that number seems to small, a 32 bit > address extension option could be used. I'm also puzzled about your desire to perform per packet rewriting and address translation so that an end station is not able to communicate its address to a peer on the other side of the translator. Is it because you feel machine capabilities are at such a level that the processing required is not burdensome? > > > What is needed is a BGPv5, any takers? > > A complete lack of engineering understanding > and roughly analogous to constructing a videocartridge > tube in the above example. The tube might allow > the videocartidges to be stacked somewhat higher, > but ultimately a very tall tube is unstable. At > some point common sense dictates setting > up multiple stacks of videocartridges. Again, why do you feel it is impossible to design a hierarchical routing protocol with IPV6? > > In general, the IETF has a tendency to attack > internet related problems by designing more > protocols. MPLS, RSVP, INTSERV, OSPF > and IPv6 are all problematic attempts to solve > performance or architectural problems by > designing a new protocol, which of course > must itself be debugged and which is > likely to be a source of new performance > and architectural problems. > > Joachim Martillo > Telford Tools, Inc. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 06:32:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA02302 for ipng-dist; Mon, 13 Jul 1998 06:27:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA02295 for ; Mon, 13 Jul 1998 06:26:55 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA21798 for ; Mon, 13 Jul 1998 06:26:52 -0700 Received: from imo11.mx.aol.com (imo11.mx.aol.com [198.81.17.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA19347 for ; Mon, 13 Jul 1998 06:26:53 -0700 (PDT) Received: from Telford001@aol.com by imo11.mx.aol.com (IMOv14_b1.1) id 9BKCa04021; Mon, 13 Jul 1998 09:26:32 -0400 (EDT) Message-ID: Date: Mon, 13 Jul 1998 09:26:32 EDT To: kre@munnari.OZ.AU Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6041) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/12/98 10:57:57 AM Eastern Daylight Time, kre@munnari.OZ.AU writes: > NAT was evil long before IPv6 was even on the horizon. And yes, that > NAT lokalike that exists in some phone PBX's is just as evil - a good PBX > would have none of that nonsense (eg: at my office we have a PBX, which is > no big surprise, but no NAT involved, numbers are all globally unique, though > if we desire (and we do) some of them can't be dialed from outside, and some > phones can't dial outside - that's firewalling - the number space is > part of the global phone numbering scheme however - what's more, my building > PBX has two providers, and hence the phones here all have two numbers, > you get to choose which you use by the number you dial, we get to choose which > we use as well... all very IPv6 faimilar types of things). Obviously, Elz works for a teeny company. If a company has locations in Waltham, MA, Austin, TX, San Jose, CA, tie-lines and address reinterpretation all become extremely valuable and useful. The key to good engineering is to make effective unprejudiced use of available technology. > | IPv6 is specifically supposed to address the problem of the dearth of IPv4 > | addresses. > And the routing table problems - one of the less often stated advantages of > IPv6 is simply that we get to start all over again with address space > assignments, and do it all again in a way that makes sense, while also > making it clear to everyone that the assignments must continue to make sense over > time (and hence IPv6 has made it much easier to renumber than IPv4, and work > is continuing to make it even easier - eventually we may have it that there's > no effort involved at all). In some senses, IPv6 almost provides the sort of structured address that would have been preferable, but one can get the renumbering and fully hierarchical addressing as well as dual level hierarchical routing by just using a left address extension option. Why bother with the rest of the cruft? > | The rest of the aspects of IPv6 are basically > | fluff (theoretical elimination of router fragmentation, > | new method of address resolution, elimination of header > | checksum, redesign of header fields etc.) and certainly > | are not valid reasons for the IPv6 effort. > Of themselves, you're right, no-one would have redesigned IPv4 just for > those - but since something was needed, we may as well get all the > advantage we can out if it. > | NAT renders the need for a larger address space unnecessary. > Nonsense, the 32 bit IPv4 address space will not be big enough regardless > of how much NAT we have. And if we do anything at all to IPv4 (such as > "address extension" option type things, which believe it or not, were > considered seriously) then we have to change the universe to make them > useable (whatever we do requires changes to the universe), and if we're > going to change the universe anyway, we may as well make it a change that > is a quantum improvement (improve everything) not just to add some gloss > around the edges. I took part in some of those meetings. I do not remember left address extensions (internet numbers) or right address extensions (subaddresses) being seriously considered. No, address extension options do not require changing the universe as long as the existing router base (Level 1 routers) just pass non-understood options along uninterpreted. DNS and some application code would have to change to provide the option information and set some socket options. If a host has to send a packet out of its internet, it would just send the packet to a default level 2 router. > | It would > | be far better to shut down the IPv6 effort and spend the > | engineering effort in doing NAT right. > > NAT cannot be "done right". For NAT to work it has to alter the contents > of packets (the headers at the very least, though in practice, in the content > as well). That means that there's no way I can tell the remote end, with > certainty, and knowing that it trusts me, and me alone, exactly who I am, > and where I can be reached - because I will not know the latter, someone is > going to fiddle it for me. It would be akin to requesting a bank send out > a bank cheque ("cashier's check" in funny language) and telling them to send > it to "the address that some other random person is going to insert in this > message". Really. I disagree. Security of the specified sort has been done for years through X.25 and X.75 gateways. > Engineering sometimes requires one to recognise that the edifice under > construction has gone as far as it can possibly go, and that it is time to > tear it down and start afresh. The point I was trying to make. IPv6 is not incremental engineering, but rather represents a radical innovation. In any case, if working engineers were in the process of finding ways to give every corporation its own private internet, I have to question whether IPv4 had gone as far as it could go. > That does not mean losing the knowledge > gained in the original construction - far from it, that is the basis upon > which we engineer the new. Not clear at all. I remember in the IP transition meetings there was a conscious attempt to ignore all the experience learned in transitioning DECNET phases. > While I certainly don't agree with every > decision that has been made in the design of IPv6, I certainly respect that > they have been made based upon the combined experience and knowledge of a > large number of very able engineers, I recommend pp. 190-192 of Engineering and the Mind's Eye by Eugene S. Ferguson. I will try to put the relevant passages up at my website today or tomorrow. > and I certainly am not about to claim > that my individual experience is in some way greater or better than that of > the group as a whole. IPv6 was a community decision. Live with it. I remember such comments in the context of ISO OSI. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 13 06:55:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA02342 for ipng-dist; Mon, 13 Jul 1998 06:47:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA02335 for ; Mon, 13 Jul 1998 06:47:42 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA24462 for ; Mon, 13 Jul 1998 06:47:39 -0700 Received: from imo14.mx.aol.com (imo14.mx.aol.com [198.81.17.4]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA28402 for ; Mon, 13 Jul 1998 06:47:40 -0700 (PDT) Received: from Telford001@aol.com by imo14.mx.aol.com (IMOv14_b1.1) id 2FLVa13455; Mon, 13 Jul 1998 09:47:03 -0400 (EDT) Message-ID: Date: Mon, 13 Jul 1998 09:47:03 EDT To: tgoodman@sonusnet.com Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6042) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/13/98 9:07:19 AM Eastern Daylight Time, tgoodman@sonusnet.com writes: > Excuse me for interrupting, but I've been watching you make this point a > number > of times and I'm honestly trying to understand the motivation. What > specifically > in the IPV6 protocol prohibits a hierarchical routing protocol from > being > implemented? I think I mentioned previously that with proper address interpretation one can use IPv6 for hierarchical routing. A good first step to extending the IP architecture is the introduction of address extension options that work with NAT and debugged dual level hierarchical routing. Sometime later moving to a modified address format would have made sense. The number of changes, the logical basis for these changes and the strategy of introduction is more of a problem than the IPv6 addresses. Although I must point out that the specification of a left address extension option (internet number) provides private internets and eliminates practically any need for IPv6. > > > So NAT is not the solution, it simply freezes the current state and > > > structure of the Internet. > > No it does not. In a reasonable engineering approach, the engineer > > identifies the inadequacies of NAT and then makes the minor > > change to fix it. In this case, the engineer would identify > > the lack of an address extension option to identify the > > internet number, which would be used by the Level 2 routers. > > If the address extension option were 16 bits, 65,535 separate > > internets could be run in parallel, which would be adequate > > for a long time. If that number seems to small, a 32 bit > > address extension option could be used. > I'm also puzzled about your desire to perform per packet rewriting and > address translation so that an end station is not able to communicate its > address to a peer on the other side of the translator. Is it because you feel > machine capabilities are at such a level that the processing required is not > burdensome? NAT is not burdensome. On routers using AM29K and Alpha and type processors it can be performed with 3 extra accesses to memory. > > > What is needed is a BGPv5, any takers? > > A complete lack of engineering understanding > > and roughly analogous to constructing a videocartridge > > tube in the above example. The tube might allow > > the videocartidges to be stacked somewhat higher, > > but ultimately a very tall tube is unstable. At > > some point common sense dictates setting > > up multiple stacks of videocartridges. > Again, why do you feel it is impossible to design a hierarchical routing > protocol with IPV6? It is not, but introducing hierarchical routing first with the address extension option would solve most NAT problems, solve the hard problems of making the internet bigger after which the IETF could deal with the rather trivial problem of reformating the IP address. > > In general, the IETF has a tendency to attack > > internet related problems by designing more > > protocols. MPLS, RSVP, INTSERV, OSPF > > and IPv6 are all problematic attempts to solve > > performance or architectural problems by > > designing a new protocol, which of course > > must itself be debugged and which is > > likely to be a source of new performance > > and architectural problems. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 13 14:59:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA03074 for ipng-dist; Mon, 13 Jul 1998 14:47:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA03067 for ; Mon, 13 Jul 1998 14:46:45 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA03059 for ; Mon, 13 Jul 1998 14:46:42 -0700 Received: from pagesz.net (nina.pagesz.net [208.194.157.3]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA05847 for ; Mon, 13 Jul 1998 14:46:43 -0700 (PDT) Received: from nina.pagesz.net (nina.pagesz.net [208.194.157.3]) by pagesz.net (8.8.5/8.8.4) with SMTP id RAA25147 for ; Mon, 13 Jul 1998 17:46:42 -0400 Date: Mon, 13 Jul 1998 17:46:40 -0400 (EDT) From: wimeran To: ipng@sunroof.eng.sun.com Subject: (IPng 6044) Re: IPv6 questions and telford Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm feeling spammed. I got in this morning and had 22 new messages. Fully 11 of them were from telford001@aol.com. Sheesh! I also read at least 3 different replies to different messages that all said essentially the same thing in the response (non-quoted) portion of the message. Mr. Martillo ought to learn from the spammers that the best way to make your point is _not_ to yell it louder and longer and more often than everybody else. It just makes everybody think you haven't gotten past the kindergarden mentality. I'm not saying he doesn't have any valid points, I'm not qualified to argue with everything he says on an engineering basis, but please, try to group together your responses and tackle several points at once. Every "is not" does not have to be followed by a carefully handcrafted "is too" that is personally addressed and kindly CC'd to all of us. Oh, and one more thing: Nobody is going yo take you seriously as long as you're on AOL. Sorry, it's just a law of physics. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 17:36:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA03220 for ipng-dist; Mon, 13 Jul 1998 17:26:10 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA03213 for ; Mon, 13 Jul 1998 17:26:05 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA01871 for ; Mon, 13 Jul 1998 17:26:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id RAA03818 for ipng@sunroof.eng.sun.com; Mon, 13 Jul 1998 17:25:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA00796 for ; Sat, 11 Jul 1998 11:43:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA05369 for ; Sat, 11 Jul 1998 11:43:48 -0700 Received: from freefall.pipeline.ch (intranet.pipeline.ch [195.134.128.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA11635 for ; Sat, 11 Jul 1998 11:43:49 -0700 (PDT) Received: from pipeline.ch ([195.134.140.2]) by freefall.pipeline.ch (Netscape Mail Server v2.02) with ESMTP id AAA320; Sat, 11 Jul 1998 20:42:25 +0200 Message-ID: <35A7B263.FC972541@pipeline.ch> Date: Sat, 11 Jul 1998 20:43:47 +0200 From: "IBS / Andre Oppermann" Organization: Internet Business Solutions Ltd. X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Telford001@aol.com CC: ipng@sunroof.eng.sun.com Subject: (IPng 6046) Re: IPv6 questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com wrote: -snip- [and cc trimmed] > I am not saying that the Internet cannot get big. Rather some growth > paths increase topological instability. The IPv6 growth path as > Bound is recommending (no NAT because NAT is evil) guarantees > increased topological instability in the core networks (which is > already a problem). IPv6+NAT addresses the topological > instability problem, but NAT elimates the IP address space > problem, which is the only really import issue that IPv6 > addresses. With NAT why bother with IPv6? Routing instability is not a direct problem of big address spaces, it's a problem of proper routing protocols and adequate filtering done on the borders of a backbone. So NAT is not the solution, it simply freezes the current state and structure of the Internet. What is needed is a BGPv5, any takers? -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs@pipeline.ch -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 17:37:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA03210 for ipng-dist; Mon, 13 Jul 1998 17:25:17 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA03203 for ; Mon, 13 Jul 1998 17:25:08 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA01666 for ; Mon, 13 Jul 1998 17:25:09 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id RAA03790 for ipng@sunroof.eng.sun.com; Mon, 13 Jul 1998 17:24:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA00784 for ; Sat, 11 Jul 1998 11:36:22 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA04918 for ; Sat, 11 Jul 1998 11:36:20 -0700 Received: from freefall.pipeline.ch (freefall.pipeline.ch [195.134.128.40]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA10282 for ; Sat, 11 Jul 1998 11:36:20 -0700 (PDT) Received: from pipeline.ch ([195.134.140.2]) by freefall.pipeline.ch (Netscape Mail Server v2.02) with ESMTP id AAA109; Sat, 11 Jul 1998 20:34:51 +0200 Message-ID: <35A7B09D.52DB2EFA@pipeline.ch> Date: Sat, 11 Jul 1998 20:36:13 +0200 From: "IBS / Andre Oppermann" Organization: Internet Business Solutions Ltd. X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Telford001@aol.com CC: ipng@sunroof.eng.sun.com Subject: (IPng 6045) Re: IPv6 questions References: <1c448443.35a78042@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com wrote: -snip- [and cc trimmed] > After reviewing the discussion, as far as I can tell NAT is > evil because it makes IPv6 unnecessary. IPv6 is specifically > supposed to address the problem of the dearth of IPv4 > addresses. The rest of the aspects of IPv6 are basically > fluff (theoretical elimination of router fragmentation, > new method of address resolution, elimination of header > checksum, redesign of header fields etc.) and certainly > are not valid reasons for the IPv6 effort. NAT renders > the need for a larger address space unnecessary. It would > be far better to shut down the IPv6 effort and spend the > engineering effort in doing NAT right. Joachim, I think you have made your point very clear and now you better should leave this list because it looks like you are not willing to give any useful critics in here. If you don't like IPv6 go to the IETF and wine and don't use it once even it is available and wide spread. I (and I think lots of others) can't follow your (IMO silly) NAT argumentation. But that should be better discussed on a IPv4 mailing list and not here. The market will choose whatever is better (or better promoted, you should start advertising for NAT on TV and radio). -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs@pipeline.ch -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 17:38:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA03229 for ipng-dist; Mon, 13 Jul 1998 17:27:00 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA03222 for ; Mon, 13 Jul 1998 17:26:49 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA01954 for ; Mon, 13 Jul 1998 17:26:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id RAA03846 for ipng@sunroof.eng.sun.com; Mon, 13 Jul 1998 17:26:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA00809 for ; Sat, 11 Jul 1998 11:54:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA06167 for ; Sat, 11 Jul 1998 11:54:47 -0700 Received: from freefall.pipeline.ch (intranet.pipeline.ch [195.134.128.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA13647 for ; Sat, 11 Jul 1998 11:54:47 -0700 (PDT) Received: from pipeline.ch ([195.134.140.2]) by freefall.pipeline.ch (Netscape Mail Server v2.02) with ESMTP id AAA86; Sat, 11 Jul 1998 20:53:23 +0200 Message-ID: <35A7B4F5.862EB19B@pipeline.ch> Date: Sat, 11 Jul 1998 20:54:45 +0200 From: "IBS / Andre Oppermann" Organization: Internet Business Solutions Ltd. X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Telford001@aol.com CC: ipng@sunroof.eng.sun.com Subject: (IPng 6047) Re: IPv6 questions References: <52105b6.35a78a12@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Telford001@aol.com wrote: > In a message dated 7/6/98 11:14:32 AM Eastern Daylight Time, > perry@piermont.com writes: -snip- [and cc trimmed] > > Before, you claimed there was no need. Now, you claim the need is > > caused by the fact that we are using insufficiently powerful > > kludges. Make up your mind... > > Learn something about the engineering process. In the normal > engineering process, the engineer analyses flaws in a system > and incrementally fixes the flaws and makes improvements. Yea, but thats not the reason why the Internet is so widespread today. > Throwing out the original system (even if the new system > is called by the same name as the old system) and ignoring > all the experience learned in the development of that and > related systems to start from scratch is not a normal > engineering process and will not result in a perfect > product (unless you are God in which case you > are not doing engineering) but will rather take > about as long as it took to develop the original > system to get the new system to the state of > effectiveness of the old system. [you have a funny way of styling your text] You call NAT the 'perfect' solution? > > > In any case, this particular problem could be easily > > > solved by the creation of an IPv4 right address extension > > > option (subaddress) rather than going to a completely new > > > IP protocol. > > > As if the effort involved in that would be any smaller? Please. > > Why would anyone think that adding one or two new options > to IPv4 would take as much time as the specification of > IPv6 has been taking? That was an option, you are too late. Beam youself back to '93 and '94. > > > I do not deal with as many banks and financial institutions as DEC, but > > > those with whom I have dealt do not even want the outside world to know > > > the internal distribution of IP addressess. > > > That has nothing to do with the question of whether one wants those > > addresses to be unique or not. > > If the system is going continually to remap unique local addresses to > unique global addresses, why bother to keep the local addresses unique? -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs@pipeline.ch -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 17:39:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA03239 for ipng-dist; Mon, 13 Jul 1998 17:29:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA03231 for ; Mon, 13 Jul 1998 17:28:41 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA02263 for ; Mon, 13 Jul 1998 17:28:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id RAA03874 for ipng@sunroof.eng.sun.com; Mon, 13 Jul 1998 17:27:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA00825 for ; Sat, 11 Jul 1998 12:00:28 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA06551 for ; Sat, 11 Jul 1998 12:00:27 -0700 Received: from freefall.pipeline.ch (intranet.pipeline.ch [195.134.128.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA14599 for ; Sat, 11 Jul 1998 12:00:27 -0700 (PDT) Received: from pipeline.ch ([195.134.140.2]) by freefall.pipeline.ch (Netscape Mail Server v2.02) with ESMTP id AAA350; Sat, 11 Jul 1998 20:59:03 +0200 Message-ID: <35A7B649.5FE3AD6D@pipeline.ch> Date: Sat, 11 Jul 1998 21:00:25 +0200 From: "IBS / Andre Oppermann" Organization: Internet Business Solutions Ltd. X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Telford001@aol.com CC: ipng@sunroof.eng.sun.com Subject: (IPng 6048) Re: IPv6 questions References: <297331ba.35a78c76@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [cc trimmed] Telford001@aol.com wrote: > In a message dated 7/6/98 10:58:13 AM Eastern Daylight Time, bound@zk3.dec.com > writes: > > >> >In any case, lack of adequate checksumming is only one > > >> >of a plethora of problems associated with IPv6. > > > >> I have no clue why you say this. What are you talking about IPv6 > > >> enhanced this by requiring us to checksum UDP too. As far as removing > > >> it from the IP header I think that was a brilliant thing to do. > > > >People keep making this claim. I cannot imagine why > > >anyone would want to allow potentially very large amount > > >of data to travel through the network unprotected by > > >checksums. > > > Others have responded but I will add with IPSEC you don't need the > > checksum either. IPSEC is mandatory for IPv6. > > I don't follow how the implementation of IPSEC would prevent > a bad guy trolling for packets according the Invasion of Europe > example A better argument would be that the military > should have a private network with NAT and firewalls > (actually it does but Bound considers such evil) or that > the IPv4 header checksum is so weak that it cannot > really thwart network trollers. I would make the > rejoinder that any checksum is better than none or > that perhaps now that headers are potentially so large > considering a stronger checksum makes a lot more > sense than eliminating checksums. Checksums do not prevent intentional altering of packet content, they just detect altering the content by accident. Authentication and authorisation do not belong to the transport layer. -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs@pipeline.ch -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 17:40:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA03247 for ipng-dist; Mon, 13 Jul 1998 17:29:46 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA03240 for ; Mon, 13 Jul 1998 17:29:30 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA02354 for ; Mon, 13 Jul 1998 17:29:22 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id RAA03902 for ipng@sunroof.eng.sun.com; Mon, 13 Jul 1998 17:28:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA02448 for ; Mon, 13 Jul 1998 07:24:23 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29196 for ; Mon, 13 Jul 1998 07:24:20 -0700 Received: from pagesz.net (nina.pagesz.net [208.194.157.3]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA15244 for ; Mon, 13 Jul 1998 07:24:08 -0700 (PDT) Received: from nina.pagesz.net (nina.pagesz.net [208.194.157.3]) by pagesz.net (8.8.5/8.8.4) with SMTP id KAA10293 for ; Mon, 13 Jul 1998 10:23:58 -0400 Date: Mon, 13 Jul 1998 10:23:58 -0400 (EDT) From: wimeran To: ipng@sunroof.eng.sun.com Subject: (IPng 6049) Re: IPv6 questions and telford Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm feeling spammed. I got in this morning and had 22 new messages. Fully 11 of them were from telford001@aol.com. Sheesh! I also read at least 3 different responses to different messages that all said essentially the same thing at the bottom. Mr. Martillo ought to learn from the spammers that the best way to make your point is _not_ to yell it louder and longer and more often than everybody else. It just makes everybody think you haven't gotten past the kindergarden mentality. I'm not saying he doesn't have any valid points, I'm not qualified to argue with everything he says on an engineering basis, but please, try to group together your responses and tackle several points at once. Every "is not" does not have to be followed by a carefully handcrafted "is too" that is personally addressed and kindly CC'd to all of us. Oh, and one more thing: Nobody is going yo take you seriously as long as you're on AOL. Sorry, it's just a law of physics. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 20:10:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA03533 for ipng-dist; Mon, 13 Jul 1998 19:44:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA03524 for ; Mon, 13 Jul 1998 19:43:41 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA10413 for ; Mon, 13 Jul 1998 19:43:27 -0700 Received: from imo22.mx.aol.com (imo22.mx.aol.com [198.81.17.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA21858 for ; Mon, 13 Jul 1998 19:43:28 -0700 (PDT) Received: from Telford001@aol.com by imo22.mx.aol.com (IMOv14_b1.1) id 3IRWa22301; Mon, 13 Jul 1998 22:43:11 +2000 (EDT) Message-ID: <758d2d82.35aac5c0@aol.com> Date: Mon, 13 Jul 1998 22:43:11 EDT To: wimeran@pagesz.net, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6050) Re: IPv6 questions and telford Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-07-13 20:57:55 EDT, wimeran@pagesz.net writes: > Nobody is going yo take you seriously as long as you're on AOL. Sorry, > it's just a law of physics. Not a competent engineering approach. One should always take criticism seriously wherever it comes. I can always send e-mail from my account at Harvard, but AOL is rather more convenient when I travel. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 14 04:18:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA03831 for ipng-dist; Tue, 14 Jul 1998 04:13:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA03824 for ; Tue, 14 Jul 1998 04:12:53 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA26934 for ; Tue, 14 Jul 1998 04:12:52 -0700 Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA09392 for ; Tue, 14 Jul 1998 04:12:52 -0700 (PDT) Received: from Telford001@aol.com by imo26.mx.aol.com (IMOv14_b1.1) id 3AONa04520; Tue, 14 Jul 1998 07:12:44 -0400 (EDT) Message-ID: Date: Tue, 14 Jul 1998 07:12:44 EDT To: wimeran@pagesz.net Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6053) Re: IPv6 questions and telford Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/13/98 6:16:33 PM Eastern Daylight Time, wimeran@pagesz.net writes: > Nobody is going you take you seriously as long as you're on AOL. Sorry, > it's just a law of physics. I was thinking about this moronic comment. I put my resume, example design documents and example packet switching software on line, which is a hell of a lot more than most of the principles in the specification of IPv6 do. Wimeran@pagesz.net makes an issue who should be taken seriously. I have to ask where is his resume. Where is his example software? Where are his design documents? Why should he be taken seriously? And BTW, I make my living in providing debugging of last resort mostly in Massachusetts and California but occasionally in Canada, Mexico and Japan (mostly networking software, occasionally hardware and network design). I am intimately familiar with the work of several engineers heavily involved in the specification of IPv6. It would have been hard to find more incompetent engineers even if a crack special forces team had been sent on a desparate mission to build a team composed of this sort of loser. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 14 04:57:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA03864 for ipng-dist; Tue, 14 Jul 1998 04:52:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA03857 for ; Tue, 14 Jul 1998 04:52:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA29565 for ; Tue, 14 Jul 1998 04:52:15 -0700 Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA18636 for ; Tue, 14 Jul 1998 04:52:15 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with SMTP id NAA21505 for ; Tue, 14 Jul 1998 13:52:13 +0200 (MET DST) Received: by komsys-pc-mw.ethz.ch (NX5.67f2/NX3.0X) id AA01999; Tue, 14 Jul 98 13:52:12 +0200 Message-Id: <9807141152.AA01999@komsys-pc-mw.ethz.ch> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nextstep-Mailer: Mail 3.3 (Enhance 2.2) Received: by NeXT.Mailer (1.118.2) From: Marcel Waldvogel Date: Tue, 14 Jul 1998 13:52:10 +0200 To: ipng@sunroof.eng.sun.com Subject: (IPng 6054) Implosion for Multicast PMTU discovery? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A recent remark got me into thinking about how Multicast PMTU discovery dealt with the issue of implosion. I have been unable to find anything in the RFCs and I-Ds. Did I miss something or has this issue not yet been addressed? Thanks, -Marcel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 12:14:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA04327 for ipng-dist; Tue, 14 Jul 1998 12:08:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA04320 for ; Tue, 14 Jul 1998 12:08:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA11913 for ; Tue, 14 Jul 1998 12:08:15 -0700 Received: from pagesz.net (nina.pagesz.net [208.194.157.3]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA18562 for ; Tue, 14 Jul 1998 12:08:09 -0700 (PDT) Received: from nina.pagesz.net (nina.pagesz.net [208.194.157.3]) by pagesz.net (8.8.5/8.8.4) with SMTP id PAA14699 for ; Tue, 14 Jul 1998 15:08:07 -0400 Date: Tue, 14 Jul 1998 15:08:06 -0400 (EDT) From: wimeran To: ipng@sunroof.eng.sun.com Subject: (IPng 6055) Re: IPv6 questions and telford 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 > > Nobody is going you take you seriously as long as you're on AOL. Sorry, > > it's just a law of physics. > > I was thinking about this moronic comment. I put my resume, > example design documents and example packet switching > software on line, which is a hell of a lot more than most of > the principles in the specification of IPv6 do. > Wimeran@pagesz.net makes an issue who should > be taken seriously. No, wimeran@pagesz.net makes a joke. The rest of the post was the subject matter I intended seriously, but you (not suprisingly) focus on the most whimsical portion of my post to "refute". > I have to ask where is his resume. Where > is his example software? Where are his design documents? > Why should he be taken seriously? I shouldn't. I read this mailing list as a learning exercise, because my experience in the field is quite limited compared to most of the poeple that post. Notice that I did not attack your engineering or design decisions, just your annoying method of communicating them. > And BTW, I make my living in providing debugging of > last resort mostly in Massachusetts and California but > occasionally in Canada, Mexico and Japan (mostly > networking software, occasionally hardware and > network design). Implying that the prevalence of a poorly designed networking scheme might contribute to your future job security...? Do I smell an ulterior motive here? > I am intimately familiar with the > work of several engineers heavily involved in the > specification of IPv6. It would have been hard to > find more incompetent engineers even if a > crack special forces team had been sent on a desparate > mission to build a team composed of this sort of loser. Ah. The truth comes out. Your dislike for IPv6 and preference for NAT is personal. Perhaps one of those involved in the design of IPv6 offered you some insult? But the fact remains. If you feel that Toyotas are vastly superior to GM cars, you don't go to the GM plant in Detroit and shout out that tidbit. That course of action would earn you nothing more than the annoyance of a large number of people, and perhaps some well-aimed wrenches. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 13:32:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA04414 for ipng-dist; Tue, 14 Jul 1998 13:23:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA04407 for ; Tue, 14 Jul 1998 13:23:25 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA00709 for ; Tue, 14 Jul 1998 13:23:01 -0700 Received: from imo26.mx.aol.com (imo26.mx.aol.com [198.81.17.70]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA01825 for ; Tue, 14 Jul 1998 13:23:00 -0700 (PDT) Received: from Telford001@aol.com by imo26.mx.aol.com (IMOv14_b1.1) id 3LDOa04520; Tue, 14 Jul 1998 16:22:46 -0400 (EDT) Message-ID: <30d16d4c.35abbe18@aol.com> Date: Tue, 14 Jul 1998 16:22:46 EDT To: wimeran@pagesz.net, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6056) Re: IPv6 questions and telford Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-07-14 15:29:36 EDT, wimeran@pagesz.net writes: > Implying that the prevalence of a poorly designed networking scheme might > contribute to your future job security...? Do I smell an ulterior motive > here? It is a good point. We have made a lot of money thanks to SNMP, which was crippled by lack of understanding of network management on the part of the Gang of Four and by Rose's incomprehension of ASN.1. Perhaps, I should not criticize IPv6. Certainly, the gradualist approach of merely introducing address extension options while volunteer organizations work to specify, develop and test a two level hierarchical routing scheme involving L1 and L2 IP routers would mean far less work for TTI. Joachim Martillo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 19:55:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA04746 for ipng-dist; Tue, 14 Jul 1998 19:50:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA04739 for ; Tue, 14 Jul 1998 19:50:44 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA09335 for ; Tue, 14 Jul 1998 19:50:44 -0700 Received: from imo30.mx.aol.com (imo30.mx.aol.com [198.81.17.74]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA05752 for ; Tue, 14 Jul 1998 19:50:44 -0700 (PDT) Received: from Telford001@aol.com by imo30.mx.aol.com (IMOv14_b1.1) id 3GXFa26166; Tue, 14 Jul 1998 22:50:20 +2000 (EDT) Message-ID: Date: Tue, 14 Jul 1998 22:50:20 EDT To: wimeran@pagesz.net, ipng@sunroof.eng.sun.com Cc: Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 6057) Re: IPv6 questions and telford Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 98-07-14 15:29:36 EDT, wimeran@pagesz.net writes: > Ah. The truth comes out. Your dislike for IPv6 and preference for NAT is > personal. Perhaps one of those involved in the design of IPv6 offered you > some insult? I rarely know the engineers personally whose messes we debug. Usually, they have already departed in one way or another the firm that hires us. I took part in some IETF discussions of IPv6 several years ago. It was quite a surprise and a damper on my interest in taking part in the IPv6 discussion when I realized how seriously the opinion of total losers was taken in the IETF (or at least IPv6) context (although I will admit that I consider it important to take all *criticism* seriously -- it is dangerous to ignore criticism no matter who the source). Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 14 21:59:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA04915 for ipng-dist; Tue, 14 Jul 1998 21:54:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA04908 for ; Tue, 14 Jul 1998 21:54:27 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA25657 for ; Tue, 14 Jul 1998 21:54:27 -0700 Received: from mail2.noc.ntt.co.jp (mail2.noc.ntt.co.jp [202.239.94.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id VAA13614 for ; Tue, 14 Jul 1998 21:54:27 -0700 (PDT) Received: by mail2.noc.ntt.co.jp (8.8.8/NOC-MAIL2) id NAA09871; Wed, 15 Jul 1998 13:54:10 +0900 (JST) Received: from maili2.noc.ntt.co.jp by mail2.noc.ntt.co.jp via vms id smtpdAAAa09758; Wed Jul 15 13:53:57 1998 Received: from shinjuku.hqs.ntt.co.jp by maili2.noc.ntt.co.jp (8.8.8/NOC-MAILI2) id NAA28224; Wed, 15 Jul 1998 13:53:54 +0900 (JST) Received: from ops.nw.hqs.ntt.co.jp by shinjuku.hqs.ntt.co.jp (8.8.8/3.6W) with ESMTP id NAA19260; Wed, 15 Jul 1998 13:53:03 +0900 (JST) Received: (from togo@localhost) by ops.nw.hqs.ntt.co.jp (8.8.8/3.4W4-nw.CO-02) id NAA18678; Wed, 15 Jul 1998 13:48:43 +0900 (JST) Message-Id: <199807150448.NAA18678@ops.nw.hqs.ntt.co.jp> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: ;;;;;;;;;;@ns.cnri.reston.va.us;@Eng.Sun.COM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6058) I-D ACTION:draft-ietf-ipngwg-ipv6-udp-mib-02.txt Date: Fri, 10 Jul 1998 09:01:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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 Management Information Base for the User Datagram Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-udp-mib-02.txt Pages : 8 Date : 09-Jul-98 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of which IP versions underlie UDP, and only the UDP listener information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. 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-udp-mib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19980709141144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.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 Tue Jul 14 22:29:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA05372 for ipng-dist; Tue, 14 Jul 1998 22:25:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA05364 for ; Tue, 14 Jul 1998 22:25:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA28920 for ; Tue, 14 Jul 1998 22:25:27 -0700 Received: from mail1.noc.ntt.co.jp (mail1.noc.ntt.co.jp [202.239.94.62]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id WAA23911 for ; Tue, 14 Jul 1998 22:25:24 -0700 (PDT) Received: by mail1.noc.ntt.co.jp (8.8.8/NOC-MAIL1) id OAA15812 for ; Wed, 15 Jul 1998 14:25:19 +0900 (JST) Received: from maili1.noc.ntt.co.jp by mail1.noc.ntt.co.jp via vms id smtpdAAAa15702; Wed Jul 15 14:25:06 1998 Received: from shinjuku.hqs.ntt.co.jp by maili1.noc.ntt.co.jp (8.8.8/NOC-MAILI1) id OAA19983 for ; Wed, 15 Jul 1998 14:25:04 +0900 (JST) Received: from ops.nw.hqs.ntt.co.jp by shinjuku.hqs.ntt.co.jp (8.8.8/3.6W) with ESMTP id OAA24800 for ; Wed, 15 Jul 1998 14:24:13 +0900 (JST) Received: from togo.nw.hqs.ntt.co.jp (nw57171.nw.hqs.ntt.co.jp [10.8.57.171]) by ops.nw.hqs.ntt.co.jp (8.8.8/3.4W4-nw.CO-02) with SMTP id OAA19884 for ; Wed, 15 Jul 1998 14:19:43 +0900 (JST) Message-Id: <199807150519.OAA19884@ops.nw.hqs.ntt.co.jp> X-Sender: togo@ops X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-Jr2 (32) Date: Wed, 15 Jul 1998 14:26:35 +0900 To: ipng@sunroof.eng.sun.com From: Seiji TOGO Subject: (IPng 6059) Re: I-D ACTION:draft-ietf-ipngwg-ipv6-udp-mib-02.txt In-Reply-To: <199807150448.NAA18678@ops.nw.hqs.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm very sorry , and please ignore previous (IPng 6058) mail. I took mistake in handling mail software. I'm very sorry. At 09:01 98/07/10 -0400, you wrote: > 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 Management Information Base for > > the User Datagram Protocol > > Author(s) : M. Daniele > > Filename : draft-ietf-ipngwg-ipv6-udp-mib-02.txt > > Pages : 8 > > Date : 09-Jul-98 > > > > This document is one in the series of documents that define various MIB > > objects for IPv6. Specifically, this document is the MIB module which > > defines managed objects for implementations of the User Datagram > > Protocol (UDP) over IP Version 6 (IPv6). > > > > This document also recommends a specific policy with respect to the > > applicability of RFC 2013 for implementations of IPv6. Namely, that > > most of managed objects defined in RFC 2013 are independent of which IP > > versions underlie UDP, and only the UDP listener information is IP > > version-specific. > > > > This memo defines an experimental portion of the Management Information > > Base (MIB) for use with network management protocols in IPv6-based > > internets. > > > > 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-udp-mib-02.txt". > > A URL for the Internet-Draft is: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.txt > > > > Internet-Drafts directories are located at: > > > > Africa: ftp.is.co.za > > > > Europe: ftp.nordu.net > > ftp.nis.garr.it > > > > Pacific Rim: munnari.oz.au > > > > US East Coast: ftp.ietf.org > > > > US West Coast: ftp.isi.edu > > > > Internet-Drafts are also available by mail. > > > > Send a message to: mailserv@ietf.org. In the body type: > > "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Content-Type: text/plain > > Content-ID: <19980709141144.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-02.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 Wed Jul 15 04:53:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA05711 for ipng-dist; Wed, 15 Jul 1998 04:49:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA05704 for ; Wed, 15 Jul 1998 04:49:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA03286 for ; Wed, 15 Jul 1998 04:49:30 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA12631 for ; Wed, 15 Jul 1998 04:49:29 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA11443; Wed, 15 Jul 1998 07:48:54 -0400 (EDT) Message-Id: <199807151148.HAA11443@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6060) Document Action: IPv6 Multicast Address Assignments to Informational Date: Wed, 15 Jul 1998 07:48:54 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IPv6 Multicast Address Assignments' as an Informational RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 15 23:01:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA06647 for ipng-dist; Wed, 15 Jul 1998 22:55:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA06640 for ; Wed, 15 Jul 1998 22:55:33 -0700 (PDT) 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 WAA25034 for ; Wed, 15 Jul 1998 22:55:31 -0700 Received: from canaa.usma.ac.pa (canaa.usma.ac.pa [168.77.100.3]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA08351 for ; Wed, 15 Jul 1998 22:55:22 -0700 (PDT) Received: from formula ([209.198.206.82]) by canaa.usma.ac.pa (8.8.5/8.8.5) with SMTP id AAA07017; Thu, 16 Jul 1998 00:50:43 -0500 From: "Ramses Morales" To: Cc: , , , Subject: (IPng 6061) Re: IPv6 questions Date: Thu, 16 Jul 1998 00:49:41 -0500 Message-ID: <01bdb07d$86ab0f40$52cec6d1@formula> 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 -----Original Message----- De: Telford001@aol.com Para: perry@piermont.com CC: bound@zk3.dec.com ; thomas.eklund@era.ericsson.se ; ipng@sunroof.Eng.Sun.COM Fecha: Lunes 6 de Julio de 1998 10:23 AM Asunto: (IPng 5992) Re: IPv6 questions >I do not deal with as many banks and financial institutions as DEC, but >those with whom I have dealt do not even want the outside world to know >the internal distribution of IP addressess. A lot of information can >be gleaned from traffic analysis. The transient binding of >private addresses to global addresses is helpful to thwart >traffic analysis. > You can prevent that kind of traffic analysis using EPS header in tunnel mode. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 17 13:15:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA08063 for ipng-dist; Fri, 17 Jul 1998 13:06:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA08056 for ; Fri, 17 Jul 1998 13:06:11 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA08052 for ; Fri, 17 Jul 1998 13:06:09 -0700 Received: from imo15.mx.aol.com (imo15.mx.aol.com [198.81.17.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA13207 for ; Fri, 17 Jul 1998 13:06:10 -0700 (PDT) Received: from Telford001@aol.com by imo15.mx.aol.com (IMOv14_b1.1) id 3UWWa20769; Fri, 17 Jul 1998 16:05:43 -0400 (EDT) Message-ID: <717cff27.35afae98@aol.com> Date: Fri, 17 Jul 1998 16:05:43 EDT To: Telford001@aol.com, wimeran@pagesz.net Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6062) Re: IPv6 questions and telford Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/14/98 7:12:44 AM Eastern Daylight Time, Telford001 writes: > In a message dated 7/13/98 6:16:33 PM Eastern Daylight Time, > wimeran@pagesz.net writes: > > Nobody is going you take you seriously as long as you're on AOL. Sorry, > > it's just a law of physics. > > I was thinking about this moronic comment. I put my resume, > example design documents and example packet switching > software on line, which is a hell of a lot more than most of > the principles in the specification of IPv6 do. > Wimeran@pagesz.net makes an issue who should > be taken seriously. I have to ask where is his resume. Where > is his example software? Where are his design documents? > Why should he be taken seriously? I have been thinking about this exchange for the past few days. While I consider outrageous the suggestion that opinions should be devalued because of the e-mail provider a person happens to use, my reaction was excessive, and I would like to apologize to anyone that was offended by my comments in the thread "IPv6 questions and telford". Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 18 13:13:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA08654 for ipng-dist; Sat, 18 Jul 1998 13:10:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA08647 for ; Sat, 18 Jul 1998 13:10:15 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA28220 for ; Sat, 18 Jul 1998 13:10:07 -0700 Received: from imo15.mx.aol.com (imo15.mx.aol.com [198.81.17.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA12889 for ; Sat, 18 Jul 1998 13:10:04 -0700 (PDT) Received: from Telford001@aol.com by imo15.mx.aol.com (IMOv14_b1.1) id TIZPa20769; Sat, 18 Jul 1998 16:09:00 -0400 (EDT) Message-ID: Date: Sat, 18 Jul 1998 16:09:00 EDT To: ramses@computer.org, ipng@sunroof.eng.sun.com Cc: perry@piermont.com, bound@zk3.dec.com, thomas.eklund@era.ericsson.se Mime-Version: 1.0 Subject: (IPng 6063) Re: IPv6 questions Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 7/16/98 2:03:15 AM Eastern Daylight Time, ramses@computer.org writes: > >I do not deal with as many banks and financial institutions as DEC, but > >those with whom I have dealt do not even want the outside world to know > >the internal distribution of IP addressess. A lot of information can > >be gleaned from traffic analysis. The transient binding of > >private addresses to global addresses is helpful to thwart > >traffic analysis. > You can prevent that kind of traffic analysis using EPS header in tunnel > mode. For this particular problem I am not sure tunneling is helpful. Suppose the spy is just looking for inquiries from the finance department of State Street Bank to a specific type of site in the internet to glean information with regard to what sorts of deals are in progress. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 19 22:34:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA08991 for ipng-dist; Sun, 19 Jul 1998 22:30:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA08984 for ; Sun, 19 Jul 1998 22:29:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA25731 for ; Sun, 19 Jul 1998 22:29:39 -0700 Received: from canaa.usma.ac.pa (canaa.usma.ac.pa [168.77.100.3]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id WAA23277 for ; Sun, 19 Jul 1998 22:29:01 -0700 (PDT) Received: from formula ([209.198.205.232]) by canaa.usma.ac.pa (8.8.5/8.8.5) with SMTP id AAA08528; Mon, 20 Jul 1998 00:27:04 -0500 From: "Ramses Morales" To: , Cc: , , Subject: (IPng 6065) Re: IPv6 questions Date: Mon, 20 Jul 1998 00:21:03 -0500 Message-ID: <01bdb39e$305dcbe0$0100007f@localhost> 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 >For this particular problem I am not sure tunneling is >helpful. Suppose the spy is just looking for inquiries >from the finance department of State Street Bank >to a specific type of site in the internet to glean >information with regard to what sorts of deals are >in progress. To prevent spying from inside, you can use EPS from the source, and then use EPS again in the firewall to tunnel the info. So I don't think you would know what deals are in progress. You would just know that some info. is sent between two computers, maybe e-mail for a party, maybe "some" deal, but not "what" deal. With a NAT you can't prevent traffic analysis from inside. And you can know that some info is being sent between to sites. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 16:44:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA09535 for ipng-dist; Mon, 20 Jul 1998 16:38:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA09528 for ; Mon, 20 Jul 1998 16:38:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA14289 for ; Mon, 20 Jul 1998 16:38:17 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA13063 for ; Mon, 20 Jul 1998 10:04:41 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA23774 for ; Mon, 20 Jul 1998 13:04:20 -0400 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 ESMTP id NAA26324 for ; Mon, 20 Jul 1998 13:04:16 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id NAA17554 for ; Mon, 20 Jul 1998 13:04:14 -0400 (EDT) Message-Id: <199807201704.NAA17554@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 6067) FWD: Last Call: FTP Extensions for IPv6 to Proposed Standard Date: Mon, 20 Jul 1998 13:04:13 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Any comments from the ipng community? ------- Forwarded Message From: The IESG To: IETF-Announce: ; Cc: ftp-wg@hops.ag.utk.edu Date: Sat, 18 Jul 1998 10:09:41 -0400 SUBJECT: Last Call: FTP Extensions for IPv6 to Proposed Standard Reply-to: iesg@ietf.org The IESG has received a request from the Extensions to FTP Working Group to consider FTP Extensions for IPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 31, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext-ftp-over-ipv6-02.txt ------- 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 Jul 20 18:21:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA09752 for ipng-dist; Mon, 20 Jul 1998 18:13:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id SAA09745 for ; Mon, 20 Jul 1998 18:13:24 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id SAA21007 for ; Mon, 20 Jul 1998 18:13:24 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id SAA16541 for ipng@sunroof.eng.sun.com; Mon, 20 Jul 1998 18:12:34 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id SAA09722 for ; Mon, 20 Jul 1998 18:02:46 -0700 (PDT) Received: from antley.eng.sun.com (antley [129.146.86.225]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA19790; Mon, 20 Jul 1998 18:02:46 -0700 (PDT) Received: by antley.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10744; Mon, 20 Jul 1998 17:58:31 -0700 Date: Mon, 20 Jul 1998 17:58:31 -0700 From: Carl.Williams@eng.sun.com (Carl Williams) Message-Id: <199807210058.RAA10744@antley.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6069) RE: Last Call: FTP Extensions for IPv6 to Proposed Standard Cc: carlw@jurassic.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can we get a poll of who has implemented this internet draft ("FTP Extensions for IPv6"). I know that most v6 prototypes/releases have implemented "FTP Operations Over Big Address Records (FOOBAR)" -- which is listed in RFC1639. Carl ----- Begin Included Message ----- From owner-ipng@sunroof.eng.sun.com Mon Jul 20 16:44:48 1998 X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 6067) FWD: Last Call: FTP Extensions for IPv6 to Proposed Standard Date: Mon, 20 Jul 1998 13:04:13 -0400 From: Thomas Narten Any comments from the ipng community? ------- Forwarded Message From: The IESG To: IETF-Announce: ; Cc: ftp-wg@hops.ag.utk.edu Date: Sat, 18 Jul 1998 10:09:41 -0400 SUBJECT: Last Call: FTP Extensions for IPv6 to Proposed Standard Reply-to: iesg@ietf.org The IESG has received a request from the Extensions to FTP Working Group to consider FTP Extensions for IPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 31, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext-ftp-over-ipv6-02.txt ------- 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 -------------------------------------------------------------------- ----- End Included Message ----- ----- 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 Tue Jul 21 03:36:02 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA09985 for ipng-dist; Tue, 21 Jul 1998 03:32:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA09978 for ; Tue, 21 Jul 1998 03:32:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA10328 for ; Tue, 21 Jul 1998 03:32:17 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id DAA12158 for ; Tue, 21 Jul 1998 03:32:17 -0700 (PDT) Received: from inner.net (stan.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.9.0/8.8.5) with ESMTP id KAA02828; Tue, 21 Jul 1998 10:32:10 GMT Message-Id: <199807211032.KAA02828@inner.net> To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: (IPng 6071) Re: FWD: Last Call: FTP Extensions for IPv6 to Proposed Standard In-reply-to: Your message of "Mon, 20 Jul 1998 13:04:13 EDT." <199807201704.NAA17554@cichlid.raleigh.ibm.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 21 Jul 1998 06:31:43 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199807201704.NAA17554@cichlid.raleigh.ibm.com>, you write: >Any comments from the ipng community? My implementation of this spec is being used by lots of users on systems using the Linux and NRL IPv6 implementations, and is running (actually, now that the code has been available for many months, it's required to play) on my IPv6 anonymous FTP server. It's easier to implement in a protocol-independent manner than LPRT/LPSV, and it works at least as well. It should be a LOT more firewall/NAT friendly. Code can be found at: ftp.ipv6.inner.net:/pub/ipv6/inet6-apps-0.34.tar.gz (via IPv6) ftp.inner.net:/pub/ipv6/inet6-apps-0.34.tar.gz (via IPv4) And will be included in the upcoming NRL release. Being a co-author, I am a highly biased observer. Please take my comments with the appropriate grain of salt. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 21 09:27:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA10196 for ipng-dist; Tue, 21 Jul 1998 09:19:17 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA10189 for ; Tue, 21 Jul 1998 09:19:12 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA02995 for ; Tue, 21 Jul 1998 09:19:12 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA17718 for ipng@sunroof.eng.sun.com; Tue, 21 Jul 1998 09:18:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id AAA09936 for ; Tue, 21 Jul 1998 00:12:55 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA25755 for ; Tue, 21 Jul 1998 00:12:53 -0700 Received: from cgns11.uscg.mil (cgns11.uscg.mil [152.121.49.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id AAA22422 for ; Tue, 21 Jul 1998 00:12:55 -0700 (PDT) Received: from ESUBOSTEX.esuboston.USCG.MIL ([10.1.16.6]) by cgns11.uscg.mil (8.8.5/8.8.5) with ESMTP id DAA17138 for ; Tue, 21 Jul 1998 03:12:53 -0400 (EDT) Received: by ESUBOSTEX with Internet Mail Service (5.0.1458.49) id <3828NPGV>; Tue, 21 Jul 1998 03:16:34 -0400 Message-ID: From: "Collier, Tirus PO" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 6072) QUESTION Date: Tue, 21 Jul 1998 03:16:30 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Request to know: Not using checksums can be dangerous. Explain how a single corrupted ARP packet broadcast by machine P can make it impossible to reach another Machine Q. THANKS, TCOLLIER@GRUBOSTON.USCG.MIL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 09:39:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA11082 for ipng-dist; Wed, 22 Jul 1998 09:29:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA11075 for ; Wed, 22 Jul 1998 09:29:24 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA05968 for ; Wed, 22 Jul 1998 09:29:12 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA04871 for ; Wed, 22 Jul 1998 09:29:10 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id MAA24178; Wed, 22 Jul 1998 12:29:07 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA06074; Wed, 22 Jul 1998 12:29:06 -0400 Message-Id: <199807221629.AA06074@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6073) Re: FWD: Last Call: FTP Extensions for IPv6 to Proposed Standard In-Reply-To: Your message of "Mon, 20 Jul 1998 13:04:13 EDT." <199807201704.NAA17554@cichlid.raleigh.ibm.com> Date: Wed, 22 Jul 1998 12:29:06 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >Any comments from the ipng community? I have followed this work from Mark, Shawn, and Craig since inception and the first draft. I think this is a much better approach for both IPv4 and IPv6. I have implemented FOOBAR and think this spec extends the evolutionary nature of FOOBAR to provide a much more elegant way to enhance the FTP implementation, and it also provides extensibility for the future quite nicely. So I support this change to IPv6 and IPv4 for that matter. I will respond to Carl's note on the issue of getting our implementations up and running with the new change. We need to pick a future date for conversion to keep interoperability in tact for IPv6. p.s. I would like to ask all the BSD folks if when making this change could we please move from YACC to C inline code for FTP and modernize the FTP public domain implementation. I have not looked at the latest pub FTP stuff for about 18 months but I would really like to see YACC subroutine and token tables go away for parsing ftp command strings. ??? /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 Jul 22 09:43:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA11100 for ipng-dist; Wed, 22 Jul 1998 09:37:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA11093 for ; Wed, 22 Jul 1998 09:36:59 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA08402; Wed, 22 Jul 1998 09:36:31 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA09220; Wed, 22 Jul 1998 09:36:27 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id MAA09403; Wed, 22 Jul 1998 12:36:27 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07002; Wed, 22 Jul 1998 12:36:26 -0400 Message-Id: <199807221636.AA07002@wasted.zk3.dec.com> To: Carl.Williams@Eng (Carl Williams) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6074) Re: Last Call: FTP Extensions for IPv6 to Proposed Standard In-Reply-To: Your message of "Mon, 20 Jul 1998 17:58:31 PDT." <199807210058.RAA10744@antley.eng.sun.com> Date: Wed, 22 Jul 1998 12:36:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Carl, >Can we get a poll of who has implemented this internet draft >("FTP Extensions for IPv6"). I know that most v6 prototypes/releases >have implemented "FTP Operations Over Big Address Records (FOOBAR)" >-- which is listed in RFC1639. Compaq IPv6 has not at this point but will. It is better than foobar. [See previous note to Thomas Narten]. But I can't see getting this done for the next test at UNH (week of 8/17). I suggest we pick a date working with Bob Fink when we all can agree to supporting this on the 6bone too and for the next UNH tests? We also need to make a decision on backwards compatibility and I would prefer we drop support for FOOBAR at some date too? Why clutter up ftp code base? Also do we do this for IPv4 too in the IPv6 community at large? I think we should? /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 Jul 22 10:12:58 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA11222 for ipng-dist; Wed, 22 Jul 1998 10:01:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA11215 for ; Wed, 22 Jul 1998 10:00:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA17250 for ; Wed, 22 Jul 1998 10:00:35 -0700 Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA25219 for ; Wed, 22 Jul 1998 10:00:33 -0700 (PDT) Received: (from uucp@localhost) by tsbgw.wide.toshiba.co.jp (8.8.8/8.8.8/2.10) with UUCP id CAA00718 for ipng@sunroof.eng.sun.com; Thu, 23 Jul 1998 02:00:11 +0900 (JST) Received: from localhost (kwa0112.mobile.toshiba.co.jp [133.120.199.28]) by splash.isl.rdc.toshiba.co.jp (8.8.8/8.8.8/3.5) with ESMTP id BAA01305 for ; Thu, 23 Jul 1998 01:58:55 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 6075) IPv6 multicast routing X-Mailer: Mew version 1.93b38 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980723015649M.jinmei@isl.rdc.toshiba.co.jp> Date: Thu, 23 Jul 1998 01:56:49 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980522 Lines: 14 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'm interested in IPv6 multicast routing, but I couldn't find any internet drafts nor RFCs about it. Is there any draft about IPv6 multicast routing? If so, please let me know how to get it. Thanks in advance, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 22 17:23:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA11865 for ipng-dist; Wed, 22 Jul 1998 17:14:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA11858 for ; Wed, 22 Jul 1998 17:14:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA07898 for ; Wed, 22 Jul 1998 17:14:06 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA05647 for ; Wed, 22 Jul 1998 17:14:06 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id CAA17752; Thu, 23 Jul 1998 02:14:02 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id CAA26015; Thu, 23 Jul 1998 02:14:01 +0200 (MET DST) Message-Id: <199807230014.CAA26015@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Cc: ftp-wg@hops.ag.utk.edu Subject: (IPng 6076) FTP Extensions for IPv6 Date: Thu, 23 Jul 1998 02:14:01 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have no strong objection about draft-ietf-ftpext-ftp-over-ipv6-02.txt. We'd see a lot of proposals for IPv6 extensions or "short" port commands then if it is the last one (it seems it'll be this one :-) it is a good thing... I have noted two details: - the delimiter '|' should be made mandatory (yes Jim, I use and like yacc :-); - the draft doesn't say whether the "EPRT |||6446|" format is legal (I believe it should be as specified in the 00 I-D) ? Francis.Dupont@inria.fr PS: ftp.ipv6.inner.net has 3ffe::1 (??) IPv6 address. It should be useful to have a test host somewhere... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 07:57:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA12281 for ipng-dist; Thu, 23 Jul 1998 07:51:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA12274 for ; Thu, 23 Jul 1998 07:51:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA08473 for ; Thu, 23 Jul 1998 07:51:19 -0700 Received: from hotmail.com (f101.hotmail.com [207.82.250.220]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA03731 for ; Thu, 23 Jul 1998 07:51:18 -0700 (PDT) Received: (qmail 29614 invoked by uid 0); 23 Jul 1998 14:51:17 -0000 Message-ID: <19980723145117.29613.qmail@hotmail.com> Received: from 202.188.24.205 by www.hotmail.com with HTTP; Thu, 23 Jul 1998 07:51:16 PDT X-Originating-IP: [202.188.24.205] From: "flowcontrol PDF" To: ipng@sunroof.eng.sun.com Subject: (IPng 6077) IPv6 over ATM Content-Type: text/plain Date: Thu, 23 Jul 1998 07:51:16 PDT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi everyone, I'm interested in IPv6 QoS and ATM QoS issue, does anyone out there knew where can I get some information relating on how to combine both QoS so that it satisfy both? Thanks Shuhaimi ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.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 Jul 23 11:29:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA12552 for ipng-dist; Thu, 23 Jul 1998 11:20:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA12545 for ; Thu, 23 Jul 1998 11:20:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA12335 for ; Thu, 23 Jul 1998 11:20:00 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA11617 for ; Thu, 23 Jul 1998 11:19:54 -0700 (PDT) Received: from inner.net (stan.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.9.0/8.8.5) with ESMTP id SAA06459; Thu, 23 Jul 1998 18:19:40 GMT Message-Id: <199807231819.SAA06459@inner.net> To: Francis Dupont cc: ipng@sunroof.eng.sun.com, ftp-wg@hops.ag.utk.edu Subject: (IPng 6078) Re: FTP Extensions for IPv6 In-reply-to: Your message of "Thu, 23 Jul 1998 02:14:01 +0200." <199807230014.CAA26015@givry.inria.fr> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 23 Jul 1998 14:18:58 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199807230014.CAA26015@givry.inria.fr>, you write: >I have noted two details: > - the delimiter '|' should be made mandatory By not choosing a mandatory delimiter and making it easy to determine the delimiter in use, there are no protocol-imposed restrictions on what sort of address syntaxes can be represented. I hope that anybody who is building an IPv6 implementation considers the additional string operations needed to parse this to be trivially easy. The added complexity here is so low that all the authors think it's worth it to not have the potential of being stuck in a corner if some new address syntax comes around. > - the draft doesn't say whether the "EPRT |||6446|" format is legal > (I believe it should be as specified in the 00 I-D) ? It's not legal. The reason it's not legal is because what that form would say syntactically is that the destination address of the active open is the same as the destination addresss as the control connection. However, the spec says that when the data connection is going to the same host as the control connection, you MUST use a passive open. The EPRT form is ONLY used for three- way transfers, in which case there MUST be a destination address present and it MUST not be the same as the address of the control connection. The reasons for this were discussed in detail in the FTP extensions WG. >PS: ftp.ipv6.inner.net has 3ffe::1 (??) IPv6 address. >It should be useful to have a test host somewhere... What problems are you experiencing? (Francis, please mail me with a traceroute if you can't reach it and I'll see if I can figure out where the routing problem is) My server has run the EPRT/EPSV code since about February 1998, and I'll even stick my neck out and say it did so without any problems. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 24 04:21:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA13527 for ipng-dist; Fri, 24 Jul 1998 04:16:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA13520 for ; Fri, 24 Jul 1998 04:16:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA15639 for ; Fri, 24 Jul 1998 04:16:43 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA13201 for ; Fri, 24 Jul 1998 04:16:40 -0700 (PDT) Received: from nestvx.kar.dec.com (nestvx.kar.dec.com [16.185.112.1]) by mail13.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id HAA07831 for ; Fri, 24 Jul 1998 07:16:31 -0400 (EDT) Received: from sand2.kar.dec.com by nestvx.kar.dec.com; (5.65/1.1.8.2/10Jul96-9.1MPM) id AA22456; Fri, 24 Jul 1998 13:16:22 +0200 Received: from localhost by sand2.kar.dec.com (5.65v4.0/1.1.19.2/03Apr98-0142PM) id AA14720; Fri, 24 Jul 1998 13:16:17 +0200 Message-Id: <199807241116.AA14720@sand2.kar.dec.com> X-Mailer: exmh version 2.0.2 2/24/98 To: ipng@sunroof.eng.sun.com Cc: jork@kar.dec.com Subject: (IPng 6079) Re: IPv6 over ATM In-Reply-To: Your message of "Thu, 23 Jul 1998 07:51:16 PDT." <19980723145117.29613.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Jul 1998 13:16:17 +0200 From: "Markus Jork" X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm interested in IPv6 QoS and ATM QoS issue, does anyone out there > knew where can I get some information relating on how to combine both > QoS so that it satisfy both? The ISSLL working group produced a couple of drafts mapping IP QoS (in the Integrated Services sense) to ATM: "A Framework for Integrated Services and RSVP over ATM" "Interoperation of Controlled-Load and Guaranteed-Service with ATM" "RSVP over ATM Implementation Requirements" "RSVP over ATM Implementation Guidelines" Combine that with the IPv6 over ATM drafts: "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" "IPv6 over ATM Networks" Markus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 24 15:40:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA14287 for ipng-dist; Fri, 24 Jul 1998 15:29:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA14280 for ; Fri, 24 Jul 1998 15:29:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA21433 for ; Fri, 24 Jul 1998 15:29:08 -0700 Received: from bag-1.mail.digex.net (bag-1.mail.digex.net [204.91.99.100]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA18398 for ; Fri, 24 Jul 1998 15:29:06 -0700 (PDT) Received: from krakow.brighttiger.com (brighttiger.com [207.86.119.34]) by bag-1.mail.digex.net (8.8.8/8.8.8) with SMTP id SAA11074 for ; Fri, 24 Jul 1998 18:29:05 -0400 (EDT) Received: from mitera (192.168.0.160) by krakow.brighttiger.com (EMWAC SMTPRS 0.81) with SMTP id ; Fri, 24 Jul 1998 18:27:02 -0400 Reply-To: From: "Peter A. Schulter" To: Subject: (IPng 6080) FW: (ION) ion working group last call for IPv6-related drafts Date: Fri, 24 Jul 1998 18:25:06 -0400 Message-ID: <000201bdb751$ea55afc0$a000a8c0@mitera.brighttiger.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following IPv6 over NBMA network drafts have just gone to WG last call in the ION WG. Please take any discussion/comments about these drafts to the ION mailing list (ion@sunroof.Eng.Sun.COM). Thanks, --- pete > -----Original Message----- > From: owner-ion@sunroof.Eng.Sun.COM > [mailto:owner-ion@sunroof.Eng.Sun.COM] On Behalf Of Andrew G. Malis > Sent: Friday, July 24, 1998 5:04 PM > To: ion@sunroof.Eng.Sun.COM > Cc: Andrew G. Malis; George Swallow; Thomas Narten; Jeffrey Burgan; > Peter A. Schulter; Grenville Armitage; Markus Jork; Alex Conta; Martin > Mueller > Subject: (ION) ion working group last call for IPv6-related drafts > > > This begins the working group last call for the following four drafts: > > draft-ietf-ion-ipv6-01.txt > draft-ietf-ion-ipv6-atm-02.txt > draft-ietf-ion-ipv6-fr-00.txt > draft-ietf-ion-ipv6-ind-00.txt > > The only known outstanding issue at this point is the official > assignment of the ND options number for the shortcut limit option > (draft-ietf-ion-ipv6-01 unofficially uses 6). The actual assignment > will be made following WG last call. > > The last call will conclude on Friday, August 7. As usual, > comments to > the list. > > 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 > > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with > X-Info: 'unsubscribe ion' in the body of the 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 Sun Jul 26 16:42:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA14921 for ipng-dist; Sun, 26 Jul 1998 16:38:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA14914 for ; Sun, 26 Jul 1998 16:38:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA07609 for ; Sun, 26 Jul 1998 16:38:20 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id QAA11266 for ; Sun, 26 Jul 1998 16:38:21 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA08782; Sun, 26 Jul 98 16:37:15 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA18402; Sun, 26 Jul 1998 16:40:17 -0700 Date: Sun, 26 Jul 1998 16:40:17 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199807262340.QAA18402@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6081) Re: FWD: Last Call: FTP Extensions for IPv6 to Proposed Standard X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It seems to me that this proposal is a significant improvement over FOOBAR. In particular, the ability to discover the preferred network protocol of the server and possibly retry the operation is a feature which is very much needed. The additional requirement that the passive mode be the default mode is also a step in the right direction since it will make interacting with firewalls and NATs less problematic. All around good stuff. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 27 07:56:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA15143 for ipng-dist; Mon, 27 Jul 1998 07:52:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA15136 for ; Mon, 27 Jul 1998 07:52:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA17172 for ; Mon, 27 Jul 1998 07:52:05 -0700 Received: from cheviot.ncl.ac.uk (cheviot.ncl.ac.uk [128.240.233.51]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA01753 for ; Mon, 27 Jul 1998 07:52:05 -0700 (PDT) Received: from ncl.ac.uk by cheviot.ncl.ac.uk id (8.7.6/ for ncl.ac.uk) with ESMTP; Mon, 27 Jul 1998 15:52:03 +0100 (BST) Message-ID: <35BC9411.3D155F43@ncl.ac.uk> Date: Mon, 27 Jul 1998 15:52:02 +0100 From: "K.J.Hollingworth" Organization: Centre for Software Reliability X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 4.1.3 sun4c) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 6082) Quick question...I hope :) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi folks, just a quick question from someone just learning a little about IPng. What are the main advantages of using IPng (once everyone is using it :) ) for web technologies ? thanks. E-Mail : K.J.Hollingworth@ncl.ac.uk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 11:58:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA15484 for ipng-dist; Mon, 27 Jul 1998 11:51:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA15474 for ; Mon, 27 Jul 1998 11:51:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA06046 for ; Mon, 27 Jul 1998 11:51:24 -0700 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA01277 for ; Mon, 27 Jul 1998 11:51:26 -0700 (PDT) Message-ID: <19980727183221.9906.rocketmail@send1e.yahoomail.com> Received: from [138.111.39.131] by send1e; Mon, 27 Jul 1998 11:32:21 PDT Date: Mon, 27 Jul 1998 11:32:21 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6084) Re: Quick question...I hope :) To: ipng@sunroof.eng.sun.com, "K.J.Hollingworth" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The advantages are: 1. 128 bit address space. 2. Flow label field allows to have different flows. ( Ex: In QoS flows ) 3. Enhanced security and authnetication. 4. The NEXT HEADER field helps u in avoiding the unnecassary processing at the intermediate nodes. 6. For jumbo data grams.(In case IPV4 it allows u only 64K of Packet length ). 7. well structured addressing architecture. 8. Stateless address config. Hope I am correct. Let me if there any mistakes. Thanks -iprsvp. 7. ---"K.J.Hollingworth" wrote: > > Hi folks, > > just a quick question from someone just learning a little about IPng. > > What are the main advantages of using IPng (once everyone is using it > :) ) for web technologies ? > > thanks. > E-Mail : K.J.Hollingworth@ncl.ac.uk > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.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 Jul 29 07:57:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA17108 for ipng-dist; Wed, 29 Jul 1998 07:53:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA17101 for ; Wed, 29 Jul 1998 07:52:55 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA00643 for ; Wed, 29 Jul 1998 07:52:53 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA25195 for ; Wed, 29 Jul 1998 07:52:53 -0700 (PDT) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA07234; Wed, 29 Jul 1998 07:52:50 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Jul 1998 07:53:17 -0700 To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU From: Steve Deering Subject: (IPng 6088) jumbogram implementations Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Has there been more than one implementation of the IPv6 Jumbo Payload option, and if so, have different implementations been shown to interoperate? This question arises as part of the IESG's deliberations about advancing the IPv6 spec to Draft Standard. If there haven't been multiple, interoperable implementations of jumbograms, we'll probably have to move that feature into a separate spec, e.g., an Experimental status RFC, in order to allow the base IPv6 to advance. Please let me know as soon as possible if there has been successful jumbogram interoperability. 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 Jul 29 11:54:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA17355 for ipng-dist; Wed, 29 Jul 1998 11:46:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA17347 for ; Wed, 29 Jul 1998 11:46:45 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA13164 for ; Wed, 29 Jul 1998 11:46:42 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA23888 for ; Wed, 29 Jul 1998 11:46:43 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA22386 for ; Wed, 29 Jul 1998 14:46:40 -0400 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA20816 for ; Wed, 29 Jul 1998 14:46:41 -0400 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16602; Wed, 29 Jul 1998 14:46:35 -0400 Message-Id: <35BF6E0B.58A265AD@raleigh.ibm.com> Date: Wed, 29 Jul 1998 14:46:35 -0400 From: Brian Haberman Organization: Remote Access Products X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 6089) Re: IPv6 multicast routing References: <19980723015649M.jinmei@isl.rdc.toshiba.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / $B?@L@C#:H(B wrote: > > Is there any draft about IPv6 multicast routing? If so, please let me > know how to get it. There is not one yet available. There should be one up before the Chicago meeting. A draft describing PIM for IPv6 will be presented in the PIM working group during the Chicago meeting. Brian Haberman IBM Research Triangle Park haberman@raleigh.ibm.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 29 12:20:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA17400 for ipng-dist; Wed, 29 Jul 1998 12:08:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA17393 for ; Wed, 29 Jul 1998 12:08:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA20572 for ; Wed, 29 Jul 1998 12:08:08 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA07275 for ; Wed, 29 Jul 1998 12:08:08 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA19752; Wed, 29 Jul 1998 21:08:06 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA01069; Wed, 29 Jul 1998 21:08:06 +0200 (MET DST) Message-Id: <199807291908.VAA01069@givry.inria.fr> From: Francis Dupont To: Brian Haberman cc: ipng@sunroof.eng.sun.com Subject: (IPng 6090) Re: IPv6 multicast routing In-reply-to: Your message of Wed, 29 Jul 1998 14:46:35 EDT. <35BF6E0B.58A265AD@raleigh.ibm.com> Date: Wed, 29 Jul 1998 21:08:05 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Is there any draft about IPv6 multicast routing? If so, please let me > know how to get it. There is not one yet available. There should be one up before the Chicago meeting. A draft describing PIM for IPv6 will be presented in the PIM working group during the Chicago meeting. => it is not exactly the case. There are some definitions for IPv6 in current PIM documents and even one implementation but I agree more dedicated work is needed (ie it is time to play with IPv6 multicast)! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 29 19:17:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA17909 for ipng-dist; Wed, 29 Jul 1998 19:03:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA17902 for ; Wed, 29 Jul 1998 19:03:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA05318 for ; Wed, 29 Jul 1998 19:03:08 -0700 Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA21992 for ; Wed, 29 Jul 1998 19:02:37 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:220:d8ff:fe00:6f2d]) by shuttle.wide.toshiba.co.jp (8.9.0+IPv6/8.9.0) with ESMTP id LAA08010; Thu, 30 Jul 1998 11:02:47 +0900 (JST) To: deering@cisco.com Cc: core@kame.net, ipng@sunroof.eng.sun.com Subject: (IPng 6092) Re: jumbogram implementations In-Reply-To: Your message of "Thu, 30 Jul 1998 00:23:34 +0900" <29812.901725814@coconut.itojun.org> References: <29812.901725814@coconut.itojun.org> X-Mailer: Mew version 1.93b38 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980730105920G.jinmei@isl.rdc.toshiba.co.jp> Date: Thu, 30 Jul 1998 10:59:20 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980522 Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 30 Jul 1998 00:23:34 +0900, >>>>> Jun-ichiro itojun Itoh said: >>> Has there been more than one implementation of the IPv6 Jumbo Payload >>> option, and if so, have different implementations been shown to >>> interoperate? >> The current KAME package doesn't support jumbogram. Since no member is >> interested in it, I bet that we won't support it. > wait a minute! we have some code fragment for jumbogram in KAME. > I believe it has been tested on loopback interface only, but > it is there... jinmei-san should have more answer to send you. Itojun is right. I implemented the jumbo payload option in KAME kernel and modified ping code to test the option. It worked (and still works) well on the loopback interface, but we haven't checked interoperability with other implementation yet. It is simple because we have no physical interface whose MTU is more than 65535. Our implementation itself does not depend on the loopback interface. Regards, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 31 07:58:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA18930 for ipng-dist; Fri, 31 Jul 1998 07:54:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA18923 for ; Fri, 31 Jul 1998 07:53:58 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29393 for ; Fri, 31 Jul 1998 07:53:57 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA13899 for ; Fri, 31 Jul 1998 07:53:56 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id KAA20564; Fri, 31 Jul 1998 10:53:45 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30734; Fri, 31 Jul 1998 10:53:45 -0400 Message-Id: <199807311453.AA30734@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU Subject: (IPng 6093) Re: jumbogram implementations In-Reply-To: Your message of "Wed, 29 Jul 1998 07:53:17 PDT." Date: Fri, 31 Jul 1998 10:53:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, Have tested it as far as an option to be looked at. But ether and fddi don't support > 65K so no real interoperability has been done. I believe UNH has tested for the presence of that option just to check header procesing but we should check that. I guess it is an issue of whether we can put into specs future extensions. This is a tough one because I recall at the Seattle meeting (I think Aug 1995) this was something all wanted in the base spec. I would also check with the Research folks like Craig Partridge? /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 Jul 31 11:36:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA19136 for ipng-dist; Fri, 31 Jul 1998 11:28:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA19129 for ; Fri, 31 Jul 1998 11:28:13 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA00726 for ; Fri, 31 Jul 1998 11:28:05 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA20354 for ; Fri, 31 Jul 1998 11:27:58 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA09051; Fri, 31 Jul 98 11:26:56 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA21820; Fri, 31 Jul 1998 11:30:08 -0700 Date: Fri, 31 Jul 1998 11:30:08 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199807311830.LAA21820@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6094) Re: jumbogram implementations X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > Has there been more than one implementation of the IPv6 Jumbo Payload > option, and if so, have different implementations been shown to > interoperate? > I have played with an implementation but I have never actually completed one and gotten it running over a link which really supports an MTU greater than 65575. My tests to this point have been over spoofed up Ethernet and FDDI interfaces that do link-layer fragmentation and reassembly. > This question arises as part of the IESG's deliberations about advancing > the IPv6 spec to Draft Standard. If there haven't been multiple, > interoperable implementations of jumbograms, we'll probably have to move > that feature into a separate spec, e.g., an Experimental status RFC, > in order to allow the base IPv6 to advance. Please let me know as soon > as possible if there has been successful jumbogram interoperability. > I actually think it would be a good idea to seperate the jumbogram option description from the base document and place it in the document which describes all the other details of jumbogram operation (if that document still exists). That would provide implementors a self-contained description for the option and its mechanics. In addition while playing with my implementation it dawned on me that there were some areas in which I thought the mechanics of the option could be improved from a performance point of view. Unfortunately, the details have long since been forgotten but it does reinforce the point that this feature may not have had the implementation scrutiny that it deserves. Just my << $.02 worth of opinion. 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 --------------------------------------------------------------------