From owner-ipng Mon Jul 1 01:31:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04895; Mon, 1 Jul 96 01:31:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04889; Mon, 1 Jul 96 01:30:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA15517; Mon, 1 Jul 1996 01:26:26 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA26713; Mon, 1 Jul 1996 01:26:25 -0700 Received: from matisse (matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with SMTP id KAA09100 ; Mon, 1 Jul 1996 10:24:56 +0200 Date: Mon, 1 Jul 1996 10:24:56 +0200 Message-Id: <199607010824.KAA09100@ibp.ibp.fr> X-Sender: eh@hera.ibp.fr X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Matt Crawford , ipng@sunroof.eng.sun.com From: "Eric HORLAIT (MASI-CNRS)" Subject: (IPng 1900) Re: API issues regarding flow IDs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 18:00 28/06/1996 -0500, Matt Crawford wrote: > >A flow label can be set only by a bind() call, and then any non-zero >flow label (alternatively, a special non-zero constant) indicates >that the kernel should choose a non-zero value. If the application >wants to know what value was chosen, it should be obtained with >getsockname(). > > This choice eliminate the possibility for an application to change the flow-id during a connection, without re-establishing another connection. I think this is not suitable in case a flow label is associated by any means (e;g. a signalling protocol) to a quality of service of the underlying network. If this scenario is accepted (changing QoS of an application during a connection), we need some mechanisms for explicit flow Id setting through the socket interface. ---------------------- Professeur Eric HORLAIT ------------------------ Universite Pierre et Marie Curie Tel: 33-1-44-27-73-83 Institut Blaise Pascal - Labo MASI Fax: 33-1-44-27-62-86 4, place Jussieu e-mail: Eric.Horlait@masi.ibp.fr 75252 PARIS Cedex 05 Telex: UPMCSIX 200-145 F http://www-masi-net.ibp.fr/~eh ----------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 1 03:44:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04950; Mon, 1 Jul 96 03:44:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04944; Mon, 1 Jul 96 03:43:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA20906; Mon, 1 Jul 1996 03:39:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA11920; Mon, 1 Jul 1996 03:39:10 -0700 Received: from mdp.tbit.dk (mdp.tbit.dk [194.182.135.65]) by ayla.tbit.dk (8.6.11/8.6.11) with SMTP id MAA28824; Mon, 1 Jul 1996 12:25:34 +0200 Message-Id: <31D82818.45B2@tbit.dk> Date: Mon, 01 Jul 1996 12:33:44 -0700 From: Martin Peck Organization: Telebit Communications X-Mailer: Mozilla 2.01 (Win16; I) Mime-Version: 1.0 Followup-To: ipng@sunroof.Eng.Sun.COM,6bone@ISI.EDU,smn To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Subject: (IPng 1901) Re: New IPv6 Release References: Content-Type: multipart/mixed; boundary="------------7E19389D242E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------7E19389D242E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, Thanks for including us in your IPng page. Telebit Communications A/S now has a major new IPv6 router release which is detailed in the attachment (htm format, viewable from Netscape Mail). Thanks in advance for updating our contribution, Best Regards, Martin Peck --------------7E19389D242E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="HINDEN2.HTM" Bob,

Telebit Communications A/S has released a major new IPv6 router implementation which has been demonstrated at the Joint European Networking Conference in Budapest.

This includes IDRPv6 for the exchange of routing information between autonomous domains, IGP to dynamically exchange routing information within domains, SNMP support for IPv6, facilities to define static IPv6 routing information, neighbor discovery, automatic and manually configured tunneling, accounting facilities and packet filtering for both IPv4 and IPv6, a full ICMPv6 implementation, IPv6 multicast generation and termination, and IPv6 ping and traceroutes. We plan to make OSPFv6, RIPv6, neighbor discovery over ATM, and RSVP (for IPv4 and IPv6) available by the end of '96, and support of IPv6 multicasting in '97.

TELEBIT COMMUNICATIONS A/S

Tel: +45 86 28 81 76

fx: +45 86 28 81 86

em: info@tbit.dk

http://www.tbit.dk/

--------------7E19389D242E-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 2 08:22:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05790; Tue, 2 Jul 96 08:22:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05775; Tue, 2 Jul 96 08:22:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17926; Tue, 2 Jul 1996 08:18:29 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA24516; Tue, 2 Jul 1996 08:18:29 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA01465; Tue, 2 Jul 96 11:14:00 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9607021514.AA01465@iol.unh.edu> Subject: (IPng 1902) transition policy To: ipng@sunroof.eng.sun.com (ipng) Date: Tue, 2 Jul 1996 11:13:59 -0400 (EDT) Cc: ngtrans@sunroof.eng.sun.com X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi everyone, Here are some of my thoughts and ideas on the transition policy triggered by the last UNH bakeoff and the following IETF (including Ran Atkinson's talk on routing of v4-compatible v6 addresses and Steve's idea of limiting the use of v4-compatible addresses to expediate the transition.) I feel the issue of routing v4-compatible addresses should be handled by ngtrans group. I feel that IPv4-compatible addresses should only be used by v6/v4 hosts which are isolated, i.e. they don't hav any v6 router on the link. Even if a subnet has a set of v6/v4 hosts but no v6/v4 router, they will have to configure tunnels to talk to pure ipv6 hosts (which do not have a IPv4 address) that lie across a cloud of IPv4 routing infrastructure, becuase they themselves will have to be the encapsulating node. These configured tunnels will have to be from these hosts to a v6/v4 router that lies on the fringes of the ipv6 domain on which the pure ipv6 host resides. Since such isolated hosts can use link-local addresses to talk to each other on the link, wasting a real ipv6 prefix on them might not be a good idea. They will use their v4-compatible address for global communication. Hosts with v4/v6 router on their links or on other links reachable directly using ipv6 without tunnelling over ipv4, i.e. having ipv6-only routers which eventually reach some ipv6/ipv4 router without tunnelling, should not use ipv4-compatible ipv6 address, firsly this will expediate the transition, secondly it will avoid a lots of mess like deciding where to encapsulate, how to handle routing for ipv4-compatible address, source address selection etc. Eventually we will run out of ipv4 addresses and hosts won't anyway have v4-compatible addresses, and the above policy will ease and expediate the transition by forcing ipv6-domains with dual routers to subscribe for actual ipv6 prefixes. The above policy might have a disadvantage of not allowing routinng domains with isolated v6/v4 hosts (i.e. without dual routers) to upgrade to use pure ipv6 prefixes, but then they can use experimental or private ipv6 prefixes whose reachability should not be announced outside the routing domain. I will briefly describe some mechanisms which might help appreciate the above policy. Hosts on booting up should send RS, on receiving an RA they know there is a v6 router on the domain, then they should not enable their tunnelling interface. Here the assumption being that the v6 router either runs a dual stack or eventually reaches a v6/v4 router on the boundary of the routing domain which will maintain both v4 and v6 routing tables and will be able to route to IPv4-compatible routes. This requirement is not asking a lot because all routers will support both stacks. System administrator can configure their v6 routing domain such that there are dual routers on the fringe of the domain, and all the v6 hosts are able to reach these without tunnelling. Also routers in the interior of the v6 routing domain should not enable their tunnelling interface, i.e. tunnelling should be pushed to the fringe of the routing domain as much as possible. Note that these routers might run ipv4 routing protocols if the ipv4 routing domain overlaps the v6 routing domain. But there need not be any interaction between the routing protocols at all. The only interaction should be via the tunnelling interface at the boundary of the v6 routing domain, at the dual routers. The boundary router will advertise reachability to the default v4-compatible route ::0.0.0.0 (prefix length 96) so that all interior routers will install this route and forward the packet to the dual router as a pure v6 packet. On boundary routers this route will point to the tunnelling interface, which will encapsulate the packet, with v4 destination address derived from the v4-compatible v6 dest. address, and v4 source address determined from the v4 address of the outgoing interface. Then the v4 routing table will be accessed to find a route to the dest. v4 address. So the interior v6 routers will not maintain any v4 routing table unless required (if the ipv4 routing domain overlaps the ipv6 routing domain). All the dual boundary routers can exchange v4 routing information by running OSPFv4 (or RIPv4) to chose the best router for the exiting encapsulated v6 packet ( in v4 ). This might increase the number of hops a packet will travel, but I think it is better than maintaining dual routing tables on all routers, and dealing with all the other problems related to tunnelling, plus helping in expediating the transition. Also by not allowing hosts in domains with dual routers to have v4-comaptible address, and hence discouraging them from having a tunnel interface will eliminate multihoming problems. Multihoming should be supported only where it is desired, e.g. in dual rail environments where failure tolerance is important. In normal internet, introducing multihoming is not a great idea, and anyway IP doesn't handle multihoming in any elegant way. So why unnecessarily introduce multihoming. In fact on isolated dual hosts where tunnelling is important, the tunnel interface should be unnumbered. In essence leave tunneling to routers which are multihomed anyway. I also think that allowing a v4-compatible address to be assigned to a LAN interface, as well as a tunnel interface should be prohibited, because it leads to interoperability problems ( as caused during UNH bakeoff in feb) where one host uses ipv6 on the link for the v4-compatible addresses which are on the link ( as determined from the v4 subnet prefix) while other host uses tunnelling and fails to answer neighbor solicitaions from the first. The above policy encourages this idea, i.e. v4-compatible addresses are used by isolated v4/v6 hosts and hence used only by the tunnel interface. Another problem eliminated is that of source address selection, hosts choose their pure ipv6 address for global communication when they are on subnets with ipv6 prefixes and routers. They use their v4-compatible address if they are isolated and hence are using their tunnel interface. On a IPv6 backbone, we should not maintain dual routing tables. All we need is dual routers maintaining only pure ipv6 routes. Each of them alo maintain a route ::0.0.0.0 ( prefix length 96) which leads to the closest v4 backbone router. So each v6 backbone router maintains this route which is thru a tunnnelling interface, which will encapsulate the packet and forward it to the closest v4 router. All v6 backbone routers need not have a v4 backbone router adjacent. In that case the next hop for this ::0.0.0.0 route will be a v6 address of the next v6 backbone router which will eventually forward the packet to a v4 backbone router. Note that only the v6 backbone router adjacent to a v4 backbone router might do the encapsulation. -- ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 4 13:55:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07714; Thu, 4 Jul 96 13:55:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07708; Thu, 4 Jul 96 13:55:23 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA07691; Thu, 4 Jul 1996 13:51:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA19438; Thu, 4 Jul 1996 13:51:19 -0700 Received: from garnet.berkeley.edu (garnet.Berkeley.EDU [128.32.155.6]) by uclink4.berkeley.edu (8.7.5/8.6.12) with ESMTP id NAA23451; Thu, 4 Jul 1996 13:51:18 -0700 (PDT) Received: from pine by garnet.berkeley.edu (8.7.5/1.33-960227) id NAA20944; Thu, 4 Jul 1996 13:51:16 -0700 Message-Id: <2.2.32.19960704204830.0072fe04@garnet.berkeley.edu> X-Sender: mendes@garnet.berkeley.edu X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 04 Jul 1996 13:48:30 -0700 To: Vijay Gurbani From: Jerry Mendes Subject: (IPng 1903) Re: IPng Presentations Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vijay: My consulting firm, DataComm Insights in Mill Valley, CA is developing a one day tutorial for IPv6. It is our plan to offer the session in-house for any organization who wants/needs it. We plan to cover the essentials describing the protocol and its adjuncts (ie--Neighbor Discover, DHCPv6, IPsec, Mobile IP) as well as transition issues. If you're interested, send me a reply, and I'll keep you posted. In addition, I'd appreciate hearing about your group's needs in such a presentation, and what types of people would need to attend (ie--engineers, product managers, system administrators, etc). Since we're still in a development stage, any input would be useful Regards, Jerry Mendes, Principal Consultant DataComm Insights mendes@garnet.berkeley.edu (415) 381-5500 PS: You can read my article on IPv6 in the March 1996 issue of Business Communications Review. At 02:33 PM 6/4/96 -0500, Vijay Gurbani wrote: >I am looking for any upcoming IPng Presentations. I have tried >(unsucessfully) to find the same information from the 'net. If someone >could mail me information about any upcoming presentations, I would >be very appreciative. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 8 18:46:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09783; Mon, 8 Jul 96 18:46:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09777; Mon, 8 Jul 96 18:46:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA04363; Mon, 8 Jul 1996 18:42:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA20556; Mon, 8 Jul 1996 18:42:10 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id SAA19919; Mon, 8 Jul 1996 18:42:08 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1375245855==_============" Date: Mon, 8 Jul 1996 18:42:22 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 1904) IPng Meeting Minutes Cc: hinden@Ipsilon.COM, minutes@cnri.reston.va.us Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --============_-1375245855==_============ Content-Type: text/plain; charset="us-ascii" Attached are the IPng meeting minutes from the Montreal IETF. Please send changes/corrections to me. Bob --============_-1375245855==_============ Content-Type: text/plain; name="minutes.jun96"; charset="us-ascii" Content-Disposition: attachment; filename="minutes.jun96" IPng Working Group Minutes Montreal IETF June 24,25,26, 1996 Steve Deering / Xerox PARC, Chair Robert Hinden / Ipsilon Networks, Chair Minutes taken by Robert Hinden ----------------------------------------------------------------- ----------------------------------------------------------------- Steve Deering introduced meeting. Robert Hinden agreed to take minutes. Reviewed other working groups discussing IPv6 issues. Reviewed agenda. Asked for additional topics. The agenda agreed to was as follows: Monday 1930 - 2200 ------------------ Introduction - Steve Deering & Bob Hinden 10 min Document Status - Bob Hinden 10 min Status Reports (each 10 min or less) 130 min UNH Testing - Bill Lenharth Header Compression - Micke Degermark IPv6 Tunneling - Alex Conta Interface IDs - Robert Elz UDP & TCP/MSS vs. Jumbograms - Dave Borman Neighbor Discovery - Tom Narten ITU Request for IPv6 Addresses - Bob Hinden IPv6 Auto-Configuration - Sue Thompson DHCPv6 - Jim Bound IPv6 Mobility - Dave Johnson RIPng - Bobby Minnear OSPFng - John Moy IDRPng - Yakov Rekhter IPv6 over FDDI - Matt Crawford IPv6 over NBMA - Grenville Armitage IPv6 over PPP - Dimitry Haskin IPv6 Multicast Routing - Steve Deering Routing Table Size Issue - Ran Atkinson Tuesday 0900 - 1130 ------------------- Host Anycast - Jim Bound & Pedro Roque 30 min Multihomed Hosts - Mike Shand & Matt Thomas 30 min BSD API Issues - Bob Gilligan 30 min Naming Link-Local Addresses - Dan Harrington 10 min Router Alert Option - Ran Atkinson 10 min Host Handling of Route Header - Steve Deering 10 min Open 30 min Wednesday 0900 - 1130 ------------------- Spec Changes/Clarifications - Steve Deering 30 min Advancement of main specs to Draft Standard? 10 min Open for Additional Topics and continuation of 100 min earlier topics Conclusion / Interim Meeting Scheduling 10 min ----------------------------------------------------------------- Monday 1930 - 2200 ----------------------------------------------------------------- Document Status - Robert Hinden ---------------------------- The following documents were approved by the IESG for proposed standard since the last IETF meeting: o "A Method for the Transmission of IPv6 Packets over Ethernet Network" o "An Architecture for IPv6 Unicast Address Allocation" o "Path MTU Discovery for IP Version 6" o "Neighbor Discovery for IP Version 6 (IPv6)" o "IPv6 Stateless Address Autoconfiguration" The following documents have completed both working group and IETF last call and are waiting for IESG action: o "A Method for the Transmission of IPv6 Packets over FDDI Networks" o "A Method for the Transmission of IPv6 Packets over Token Ring Networks" o "IP Version 6 over PPP" The "IPv6 over FDDI" document has been held up because of issues regarding how this should work in the presence of mixed media bridges. The current draft includes an expanded discussion and procedures for this case. The author and chairs believe this should enable it to proceed through the IESG. The "IPv6 over Token Ring" document is waiting for resolution of the "IPv6 over FDDI" document due to similar issues with mixed media bridges. The following document was returned by the IANA: o "OSI NSAPs and IPv6" The IANA returned the document to the working group because it used all of the address space allocated to the IANA for NSAPs. To deal with this a AFI has been assigned to the IANA and a new draft has been written. The working group was Queried about moving NSAP document forward without another w.g.last call and to ask the IESG to skip the IETF last call. Working group approved this course of action. UNH Testing - Bill Lenharth --------------------------- The second IPv6 interoperability testing event was held at University of New Hampshire the week prior to this IETF meeting. About a dozen organizations participated. These included: o Bay Networks o Digital Equipment o FTP Software o HP o HP/SICS o Hitachi o IBM o INRIA o Mentat o Sumitomo o Sun o WIDE UNH staff ran both conformance and interoperability testing. Many implementation problems were found and resolved. Overall of the systems tested 1/3 ran very well, 1/3 ran well but had missing pieces, 1/3 didn't run well. Major progress from previous IPv6 testing event. UNH plans to expand testing their IPv6 testing capability. Planning started for the next testing event in late October or early November this year. Also planning event at Interop Spring 1997. Header Compression - Micke Degermark ------------------------------------ Current draft is draft version 1. New draft deals with links which reorder and loose lots of packets. Demux structure is also different. Plan version 2, which will deal with RTP header compression. SICS has a working "alpha" implementation for NetBSD 1.1 (based on INRIA IPv6 implementation). Plan to distribute code in August. Author expects to be able to move draft forward to proposed standard in August. IPv6 Tunneling - Alex Conta --------------------------- New draft version 02. Changes include: o Removed old text from appendix A o Moved section 4.1.4 (risks of recursive encapsulation) to Appendix A. o Added section 3.2, packet processing in tunnels o Added 8.4, ICMP messages generation. Discussion ICMP generation in case of recursive tunnels o Improved text and figures. Working group agreed to move this document forward and do a working group last call. UDP & TCP/MSS vs. Jumbograms - Dave Borman ------------------------------------------ How do UDP and TCP deal with Jumbograms. Dave Borman did not attend. Check w/ Dave Borman to see if wants to pursue this work. Neighbor Discovery - Tom Narten ------------------------------- On RFC editor desk. ITU Request for IPv6 Addresses - Robert Hinden ------------------------------------------- The IETF received a request from ITU-Telecommunication Standardization Sector STUDY GROUP 17, Rapporteur Q3/7 on 17 July 1995. The ITU requested an IPv6 Format Prefix for X.121 Public Data Network Addresses. It also suggested that ITU-T Study Group 2 may also make a similar request for E.164 addresses. X.121 Public Network addresses are not Internetwork addresses. As a result it would be better to treat them as IPv6 handles other networks such as Ethernet, FDDI, etc. We should define interface identifiers from the X.121 addresses. The BSD digits of the X.121 address would be converted to binary. An IPv6 over X.121 Public Data Networks document could be written. A suggestion was made that there is also an AFI for these type of addresses in the NSAP space. This would fit into the framework defined in "OSI NSAPs and IPv6" document. This could accommodate their needs. Christian Huitema suggested was ask them how this would be used. Ross Callon suggested to invite them to come to the IETF and talk about what they had in mind. The IPng document editor will draft a response. IPv6 Auto-Configuration - Sue Thompson -------------------------------------- On RFC editor desk. DHCPv6 - Jim Bound ------------------ The architecture is stable. Uses features of IPv6 and stateless addr configuration. Changes DHCPv4 architecture in significant way. Document now contains appendix describing differences. The use of IPv6 multicast helped the architecture extensively. Also integrated w/ Dynamic Updates to DNS. Security authentication model defined, but no consensus yet. New relay agent model. Bound expects implementations by October 1996. Place to request advance to proposed standard after December 1996. There will be a public domain code base. Expect to test at next UNH test event. RIPng - Bob Hinden ------------------ A new RIPng draft has been published. It includes a few mechanisms from the RIPv2 protocol not included in the first RIPng draft. This is expected to move forward in the RIPv2 working group. OSPFng - John Moy ----------------- New draft version 02. Complete specificaiton. Will be discussed in detail in OSPF meeting. Major changes from previous version o Runs directly over IPv6 o Addressing semantics removed from LSA header, router LSA, network LSA and just in other LSA's. Results in all address being removed from base OSPF headers. o Run per-link, not per-subnet, explicit support for multiple instances per link. o Uses IPv6 authentication header and encapsulation security payload. o Supports OSPF extensions: MOSPF, NSSA areas, and demand circuits o Incremented OSPF version from two to three. LSA Format Changes o LS type now explicitly encodes flooding scope (link local, area, global) and handling of unknown LS types. o Link state ID remains 32 bits o Advertising router remains 32 bits o Router-LSA can be fragmented IDRPng - Paul Traina -------------------- o IDRP for IPv4 and IPv6 (think about as BGP-5) o Based on BGP4 / IDRP o FIB tag for extensible / divergent routing (e.g., QOS and unicast vs. multicast) o Uses IDRP transport mechanisms (multicast "flooding" in the future) o IDRPv1 state eliminated. Route withdraws are now supported. IPv6 over FDDI - Matt Crawford ------------------------------ Presented issues which caused IESG to not move this forward the when it was first submitted. The main issue was how this should function in the presence of mixed media bridges (e.g., FDDI <-> Ethernet). The goal for the current design is to not require any IPv6 intelligence in a mixed media bridge. Lots of mixed media bridges exist and are heavily used. Proposed mechanism is for any node on an FDDI ring to send traffic with a non-zero value in FDDI LLC priority field. Bridge will set this field to zero when going from Ethernet to FDDI. Field does not exist on Ethernet. All routers can advertise an ethernet size MTU in IPv6 neighbor discovery. All nodes start sending multicast packets with 1500 MTU. Nodes can only send larger MTU packets when receive LLC Non-zero value. Author discovered after ID was written, that DEC VAX cluster uses a very similar algorithm to deal with the same issue. IPv6 over NBMA - Grenville Armitage ----------------------------------- Tuesday ION working group session is discussing this issue. Main issues are how to do cut through, how to keep IPv6 neighbor discovery with out changes or to develop a alternative mechanism to neighbor discovery. IPv6 over PPP - Dimitry Haskin ------------------------------ Changes from the previous draft o Token flag reduced to 32 bits o Clarifications to text Competed working group and IETF last call and been sent to IESG. IPv6 Multicast Routing - Steve Deering -------------------------------------- One missing piece of IPng is multicast routing protocols. Discussed to document how to represent multicast routing table independent of specific routing protocols. There is a large number of multicast routing protocols in IPv4. We should be able to reduce number of multicast routing protocols. We should also be able to eliminate the need for separate multicast tunnels. Multicast routing topology should be same as unicast topology. Suggested we don't need to do DVMRP for IPv6. PIM dense mode should be fine. Deering has summer students working on IPv6 multicast routing. Plan is to implement PIM dense mode for IPv6 multicast routing. Tom Pussatari noted that MOSPF has been specified and also provides IPv6 multicast routing. Note that new PIM dense mode specification also supports IPv6. Routing Table Size Issues - Ran Atkinson ---------------------------------------- Outline o IPv4 Routing entry size o IPv6 routing entry size IPv4 Routing Entry o Has two components: 32bits entry, 32bit masks IPv6 Routing Entry o 128 entry, 128 bits mask [Editors Note: Most implementations would likely not use a 128bit mask, but would instead use a 8 bit prefix length.] o IPv6 has native addresses and IPv4 compatible addresses Routing table issue o Routes for native addresses are not a big problem. o If IPv4 addresses were carried in IPv6 table would increase memory requirements by a large factor. Alternatives o Router filter out IPv4 compatible prefixes. o Do nothing o Do not put compatible addressing IPv6 table. Proposed Approach o Clarify IPv6 routing protocol specifications to prohibit transmission of IPv4 compatible IPv6 routes as if they were IPv6 routes. Implementations: o IPv6 routes will use the V4 routing table to lookup compatible addresses. Recommendations o Add clarification to NG Trans draft. Modify IPv6 routing protocol specifications: - IGP: OSPF, RIPng, I/ISIS - EGP: IDRP Group discussion on how to deal with this. There was general agreement that it is a good idea in the short term to keep IPv4 and IPv6 routing tables separate. Especially for backbone networks. This is an important issue for internet service providers. However there may be some environments where it is desirable to add IPv4 compatible routes to an IPv6 routing table. It is not clear it this recommendation has to be done in each protocol document. Could be dealt with in separate standalone document. It was noted that this issue is covered in NG-Trans routing document, but needs to be made clearer. Chairs asked that a standalone document be written which specifies this behavior. Ran Atkinson will send email. Document editor volunteered to help to turn into an internet draft. Default Hop Limit ----------------- What should be default Hop Limit be in IPv6? Deering suggested 64. Frank Kastenholts suggested max value. Much discussion. Group decided to use max value of 256 as the default IPv6 Hop Limit. IPv6 Mobility - Dave Johnson ---------------------------- Mobile IP w.g. has consensus on basic approach and protocol. Current draft isd raft-ietf-mobileip-ipv6-01.txt. Design philosophy is a combination of what we learned with Mobile IPv4, new features present in IPv6, and opportunity of a new IP. Important functions for Mobile IP o Reliable and timely location and notification to nodes that need it o Correspondent nodes communicating with a mobile node o The mobile node's home agent Basic Operation o Mobile node always addressable by home address o Mobile node away from home also has a care-of-address o Mobile node sends notification through Binding Update o Movement detection through Neighbor Discovery Binding Option is a new IPv6 Destination option (may be included in any packet). Home address for binding must be IPv6 source address. Packet must include IPv6 authentication header. Binding acknowledgment message is a new IPv6 informational ICMP Message. Only needed if acknowledgment set in binding update. Requirements for IPv6 Nodes: o Every IPv6 node must be able to: 1) Receive binding updates and send binding acknowledgments, and 2) Maintain a binding cache o Every IPv6 node that wants to be a mobile node must be able to: 1) Perform IPv6 unencapsulation, 2) send binding updates and receive binding acknowledgments, and 3) maintain a binding update list of unexpired bindings set. Requirements for IPv6 Routers o Every IPv6 router must be able to use a binding cache entry to encapsulate for forwarding. o At least one router in a mobile nodes home network must be able serve as a home agent. o Mobile nodes which function as a home agent, must be able to: 1) Maintain a registry containing the mobile nodes binding, 2) Intercept home network packets for mobile node, 3) Encapsulate the the mobile node's care-of-address. ------------------------------------------------------------------ Tuesday 0900 - 1130 ------------------------------------------------------------------ Host Anycast - Jim Bound & Pedro Roque -------------------------------------- IPv6 Anycasting Service / Minimum Requirements Goals: Anycast initiated communication Anycast Problems o Server configuration, o Routing o Unicast reply to anycast datagram (mechanisms must be present in all IPv6 nodes). Solution independent of the above two problems, no changes to TCP/UDP specifications Layering Issues o Anycast addresses are a Network issue o Transport must be able to identify datagrams belonging to the same communication Transport/Network Interface o No mapping is performed between identifier and locator o BSD based implementations o Interfaces: transp_input() transp_output() Discussion about the need for a mapping between identifier and locator. Should not be eliminated for possible future use. Operational Model [Editors Note: Time based packet trace not included in minutes] Client: S=uncast_A;D=anycast Server: S=uncast_B;D=uncast_A[Id=anycast] Client: S=uncast_A;D=anycast o Stateless UDP o TCP and state-full UDP anycast initiated communication Identification Option Processing o Network passes information to the transport layer o TCP: state SYN-SENT, demultiplexing by identifier, destination->unicast source address o UDP: applications must select the appropriate behavior, demultiplexing by identifier Deering: If server adds an options which says this was an anycast address, the client will know that the response was in response to a request sent to an anycast address. Open Issues o TCP - receipt RST/ACK segment in SYN-SENT An RST/ACK segment on an active open implies there is no listener. o Security (authentication) o UDP API Issues o Special case of anycast address represents the interfaces of an multi-homed host. Discussion about whether this is a change to TCP/UDP. Presenter disagreed, but it is a change the the behavior for TCP implementations. Discussion about need for RST/ACK semantics. Suggestion for TCP options or other mechanism. Naming Link-Local Addresses and Names - Dan Harrington ------------------------------------------------------ Introduction o Issue is that Plug and Play is limited without names. o Hex addresses are not finger friendly o Limited scope addresses do not belong in the DNS Proposal o Server / Advertisement +--------------+ | FE80::8AF1:C | +--------------+ | fred | +--------------+ o Client Request +--------------+ +----------------+ | ??????? | | FE80::CAFE:A8E | +--------------+ +----------------+ | barney | | ???????? | +--------------+ +----------------+ o Lifetime / Cacheing o Link-local multicast Issues o Interaction w/ resolver (.link pseudo-domain might be nice) o Duplicate names / addresses o Doesn't scale to CERN's LAN o Some (how much?) overlap with Service Location protocol Robert Elz thought overall was a good idea. Would remove simple names and allow fully qualified DNS names. Deering: three questions. 1) Both advertisement and on demand approach. Why both? Wanted to allow both types of interaction. 2) For query could use solicited node multicast address. 3) Overlap with service location? This could be input to service location working group when they deal with IPv6. [Editors Note: The service is starting to work on an IPv6 version of service location.] IPv6 Router Alert Option - Ran Atkinson --------------------------------------- Problem: o Some Control packets (IGMP, RSVP) that need special processing by a router but are not addressed to a router. o Desire to not have to look at all packet options in transit packets. IPv4 Approach o Control packets which contain this option are fully processed Proposed IPv6 Approach o Identical concept as for IPv4 o IPv6 Hop by Hop options Which Packet use Router Alert o IGMP o RSVP Implementation Issues o All hosts must add this option for IGMP/RSVP packets o Routers must process packets which receive this option o Control packets which do not contain this option might not be processed correctly by routers Discussion: KRE liked idea, but suspects RSVP should be a Hop by Hop option itself. Should not follow IPv4 model for this case. Deering: Need to clarify processing semantics: Just for IGMP/RSVP/etc, or process all of the packet (like it was addressed to router). We should consider allowing larger hop by hop options. General discussion about how RSVP would better if this was done with a hop by hop header. This will be discussed more on Wednesday. Host Handling of Route Header - Steve Deering --------------------------------------------- What should host do with route headers? Can a host process a route header or should routers only process route headers. Current specs permit hosts to process route header. Mobile IP has a special case where this is used. Another issues is should hosts reverse source route when replying to packets containing route headers. Should hosts only support route reversal if packet authenticated. Mobile host does not require route reversal. Third issues: What if both application and IP layer adds a routing header? One have priority over the other, or add both route headers? Proposes 1) Hosts Must process route headers. 2) Decision to reverse route headers is at transport level. Strongly suggest that authentication be used here. Simpler rule is at the present, we do not recommend that hosts reverse routes. Add this to next draft of base IPv6 specification. Suggestion from Charlie Perkins for another route header (one which is required to be reversed, one which is not). BSD API Issues - Bob Gilligan ----------------------------- Overview of Discussion Differences between current spec and previous issues raised. Current draft is version 05, April 18, 1996 Changes o Eliminated source route and interface identification features - Group could not agree on right way to provide these features - Could be proposed in follow on document. - Most applications do not need these functions, doesn't hold up "basic" spec. o Replace hostname2addr() with Posix getaddrinfo() function o Replace addr2hostname() with new getaddrinfo() function donated by Keith Sklower - Want to use existing standards when they exist. o Changed name of addr2ascii() to inet_ntop() o Changed name of ascii2addr() to inet_pton() - Semantics unchanged - Function name prefix needed to avoid conflict with user and other library functions Issues Raised o Spec should give function prototype for getaddrinfo() - Concern that Posix might change function - Our specification would have to track Posix specification o Proposed Resolution - Include function prototype in specification - Add caveat saying that Posix document is definitive specification Suggestion to make this a separate draft. Would make easier to update later. Deering: Thinks it is important to include interface identification. Asked why this was not included. Answer was that it will be dealt with later in separate document. Many other comments saying that it is very important to support interface identification o Name prefix for inet_pton() and inet_ntop() - Implies IP specific functionality, but functions are designed to be generic. - But "inet_" is prefix least likely to cause name conflict o Proposed resolution - No change o Name suffix for inet_pton() and inet_ntop() - Hard to infer meaning from name - Issue of "taste" o Proposed resolution - No change o Lower level name/address translation functions are needed - Changing existing apps to use getaddrinfo() is hard. o Proposed resolution: - Add definitions for gethostbyname(), gethostbyname2(), and gethostbyaddr() - No change to getaddrinfo() or getnameinfo() definitions. Other issues: o Interface identification o Interface naming for multicast Working group agreed to move this forward. Hinden queried group to ask for if there is any remaining issues. There are major issues with how to do interface identification. This will be very hard to resolve. Still very important to add to API. Current proposal is to handle this in separate document. Proceed now with "basic" specification. Additional issue raised: o Enable/Disable PMTU per-Socket (wants to fragment at 576 MTU, instead of interface MTU) Some discussion, no consensus. Person suggesting will write a short draft. o Flow ID & Priority - Structs vs. bitmask Some discussion. Will be left the way it is now. o Interface naming for Multicast Deering suggested we wait for conclusion of link local address discussion on Wednesday. ------------------------------------------------------------------ Wednesday 0900 - 1130 ------------------------------------------------------------------ Spec Changes/Clarifications - Steve Deering ------------------------------------------- Changes from UNH Testing o Determination of neighborness for strict source route How to decide if next hop is a neighbor? Deering will propose clarification on the mailing list. o Should Echo Replies be truncated to return MTU? No, they should be fragmented. o Need for "Full Info" flag in Router Advertisement - Unsolicited RA's may omit some info, e.g., long lived prefixes - Solicited RA's may be multicast - When a host solicits on startup first head RA, terminates solicitation - Solicited and unsolicited RA's are indistinguishable Result is that Host may not receive all info in response to solicitation. Possible solutions include: 1) Put all info in all RA's 2) Unicast all responses to solicitations 3) Add "solicited" for "full info" flag to RAS; Only Full info RAS would terminate solicitation. Discussion. Not clear how much of a problem this is. Will be discussed on mailing list. o NUD vs. Router Discovery - If NUD reports all known routers are down, for those destinations that were previously being reached through a router, should a host: a) Assume on-link and solicit locally, or b) Continue to assume off-link, until lifetime of all received RA's have expired? Discussion. Second case is the specified behavior. o What response to fragments that exceed reassembly buffer size? None. Drop packet with no error reply. o Should receivers discard overlapping fragments? Drop overlapping fragments. o Can Packets to link-local destination be forwarded onto same link? Address Arch need to expand rules to cover both source and destination link-local addresses. OK to allow router to forward these packets back on the link it came in on. o Link-local address used in route header? Two cases: 1) S1 -> L1 -> L2 R | L1 ---------------- | | L2 S1 D 2) S -> G -> L S ----.....-----R | G ---------------- | L D Do not allow link local addresses in route header. First might be ok. Deering will think about and send analysis on mailing. o Clarify format + byte order of IPv4 addresses embedded in IPv6 address representation Fix in spec. o Support options with data > 255 bytes? Would be useful for RSVP, etc. Options include: 1) Make length field bigger 2) Define new "big options" 3) Escape length 4) Semantically fragment option data 5) Forget it (e.g., just say no) Do not change spec and suggest 4) if bigger options are needed. o Eliminate (reserve) the priority field (and exclude from Authentication Header (AH) computation? Currently encourages hosts to sent more packets than will get through to the destination. Encourages bad behavior. Deering suggests this is a research topic and we should get more experience before specifying. Discussion that it can be used now to distinguish control traffic now (e.g. router updates, etc.). Would also be nice to have some reserved bits that could be used for new features later. Neighbor discovery currently specifies a priority for ND packets. Group agreed to set the bits to all zeros now. Less clear about excluding them from the AH. Discuss issue further on mailing list. Multihomed Hosts - Matt Thomas ------------------------------ Cases: ----------- ----------------- | \ / | \ / | \/ | | H H ----------- ----------------- | | | H H R------ | | | ----------- ----------------- 1) Did we cover the right cases? 2) Working group comfortable with anycast proposal? 3) Choosing and Interface? a) Never lose a packet? b) Never duplicate a packet? c) Application dependent? First case (a) may mean sending over all interfaces 4) Is there one mechanism or will we need lots of mechanisms? Discussion about building mechanisms for multihoming in IPv6 or use IPv6 Mobile Host support, and how mobility support can help with this problem. Some consensus that mobile IPv6 might be a better way to deal with these problems. Currently do not think the anycast solution is fleshed out enough. Document is good overview of the issues, but as of today we can not pick a specific solution. Group thought work is important and should proceed. Interface Token Size - Robert Elz --------------------------------- Raised issue about how big a token should be. Is it 48bits or can it grow? Deering proposes that we make maximum token length 48 bits. Group agreed to adopt this limit. Interface IDs - Robert Elz -------------------------- Reviewed proposal to add interface identifier to link local definition. Would add interface token to link local address. Discussion and questions about proposal. Proposal is compatible with current link local address definition (e.g., interface token is zero). Comment that there is no reason to have this extra information on the wire. This is dealing with a local problem inside of a machine. Author did not agree. Deering said he hates this too and naming of interface is completely orthogonal to defining addresses. They should not be tied together. These addresses should not go out on the wire. Current spec does not require any changes to hosts which do not want to implement this. Dennis Fergusion this is useful because multiple links might be bridged together later and the way we use link local would cause conflicts (e.g., routing protocols). Erik Nordmark thought the routing protocol issues could be dealt with in different ways. Comment that link local may change because interface token may change based on how host creates the interface token. Nordmark raised concerned that this was adding a lot of complexity to specifications. Deering suggested that real issue is generating duplicate tokens. Duplicate Address Detection (DAD) should be redefined to have this view. Brian Carpenter noted that this is really a L2 problem. DAD needs to look at whole address. If you end up with multiple interface on the same LAN, it does not work correctly. Ethernet gets multiple packets. FDDI will does not work. Deering polled group. Slightly more thought ok, but not clear consensus. Group needs to resolve this on the mailing list. Author encourages people to send comments. ------------------------------------------------------------------------ ------------------------------------------------------------------------ Meeting ended. The following agenda items were not discussed due to lack of time: o Advancement of main specs to Draft Standard? o Reverse Name Lookups of IPv4 Compatible Addresses - Paul Vixie o Conclusion / Interim Meeting Scheduling These will be discussed on he mailing list. ------------------------------------------------------------------------ ------------------------------------------------------------------------ --============_-1375245855==_============-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 9 07:17:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10213; Tue, 9 Jul 96 07:17:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10207; Tue, 9 Jul 96 07:17:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04440; Tue, 9 Jul 1996 07:13:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA24513; Tue, 9 Jul 1996 07:13:16 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2099; Tue, 09 Jul 96 10:13:20 EDT Received: by RTP (XAGENTA 4.0) id 6674; Tue, 9 Jul 1996 10:13:09 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17709; Tue, 9 Jul 1996 10:12:35 -0400 Message-Id: <9607091412.AA17709@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1905) Default Hop Limit In-Reply-To: Your message of "Mon, 08 Jul 1996 18:42:22 PDT." Date: Tue, 09 Jul 1996 10:12:35 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From the Montreal meeting minutes: > Default Hop Limit > ----------------- > > What should be default Hop Limit be in IPv6? Deering suggested 64. Frank > Kastenholts suggested max value. Much discussion. Group decided to use > max value of 256 as the default IPv6 Hop Limit. I'm really uncomfortable with this decision. I think that caution is advised and we should take a conservative approach because of the potential impact on Internet congestion. As I recall, the main argument for the change was that by setting the default to something low (like the current 64 specified in the assigned numbers RFC), we only make life difficult later when the limit needs to be raised. Some relevant issues: 1) Occasional routing loops are a reality today and will be for the foresable future. Packets caught in the loop contribute to congestion, impacting not just traffic caught in the loop, but also links carrying traffic to destinations that are not part of the loop. A looping packet with a Hop Limit of 255 takes 4 times as long to expire as one with 64. This factor of 4 difference has a very real and measurable impact, especially on slower links. Consequence: raising the default Hop Limit will increase congestion in some circumstances. Just how much is difficult to predict with certainty. Given the reality that the Internet is congested today and will be for the foresable future, I'd feel a lot more comfortable taking a more conservative approach with regards to selecting a max default Hop Limit. 2) With Neighbor Discovery & Router Advertisements, changing the default Hop Limit at a future time is easy. Changing the default TTL in IPv4 was hard because the constant was hard-wired into stack implementations. That is not the case in IPv6. All routers will need a way for system admininstrators to specify what prefixes to advertise via Router Advertisements, which prefixes are on-link, etc. Given that such information MUST be hand-configured, the incremental effort needed to also specify an alternate Hop Limit is negligible. If sometime down the road a protocol is developed for propagating prefix information automatically, the protocol could also include additional information to be advertised (i.e., Hop Limit). So I simply don't buy the argument that raising the Hop Limit later is unreasonably onerous. 3) If we make the default Hop Limit 255, by implication we should also revisit a number of base documents and ask the question of whether we even need a way to set the default Hop Limit. That is, if we recommend that everyone use 255 as a default, why require all the knobs to make it easy to set lower (i.e., via RAs)? Including the knobs suggests that we aren't sure 255 is really a good idea. But history has shown that it's harder to get folks to fix things that don't directly effect them (i.e., big Hop Limit contributes to congestion somewhere offsite), so in practice we'll never be able to get folks to lower their default Hop Limit later. In contrast, getting folks to raise it will be relatively easy, since presumably they are having difficulty communicating with some sites (i.e., something visible locally). 4) Just what is the longest path in the current Internet? How close to the 64 limit are we getting? If the current limit is too small, I'd advocate a more conservative approach and bump it up only as much as can reasonably be argued is necessary. Would 80 be enough? 90? 100? Also, what evidence is there that the average path length is increasing? At what rate is it increasing? And what is the likely maximum end point value? If we really think it will approach 255, doesn't that suggest we need to consider making the Hop Limit field itself bigger? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 9 08:19:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10392; Tue, 9 Jul 96 08:19:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10362; Tue, 9 Jul 96 08:13:13 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA11504; Tue, 9 Jul 1996 08:09:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA10118; Tue, 9 Jul 1996 08:09:02 -0700 Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id LAA27362; Tue, 9 Jul 1996 11:08:08 -0400 Received: from centime.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id LAA08549; Tue, 9 Jul 1996 11:09:02 -0400 Received: by centime.cascade (5.x/SMI-SVR4) id AA08948; Tue, 9 Jul 1996 11:09:01 -0400 Date: Tue, 9 Jul 1996 11:09:01 -0400 From: conta@alpo.casc.com (Alex Conta) Message-Id: <9607091509.AA08948@centime.cascade> To: ipng@sunroof.eng.sun.com, narten@VNET.IBM.COM Subject: (IPng 1906) Re: Default Hop Limit Cc: conta@alpo.casc.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Thomas Narten" > Sender: owner-ipng@sunroof.Eng.Sun.COM > Precedence: bulk > Content-Type: text > Content-Length: 4008 > > From the Montreal meeting minutes: > > > Default Hop Limit > > ----------------- > > > > What should be default Hop Limit be in IPv6? Deering suggested 64. Frank > > Kastenholts suggested max value. Much discussion. Group decided to use > > max value of 256 as the default IPv6 Hop Limit. > > I'm really uncomfortable with this decision. I think that caution is > advised and we should take a conservative approach because of the > potential impact on Internet congestion. .... I do not feel comfortable either with 255. ND was designed to set/change the hop limit easily. We should start with 64 for now. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 9 08:27:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10434; Tue, 9 Jul 96 08:27:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10428; Tue, 9 Jul 96 08:27:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA13542; Tue, 9 Jul 1996 08:23:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA14716; Tue, 9 Jul 1996 08:23:19 -0700 Received: by callc2.competitive.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB6D88.4C61D380@callc2.competitive.com>; Tue, 9 Jul 1996 11:18:04 -0400 Message-Id: From: JohnM To: "'ipng@sunroof.Eng.Sun.COM'" , "'Thomas Narten'" Subject: (IPng 1907) RE: Default Hop Limit Date: Tue, 9 Jul 1996 11:18:02 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Increasing the hop limit masks the real problem: the current wiring system needs to be rethought. On the US road system of the 1930s, how many times would a driver have to stop to get from any one place in the country to the other (assuming unlimited gas supply and no pit stops)? Either several or indeterminate. On the other hand, with the US highway system in place, with on ramps and off ramps (and assuming no toll plazas) one can argue that it should never take more than 16 stops (or hops) to get from any place to any other place. With a healthy redesign of the wiring system, no packet should have to go more than 16 hops. The system of routers would have to be "tiered" to go to more authoritative routers. Obviously, those more authoritative routers would have to be high performance routers, lest they become the bottlenecks. Furthermore, these more authoritative routers would need to be connected to each other by high speed trunk lines. (My humble apologies for stating the obvious; I'm sure this has already been thought out and you all are aware of this.) But increasing the hop count will only make things worse, ultimately. John Mangione >---------- >From: Thomas Narten[SMTP:narten@VNET.IBM.COM] >Sent: Tuesday, July 09, 1996 9:12 AM >To: ipng@sunroof.Eng.Sun.COM >Subject: (IPng 1905) Default Hop Limit > >From the Montreal meeting minutes: > >> Default Hop Limit >> ----------------- >> >> What should be default Hop Limit be in IPv6? Deering suggested 64. Frank >> Kastenholts suggested max value. Much discussion. Group decided to use >> max value of 256 as the default IPv6 Hop Limit. > >I'm really uncomfortable with this decision. I think that caution is >advised and we should take a conservative approach because of the >potential impact on Internet congestion. > >As I recall, the main argument for the change was that by setting the >default to something low (like the current 64 specified in the >assigned numbers RFC), we only make life difficult later when the >limit needs to be raised. > >Some relevant issues: > >1) Occasional routing loops are a reality today and will be for the >foresable future. Packets caught in the loop contribute to congestion, >impacting not just traffic caught in the loop, but also links carrying >traffic to destinations that are not part of the loop. A looping >packet with a Hop Limit of 255 takes 4 times as long to expire as one >with 64. This factor of 4 difference has a very real and measurable >impact, especially on slower links. Consequence: raising the default >Hop Limit will increase congestion in some circumstances. Just how >much is difficult to predict with certainty. > >Given the reality that the Internet is congested today and will be for >the foresable future, I'd feel a lot more comfortable taking a more >conservative approach with regards to selecting a max default Hop >Limit. > >2) With Neighbor Discovery & Router Advertisements, changing the >default Hop Limit at a future time is easy. Changing the default TTL >in IPv4 was hard because the constant was hard-wired into stack >implementations. That is not the case in IPv6. All routers will need a >way for system admininstrators to specify what prefixes to advertise >via Router Advertisements, which prefixes are on-link, etc. Given that >such information MUST be hand-configured, the incremental effort >needed to also specify an alternate Hop Limit is negligible. If >sometime down the road a protocol is developed for propagating prefix >information automatically, the protocol could also include additional >information to be advertised (i.e., Hop Limit). So I simply don't buy >the argument that raising the Hop Limit later is unreasonably onerous. > >3) If we make the default Hop Limit 255, by implication we should also >revisit a number of base documents and ask the question of whether we >even need a way to set the default Hop Limit. That is, if we recommend >that everyone use 255 as a default, why require all the knobs to make >it easy to set lower (i.e., via RAs)? Including the knobs suggests >that we aren't sure 255 is really a good idea. But history has shown >that it's harder to get folks to fix things that don't directly effect >them (i.e., big Hop Limit contributes to congestion somewhere >offsite), so in practice we'll never be able to get folks to lower >their default Hop Limit later. In contrast, getting folks to raise it >will be relatively easy, since presumably they are having difficulty >communicating with some sites (i.e., something visible locally). > >4) Just what is the longest path in the current Internet? How close to >the 64 limit are we getting? If the current limit is too small, I'd >advocate a more conservative approach and bump it up only as much as >can reasonably be argued is necessary. Would 80 be enough? 90? 100? > >Also, what evidence is there that the average path length is >increasing? At what rate is it increasing? And what is the likely >maximum end point value? If we really think it will approach 255, >doesn't that suggest we need to consider making the Hop Limit field >itself bigger? > >Thomas > > > > >------------------------------------------------------------------------ >------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 9 08:41:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10461; Tue, 9 Jul 96 08:41:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10455; Tue, 9 Jul 96 08:41:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15653; Tue, 9 Jul 1996 08:37:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA19487; Tue, 9 Jul 1996 08:37:35 -0700 Received: by oxygen.house.gov (AIX 3.2/UCB 5.64/4.03) id AA50871; Tue, 9 Jul 1996 11:37:09 -0400 Date: Tue, 9 Jul 1996 11:37:09 -0400 From: johns@oxygen.house.gov (John Schnizlein) Message-Id: <9607091537.AA50871@oxygen.house.gov> To: ipng@sunroof.eng.sun.com, narten@VNET.IBM.COM Subject: (IPng 1908) Re: Default Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I thought the reason for increasing the hop count was to support mobile IP addresses. As the encapsulation solution for mobile IP routes a packet to the mobile station via a home station (or intermediate) it crosses the Internet essentially twice. If all these hops are to be reflected in the outside header, you need more hops for this. Without engaging the whole mobile IP debate, I think accommodating mobile stations might require more hops in principle. I am not comfortable with hiding the hop count of (tunnel) legs of the packet's trip because that expands the risk of looping packets more. John Schnizlein ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 9 10:28:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10557; Tue, 9 Jul 96 10:28:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10550; Tue, 9 Jul 96 10:27:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA08399; Tue, 9 Jul 1996 10:23:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA28638; Tue, 9 Jul 1996 10:23:34 -0700 Received: from margit (margit.scri.fsu.edu [144.174.128.45]) by mailer.scri.fsu.edu (8.6.12/8.6.12) with SMTP id NAA20441; Tue, 9 Jul 1996 13:25:23 -0400 From: Ken Hays Received: by margit (AIX 3.2/UCB 5.64) id AA16998; Tue, 9 Jul 1996 13:23:16 -0400 Date: Tue, 9 Jul 1996 13:23:16 -0400 Message-Id: <9607091723.AA16998@margit> To: JohnM Cc: "'ipng@sunroof.Eng.Sun.COM'" , "'Thomas Narten'" In-Reply-To: Subject: (IPng 1909) RE: Default Hop Limit Reply-To: Ken Hays Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JohnM wrote on 9-Jul-96 at 11:18:02 -0400, in part: > >Increasing the hop limit masks the real problem: the current wiring >system needs to be rethought. ..text omitted > >With a healthy redesign of the wiring system, no packet should have to >go more than 16 hops. The system of routers would have to be "tiered" to >go to more authoritative routers. Obviously, those more authoritative >routers would have to be high performance routers, lest they become the >bottlenecks. Furthermore, these more authoritative routers would need >to be connected to each other by high speed trunk lines. (My humble >apologies for stating the obvious; I'm sure this has already been >thought out and you all are aware of this.) One short and obvious comment - there needs to be more "peering" at the "local / regional" level to avoid having packets from one side of town take a trip across the network (country/globe) twice to get the other side of town. Later, Ken ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 9 10:43:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10587; Tue, 9 Jul 96 10:43:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10514; Tue, 9 Jul 96 09:08:41 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20126; Tue, 9 Jul 1996 09:04:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA28918; Tue, 9 Jul 1996 09:04:30 -0700 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id MAA05453; Tue, 9 Jul 1996 12:04:53 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA52369; Tue, 9 Jul 1996 12:04:26 -0400 From: Charlie Perkins Message-Id: <9607091604.AA52369@hawpub1.watson.ibm.com> To: johns@oxygen.house.gov (John Schnizlein) Cc: ipng@sunroof.eng.sun.com, narten@VNET.IBM.COM Subject: (IPng 1910) Re: Default Hop Limit In-Reply-To: Your message of Tue, 09 Jul 96 11:37:09 D. <9607091537.AA50871@oxygen.house.gov> Date: Tue, 09 Jul 96 12:04:26 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've taken the liberty of re-formatting the following comments so that the lines fit within fewer columns. > I thought the reason for increasing the hop count was to support > mobile IP addresses. As far as I remember, this was not part of the stated justification. > As the encapsulation solution for mobile IP > routes a packet to the mobile station via a home station (or > intermediate) it crosses the Internet essentially twice. If all > these hops are to be reflected in the outside header, you need > more hops for this. Except that I don't know what is meant by an "intermediate", what you say is true enough. However, our mobile-IP proposal for IPv6 goes to some length to make sure that the home agent is rarely involved. Datagrams routed through the home agent should be viewed as triggering an initialization or resynchronization procedure. And, I don't think the conditional in the latter sentence is satisfied by protocols outlined in the existing drafts. > Without engaging the whole mobile IP debate, I think accommodating > mobile stations might require more hops in principle. I am not > comfortable with hiding the hop count of (tunnel) legs of the > packet's trip because that expands the risk of looping packets more. I don't think this part of your argument is specific to mobility. Instead, it is part of the discussion of any solution which uses tunneling. Wasn't the issue already decided in general (and thus, decided for any particular solution using tunneling)? Does there need to be more than one flavor of tunneling, to allow for a choice of various hop-limit behaviors? > John Schnizlein Charles Perkins ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 9 19:07:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11042; Tue, 9 Jul 96 19:07:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11036; Tue, 9 Jul 96 19:07:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA04956; Tue, 9 Jul 1996 19:03:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA10998; Tue, 9 Jul 1996 19:03:02 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA06388; Tue, 9 Jul 96 22:03:10 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9607100203.AA06388@wizard.gsfc.nasa.gov> Subject: (IPng 1911) Re: Default Hop Limit To: conta@alpo.casc.com (Alex Conta) Date: Tue, 9 Jul 1996 22:03:09 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com, narten@VNET.IBM.COM, conta@alpo.casc.com In-Reply-To: <9607091509.AA08948@centime.cascade> from "Alex Conta" at Jul 9, 96 11:09:01 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: conta@alpo.casc.com (Alex Conta) > > From: "Thomas Narten" > > > > From the Montreal meeting minutes: > > > > > Default Hop Limit > > > ----------------- > > > > > > What should be default Hop Limit be in IPv6? Deering suggested 64. Frank > > > Kastenholts suggested max value. Much discussion. Group decided to use > > > max value of 256 as the default IPv6 Hop Limit. > > > > I'm really uncomfortable with this decision. I think that caution is > > advised and we should take a conservative approach because of the > > potential impact on Internet congestion. > .... > > I do not feel comfortable either with 255. > > ND was designed to set/change the hop limit easily. We should start with 64 > for now. I also think we should be conservative and start with a hop limit of 64. When packets do loop, they shouldn't consume more resources than are reasonably necessary for the expected diameter of the Internet. And given that most of the planet is connected already, I would think that we should be approaching an upper bound on the Internet diameter. And finally, if and when the hop limit would ever need to be increased, since only routers would need to be reconfigured, it's a fairly small and quite manageable task to implement the change. -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 9 23:51:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11138; Tue, 9 Jul 96 23:51:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11132; Tue, 9 Jul 96 23:51:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA00032; Tue, 9 Jul 1996 23:47:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA21063; Tue, 9 Jul 1996 23:47:17 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id IAA05903; Wed, 10 Jul 1996 08:47:15 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA02106; Wed, 10 Jul 1996 08:47:05 +0200 Message-Id: <9607100647.AA02106@dxcoms.cern.ch> Subject: (IPng 1912) Re: Default Hop Limit To: JohnM@competitive.com (JohnM), narten@VNET.IBM.COM Date: Wed, 10 Jul 1996 08:47:04 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "JohnM" at Jul 9, 96 11:18:02 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tom, > 4) Just what is the longest path in the current Internet? How close to > the 64 limit are we getting? If the current limit is too small, I'd > advocate a more conservative approach and bump it up only as much as > can reasonably be argued is necessary. Would 80 be enough? 90? 100? Fred Baker and a few friends have recently been making some ad hoc measurements of the path lengths in the current Internet. Using an admittedly biased sample of hosts, we see a mean path length of around 16 hops, with a maximum in the low 30's. Any outliers observed (with 50 or more hops) appear to be due to pathological cases such as temporary loops. > Also, what evidence is there that the average path length is > increasing? At what rate is it increasing? We have no evidence about this, unless anyone has historical data on mean path lengths. > ...And what is the likely > maximum end point value? If we really think it will approach 255, > doesn't that suggest we need to consider making the Hop Limit field > itself bigger? If it gets anywhere 255 we have plenty of other problems. John, > > With a healthy redesign of the wiring system, no packet should have to > go more than 16 hops. The system of routers would have to be "tiered" to > go to more authoritative routers. Sorry but no. In a world with several thousand competing ISPs we cannot engineer the topology towards any theoretical ideal. However, there is good news. We can only reasonably expect the net to grow by another three orders of magnitude, and some handwaving arguments suggest that would only add about 6 or 7 hops to the current path mean path length (assuming a log law applies - an unproven assumption). My conclusion is that 64 hops will take us a long way. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 02:02:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11225; Wed, 10 Jul 96 02:02:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11219; Wed, 10 Jul 96 02:02:42 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA11098; Wed, 10 Jul 1996 01:58:31 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA06590; Wed, 10 Jul 1996 01:58:30 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0udv6F-000ZB2C; Wed, 10 Jul 96 01:58 PDT Message-Id: Date: Wed, 10 Jul 96 01:58 PDT From: Michael Gersten To: ipng@sunroof.eng.sun.com Subject: (IPng 1913) Re: Default Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just for what it's worth, I've seen 25 hops fairly frequently (measured by traceroute). I have yet to see anything today that can't be reached in 30 hops. (lets see, say it takes 6 hops to cross a "backbone", say you need to cross three of these, say you need 5 hops to cross an ISP (two of these), and another 4 hops for your local WAN. That's 18 + 10 + 8 = 36, which is probably the worst case anywhere.) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 02:28:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11255; Wed, 10 Jul 96 02:28:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11249; Wed, 10 Jul 96 02:28:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA12995; Wed, 10 Jul 1996 02:24:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id CAA09913; Wed, 10 Jul 1996 02:24:07 -0700 From: Masataka Ohta Message-Id: <199607100914.SAA09105@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA09105; Wed, 10 Jul 1996 18:14:14 +0900 Subject: (IPng 1914) Re: Default Hop Limit To: ipng@sunroof.eng.sun.com Date: Wed, 10 Jul 96 18:14:12 JST X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Due to planarily of the surface of the Earth, the most economical (to the total length of wiring) backbone topology make hop count grow square root to the size of the Internet. So, 255 may not be large enough. But, as the constant factor is not so large, it may be enough. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 04:18:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11319; Wed, 10 Jul 96 04:18:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11313; Wed, 10 Jul 96 04:18:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA19718; Wed, 10 Jul 1996 04:14:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA25206; Wed, 10 Jul 1996 04:14:08 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA05726; Wed, 10 Jul 1996 13:14:06 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA28649; Wed, 10 Jul 1996 13:14:00 +0200 Message-Id: <9607101114.AA28649@dxcoms.cern.ch> Subject: (IPng 1915) Re: Default Hop Limit To: michael@stb.info.com (Michael Gersten) Date: Wed, 10 Jul 1996 13:13:59 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Michael Gersten" at Jul 10, 96 01:58:00 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The measurements I cited earlier today agree with what you say. Brian Carpenter >--------- Text sent by Michael Gersten follows: > > Just for what it's worth, I've seen 25 hops fairly frequently > (measured by traceroute). I have yet to see anything today that > can't be reached in 30 hops. > > (lets see, say it takes 6 hops to cross a "backbone", say you > need to cross three of these, say you need 5 hops to cross an > ISP (two of these), and another 4 hops for your local WAN. > That's 18 + 10 + 8 = 36, which is probably the worst case > anywhere.) > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 04:41:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11349; Wed, 10 Jul 96 04:41:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11343; Wed, 10 Jul 96 04:41:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA21767; Wed, 10 Jul 1996 04:37:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA28181; Wed, 10 Jul 1996 04:37:05 -0700 Received: from A117018.dfw1.as.crl.com by A.crl.com with SMTP id AA23600 (5.65c/IDA-1.5 for ); Wed, 10 Jul 1996 04:36:31 -0700 Date: Wed, 10 Jul 1996 04:36:31 -0700 Message-Id: <199607101136.AA23600@A.crl.com> X-Sender: trohling@a.crl.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: Ted Rohling Subject: (IPng 1916) Re: Default Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The lively debate over the hop limit is exhiliarating. I must chime in with my support for the 64 limit. While 255 might seem a bit large for technical reasons, the overall impact of such a large hop count will be viewed in more asthetic terms....it will take too long for people to use the net. If users have to go through 255 routing devices to get to the destination(and 255 back) then the net will suffer from the CB radio syndrome. The ultimate CSMA/CD network (CB Radio) was overused to the point of popular extinction (Unless ur a good buddy). Use the KISS method, it works! Regards, Ted trohling@a.crl.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 06:55:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11420; Wed, 10 Jul 96 06:55:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11414; Wed, 10 Jul 96 06:55:01 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01885; Wed, 10 Jul 1996 06:50:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA24862; Wed, 10 Jul 1996 06:50:48 -0700 Received: from munin.fnal.gov ("port 2619"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I6WHBIK4Q6000UY6@FNAL.FNAL.GOV> for ipng@sunroof.eng.sun.com; Wed, 10 Jul 1996 08:50:47 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id IAA16590; Wed, 10 Jul 1996 08:49:29 -0500 (CDT) Date: Wed, 10 Jul 1996 08:49:28 -0500 From: Matt Crawford Subject: (IPng 1917) Re: Default Hop Limit In-Reply-To: "09 Jul 1996 22:03:09 EDT." <"9607100203.AA06388"@wizard.gsfc.nasa.gov> To: ipng@sunroof.eng.sun.com Message-Id: <199607101349.IAA16590@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11443; Wed, 10 Jul 96 07:24:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11431; Wed, 10 Jul 96 07:23:45 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04711; Wed, 10 Jul 1996 07:19:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA02255; Wed, 10 Jul 1996 07:19:33 -0700 Received: from ftp.com by ftp.com ; Wed, 10 Jul 1996 10:19:30 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 10 Jul 1996 10:19:30 -0400 Received: by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id KAA19611; Wed, 10 Jul 1996 10:19:15 -0400 Date: Wed, 10 Jul 1996 10:19:15 -0400 Message-Id: <199607101419.KAA19611@MAILSERV-2HIGH.FTP.COM> To: ipng@sunroof.eng.sun.com Subject: (IPng 1918) Re: Default Hop Limit From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Repository: mailserv-2high.ftp.com, [message accepted at Wed Jul 10 10:19:10 1996] Originating-Client: d-cell.ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > From the Montreal meeting minutes: > > > > > Default Hop Limit > > > ----------------- > > > > > > What should be default Hop Limit be in IPv6? Deering suggested 64. Frank > > > Kastenholts suggested max value. Much discussion. Group decided to use > > > max value of 256 as the default IPv6 Hop Limit. > > > > I'm really uncomfortable with this decision. I think that caution is > > advised and we should take a conservative approach because of the > > potential impact on Internet congestion. > .... > > I do not feel comfortable either with 255. > > ND was designed to set/change the hop limit easily. We should start with 64 > for now. the basis of my argument for 255 is that relying on nd does not solve the problem, it moves it and it (dramatically) shrinks it. it "moves" the problem by moving the place where someone has to type in "ttl=123" from the individual hosts to the routers. it "shrinks" the problem because there are less routers than hosts around, less places to type in the number and the routers are more likely to be properly administered. if we make the hopcount 255 then it will _never_ need to be changed and that's one less task for the system administrators to deal with (should they ever have to). the downside is that packets could live longer in routing loops, filling more buffers, possibly preventing the routers from running the routing protocol to break the loop, possibly preventing other, unlooped traffic from transiting the router. (of course, if a packet lives 4 times as long in a loop with ttl=255 than if the ttl=64 then the packet will, over its life time, consume 4 times as many buffers, perhaps blocking that many more other packets from entering the loop (and those packets would be thrown away immediately because of no buffer space rather than 'later' because their ttl expired). so if the loop lives long enough for one ttl=255 packet to die of ttl exhaustion and 3 other packets to die of no-bufferpsace, then it would live long enough for 4 ttl=64 packets to die of ttl exhaustion too. the only external difference is that with ttl-64, you get 4 icmp messages, with ttl255, only one. hmm interesting tradeoff. but i digress...) i'm not arguing for or against the 255 proposal. just offering my reasoning behind it. -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 07:24:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11444; Wed, 10 Jul 96 07:24:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11432; Wed, 10 Jul 96 07:23:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04708; Wed, 10 Jul 1996 07:19:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA02257; Wed, 10 Jul 1996 07:19:32 -0700 Received: from ftp.com by ftp.com ; Wed, 10 Jul 1996 10:19:31 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 10 Jul 1996 10:19:31 -0400 Received: by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id KAA19613; Wed, 10 Jul 1996 10:19:16 -0400 Date: Wed, 10 Jul 1996 10:19:16 -0400 Message-Id: <199607101419.KAA19613@MAILSERV-2HIGH.FTP.COM> To: ipng@sunroof.eng.sun.com Subject: (IPng 1919) Re: Default Hop Limit From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Repository: mailserv-2high.ftp.com, [message accepted at Wed Jul 10 10:19:12 1996] Originating-Client: d-cell.ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 'make plans to fit circumstances, not circumstances to fit plans' or the option of rewiring the internet to suit our technical preferences is not available to us from Ken Hays > > JohnM wrote on 9-Jul-96 at 11:18:02 -0400, in part: > > > >Increasing the hop limit masks the real problem: the current wiring > >system needs to be rethought. > ..text omitted > > > >With a healthy redesign of the wiring system, no packet should have to > >go more than 16 hops. The system of routers would have to be "tiered" to > >go to more authoritative routers. Obviously, those more authoritative > >routers would have to be high performance routers, lest they become the > >bottlenecks. Furthermore, these more authoritative routers would need > >to be connected to each other by high speed trunk lines. (My humble > >apologies for stating the obvious; I'm sure this has already been > >thought out and you all are aware of this.) > > One short and obvious comment - there needs to be more "peering" at > the "local / regional" level to avoid having packets from one side of > town take a trip across the network (country/globe) twice to get the > other side of town. -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 08:41:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11527; Wed, 10 Jul 96 08:41:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11521; Wed, 10 Jul 96 08:41:13 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA16195; Wed, 10 Jul 1996 08:37:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA25072; Wed, 10 Jul 1996 08:37:00 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3794; Wed, 10 Jul 96 11:37:04 EDT Received: by RTP (XAGENTA 4.0) id 7239; Wed, 10 Jul 1996 11:36:54 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20173; Wed, 10 Jul 1996 11:36:12 -0400 Message-Id: <9607101536.AA20173@cichlid.raleigh.ibm.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1920) Re: Default Hop Limit In-Reply-To: Your message of "Wed, 10 Jul 1996 08:49:28 CDT." <199607101349.IAA16590@munin.fnal.gov> Date: Wed, 10 Jul 1996 11:36:12 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: >And just so we're all on the same page, what we're discussing is the >hop limit hosts should use in the case of no router advertisements >(when the whole question should be moot) and in the case that all >routers are advertising zero as the "Cur Hop Limit". I actually interpreted the discussion to essentially mean "set the suggested max Hop Limit in the Assigned Numbers RFC to 255". That is, everyone just assumes 255, unless told otherwise. But one wouldn't be told otherwise without someone somewhere having explicitly configured a lower value. After all, there wouldn't be much point in having hosts by default use 255, if routers were (by default out of the box) configured to advertise 64 (which the current ND spec does say): > 6.2.1. Router Configuration Variables > [ ... ] > AdvCurHopLimit > The default value to be placed in the Cur Hop Limit > field in the Router Advertisement messages sent by > the router. The value should be set to that current > diameter of the Internet. The value zero means > unspecified (by this router). > > Default: The value specified in the "Assigned > Numbers" RFC [ASSIGNED] that was in effect at the > time of implementation. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 09:11:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11567; Wed, 10 Jul 96 09:11:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11561; Wed, 10 Jul 96 09:11:23 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20838; Wed, 10 Jul 1996 09:07:10 -0700 From: bmanning@ISI.EDU Received: by mercury.Sun.COM (Sun.COM) id JAA05222; Wed, 10 Jul 1996 09:07:11 -0700 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 10 Jul 1996 09:07:10 -0700 Posted-Date: Wed, 10 Jul 1996 09:06:17 -0700 (PDT) Message-Id: <199607101606.AA06787@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Wed, 10 Jul 1996 09:06:17 -0700 Subject: (IPng 1921) Re: Default Hop Limit To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Wed, 10 Jul 1996 09:06:17 -0700 (PDT) Cc: JohnM@competitive.com, narten@VNET.IBM.COM, ipng@sunroof.eng.sun.com In-Reply-To: <9607100647.AA02106@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Jul 10, 96 08:47:04 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 4) Just what is the longest path in the current Internet? How close to > > the 64 limit are we getting? If the current limit is too small, I'd > > advocate a more conservative approach and bump it up only as much as > > can reasonably be argued is necessary. Would 80 be enough? 90? 100? > > Fred Baker and a few friends have recently been making some ad hoc > measurements of the path lengths in the current Internet. > Using an admittedly biased sample of hosts, we see a mean path > length of around 16 hops, with a maximum in the low 30's. > Any outliers observed (with 50 or more hops) appear to be due > to pathological cases such as temporary loops. > 64 might be ok for now. I've just reviewed a paper by Ramesh Govindan and Anoop Reddy that has done some analysis on path length over the last 18 months. It has not changed significantly in that time. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 09:32:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11611; Wed, 10 Jul 96 09:32:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11605; Wed, 10 Jul 96 09:32:15 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA23996; Wed, 10 Jul 1996 09:28:01 -0700 Received: by venus.Sun.COM (Sun.COM) id JAA15835; Wed, 10 Jul 1996 09:28:01 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id JAA07855 for ; Wed, 10 Jul 1996 09:26:45 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA01588; Wed, 10 Jul 96 09:26:40 MST; for ipng@sunroof.eng.sun.com Message-Id: <9607101626.AA01588@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Wed, 10 Jul 1996 09:26:40 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 1922) Re: Default Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just noticed that Solaris has been using a default TTL of 255 for both TCP and UDP for a number of years (at least since Solaris 2.1). Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 10:26:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11740; Wed, 10 Jul 96 10:26:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11734; Wed, 10 Jul 96 10:26:42 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA03044; Wed, 10 Jul 1996 10:22:26 -0700 Received: by venus.Sun.COM (Sun.COM) id KAA26288; Wed, 10 Jul 1996 10:22:25 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id TAA01540; Wed, 10 Jul 1996 19:20:19 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id TAA01332; Wed, 10 Jul 1996 19:20:19 +0200 (MET DST) Message-Id: <199607101720.TAA01332@givry.inria.fr> From: Francis Dupont To: Michael Gersten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1923) Re: Default Hop Limit In-Reply-To: Your message of Wed, 10 Jul 1996 01:58:00 PDT. Date: Wed, 10 Jul 1996 19:20:18 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Just for what it's worth, I've seen 25 hops fairly frequently (measured by traceroute). I have yet to see anything today that can't be reached in 30 hops. => I have seen several cases of path lengths over 30 hops between RENATER (French academic network) and Japan (far enough to cause bad DNS problems). I believe you can find 40 hop paths today... Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 10:35:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11752; Wed, 10 Jul 96 10:35:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11746; Wed, 10 Jul 96 10:35:33 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA04551; Wed, 10 Jul 1996 10:31:18 -0700 Received: by venus.Sun.COM (Sun.COM) id KAA27643; Wed, 10 Jul 1996 10:31:18 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA25454; Thu, 11 Jul 1996 03:29:25 +1000 (from kre@munnari.OZ.AU) To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1924) Re: Default Hop Limit In-Reply-To: Your message of "Wed, 10 Jul 1996 08:49:28 EST." <199607101349.IAA16590@munin.fnal.gov> Date: Thu, 11 Jul 1996 03:29:25 +1000 Message-Id: <19774.837019765@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 10 Jul 1996 08:49:28 -0500 From: Matt Crawford Message-ID: <199607101349.IAA16590@munin.fnal.gov> And just so we're all on the same page, what we're discussing is the hop limit hosts should use in the case of no router advertisements (when the whole question should be moot) and in the case that all routers are advertising zero as the "Cur Hop Limit". Correct?' I missed the session in Montreal where this was discussed, so I wasn't quite sure exactly what the topic was here [Aside: Bob - this is a hint that the minutes need additional clarity - assuming there was any in the discussion in the session] However, if it was as you suggest it, and the limit under discussion was what should be done if no routers advertise a (sensible) hop limit then I would favour a very low number, much under 64, perhaps even 1. If the routers' owners can't be bothered to config this number (or even let it default to the suggested value) then the hosts may as well be all cut off from all routing until the router is fixed (just as if the router is misconfigured in a hundred other possible ways). But that wasn't how I had interpreted the discussion, I assumed it was probably about what the default value should be for routers to advertise. For that, I'd agree with the suggested 64, but would perhaps be slightly happier with a less "round" number - say 59 or 62 or something like that. Numbers like 64 tend to suggest to people that there's some good reason for choosing that particular value. I'd actually be quite happy with advising router vendors to set the default value to "some number between 55 and 70". Frank - having to go config this number higher if it should happen to be needed is a trivial burden. It is nothing at all like the problem with IPv4 when the magic 15 was exceeded - that number was compiled into the binaries, and it was only because it happened to be fairly easy to patch the binaries for almost all architectures to turn the 15 into 31 that we managed to survive. As long as it is a configureable number, even if it were in the hosts, we don't need to worry too much about the possibility that we might just perhaps need to increase it again. In the routers we shouldn't even begin to think about worrying about this possibility. Your analysis of the effects of a routing look assume that it is terminal (essentially all packets get involved and meltdown ensues). In practice this is rarely the case, most often just a small percentage of the overall packet load on any segment of the net is involved in the loop, all the rest is perfectly normal stuff. Making the packets live 4 times longer simply means 4 times as much work due to the loop, nothing fills buffers and results in packets being dropped. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 12:43:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11855; Wed, 10 Jul 96 12:43:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11849; Wed, 10 Jul 96 12:42:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA00014; Wed, 10 Jul 1996 12:38:26 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA27081; Wed, 10 Jul 1996 12:38:19 -0700 Received: from inner.net (fiasco.cs.nrl.navy.mil [132.250.90.21]) by inner.net (8.7.3/42) with ESMTP id OAA02654 for ; Thu, 11 Jul 1996 14:12:49 -0400 Message-Id: <199607111812.OAA02654@inner.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 1925) BSD API draft 5 question X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Wed, 10 Jul 1996 15:36:27 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Consider these /etc/services entries: foo 1234/tcp bar 1234/udp If a sockaddr with sin6_port = htons(1234) is passed to getnameinfo(), what service name is returned? -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 12:57:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11892; Wed, 10 Jul 96 12:57:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11886; Wed, 10 Jul 96 12:56:43 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA02520; Wed, 10 Jul 1996 12:52:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA03115; Wed, 10 Jul 1996 12:52:14 -0700 Received: by doe.ernet.in (4.1/SMI-4.1-MHS-7.0) id AA18894; Thu, 11 Jul 96 01:25:33+050 Received: by iitk.ernet.in (Smail3.1.29.1 #1) id m0ue44H-0009rtC; Thu, 11 Jul 96 00:02 GMT+5:30 Received: from csesun1 by yamuna.iitk.ernet.in with smtp (Smail3.1.29.1 #3) id m0ue3ui-000JblC; Wed, 10 Jul 96 23:53 IST(+5:30) Received: by csesun1 (4.0/SMI-4.0) id AA16126; Wed, 10 Jul 96 23:59:10 IST Date: Wed, 10 Jul 96 23:59:10 IST From: dheeraj@iitk.ernet.in (Dheeraj Sanghi) Message-Id: <9607101829.AA16126@csesun1> To: ipng@sunroof.eng.sun.com, kasten@ftp.com Subject: (IPng 1926) Re: Default Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the downside is that packets could live longer in routing loops, > filling more buffers, possibly preventing the routers from running > the routing protocol to break the loop, possibly preventing other, > unlooped traffic from transiting the router. (of course, if a packet > lives 4 times as long in a loop with ttl=255 than if the ttl=64 then > the packet will, over its life time, consume 4 times as many buffers, > perhaps blocking that many more other packets from entering the loop > (and those packets would be thrown away immediately because of no > buffer space rather than 'later' because their ttl expired). so if > the loop lives long enough for one ttl=255 packet to die of ttl > exhaustion and 3 other packets to die of no-bufferpsace, then it > would live long enough for 4 ttl=64 packets to die of ttl exhaustion > too. the only external difference is that with ttl-64, you get 4 icmp > messages, with ttl255, only one. hmm interesting tradeoff. but i > digress...) There is more to the tradeoff than the number of ICMP messages. Let us examine two cases. Case 1. One packet dropped due to TTL=0 Three packets dropped due to lack of buffers. Case 2. All 4 packets dropped due to TTL=0. If we assume that diameter is indeed less than 64, as most people on this list seem to agree, than packets lost due to TTL=0 are those which are caught in a routing loop. The hosts couldn't care less whether they are dropped after 64 hops or 255 hops. But in case 1, there are three packets getting dropped which probably wouldn't have been caught in a routing loop. So, the tradeoff is between dropping packets caught in a routing loop and dropping packets which may not be caught in such a loop. I, for one, would prefer to drop packets in the former category. Also, since everybody seems to agree that the Internet diameter is less than 30, there is no point in keeping a packet for much longer. Even if the packet indeed reaches the destination because of high TTL, it would have taken substantially longer time than most packets, and if the transport protocol is TCP, there would be a time-out, and retransmission. -dheeraj -------------- Dheeraj Sanghi +91 (512) 25-7077 (Off) Dept. of Computer Science & Engineering +91 (512) 25-8627 (Res) Indian Institute of Technology +91 (512) 25-0260 (Fax) Kanpur - 208 016 (UP), INDIA. dheeraj@iitk.ernet.in ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 13:18:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11916; Wed, 10 Jul 96 13:18:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11908; Wed, 10 Jul 96 13:17:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA05750; Wed, 10 Jul 1996 13:13:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA11073; Wed, 10 Jul 1996 13:13:47 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with ESMTP id NAA15166; Wed, 10 Jul 1996 13:13:34 -0700 (MST) Received: (from rstevens@localhost) by gemini.tuc.noao.edu (8.7.5/8.7.3/SAG-10Jul96) id NAA06566; Wed, 10 Jul 1996 13:13:36 -0700 (MST) Message-Id: <199607102013.NAA06566@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Wed, 10 Jul 1996 13:13:36 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Craig Metz , ipng@sunroof.eng.sun.com Subject: (IPng 1927) Re: BSD API draft 5 question Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jul 10, 3:36pm you write:] > > Consider these /etc/services entries: > > foo 1234/tcp > bar 1234/udp > > If a sockaddr with sin6_port = htons(1234) is passed to getnameinfo(), > what service name is returned? Here is the comment from my implementation: /* * Notice that we do not have enough information to pass a * "protocol" argument to getservbyport(), so the assumption * is that the protocol (TCP or UDP) does not matter. */ Are there different services that use the same port, one for TCP and one for UDP? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 13:33:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11961; Wed, 10 Jul 96 13:33:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11955; Wed, 10 Jul 96 13:32:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA07823; Wed, 10 Jul 1996 13:28:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA16007; Wed, 10 Jul 1996 13:28:45 -0700 Received: from munin.fnal.gov ("port 2938"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I6WV7UQX6O000UY6@FNAL.FNAL.GOV>; Wed, 10 Jul 1996 15:28:42 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id PAA19913; Wed, 10 Jul 1996 15:27:23 -0500 (CDT) Date: Wed, 10 Jul 1996 15:27:21 -0500 From: Matt Crawford Subject: (IPng 1928) Re: BSD API draft 5 question In-Reply-To: "10 Jul 1996 13:13:36 PDT." <"199607102013.NAA06566"@gemini.tuc.noao.edu> To: Richard Stevens Cc: Craig Metz , ipng@sunroof.eng.sun.com Message-Id: <199607102027.PAA19913@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Are there different services that use the same port, one for TCP > and one for UDP? shell 514/tcp cmd # no passwords used syslog 514/udp ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 13:46:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11978; Wed, 10 Jul 96 13:46:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11972; Wed, 10 Jul 96 13:46:35 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA10056; Wed, 10 Jul 1996 13:42:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA21117; Wed, 10 Jul 1996 13:42:22 -0700 Received: from inner.net (fiasco.cs.nrl.navy.mil [132.250.90.21]) by inner.net (8.7.3/42) with ESMTP id PAA02698; Thu, 11 Jul 1996 15:16:58 -0400 Message-Id: <199607111916.PAA02698@inner.net> To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1929) Re: BSD API draft 5 question In-Reply-To: Your message of "Wed, 10 Jul 1996 13:13:36 PDT." <199607102013.NAA06566@gemini.tuc.noao.edu> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Wed, 10 Jul 1996 16:40:43 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199607102013.NAA06566@gemini.tuc.noao.edu>, you write: >Here is the comment from my implementation: > > /* > * Notice that we do not have enough information to pass a > * "protocol" argument to getservbyport(), so the assumption > * is that the protocol (TCP or UDP) does not matter. > */ > >Are there different services that use the same port, one for TCP >and one for UDP? There aren't supposed to be, but that doesn't mean they don't exist. Would explicitly mentioning this problem in the spec be a reasonable way to handle this problem? -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 14:56:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12059; Wed, 10 Jul 96 14:56:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12053; Wed, 10 Jul 96 14:56:41 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA23587; Wed, 10 Jul 1996 14:52:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA15844; Wed, 10 Jul 1996 14:52:28 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA30873; Wed, 10 Jul 1996 17:41:34 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA24978; Wed, 10 Jul 1996 17:41:33 -0400 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id RAA19467; Wed, 10 Jul 1996 17:47:15 GMT Message-Id: <199607101747.RAA19467@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: kasten@ftp.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1930) Re: Default Hop Limit In-Reply-To: Your message of "Wed, 10 Jul 1996 10:19:15 -0400." <199607101419.KAA19611@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Jul 1996 17:47:11 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the basis of my argument for 255 is that relying on nd does not solve > the problem, it moves it and it (dramatically) shrinks it. it "moves" > the problem by moving the place where someone has to type in > "ttl=123" > from the individual hosts to the routers. it "shrinks" the problem > because there are less routers than hosts around, less places to type > in the number and the routers are more likely to be properly > administered. if we make the hopcount 255 then it will _never_ > need to be changed and that's one less task for the system > administrators to deal with (should they ever have to). This is no different from the renumbering problem. You get a new prefix for your "intranet" from one of your providers? How do you update routers to not only understand the new prefix but to insert their "link" specific part into it? My own (possibly warped) view is that IPv6 could really use a router-to-router configuration protocol to handle this type of issue. (the border router(s) learn the hop count from the provider, adjust it up if needed, and then this gets propogated to other routers in the intranet being compensated by the number of hops from the border routers). Or whatever. Just punting on the hop limit and setting it to 255 is stupid. We have a mechanism with which we can update the hosts. Now get another mechanism for the routers (and I am not volunteering!). -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 18:13:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12176; Wed, 10 Jul 96 18:13:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12170; Wed, 10 Jul 96 18:13:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA11357; Wed, 10 Jul 1996 18:09:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA23592; Wed, 10 Jul 1996 16:59:58 -0700 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id QAA29885; Wed, 10 Jul 1996 16:59:57 -0700 Date: Wed, 10 Jul 1996 16:59:57 -0700 From: Ran Atkinson Message-Id: <199607102359.QAA29885@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1931) Re: Default Hop Limit In-Reply-To: <199607101747.RAA19467@whydos.lkg.dec.com> References: <199607101419.KAA19611@MAILSERV-2HIGH.FTP.COM> Organization: cisco Systems, Inc., Menlo Park, Ca. Cc: matt@lkg.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <199607101747.RAA19467@whydos.lkg.dec.com> Matt wrote: >My own (possibly warped) view is that IPv6 could really use a >router-to-router configuration protocol to handle this type of >issue. (the border router(s) learn the hop count from the provider, >adjust it up if needed, and then this gets propogated to other >routers in the intranet being compensated by the number of hops from >the border routers). Or whatever. > >Just punting on the hop limit and setting it to 255 is stupid. >We have a mechanism with which we can update the hosts. Now >get another mechanism for the routers (and I am not volunteering!). I've already got an astonishing number of knobs associated with IPv6. Hence, as a general principle, I am really really not in favour lots of additional knobs to add complexity and confuse things. However, given a choice between a per-router TTL knob, a per-interface TTL knob, and yet another protocol, I'll pick the per-router TTL knob anyday. Its only a few minutes of code to write. Note that if we simply picked 255 then we'd be no worse off than today's IPv4 Internet. Today's deployed Internet mostly uses a default TTL of 255 (RFCs to the contrary not withstanding). Today's Internet doesn't seem to have any major problem with the use of 255 as the default TTL. So let me try to emulate Yakov and ask "what current observable real world operational problem are we trying to solve with a TTL less than 255 ?". I gently suggest that no observable real-world problem with TTL exists and that this discussion, while intellectually stimulating, isn't all that useful. It WOULD be good if consensus were reached on this TTL question soon though. I prefer no knobs, no new protocols, and default TTL of 255. Back to coding, Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 18:46:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12206; Wed, 10 Jul 96 18:46:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12200; Wed, 10 Jul 96 18:46:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA18390; Wed, 10 Jul 1996 18:41:58 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA17822; Wed, 10 Jul 1996 18:41:58 -0700 Received: from pferguso-pc.cisco.com (c2robo12.cisco.com [171.68.13.44]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id SAA06645; Wed, 10 Jul 1996 18:42:55 -0700 Message-Id: <199607110142.SAA06645@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Jul 1996 21:41:53 -0400 To: Matt Thomas From: Paul Ferguson Subject: (IPng 1932) Re: Default Hop Limit Cc: kasten@ftp.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, you're not warped. Sick, evil, rotten, mean, nasty -- sure. I honestly admit that I simply cannot envision a router-to-router auto-configuration mechanism. - paul At 05:47 PM 7/10/96 +0000, Matt Thomas wrote: > >My own (possibly warped) view is that IPv6 could really use a >router-to-router configuration protocol to handle this type of >issue. (the border router(s) learn the hop count from the provider, >adjust it up if needed, and then this gets propogated to other >routers in the intranet being compensated by the number of hops from >the border routers). Or whatever. > >Just punting on the hop limit and setting it to 255 is stupid. >We have a mechanism with which we can update the hosts. Now >get another mechanism for the routers (and I am not volunteering!). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 19:38:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12283; Wed, 10 Jul 96 19:38:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12277; Wed, 10 Jul 96 19:38:23 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA23242; Wed, 10 Jul 1996 19:34:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA26663; Wed, 10 Jul 1996 19:34:10 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id WAA01906; Wed, 10 Jul 1996 22:34:36 -0400 (EDT) Date: Wed, 10 Jul 1996 22:34:36 -0400 (EDT) From: Scott Bradner Message-Id: <199607110234.WAA01906@newdev.harvard.edu> To: matt@lkg.dec.com, pferguso@cisco.com Subject: (IPng 1933) Re: Default Hop Limit Cc: ipng@sunroof.eng.sun.com, kasten@ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I honestly admit that I simply cannot envision a router-to-router > auto-configuration mechanism. well, I must have a better imagination cuz I can & I feel that in the long run we need to be able to do just that. I can envision an environment where your border router gets a (secure) message from your ISP telling you to renumber and your border routers forward that request on to your internal routers ... I can also envision an environment where your routers scale the subnet size based on the number of "nodes" at the same level in the architectural hierarchy and reconfigure based on that - communicating betwen themselves in the process. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 19:41:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12295; Wed, 10 Jul 96 19:41:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12289; Wed, 10 Jul 96 19:41:06 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA23497; Wed, 10 Jul 1996 19:36:53 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id TAA27105; Wed, 10 Jul 1996 19:36:53 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id WAA07496; Wed, 10 Jul 1996 22:29:05 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA12966; Wed, 10 Jul 1996 22:29:04 -0400 Message-Id: <9607110229.AA12966@fwasted.zk3.dec.com> To: Paul Ferguson Cc: Matt Thomas , kasten@ftp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1934) Re: Default Hop Limit In-Reply-To: Your message of "Wed, 10 Jul 96 21:41:53 EDT." <199607110142.SAA06645@lint.cisco.com> Date: Wed, 10 Jul 96 22:29:03 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, >I honestly admit that I simply cannot envision a router-to-router >auto-configuration mechanism. What about an administration protocol to do what Matt suggests? I think we need it for renumbering anyway????? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 21:57:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12379; Wed, 10 Jul 96 21:57:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12373; Wed, 10 Jul 96 21:57:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA05489; Wed, 10 Jul 1996 21:53:05 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id VAA15971; Wed, 10 Jul 1996 21:53:04 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id AAA18727; Thu, 11 Jul 1996 00:40:20 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18079; Thu, 11 Jul 1996 00:40:17 -0400 Message-Id: <9607110440.AA18079@fwasted.zk3.dec.com> To: Scott Bradner Cc: matt@lkg.dec.com, pferguso@Cisco.COM, ipng@sunroof.eng.sun.com, kasten@ftp.com Subject: (IPng 1935) Re: Default Hop Limit In-Reply-To: Your message of "Wed, 10 Jul 96 22:34:36 EDT." <199607110234.WAA01906@newdev.harvard.edu> Date: Thu, 11 Jul 96 00:40:17 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >well, I must have a better imagination cuz I can & I feel that >in the long run we need to be able to do just that. I can envision >an environment where your border router gets a (secure) message >from your ISP telling you to renumber and your border routers forward that >request on to your internal routers ... I can also envision an environment >where your routers scale the subnet size based on the number of "nodes" >at the same level in the architectural hierarchy and reconfigure based >on that - communicating betwen themselves in the process. I can see this vision too. Makes sense to me. It can be done. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 10 23:19:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12417; Wed, 10 Jul 96 23:19:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12411; Wed, 10 Jul 96 23:19:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA13882; Wed, 10 Jul 1996 23:15:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA00219; Wed, 10 Jul 1996 23:15:20 -0700 Received: (dkatz@localhost) by puli.cisco.com (8.6.12/8.6.5) id XAA06639; Wed, 10 Jul 1996 23:15:15 -0700 Date: Wed, 10 Jul 1996 23:15:15 -0700 From: Dave Katz Message-Id: <199607110615.XAA06639@puli.cisco.com> To: michael@stb.info.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: Michael Gersten's message of Wed, 10 Jul 96 01:58 PDT Subject: (IPng 1936) Re: Default Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Those with a long memory (in Internet terms) will recall that certain Unix implementations once shipped with a default TTL small enough to require the T1 NSFNET to play silly games with TTL in order to maintain reachability. Please don't try to guess what is "reasonable." This has been proven to be folly repeatedly in this business. (Just this afternoon I saw 33 hops between my home machine and an office I was visiting at the time.) Date: Wed, 10 Jul 96 01:58 PDT From: Michael Gersten Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Just for what it's worth, I've seen 25 hops fairly frequently (measured by traceroute). I have yet to see anything today that can't be reached in 30 hops. (lets see, say it takes 6 hops to cross a "backbone", say you need to cross three of these, say you need 5 hops to cross an ISP (two of these), and another 4 hops for your local WAN. That's 18 + 10 + 8 = 36, which is probably the worst case anywhere.) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 02:40:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12656; Thu, 11 Jul 96 02:40:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12650; Thu, 11 Jul 96 02:40:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA00139; Thu, 11 Jul 1996 02:36:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id CAA01558; Thu, 11 Jul 1996 02:36:19 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1937) Re: BSD API draft 5 question To: rstevens@noao.edu Date: Thu, 11 Jul 1996 10:51:25 +0100 (BST) Cc: cmetz@inner.net, ipng@sunroof.eng.sun.com In-Reply-To: <199607102013.NAA06566@gemini.tuc.noao.edu> from "Richard Stevens" at Jul 10, 96 01:13:36 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Are there different services that use the same port, one for TCP > and one for UDP? Yes exec 512/tcp biff 512/udp comsat login 513/tcp who 513/udp whod shell 514/tcp cmd # no passwords used syslog 514/udp PS: I can't get mail direct just to you at noao .. our firewall sits dropping ident requests and our mailer waits ages for a response then times out. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 03:19:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12683; Thu, 11 Jul 96 03:19:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12677; Thu, 11 Jul 96 03:18:45 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA02876; Thu, 11 Jul 1996 03:14:32 -0700 From: sthaug@nethelp.no Received: by mercury.Sun.COM (Sun.COM) id DAA06898; Thu, 11 Jul 1996 03:14:24 -0700 Received: (qmail-queue invoked from smtpd); 11 Jul 1996 10:13:52 +0000 (GMT) Received: from localhost (HELO verdi.nethelp.no) (@127.0.0.1) by localhost with SMTP; 11 Jul 1996 10:13:52 +0000 (GMT) To: iialan@iifeak.swan.ac.uk Cc: rstevens@noao.edu, cmetz@inner.net, ipng@sunroof.eng.sun.com Subject: (IPng 1938) Re: BSD API draft 5 question In-Reply-To: Your message of "Thu, 11 Jul 1996 10:51:25 +0100 (BST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.28.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 11 Jul 1996 12:13:52 +0200 Message-Id: <2252.837080032@verdi.nethelp.no> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > PS: I can't get mail direct just to you at noao .. our firewall sits dropping > ident requests and our mailer waits ages for a response then times out. (The following is *not* meant to start the ident war again, please!) If you don't want to run ident on your internal hosts, it may be a good idea to run a fake identd on your mail hub - whose only purpose is to answer 'UNKNOWN ERROR'. And of course let ident requests for this host through the firewall. That way ident requests are answered, and you avoid the timeouts, but no useful information is returned. I run such a fake identd on my own mail server. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 05:20:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12752; Thu, 11 Jul 96 05:20:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12746; Thu, 11 Jul 96 05:20:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA11664; Thu, 11 Jul 1996 05:16:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA26704; Thu, 11 Jul 1996 05:16:05 -0700 Received: from morgan.cnu.edu (morgan.cnu.edu [137.155.12.216]) by morgan.cnu.edu (8.7.3/8.6.9) with SMTP id IAA12099; Thu, 11 Jul 1996 08:15:34 -0400 (EDT) Date: Thu, 11 Jul 1996 08:15:33 -0400 (EDT) From: "J. Patrick Narkinsky" To: Alan Cox Cc: rstevens@noao.edu, cmetz@inner.net, ipng@sunroof.eng.sun.com Subject: (IPng 1939) Re: BSD API draft 5 question In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 11 Jul 1996, Alan Cox wrote: > > Are there different services that use the same port, one for TCP > > and one for UDP? > > Yes > > exec 512/tcp > biff 512/udp comsat > login 513/tcp > who 513/udp whod > shell 514/tcp cmd # no passwords used > syslog 514/udp > How bout a couple that are not BSD-isms? time 37/tcp timserver time 37/udp timserver domain 53/udp domain 53/tcp echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null daytime 13/tcp daytime 13/udp My understanding is that the UDP and TCP ports are totally seperate entities. I.e. A connection is specified by: Local IP Remote IP Local Port Remote Port Layer 4 protocol (i.e. UDP/TCP) So, while I haven't tried it, I strongly suspect that you could run a UDP daemon on say port 25 and not step on anything. Patrick --------------------------------------------------------------------------- J. Patrick Narkinsky | | Over the router, through the bridge, Comp. Systems Sr. Engineer | past the T1, bounce off MAE-East, CNU Computer Center | nothing but net. (804)594-7180 | --------------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 06:19:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12791; Thu, 11 Jul 96 06:19:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12785; Thu, 11 Jul 96 06:19:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA16969; Thu, 11 Jul 1996 06:15:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA07820; Thu, 11 Jul 1996 06:15:20 -0700 Received: from ftp.com by ftp.com ; Thu, 11 Jul 1996 09:14:03 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 11 Jul 1996 09:14:03 -0400 Received: by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id JAA11696; Thu, 11 Jul 1996 09:13:48 -0400 Date: Thu, 11 Jul 1996 09:13:48 -0400 Message-Id: <199607111313.JAA11696@MAILSERV-2HIGH.FTP.COM> To: pferguso@cisco.com Subject: (IPng 1940) Re: Default Hop Limit From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: matt@lkg.dec.com, kasten@ftp.com, ipng@sunroof.eng.sun.com Repository: mailserv-2high.ftp.com, [message accepted at Thu Jul 11 09:13:39 1996] Originating-Client: d-cell.ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I honestly admit that I simply cannot envision a router-to-router > auto-configuration mechanism. i can envision it (though people have called me worse than warped...). i have envisioned it. i have periodically spent a great deal of time thinking about how you could build a 'set' of self- organizing routers so that they could figure out what subnets they are attached to, assign net numbers/masks accordingly, determine hop-counts, etc. the ieee802 spanning tree bridging technology does many of the fundamental things. it determines a least-cost spanning tree over an arbitrary topology. you probably could use a similar technique to have all the routers talk to their neighbors and deduce a similar spanning tree over the ip internet and then use that tree structure to start assigning network numbers/masks. the big stumbling block seems to be settling time for the algorithm. brian carpenter recently suggested that the way around this is to divide up the network into "easily settlable" chunks. it probably would work, but it still requires smart humans to figure out where those chunks are. i like to think big. i'd like to figure out how to make the entire internet self-organize. (i just need to find more spare time -- i keep ordering some from the stock room but it's always backordered. sigh.) > > - paul > > At 05:47 PM 7/10/96 +0000, Matt Thomas wrote: > > > > >My own (possibly warped) view is that IPv6 could really use a > >router-to-router configuration protocol to handle this type of > >issue. (the border router(s) learn the hop count from the provider, > >adjust it up if needed, and then this gets propogated to other > >routers in the intranet being compensated by the number of hops from > >the border routers). Or whatever. > > > >Just punting on the hop limit and setting it to 255 is stupid. > >We have a mechanism with which we can update the hosts. Now > >get another mechanism for the routers (and I am not volunteering!). > -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 07:49:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12910; Thu, 11 Jul 96 07:49:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12904; Thu, 11 Jul 96 07:48:57 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA28258; Thu, 11 Jul 1996 07:44:44 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA06355; Thu, 11 Jul 1996 07:44:40 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0873; Thu, 11 Jul 96 10:44:40 EDT Received: by RTP (XAGENTA 4.0) id 7856; Thu, 11 Jul 1996 10:44:27 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17664; Thu, 11 Jul 1996 10:43:36 -0400 Message-Id: <9607111443.AA17664@cichlid.raleigh.ibm.com> To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1941) Re: Default Hop Limit In-Reply-To: Your message of "Wed, 10 Jul 1996 16:59:57 PDT." <199607102359.QAA29885@puli.cisco.com> Date: Thu, 11 Jul 1996 10:43:35 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran Atkinson writes: >Note that if we simply picked 255 then we'd be no worse off than today's IPv4 >Internet. Not so fast. A quick test among machines I have easy access to and can identify shows that all of the following OS types use a TTL of 64ish: AIX, Linux, FreeBSD, VM, and OS2. Interestingly enough, Windows 95 uses a TTL of 32. The above was determined using tcpdump and opening a TCP connection to the machines in question. Don't be confused by ICMP TTLs. Some of the above machines use 255 TTLs in answering pings. Can anyone identify machines that really do use a TTL of > 64? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 08:24:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12965; Thu, 11 Jul 96 08:24:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12959; Thu, 11 Jul 96 08:24:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA03995; Thu, 11 Jul 1996 08:19:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA21559; Thu, 11 Jul 1996 08:19:43 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA32656; Fri, 12 Jul 1996 01:19:23 +1000 (from kre@munnari.OZ.AU) To: "Thomas Narten" Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 1942) Re: Default Hop Limit In-Reply-To: Your message of "Thu, 11 Jul 1996 10:43:35 -0300." <9607111443.AA17664@cichlid.raleigh.ibm.com> Date: Fri, 12 Jul 1996 01:19:23 +1000 Message-Id: <20485.837098363@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 11 Jul 1996 10:43:35 -0300 From: "Thomas Narten" Message-ID: <9607111443.AA17664@cichlid.raleigh.ibm.com> Can anyone identify machines that really do use a TTL of > 64? The only one I could find here was Solaris 2.5. Everything else I tested (Digital Unix, BSDi, SunOS, IRIX) uses either 60 or 64. Solaris seems to be 255. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 08:55:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12990; Thu, 11 Jul 96 08:55:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12984; Thu, 11 Jul 96 08:55:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08847; Thu, 11 Jul 1996 08:50:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA03860; Thu, 11 Jul 1996 08:50:34 -0700 Received: from pferguso-pc.cisco.com (c1robo2.cisco.com [171.68.13.2]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id IAA12323; Thu, 11 Jul 1996 08:50:25 -0700 Message-Id: <199607111550.IAA12323@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Jul 1996 11:49:24 -0400 To: Scott Bradner From: Paul Ferguson Subject: (IPng 1943) Re: Default Hop Limit Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, even though I can't foresee it happening certainly doesn't mean that its not possible. :-) Given enough thought & resources, anything is possible. I'm just wondering if it would be complexity-in-excess; too much so to actually be practical. But I digress. I'm certainly interested in discussions in this venue. - paul At 10:34 PM 7/10/96 -0400, Scott Bradner wrote: >> I honestly admit that I simply cannot envision a router-to-router >> auto-configuration mechanism. > >well, I must have a better imagination cuz I can & I feel that >in the long run we need to be able to do just that. I can envision >an environment where your border router gets a (secure) message >from your ISP telling you to renumber and your border routers forward that >request on to your internal routers ... I can also envision an environment >where your routers scale the subnet size based on the number of "nodes" >at the same level in the architectural hierarchy and reconfigure based >on that - communicating betwen themselves in the process. > >Scott > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 09:04:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13006; Thu, 11 Jul 96 09:04:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13000; Thu, 11 Jul 96 09:03:55 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA10110; Thu, 11 Jul 1996 08:59:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA07681; Thu, 11 Jul 1996 08:59:30 -0700 Received: from pferguso-pc.cisco.com (c1robo2.cisco.com [171.68.13.2]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id IAA16417; Thu, 11 Jul 1996 08:59:55 -0700 Message-Id: <199607111559.IAA16417@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Jul 1996 11:58:56 -0400 To: bound@zk3.dec.com From: Paul Ferguson Subject: (IPng 1944) Re: Default Hop Limit Cc: Matt Thomas , kasten@ftp.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not sure -- at least I haven't given it enough thought to the point that it appears practical. I had been meaning to respond to an earlier message from Quaizar Vohra on transition issues, with regards to renumbering issues. Brian Carpenter and I had briefly discussed a couple of issues on this in relationship to a draft that I have been working on for PIER, which contrasts the NGTRANS agreed upon method of transitioning networks by running dual IPv4/IPv6 stacks. Not to dredge up topics already discussed, but this doesn't seem quite practical to me, at least in all circumstances. I suggested that in some instances, it may be more practical to use a IPv4/IPv6 NAT-like device, and negate the need for dual stacks, which many organizations may not be able to accommodate. As Scott already suggested, any router-to-router auto-config protocol would have to be *highly* secure, and due to anticipated performance impact, could only be deployed in a limited scope, methinks. Its an interesting concept, no doubt. ;-) - paul At 10:29 PM 7/10/96 -0400, bound@zk3.dec.com wrote: >Paul, > >>I honestly admit that I simply cannot envision a router-to-router >>auto-configuration mechanism. > >What about an administration protocol to do what Matt suggests? >I think we need it for renumbering anyway????? > >/jim > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 10:03:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13089; Thu, 11 Jul 96 10:03:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13082; Thu, 11 Jul 96 10:03:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA21472; Thu, 11 Jul 1996 09:59:14 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id JAA01041; Thu, 11 Jul 1996 09:58:01 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA23153; Thu, 11 Jul 1996 12:40:34 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA02485; Thu, 11 Jul 1996 12:40:27 -0400 Message-Id: <9607111640.AA02485@fwasted.zk3.dec.com> To: Paul Ferguson Cc: bound@zk3.dec.com, Matt Thomas , kasten@ftp.com, ipng@sunroof.eng.sun.com Subject: (IPng 1945) Re: Default Hop Limit In-Reply-To: Your message of "Thu, 11 Jul 96 11:58:56 EDT." <199607111559.IAA16417@lint.cisco.com> Date: Thu, 11 Jul 96 12:40:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, >I'm not sure -- at least I haven't given it enough thought to the point >that it appears practical. I had been meaning to respond to an earlier >message from Quaizar Vohra on transition issues, with >regards to renumbering issues. Brian Carpenter and I had briefly discussed >a couple of issues on this in relationship to a draft that I have been >working on for PIER, which contrasts the NGTRANS agreed upon method of >transitioning networks by running dual IPv4/IPv6 stacks. Not to dredge up >topics already discussed, but this doesn't seem quite practical to me, at >least in all circumstances. I suggested that in some instances, it may be >more practical to use a IPv4/IPv6 NAT-like device, and negate the need for >dual stacks, which many organizations may not be able to accommodate. We in IPng are not going to support NAT as a means for Transition (at least without a major battle from me and lots of other people) but clearly if one wants to use NAT as a means a spec on it is certainly an interesting approach. The NGTRANS spec works and I am testing it now with real customers and I am getting no heart burn. I agree with Ran's recent suggestion to not contain route entries for v4-compatible addresses or to route them as IPv6 addresses. But that does not alter Quaizar's reiteration for Transition. The sending rules in the NGTRANS draft need to be updated but they work in real life and at the UNH Interoperability events with at least 8 host vendors and 3 router vendors who have IPv6 RUNNING CODE right now. So I am not speaking from theory at this point but practice. I would be interested in your thinking on this and why we may need to update our thinking but I would imagine thats more than a paragraph and most likely should be done on the NGTRANS list. I am glad your thinking about this as we need to get it right like right now. But this was discussed at length on NGTRANS and Big-I (which I found pretty useless on Big-I). I just don't want to revinvent the wheel without some logic check though. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 10:19:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13144; Thu, 11 Jul 96 10:19:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13138; Thu, 11 Jul 96 10:18:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA24556; Thu, 11 Jul 1996 10:14:43 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA07367; Thu, 11 Jul 1996 10:13:50 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id NAA02119; Thu, 11 Jul 1996 13:12:57 -0400 (EDT) Message-Id: <199607111712.NAA02119@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Ran Atkinson Cc: ipng@sunroof.eng.sun.com, matt@lkg.dec.com Subject: (IPng 1946) Re: Default Hop Limit In-Reply-To: Your message of "Wed, 10 Jul 1996 16:59:57 PDT." <199607102359.QAA29885@puli.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 11 Jul 1996 13:12:51 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran Atkinson writes: > Internet doesn't seem to have any major problem with the use of 255 > as the default TTL. So let me try to emulate Yakov and ask "what > current observable real world operational problem are we trying to > solve with a TTL less than 255 ?". Actually the default TTL is 64 or so in IPv4 (32 in Win95 -- sigh). It does, in fact, cut off routing loops quickly, and I can think of many a network that would be far worse off without that. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 10:19:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13151; Thu, 11 Jul 96 10:19:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12313; Wed, 10 Jul 96 19:53:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA24357; Wed, 10 Jul 1996 19:49:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA29278; Wed, 10 Jul 1996 19:49:14 -0700 Received: from sex.syd.dms.CSIRO.AU by dmssyd.syd.dms.CSIRO.AU (4.1/5.17) id AA23702; Thu, 11 Jul 96 12:49:12 EST (from Mark.Andrews@dms.csiro.au (Mark Andrews)) Message-Id: <9607110249.AA23702@dmssyd.syd.dms.CSIRO.AU> To: ipng@sunroof.eng.sun.com Subject: (IPng 1947) Re: Default Hop Limit In-Reply-To: Your message of "Wed, 10 Jul 1996 22:29:03 -0400." <9607110229.AA12966@fwasted.zk3.dec.com> Date: Thu, 11 Jul 1996 12:49:11 +1000 From: Mark Andrews Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Paul, > > >I honestly admit that I simply cannot envision a router-to-router > >auto-configuration mechanism. > > What about an administration protocol to do what Matt suggests? > I think we need it for renumbering anyway????? > > /jim > If we want to be able to renumber a continent we need something like this. Mark -- Mark Andrews, CSIRO Div Maths & Stats Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au MOBIL: +61 41 942 9884 UUCP:....!uunet!syd.dms.csiro.au!marka ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 10:29:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13169; Thu, 11 Jul 96 10:29:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12931; Thu, 11 Jul 96 08:08:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA01574; Thu, 11 Jul 1996 08:04:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA15395; Thu, 11 Jul 1996 08:04:26 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id LAA27576; Thu, 11 Jul 1996 11:03:24 -0400 Received: from belushi.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA29226; Thu, 11 Jul 96 11:00:39 EDT Date: Thu, 11 Jul 96 11:00:39 EDT From: mdigioia@BayNetworks.com (Michael DiGioia) Message-Id: <9607111500.AA29226@pobox.BayNetworks.com> To: kasten@ftp.com, pferguso@cisco.com Subject: (IPng 1948) Re: Default Hop Limit Cc: ipng@sunroof.eng.sun.com, matt@lkg.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I honestly admit that I simply cannot envision a router-to-router > > auto-configuration mechanism. > >i can envision it (though people have called me worse than >warped...). i have envisioned it. i have periodically spent a great >deal of time thinking about how you could build a 'set' of self- >organizing routers so that they could figure out what subnets they >are attached to, assign net numbers/masks accordingly, determine >hop-counts, etc. I believe we have the technology, the question, however, can two or more router companies agree to share a pool of resources such as network numbers/masks at config time? The example is the DHCP client/server protocol for IP address. /mpd ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 10:34:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13181; Thu, 11 Jul 96 10:34:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13175; Thu, 11 Jul 96 10:34:08 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA27402; Thu, 11 Jul 1996 10:29:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA13432; Thu, 11 Jul 1996 10:29:49 -0700 Received: from pferguso-pc.cisco.com (c1robo2.cisco.com [171.68.13.2]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id KAA23378; Thu, 11 Jul 1996 10:30:27 -0700 Message-Id: <199607111730.KAA23378@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Jul 1996 13:29:26 -0400 To: Mark Andrews From: Paul Ferguson Subject: (IPng 1949) Re: Default Hop Limit Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:49 PM 7/11/96 +1000, Mark Andrews wrote: > If we want to be able to renumber a continent we need something like > this. > I would suggest that this may be more of a political problem than a technical one. :-/ - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 11:25:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13256; Thu, 11 Jul 96 11:25:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13250; Thu, 11 Jul 96 11:25:02 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA07125; Thu, 11 Jul 1996 11:20:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA05846; Thu, 11 Jul 1996 11:20:01 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) id TAA29071; Thu, 11 Jul 1996 19:14:29 +0100 Date: Thu, 11 Jul 1996 19:14:29 +0100 Message-Id: <199607111814.TAA29071@oberon.di.fc.ul.pt> From: Pedro Roque Marques To: mdigioia@BayNetworks.com (Michael DiGioia) Cc: kasten@ftp.com, pferguso@cisco.com, ipng@sunroof.eng.sun.com, matt@lkg.dec.com Subject: (IPng 1950) Re: Default Hop Limit In-Reply-To: <9607111500.AA29226@pobox.BayNetworks.com> References: <9607111500.AA29226@pobox.BayNetworks.com> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Michael" == Michael DiGioia writes: >> > I honestly admit that I simply cannot envision a >> router-to-router > auto-configuration mechanism. >> i can envision it (though people have called me worse than >> warped...). i have envisioned it. i have periodically spent a >> great deal of time thinking about how you could build a 'set' >> of self- organizing routers so that they could figure out what >> subnets they are attached to, assign net numbers/masks >> accordingly, determine hop-counts, etc. Michael> I believe we have the technology, the question, however, Michael> can two or more router companies agree to share a pool of Michael> resources such as network numbers/masks at config time? Michael> The example is the DHCP client/server protocol for IP Michael> address. I think that SNMP v2 is a good enhough tool to acomplish the degree of "easy configuration" on an AS that i consider resonable. All you need to have is a BasePrefix or ASPrefix variable that can be changed from the management station. This can allow even the distribution of "intelligence" needed on the software, that is the Mgmt station can use that base value to calculate the prefixes that should be configured for every router and distribute them. I think that the current management framework is more appropriate than an auto-router-config protocol would because it models better the trust relations that exist in real world management. You should have an hard time convincing the manager of an AS to configure it's routers announced TTL to some number it receives from a router of an another AS. I think Ran is right, IPv6 routers are already complex to implement. Let's try to reuse the management software that already must be present. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 12:27:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13370; Thu, 11 Jul 96 12:27:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13351; Thu, 11 Jul 96 12:24:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA17878; Thu, 11 Jul 1996 12:20:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAB26738; Thu, 11 Jul 1996 12:20:31 -0700 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id PAA18200; Thu, 11 Jul 1996 15:17:08 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA48852; Thu, 11 Jul 1996 15:16:40 -0400 From: Charlie Perkins Message-Id: <9607111916.AA48852@hawpub1.watson.ibm.com> To: ipng@sunroof.eng.sun.com, svrloc@tgv.com Cc: veizades@home.net, Erik Guttman Subject: (IPng 1951) Service Location draft for IPv6 Date: Thu, 11 Jul 96 15:16:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We're about ready to release a new draft detailing how to implement the Service Location Protocol for IPv6, and a question arises about the general format of the draft. There are two possibilities: 1) A new, short draft which describes the changes needed to the current version of the protocol, with pointers into the current Internet Draft. 2) A self-contained, long draft which incorporates the changes into the body of the specification, and in addition contains Appendix C, which summarizes the changes for people who are already familiar with the current Internet Draft. Both (1) and (2) can be produced with about the same amount of effort, and would be available within a week (probably within a few days). Both (1) and (2), along with conditional selection of text from the master document source, will allow the IPv4 and IPv6 protocol specifications to track each other as need be. We'd like to find out what the preferences are from those people who are likely to be concerned with implementing the protocol. Regards, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 11 17:34:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13630; Thu, 11 Jul 96 17:34:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13624; Thu, 11 Jul 96 17:34:34 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA14690; Thu, 11 Jul 1996 17:30:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA03105; Thu, 11 Jul 1996 17:30:18 -0700 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA08244; Thu, 11 Jul 96 20:30:29 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9607120030.AA08244@wizard.gsfc.nasa.gov> Subject: (IPng 1952) Re: Default Hop Limit To: rja@cisco.com (Ran Atkinson) Date: Thu, 11 Jul 1996 20:30:28 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com, matt@lkg.dec.com In-Reply-To: <199607102359.QAA29885@puli.cisco.com> from "Ran Atkinson" at Jul 10, 96 04:59:57 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Ran Atkinson > > Note that if we simply picked 255 then we'd be no worse off than today's IPv4 > Internet. Today's deployed Internet mostly uses a default TTL of 255 (RFCs to > the contrary not withstanding). I did a quick check on our campus FDDI backbone and here's a breakdown that I saw by ttl for one snapshot of 100000 packets: TTL Count --- ----- 0-64 87558 65-128 289 129-192 135 193-255 12018 I did a second snapshot a couple of hours later with very similar results. So at least in the campus backbone environment, the vast bulk of the traffic is TTL 64 or less. As others indicated, I also checked what various flavors of Unix systems were using and only Solaris systems were using a TTL of 255 among the ones I tested with. I would consider Solaris the equivalent of a polluter. As with pollution, any one polluter might not be that noticeable. And admittedly, most of the time the network works as intended and using too high a TTL doesn't have any deleterious effect. But when there are network routing problems, the Solaris approach is the equivalent of pouring gasoline onto a fire. > Today's Internet doesn't seem to have any > major problem with the use of 255 as the default TTL. So let me try to > emulate Yakov and ask "what current observable real world operational problem > are we trying to solve with a TTL less than 255 ?". I gently suggest that no > observable real-world problem with TTL exists and that this discussion, while > intellectually stimulating, isn't all that useful. One of the great strengths of TCP/IP is its adaptability in the face of network problems. On the flip side, it also tends to mask a lot of problems because of that very adaptability, unless one explicitly looks for the anomalous behavior. The relevant questions should be how often do routing loops form, how long do they tend to last, and would using a TTL of 255 rather than 64 compound the congestion and routing problems. We also can't necessarily extrapolate the future Internet from the current Internet. The tunneling mechanisms that will be used for the transition from IPv4 to IPv6 will possibly introduce a whole new set of problems with unforeseen consequences. Likewise, the ubiquitous deployment of new UDP based applications such as Internet phone and videophone will also have major repercussions that will transform the current nature of the Internet (and may have no mechanism for detecting that packets are being blackholed). And in a purely local environment, when a routing loop does form, the full bandwidth of the link can easily be consumed by packets racing back and forth among a set of high performance routers. There's no need to magnify the problem by a factor of 4. > It WOULD be good if consensus were reached on this TTL question soon though. > I prefer no knobs, no new protocols, and default TTL of 255. Be conservative in what you send. Don't unnecessarily waste resources or unnecessarily magnify problems when they occur. The knob may never have to be increased from 64 and if it ever does, it's really easy to turn the knob. Let's stick with 64. It should last a long time. > Back to coding, > > Ran > rja@cisco.com -Bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Jul 13 19:55:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14633; Sat, 13 Jul 96 19:55:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14627; Sat, 13 Jul 96 19:55:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA18771; Sat, 13 Jul 1996 19:50:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA13261; Sat, 13 Jul 1996 19:50:42 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id WAA02482 for ipng@sunroof.Eng.Sun.COM; Sat, 13 Jul 1996 22:50:52 -0400 (EDT) Date: Sat, 13 Jul 1996 22:50:52 -0400 (EDT) From: Scott Bradner Message-Id: <199607140250.WAA02482@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 1953) Re: Default Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm sure this has been mentioned before but I seem to have missed it from RFC 1700 (Assigned Numbers: ---- IP TIME TO LIVE PARAMETER The current recommended default time to live (TTL) for the Internet Protocol (IP) [45,105] is 64. ---- Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jul 14 04:00:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14825; Sun, 14 Jul 96 04:00:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14819; Sun, 14 Jul 96 04:00:13 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA06180; Sun, 14 Jul 1996 03:55:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA04400; Sun, 14 Jul 1996 03:55:43 -0700 Received: from dos-lan.cs.up.ac.za by inet.up.ac.za with esmtp (Smail3.1.29.1 #5) id m0ufOVI-0001qAC; Sun, 14 Jul 96 12:34 WET Received: from DOS-LAN/SpoolDir by dos-lan.cs.up.ac.za (Mercury 1.21); 14 Jul 96 12:32:49 +0200 Received: from SpoolDir by DOS-LAN (Mercury 1.21); 14 Jul 96 12:32:39 +0200 From: "Naveed Kashif" Organization: University of Pretoria To: ipng@sunroof.eng.sun.com Date: Sun, 14 Jul 1996 12:32:34 CAT-2 Subject: (IPng 1954) Re: IPng software Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <4D5CCD2972@dos-lan.cs.up.ac.za> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Would it be possible for any body to guide me to get the IPng software for Solaris 2.4 and Linux (Slackware 3.0). I saw IPng software on http://playground.sun.com/pub/solaris2- ipv6/html/solaris2-ipv6.html but it is for Solaris 2.5 Regards, Naveed Kashif ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 15 11:39:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15335; Mon, 15 Jul 96 11:39:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA15329; Mon, 15 Jul 96 11:39:17 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA05372; Mon, 15 Jul 1996 11:34:58 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA29657; Mon, 15 Jul 1996 11:34:35 -0700 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id LAA01472 for ipng@sunroof.eng.sun.com; Mon, 15 Jul 1996 11:34:02 -0700 Message-Id: <199607151834.LAA01472@puli.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Mon, 15 Jul 1996 11:34:02 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 1955) Advertised Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This note is not on the topic of the main Hop Limit thread being discussed just now, but it is about Hop Limits. Consider the case of a multi-homed host that is receiving different "Default Hop Limit" values from different Router Advertisements coming from different routers. At the time the host is creating IP packets and filling in the IPv6 header's Hop Limit field, the host implementation does not yet know which outbound interface the packet will leave, so a per-interface variable doesn't help (also see next scenario for another reason a per-interface variable doesn't solve this problem). Which of the conflicting Hop Limit values should the host be using for outbound traffic ? Now consider the case of a single-homed host that is receiving Router Advertisements from more than one router, again with the advertised "Default Hop Limit" values being different. Which of the conflicting Hop Limit values should the host be using for outbound traffic ? The ND spec (page 52, 2nd paragraph from the bottom) implies there is a single node-wide variable and says explicitly that the default hop limit "SHOULD" be set to the value received from the Router Advertisement. Given the scenarios above and the current ND spec, there is some potential for a host to "thrash" back and forth among the various advertised values. For packets having a path above at least one of the advertised values but not above all of the advertised values, this would cause hard-to-diagnose intermittent connectivity problems. This outcome seems undesirable to me. Is the community writing off this issue as one of "network admin shot user in the foot by having an inconsistent configuration" ?? Ran rja@cisco.com -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 15 14:06:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15489; Mon, 15 Jul 96 14:06:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA15483; Mon, 15 Jul 96 14:06:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04224; Mon, 15 Jul 1996 14:01:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA04994; Mon, 15 Jul 1996 14:01:38 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) id VAA00293; Mon, 15 Jul 1996 21:59:58 +0100 Date: Mon, 15 Jul 1996 21:59:58 +0100 Message-Id: <199607152059.VAA00293@oberon.di.fc.ul.pt> From: Pedro Roque Marques To: rja@cisco.com (Ran Atkinson) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1956) Advertised Hop Limit In-Reply-To: <199607151834.LAA01472@puli.cisco.com> References: <199607151834.LAA01472@puli.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Ran" == Ran Atkinson writes: Ran> Given the scenarios above and the current ND spec, there is Ran> some potential for a host to "thrash" back and forth among Ran> the various advertised values. For packets having a path Ran> above at least one of the advertised values but not above all Ran> of the advertised values, this would cause hard-to-diagnose Ran> intermittent connectivity problems. This outcome seems Ran> undesirable to me. Just a clarification request. My reading of the default hop limit value is that should be the value used to initialize the per socket hop limit, meaning this that a change in the default hop limit should not imply any change in the hop limit of open sockets, otherwise it could override an hoplimit that had been selected by the application. Well... actually two clarification requests :-) the general policy on coherency of announcements seams to be "moan heavly" to the syslog, which does require routers to scan through all RAs announced and check the fields... (of course this doesn't eliminate the possible results of inconsistencies such as Ran describes) regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 15 21:18:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15848; Mon, 15 Jul 96 21:18:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA15842; Mon, 15 Jul 96 21:18:12 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA05934; Mon, 15 Jul 1996 21:13:51 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id VAA02438; Mon, 15 Jul 1996 21:13:52 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id AAA31421; Tue, 16 Jul 1996 00:00:10 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19049; Tue, 16 Jul 1996 00:00:06 -0400 Message-Id: <9607160400.AA19049@fwasted.zk3.dec.com> To: rja@cisco.com (Ran Atkinson) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1957) Re: Advertised Hop Limit In-Reply-To: Your message of "Mon, 15 Jul 96 11:34:02 PDT." <199607151834.LAA01472@puli.cisco.com> Date: Tue, 16 Jul 96 00:00:05 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Consider the case of a multi-homed host that is receiving different "Default >Hop Limit" values from different Router Advertisements coming from different >routers. At the time the host is creating IP packets and filling in the IPv6 >header's Hop Limit field, the host implementation does not yet know which >outbound interface the packet will leave, so a per-interface variable doesn't >help (also see next scenario for another reason a per-interface variable >doesn't solve this problem). > > Which of the conflicting Hop Limit values > should the host be using for outbound traffic ? I am not sure I agree with the above premise other than the point where an RA has not yet updated the routing cache (neighbor and discover). Host implemenations can keep interface knowledge in the routing cache and as many will look for a route entry at the transport layer also obtain the interface. I think whether the node is multi or single homed is not the issue. The issue I think is that clearly an RA could come in by the time the host has already built the packet and at that point cohesion is lost in the stack with the RA. Depending on how often this can happen determines the thrashing factor. I have not seen this happen at either one of our UNH Interoperability events and in each case we had 3 segments with multiple subnets and three different routers. In fact we did test getting conflicting information in the RAs in the first event, but we did not watch the thrashing factor. I think the Hop Limit can be kept in the cache too but even if its wrong it should coverge quickly via ND. >The ND spec (page 52, 2nd paragraph from the bottom) implies there is >a single node-wide variable and says explicitly that the default hop >limit "SHOULD" be set to the value received from the Router Advertisement. Page 52 in general implies you should use the values from an RA but if they are unspecified or zero do not change the old value. I take this as an implementation to mean get to the RA data as quick as you can and update your cache (or whereever you want to keep it). >Given the scenarios above and the current ND spec, there is some potential for >a host to "thrash" back and forth among the various advertised values. For >packets having a path above at least one of the advertised values but not >above all of the advertised values, this would cause hard-to-diagnose >intermittent connectivity problems. This outcome seems undesirable to me. I am not convinced this is a solvable problem given my assumptions above. I also don't see this as a "norm" on the network. >Is the community writing off this issue as one of "network admin shot >user in the foot by having an inconsistent configuration" ?? No. Thanks for bringing it up. We should discuss it now. I also think this would be a good test in general for RAs at the next UNH Interoperability Event in Nov 96. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 16 07:14:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16000; Tue, 16 Jul 96 07:14:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA15994; Tue, 16 Jul 96 07:14:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA10651; Tue, 16 Jul 1996 07:10:24 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA02729; Tue, 16 Jul 1996 07:10:23 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id KAA06590; Tue, 16 Jul 1996 10:01:44 -0400 Date: Tue, 16 Jul 1996 10:01:44 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9607161001.ZM6588@seawind.bellcore.com> In-Reply-To: bound@zk3.dec.com "(IPng 1957) Re: Advertised Hop Limit" (Jul 16, 12:00am) References: <9607160400.AA19049@fwasted.zk3.dec.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: bound@zk3.dec.com, rja@cisco.com (Ran Atkinson) Subject: (IPng 1958) Re: Advertised Hop Limit Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Jul 16, 12:00am, bound@zk3.dec.com wrote: > > Which of the conflicting Hop Limit values > > should the host be using for outbound traffic ? Jim, I had a private exchange with Ran on that subject, and I believe that there is a very simple solution. Suppose that you keep two variables: HL, HLAH, the address of the advertizing host. The algorithms goes as follow: 1) Initial: 64 -> HL, 0::0 -> HLAH. 2) Upon reception of an advertizement message for hop limit NHL from host NHLAH: if (NHL > HL){ /* The hop count increased */ NHL -> HL, NHLAH -> HLAH }else if (NHLAH == HLAH){ /* the advertizer changed its mind */ NHL -> HL } You may indeed want to make it more complex, for example check that the advertizing host is an authorized router -- but that is already requirted by autocinfig, right ? -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 16 09:00:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16062; Tue, 16 Jul 96 09:00:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA16056; Tue, 16 Jul 96 09:00:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22448; Tue, 16 Jul 1996 08:56:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA06256; Tue, 16 Jul 1996 08:56:12 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA23975; Tue, 16 Jul 1996 11:37:40 -0400 (EDT) Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA15169; Tue, 16 Jul 1996 11:37:39 -0400 Received: by netrix.lkg.dec.com; (5.65v3.2/1.1.8.2/28May95-0415PM) id AA25480; Tue, 16 Jul 1996 11:37:38 -0400 Date: Tue, 16 Jul 1996 11:37:38 -0400 From: Dan Harrington Message-Id: <9607161537.AA25480@netrix.lkg.dec.com> To: huitema@bellcore.com Subject: (IPng 1959) Re: Advertised Hop Limit Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Christian, > You may indeed want to make it more complex, for example check that the > advertizing host is an authorized router -- but that is already requirted > by autocinfig, right ? Permitted, but not required... The protocol contains no mechanism to determine which neighbors are authorized to send a particular type of message e.g. Router Advertisements; any neighbor, presumably even in the presence of authentication, can send Router Advertisement messages thereby being able to cause denial of service. Furthermore, any neighbor can send proxy Neighbor Advertisements as well as unsolicited Neighbor Advertisements as a potential denial of service attack. Neighbor Discovery protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an Authentication Header when sending Neighbor Discovery packets if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 18 05:36:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17707; Thu, 18 Jul 96 05:36:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17701; Thu, 18 Jul 96 05:36:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA24412; Thu, 18 Jul 1996 05:32:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA22097; Thu, 18 Jul 1996 05:32:08 -0700 Received: from rtpdce01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA171284; Thu, 18 Jul 1996 08:30:18 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id IAA31080; Thu, 18 Jul 1996 08:30:21 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA21318; Thu, 18 Jul 1996 08:30:30 -0400 Message-Id: <9607181230.AA21318@cichlid.raleigh.ibm.com> To: rja@cisco.com (Ran Atkinson) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1960) Re: Advertised Hop Limit In-Reply-To: Your message of "Mon, 15 Jul 1996 11:34:02 PDT." <199607151834.LAA01472@puli.cisco.com> Date: Thu, 18 Jul 1996 08:30:30 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, > Which of the conflicting Hop Limit values > should the host be using for outbound traffic ? This issue has been discussed before. As you point out, the current ND spec simply says use the most recently received value, which leads to the possibility of thrashing, should Router Advertisements be misconfigured. I agree that this is undesirable. The question I pose to you is just what behavior do you want to have happen, and how do you propose to guarantee it? Once one gets into the details of ensuring that the "right choice" is made when conflicting values are available, things quickly get complex. Consider: 1) This issue is relevant to other parameters, not just the Hop Limit (e.g., MTU). It would be nice to have a generic mechanism that handles all advertised quantities the same way rather than rules that are specific to the type of information being advertised. For the Hop Limit, one might want the higher value used; for MTUs one might want the lower value used. 2) You give the example of both a low (incorrect) and high (correct) Hop Limit being advertised, where it is clear that higher one should be used. But what if the higher value was the incorrect one, and the sys admin has now gone and fixed all the advertisements, so the lower one is the correct value. When will the higher (incorrect) value time out? The proposed solution: > 1) Initial: > 64 -> HL, > 0::0 -> HLAH. > 2) Upon reception of an advertizement message for hop limit NHL > from host NHLAH: > if (NHL > HL){ > /* The hop count increased */ > NHL -> HL, > NHLAH -> HLAH > }else if (NHLAH == HLAH){ > /* the advertizer changed its mind */ > NHL -> HL > } also has scenarios that don't work quite right. Consider, for example, R1 and R2 advertising low and high values respectively. The high value from R2 wins. Suppose R2 now dies never to rise again (it was a machine that should never have been turned on as a router). Is the high value used forever? When does it "time out"? It would be counterintuitive at best for Router Advertisements advertising correct information to be ignored. 3) Another possible approach is to associate Lifetimes with each advertised value. But then you also have to deal with the case where a value's Lifetime expires. Do you also have to keep around other potential (different) values to fall back on? Or do you wait until the next Router Advertisement (which in the worst case can be some 30 minutes later)? The former adds more implementation complexity. The latter leaves open scenarios where routers are advertising proper values, but they aren't being used as expected. IMO, the additional complexity just isn't worth the hassle. Inconsistent advertisements could be easily handled by a daemon whose sole job in life is to listen to Router Advertisements looking for inconsistencies. When a serious one occurs, it notifies the system administrator. huitema@bellcore.com (Christian Huitema) writes: >You may indeed want to make it more complex, for example check that the >advertizing host is an authorized router -- but that is already requirted >by autocinfig, right ? If you know of a way for an arbitrary node (say a host) to know whether some other arbitrary node (say a router) is authorized to send a particular piece of information (say as part of a Router Advertisement), the IPSec community would love to hear from you. :-) Seriously, this is a problem way outside of the scope of what Neighbor Discovery can do. Given that ND can use IPSec, however, one has the ability to ignore all RAs from nodes that don't include an AH, providing the mechanism for determining which routers are authorized (i.e., those that send RAs that can be properly authenticated). The trust/authorization issue would be handled via the setting up of SPIs. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 18 06:01:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17736; Thu, 18 Jul 96 06:01:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17730; Thu, 18 Jul 96 06:01:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA25981; Thu, 18 Jul 1996 05:57:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA29560; Thu, 18 Jul 1996 05:57:14 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07406; 18 Jul 96 8:49 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1961) Protocol Action: IP Version 6 over PPP to Proposed Standard Date: Thu, 18 Jul 96 08:49:03 -0400 Message-Id: <9607180849.aa07406@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft "IP Version 6 over PPP" as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. Technical Summary This document defines the method for transmission of IP Version 6 packets over PPP links as well as the Network Control Protocol for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This protocol has been reviewed by Frank Kastenholz and Jeffrey Burgan of the IESG. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 18 06:11:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17755; Thu, 18 Jul 96 06:11:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17749; Thu, 18 Jul 96 06:11:34 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA26948; Thu, 18 Jul 1996 06:07:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA02735; Thu, 18 Jul 1996 06:07:11 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07688; 18 Jul 96 9:00 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1962) Protocol Action: A Method for the Transmission of IPv6 Packets over FDDI Networks to Proposed Standard Date: Thu, 18 Jul 96 09:00:49 -0400 Message-Id: <9607180900.aa07688@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft "A Method for the Transmission of IPv6 Packets over FDDI Networks" as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This memo specifies the MTU and frame format for transmission of IPv6 packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in IPv6 Neighbor Discovery when those messages are transmitted on an FDDI network. Working Group Summary Working Group Last-Call produced no issues with this proposal. The document was revised based on comments received during IESG consideration. Protocol Quality This document was reviewed for the IESG by Scott Bradner and Allison Mankin. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 18 07:22:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17789; Thu, 18 Jul 96 07:22:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17783; Thu, 18 Jul 96 07:21:48 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA02680; Thu, 18 Jul 1996 07:17:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA28121; Thu, 18 Jul 1996 07:17:25 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09068; 18 Jul 96 10:10 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1963) Document Action: OSI NSAPs and IPv6 to Experimental Date: Thu, 18 Jul 96 10:10:08 -0400 Message-Id: <9607181010.aa09068@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has reviewed the Internet-Draft "OSI NSAPs and IPv6" and recommends that it be published by the RFC Editor as an Experimental RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 18 07:59:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17810; Thu, 18 Jul 96 07:59:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17804; Thu, 18 Jul 96 07:59:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA07514; Thu, 18 Jul 1996 07:55:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA12615; Thu, 18 Jul 1996 07:54:10 -0700 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA02861; Thu, 18 Jul 96 09:59:42 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA07168; Thu, 18 Jul 96 09:56:47 CDT Date: Thu, 18 Jul 96 09:56:47 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9607181456.AA07168@anubis.network.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1964) Re: Advertised Hop Limit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You can take the point of view that hop limits are routing information (roughly, a very terse summary of the network beyond whoever is advertising -- 'this is the max length of the shortest path in the graph out thataway'). If it's routing data, manage it as such. Or, just nail it to 255, and move on to real problems. Andrew ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 18 09:35:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17935; Thu, 18 Jul 96 09:35:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17929; Thu, 18 Jul 96 09:35:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA21715; Thu, 18 Jul 1996 09:30:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA15264; Thu, 18 Jul 1996 09:30:17 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA01051; Thu, 18 Jul 96 12:24:53 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9607181624.AA01051@iol.unh.edu> Subject: (IPng 1965) v4-compatible addresses To: ipng@sunroof.eng.sun.com (ipng) Date: Thu, 18 Jul 1996 12:24:52 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi everyone, I was trying to set up a test network in the Lab. to connect to the 6-bone. I found a problem with IPv4-compatible addresses. I had the following configuration. HOST1 - has tunneling disabled, but is using IPv4-compatible IPv6 address on its ethernet interface thru which it is connected to router RTR, which is acting as its default router too. RTR - has a tunnel configured to HOST2 which is on another link, connected via ipv4-routing to RTR1 (HOST1 is acting as a tunnel endpoint on the v6-bone, for the weird reason that it is the only implementation which handles tunneling and routing well. RTR is configured with a default route ::/0, with next hop as the tunnel end-point, i.e. HOST1's v4 compatible address.) HOST2 - acts as a tunnel end-point for the tunnel mentioned above. Since its doing tunneling, it has a route ::0.0.0.0/96 ( which is useful for auto-tunnels as well as configuring tunnel end-points for routing to distant v6 subnets, i.e. accessible via an intermediate v4 routing infrastructure) Now I send an echo-request from HOST1 to HOST2's v4-compatible address. HOST1 chooses source address as its v4-compatible address ( as it has one on its ethernet interface connecting it to RTR). But since it is not doing tunneling, it solicits RTR and sends v6 packets to RTR. RTR encapsulates the packet and forwards it to HOST2. HOST2 gets the packet, decapsulates it and replies. Now since the dest. for the reply is HOST1's v4-compatible address, it matches the ::0.0.0.0/96 route on HOST2. HOST2 now does auto-tunneling directly to HOST1, encapsulating the reply in a IPv4 packet with IPv4-dest. as HOST1's IPv4 address. HOST1 receives the IPv4 packet, but since its tunneling interface is not up, it drops the packet. So the questions are : Should an interface be assigned a v4-compatible address if it happens to have a IPv4 address on that interface, if it is not tunneling ? I think no ( read my previous mail on transition policy). Or should v4 stack pass encapsulated packets to v6 stack even if its tunneling interface is not up ? I think no (read my previous mail on transition policy). In fact, let me be bold enough to suggest that there should be no v4-compatible addresses in IPv6 for atleast the purpose of transition. Currently we use them to identify next-hops in routes which are accessible via a tunnel, and the tunnel end-point acting as the next-hop, or for getting to isolated IPv6/IPv4 hosts. In first place configured tunnels are useful in routing v6 over v4, and identifying the end-points with IPv6 addresses might be useful for routing protocols. Where else ? So why not identify with global IPv6 addresses (not v4-compatible addresses). Or why identify at all. Let them be unnumbered point to point interfaces, with v4 link-layer addresses. OSPF has a notion of such unnumbered point-to-point interfaces ( I am not an expert in OSPF ). Secondly, I think auto-tunnels should be discouraged to the point of extinction, i.e. there should be no auto-tunneling mechanism. We need auto-tunnels to reach isolated v6/v4 hosts, with v4-compatible addresses. If we force all isolated hosts to use global IPv6 addresses (or experimental global addresses now), and forcing them to configure tunnels to the nearest v6/v4 router. Note that only the nearest v6/v4 router needs to configure the reverse tunnel. Rest it propagates routes for this host elsewhere. If the argument is that there might be too many routes to propagate, then let me say that auto-tunneling and v4-compatible addresses won't prevent that, as these routes will have to be propagated to pure v6 domains (which are eventually going to surface on this globe at some future point of time and then you'll have to propagate routes to all isolated v4-compatible addresses in these domains). This whole argument of route propagation is stupid. No one should propagate any such routes, let default routes leading to v4/v6 tunneling router take care of this. Also I think isolated hosts must get global addresses from their IPv6 internet service providers, and help in hierarchical routing. Only the ISP router needs to know of the existence of subscribing domains with isolated IPv6/IPv4 hosts. If a subscribing domain has several isolated hosts, then it should take care of configuring tunnels among its isolated hosts, and advertise only one tunnel to the ISP ( or rather configure one tunnel with the ISP's router) and take care of routing to the other isolated v6/v4 hosts. If we allow v4-compatible addresses to be used as global v6 addresses, existing v4 networks might upgrade to v6 using v4-compatible addresses, and never go to ISPs or registries for actual IPv6 addresses. There goes the whole benefit of hierarchical routing so much envisioned for IPv6, degenerating into a stupid v4 routing topology. Quaizar -- ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 22 03:33:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20512; Mon, 22 Jul 96 03:33:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA20506; Mon, 22 Jul 96 03:33:09 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA24789; Mon, 22 Jul 1996 03:28:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA12497; Mon, 22 Jul 1996 03:28:41 -0700 Received: from matisse (matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with SMTP id MAA14015 for ; Mon, 22 Jul 1996 12:00:11 +0200 Date: Mon, 22 Jul 1996 12:00:11 +0200 Message-Id: <199607221000.MAA14015@ibp.ibp.fr> X-Sender: eh@hera.ibp.fr X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: "Eric HORLAIT (MASI-CNRS)" Subject: (IPng 1966) IPv6 and routing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is there a special (reserved) multicast address for routers in IPv6, as there is one in IPv4? ---------------------- Professeur Eric HORLAIT ------------------------ Universite Pierre et Marie Curie Tel: 33-1-44-27-73-83 Institut Blaise Pascal - Labo MASI Fax: 33-1-44-27-62-86 4, place Jussieu e-mail: Eric.Horlait@masi.ibp.fr 75252 PARIS Cedex 05 Telex: UPMCSIX 200-145 F http://www-masi-net.ibp.fr/~eh ----------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 22 08:53:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20682; Mon, 22 Jul 96 08:53:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA20676; Mon, 22 Jul 96 08:53:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA18437; Mon, 22 Jul 1996 08:48:58 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA13990; Mon, 22 Jul 1996 08:48:56 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id IAA03292; Mon, 22 Jul 1996 08:48:13 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: In-Reply-To: <199607221000.MAA14015@ibp.ibp.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jul 1996 08:50:18 -0700 To: "Eric HORLAIT (MASI-CNRS)" From: Bob Hinden Subject: (IPng 1967) Re: IPv6 and routing Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, >Is there a special (reserved) multicast address for routers in IPv6, as >there is one in IPv4? >From RFC-1884, "IP Version 6 Addressing Architecture": All Routers Addresses: FF01:0:0:0:0:0:0:2 FF02:0:0:0:0:0:0:2 The above multicast addresses identify the group of all IPv6 routers, within scope 1 (node-local) or 2 (link-local). Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 23 18:00:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21889; Tue, 23 Jul 96 18:00:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA21883; Tue, 23 Jul 96 18:00:38 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA27473; Tue, 23 Jul 1996 17:56:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA29290; Tue, 23 Jul 1996 17:56:07 -0700 Received: from borg.mindspring.com (borg.mindspring.com [204.180.128.14]) by answerman.mindspring.com (8.6.12/8.6.12) with ESMTP id UAA27504 for ; Tue, 23 Jul 1996 20:56:06 -0400 Received: from sthomas.mindspring.com (user-168-121-37-118.dialup.mindspring.com [168.121.37.118]) by borg.mindspring.com (8.6.12/8.6.12) with SMTP id UAA29041 for ; Tue, 23 Jul 1996 20:56:03 -0400 Message-Id: <2.2.32.19960724005516.0068c6dc@mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 23 Jul 1996 20:55:16 -0400 To: ipng@sunroof.eng.sun.com From: Stephen Thomas Subject: (IPng 1968) Token Ring draft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng Folks: Now that the FDDI draft seems to be fairly settled, it seems time to tackle the Token Ring issue. The adjacency detection approach of FDDI (overloading the MAC layer priority field) seems to be more than a little unpopular with the 802.5 representatives. Not representing a Token Ring vendor myself, I can only speculate that perhaps those vendors have plans for using that priority field in other ways. (Multimedia traffic comes to mind.) With that, would it be inappropriate to once again ask for a working group last call on the existing draft? (draft-ietf-ipngwg-token-ring-01.txt) That draft, by specifying a default MTU of 1500 bytes, maintains interoperability over mixed-media, bridged LANs at the cost of some performance. --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 24 18:22:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22551; Wed, 24 Jul 96 18:22:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA22545; Wed, 24 Jul 96 18:22:37 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13235; Wed, 24 Jul 1996 18:18:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA12716; Wed, 24 Jul 1996 18:18:02 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id SAA25868; Wed, 24 Jul 1996 18:17:17 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: In-Reply-To: <2.2.32.19960724005516.0068c6dc@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 1996 18:19:26 -0700 To: Stephen Thomas From: Bob Hinden Subject: (IPng 1969) Re: Token Ring draft Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen, >With that, would it be inappropriate to once again ask for >a working group last call on the existing draft? >(draft-ietf-ipngwg-token-ring-01.txt) That draft, by specifying >a default MTU of 1500 bytes, maintains interoperability over >mixed-media, bridged LANs at the cost of some performance. Are there examples of Token_Ring<->Ethernet and/or TokenRing<->FDDI bridges in widespread use? For the FDDI spec we decided that FDDI<->Ethernet bridges were very common and that it was important to deal with them in a reasonable way. I am not sure how important these issues are for token ring bridges. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 24 18:58:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22615; Wed, 24 Jul 96 18:58:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA22609; Wed, 24 Jul 96 18:58:02 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA17463; Wed, 24 Jul 1996 18:53:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA20412; Wed, 24 Jul 1996 18:53:30 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id VAA21396; Wed, 24 Jul 1996 21:53:37 -0400 (EDT) Date: Wed, 24 Jul 1996 21:53:37 -0400 (EDT) From: Scott Bradner Message-Id: <199607250153.VAA21396@newdev.harvard.edu> To: hinden@Ipsilon.COM, sthomas@mindspring.com Subject: (IPng 1970) Re: Token Ring draft Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > re there examples of Token_Ring<->Ethernet IBM 8209, Cisoc routers running in 8209 mode .... yes - they are in wide use Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 24 19:06:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22633; Wed, 24 Jul 96 19:06:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA22624; Wed, 24 Jul 96 19:04:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA18128; Wed, 24 Jul 1996 19:00:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA21660; Wed, 24 Jul 1996 19:00:11 -0700 Received: from borg.mindspring.com (borg.mindspring.com [204.180.128.14]) by answerman.mindspring.com (8.6.12/8.6.12) with ESMTP id WAA18167; Wed, 24 Jul 1996 22:00:10 -0400 Received: from sthomas.mindspring.com (user-168-121-37-118.dialup.mindspring.com [168.121.37.118]) by borg.mindspring.com (8.6.12/8.6.12) with SMTP id WAA05655; Wed, 24 Jul 1996 22:00:06 -0400 Message-Id: <2.2.32.19960725015918.0069a34c@mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 1996 21:59:18 -0400 To: Bob Hinden From: Stephen Thomas Subject: (IPng 1971) Re: Token Ring draft Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:19 PM 7/24/96 -0700, Bob Hinden wrote: >Are there examples of Token_Ring<->Ethernet and/or TokenRing<->FDDI bridges >in widespread use? For the FDDI spec we decided that FDDI<->Ethernet >bridges were very common and that it was important to deal with them in a >reasonable way. I am not sure how important these issues are for token >ring bridges. Based on both my own experience and others' in 802.5 there doesn't seem to be a big demand for Token Ring<->anything today. I suspect, though, that Fast Ethernet and especially Gigabit Ethernet may convince a few Token Ring shops to move to an Ethernet backbone. There's also the possibility of 100VG-AnyLAN eeking out an existance in combined Ethernet and Token Ring environments. Is your question raising the possibility of defaulting the Token Ring MTU to ~4500 bytes instead of 1500 and forcing either RAs or manual configuration to override to 1500 in a mixed environment? If so, the idea certainly has merit. My own preference is to err on the side of interoperability rather than performance, but I'm happy to put either in the draft based on the working group's feelings. --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 24 19:26:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22667; Wed, 24 Jul 96 19:26:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA22653; Wed, 24 Jul 96 19:24:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA20066; Wed, 24 Jul 1996 19:20:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA25277; Wed, 24 Jul 1996 19:20:27 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.3/8.6.10-MT4.00) id WAA21497; Wed, 24 Jul 1996 22:20:33 -0400 (EDT) Date: Wed, 24 Jul 1996 22:20:33 -0400 (EDT) From: Scott Bradner Message-Id: <199607250220.WAA21497@newdev.harvard.edu> To: hinden@Ipsilon.COM, sthomas@mindspring.com Subject: (IPng 1972) Re: Token Ring draft Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Based on both my own experience and others' in 802.5 there doesn't seem > to be a big demand for Token Ring<->anything today. This is counter to my own experience - there are many large token ring networks where ineroperation with new 10BaseT nets is required Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 25 05:53:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22987; Thu, 25 Jul 96 05:53:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA22981; Thu, 25 Jul 96 05:53:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA27321; Thu, 25 Jul 1996 05:48:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA20354; Thu, 25 Jul 1996 05:48:39 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) id NAA08917; Thu, 25 Jul 1996 13:47:12 +0100 Date: Thu, 25 Jul 1996 13:47:12 +0100 Message-Id: <199607251247.NAA08917@oberon.di.fc.ul.pt> From: Pedro Roque Marques To: ipng@sunroof.eng.sun.com Subject: (IPng 1973) Bad source address ICMP ? Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When a router receives a packet to forward and the source address is link local should it send an ICMP after discarding the packet ? RFC 1885 say yes: "A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (An ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion.)" Now the problem is what code to pick for the ICMP... Code 2, "not a neighbor" would be a candidate but it's current meaning is quite different. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 25 06:20:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23018; Thu, 25 Jul 96 06:20:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23012; Thu, 25 Jul 96 06:20:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29464; Thu, 25 Jul 1996 06:15:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA26021; Thu, 25 Jul 1996 06:15:47 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id PAA26363; Thu, 25 Jul 1996 15:15:45 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id PAA24313; Thu, 25 Jul 1996 15:15:44 +0200 (MET DST) Message-Id: <199607251315.PAA24313@givry.inria.fr> From: Francis Dupont To: Pedro Roque Marques Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1974) Re: Bad source address ICMP ? In-Reply-To: Your message of Thu, 25 Jul 1996 13:47:12 BST. <199607251247.NAA08917@oberon.di.fc.ul.pt> Date: Thu, 25 Jul 1996 15:15:29 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: When a router receives a packet to forward and the source address is link local should it send an ICMP after discarding the packet ? RFC 1885 say yes: "A Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (An ICMPv6 message MUST NOT be generated if a packet is dropped due to congestion.)" => I believe it is the same case for multicast packets (ie with multicast destination or received via link-layer multicast). The RFC 1883 suggests to simply drop the packet (see the forwarding algorithm for routing header). Now the problem is what code to pick for the ICMP... Code 2, "not a neighbor" would be a candidate but it's current meaning is quite different. => parameter problem (:-) ? Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 25 06:35:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23038; Thu, 25 Jul 96 06:35:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23032; Thu, 25 Jul 96 06:35:24 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00999; Thu, 25 Jul 1996 06:30:52 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA00936; Thu, 25 Jul 1996 06:30:52 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id JAA14177; Thu, 25 Jul 1996 09:32:24 -0400 Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA05466; Thu, 25 Jul 96 09:29:29 EDT Date: Thu, 25 Jul 96 09:29:29 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9607251329.AA05466@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com, roque@di.fc.ul.pt Subject: (IPng 1975) Re: Bad source address ICMP ? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Our implementation uses the Communication Administratively Prohibited code (1) in such a case. Dimitry > From majordom Thu Jul 25 09:12:38 1996 > Date: Thu, 25 Jul 1996 13:47:12 +0100 > From: Pedro Roque Marques > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 1973) Bad source address ICMP ? > Mime-Version: 1.0 (generated by tm-edit 7.69) > Content-Type> : > text/plain> ; > charset=US-ASCII> > Sender: owner-ipv6 > Content-Length: 916 > > > When a router receives a packet to forward and the source address is > link local should it send an ICMP after discarding the packet ? > > RFC 1885 say yes: > > "A Destination Unreachable message SHOULD be generated by a router, or > by the IPv6 layer in the originating node, in response to a packet > that cannot be delivered to its destination address for reasons other > than congestion. (An ICMPv6 message MUST NOT be generated if a > packet is dropped due to congestion.)" > > Now the problem is what code to pick for the ICMP... > > Code 2, "not a neighbor" would be a candidate but it's current meaning > is quite different. > > regards, > Pedro. > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 25 08:51:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23154; Thu, 25 Jul 96 08:51:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23148; Thu, 25 Jul 96 08:51:42 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA16375; Thu, 25 Jul 1996 08:47:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA09360; Thu, 25 Jul 1996 08:47:08 -0700 Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.12/8.6.5) with SMTP id IAA28111; Thu, 25 Jul 1996 08:45:55 -0700 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Jul 1996 08:49:35 -0700 To: Stephen Thomas From: Fred Baker Subject: (IPng 1976) Re: Token Ring draft Cc: Bob Hinden , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:59 PM 7/24/96, Stephen Thomas spluttered: > Is your question raising the possibility of defaulting the Token Ring > MTU to ~4500 bytes instead of 1500 and forcing either RAs or manual > configuration to override to 1500 in a mixed environment? If so, the > idea certainly has merit. My own preference is to err on the side of > interoperability rather than performance, but I'm happy to put either > in the draft based on the working group's feelings. Yes, that's it in a nutshell. There exists a way to negotiate the MTU down, why force it to start down on an architectural assumption that there *might* be an Ethernet around? If you're going to make assumptions like that, maybe we need to rethink IP6/Localtalk... I would guess that it's far more probable that the thing connecting multiple token rings has more bandwidth than the token rings, not less. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I don't suffer from insanity. I enjoy every minute of it. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 25 09:46:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23265; Thu, 25 Jul 96 09:46:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23168; Thu, 25 Jul 96 09:04:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA18219; Thu, 25 Jul 1996 09:00:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA14249; Thu, 25 Jul 1996 09:00:11 -0700 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id LAA27180; Thu, 25 Jul 1996 11:57:55 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/5/18/96) id AA27486; Thu, 25 Jul 1996 11:57:26 -0400 From: Charlie Perkins Message-Id: <9607251557.AA27486@hawpub1.watson.ibm.com> To: ipng@sunroof.eng.sun.com Cc: veizades@home.net, eguttman@osmosys.incog.com Subject: (IPng 1977) Service Location for IPv6 Date: Thu, 25 Jul 96 11:57:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John Veizades and Erik Guttman have completed work on a draft which describes the modifications Service Location will require to function using IPv6. This draft is available as: draft-ietf-svrloc-IPv6-00.txt The protocol itself is available as: draft-ietf-svrloc-protocol-14.txt Regards, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 25 11:14:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23300; Thu, 25 Jul 96 11:14:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23294; Thu, 25 Jul 96 11:13:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA11585; Thu, 25 Jul 1996 11:09:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA07016; Thu, 25 Jul 1996 11:09:15 -0700 Received: from inner.net (fiasco.cs.nrl.navy.mil [132.250.90.21]) by inner.net (8.7.3/42) with ESMTP id MAA11080 for ; Fri, 26 Jul 1996 12:34:22 -0400 Message-Id: <199607261634.MAA11080@inner.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 1978) getnameinfo() flags? X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Thu, 25 Jul 1996 14:07:33 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At the risk of creeping featurism, I'd like to see a flags field added to getnameinfo(). The two specific flags I'd like to see added are one that causes the function not to resolve host names symbolically (i.e., always print the address per inet_ntop) and one that causes the function not to resolve service names symbolically (i.e., always print the port number), both of which default to off. Presumably a TCP/UDP flag could be added, too, if people thought that was appropriate. Anyone have thoughts on this? Mainly, I want to not have to kluge around the common and useful '-n' option many programs support. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 25 11:55:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23340; Thu, 25 Jul 96 11:55:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23334; Thu, 25 Jul 96 11:55:26 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA19994; Thu, 25 Jul 1996 11:50:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA22857; Thu, 25 Jul 1996 11:50:51 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with ESMTP id LAA26368; Thu, 25 Jul 1996 11:50:44 -0700 (MST) Received: (from rstevens@localhost) by gemini.tuc.noao.edu (8.7.5/8.7.3/SAG-11Jul96) id LAA26657; Thu, 25 Jul 1996 11:50:44 -0700 (MST) Message-Id: <199607251850.LAA26657@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Thu, 25 Jul 1996 11:50:43 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Craig Metz , ipng@sunroof.eng.sun.com Subject: (IPng 1979) Re: getnameinfo() flags? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jul 25, 2:07pm you write:] > > At the risk of creeping featurism, I'd like to see a flags field > added to getnameinfo(). The two specific flags I'd like to see added are > one that causes the function not to resolve host names symbolically (i.e., > always print the address per inet_ntop) and one that causes the function not > to resolve service names symbolically (i.e., always print the port number), > both of which default to off. Presumably a TCP/UDP flag could be added, too, > if people thought that was appropriate. > > Mainly, I want to not have to kluge around the common and useful > '-n' option many programs support. Craig: I brought this up with Keith Sklower a few months ago. I had proposed a negative length field for either the hostname of service name as an indicator that no lookup was to be done, but Keith was against negative lengths (I now agree) and he suggested adding another function that just returned the printable versions. So what I've come up with is a new function sock_ntop() that takes a pointer to a socket address structure, its length (since all functions that take a pointer to a sockaddr{} always take its length as the next argument), and then a pointer to a buffer for the result. (You could also add a length for the result buffer, similar to inet_ntop().) It's trivial to code, and as you note, there are definitely times when you don't want any lookups being performed, but you want a printable, numeric address for logging. Notice that the reason a new function is needed, instead of calling inet_ntop() is to avoid making the caller look inside the socket address structure at the family, to determine where the numeric address is stored (sin_addr for IPv4, sin6_addr for IPv6, etc.). sock_ntop() is then protocol independent. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 25 18:39:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23623; Thu, 25 Jul 96 18:39:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23617; Thu, 25 Jul 96 18:39:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA21676; Thu, 25 Jul 1996 18:34:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA14883; Thu, 25 Jul 1996 18:34:29 -0700 Received: from borg.mindspring.com (borg.mindspring.com [204.180.128.14]) by answerman.mindspring.com (8.6.12/8.6.12) with ESMTP id VAA07202; Thu, 25 Jul 1996 21:34:26 -0400 Received: from sthomas.mindspring.com (user-168-121-37-118.dialup.mindspring.com [168.121.37.118]) by borg.mindspring.com (8.6.12/8.6.12) with SMTP id VAA18866; Thu, 25 Jul 1996 21:34:22 -0400 Message-Id: <2.2.32.19960726013332.0069b718@mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Jul 1996 21:33:32 -0400 To: ipng@sunroof.eng.sun.com From: Stephen Thomas Subject: (IPng 1980) Re: Token Ring draft Cc: Bob Hinden , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The response so far seems to make a case for advancing the Token Ring draft as is. (Though I'm not trying to be stubborn; if the group wants revisions, I'll be happy to make them.) First, Scott Bradner wrote: >> re there examples of Token_Ring<->Ethernet > >IBM 8209, Cisoc routers running in 8209 mode .... >yes - they are in wide use Which supports my concern that we preserve interoperability in mixed-media environments. (BTW, I'm sure I'm not the first to wonder, but how DOES Scott find time to read all his email? I am impressed!) Meanwhile, Fred Baker (replying to me) wrote: >At 9:59 PM 7/24/96, Stephen Thomas spluttered: >> Is your question raising the possibility of defaulting the Token Ring >> MTU to ~4500 bytes instead of 1500 and forcing either RAs or manual >> configuration to override to 1500 in a mixed environment? If so, the >> idea certainly has merit. My own preference is to err on the side of >> interoperability rather than performance, but I'm happy to put either >> in the draft based on the working group's feelings. > >Yes, that's it in a nutshell. There exists a way to negotiate the MTU down, >why force it to start down on an architectural assumption that there >*might* be an Ethernet around? If you're going to make assumptions like >that, maybe we need to rethink IP6/Localtalk... I'm not sure what mechanism exists to negotiate an MTU down. The Token Ring draft does not propose overloading the priority field as does the FDDI draft. There are too many Token Ring vendors that are actually planning to use the priority field to indicate priority. (Or, at least, that's what they say ;^) The current draft proposes only three ways to change the default MTU: 1) manual configuration (which, depending on an implementation, could be either link-specific or neighbor-specific, though the latter strikes me as a nasty can of worms) 2) source route bridging's largest frame field (which doesn't apply in mixed media networks) 3) router advertisements (which are only link-specific) Am I missing something? If not, I'd suggest sticking with the current default of 1500. It means manual overrides are necessary to tweak the absolute maximum performance from Token Ring, but it does ensure that you can plug a host into a mixed media environment and have the thing actually work. --Stephen ________________________ Stephen A. Thomas 4397 Windsor Oaks Circle Marietta, GA 30066-2387 E-mail: s.thomas@acm.org ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Jul 27 21:54:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24475; Sat, 27 Jul 96 21:54:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24469; Sat, 27 Jul 96 21:54:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA00748; Sat, 27 Jul 1996 21:49:52 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA29211; Sat, 27 Jul 1996 21:49:52 -0700 Received: by gw.home.vix.com id VAA13123; Sat, 27 Jul 1996 21:49:51 -0700 (PDT) Date: Sat, 27 Jul 1996 21:49:51 -0700 (PDT) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1981) Re: getnameinfo() flags? Organization: Vixie Enterprises Message-Id: References: <199607251850.LAA26657@gemini.tuc.noao.edu> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: rstevens@noao.edu's message of 25 Jul 1996 16:45:56 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Notice that the reason a new function is needed, instead of calling > inet_ntop() is to avoid making the caller look inside the socket address > structure at the family, to determine where the numeric address is stored > (sin_addr for IPv4, sin6_addr for IPv6, etc.). sock_ntop() is then > protocol independent. #define sock_ntop(sa, len, buf, size) \ inet_ntop(sa->sa_family, &sa->sa_data, buf, size) -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jul 28 06:16:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24623; Sun, 28 Jul 96 06:16:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24617; Sun, 28 Jul 96 06:16:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA11878; Sun, 28 Jul 1996 06:11:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA15424; Sun, 28 Jul 1996 06:11:52 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with ESMTP id GAA29378; Sun, 28 Jul 1996 06:11:49 -0700 (MST) Received: (from rstevens@localhost) by gemini.tuc.noao.edu (8.7.5/8.7.3/SAG-11Jul96) id GAA17365; Sun, 28 Jul 1996 06:11:50 -0700 (MST) Message-Id: <199607281311.GAA17365@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Sun, 28 Jul 1996 06:11:50 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: paul@vix.com (Paul A Vixie), ipng@sunroof.eng.sun.com Subject: (IPng 1982) Re: getnameinfo() flags? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Jul 27, 9:49pm you write:] > > Notice that the reason a new function is needed, instead of calling > > inet_ntop() is to avoid making the caller look inside the socket address > > structure at the family, to determine where the numeric address is stored > > (sin_addr for IPv4, sin6_addr for IPv6, etc.). sock_ntop() is then > > protocol independent. > > #define sock_ntop(sa, len, buf, size) \ > inet_ntop(sa->sa_family, &sa->sa_data, buf, size) Ah, but this is the fundamental problem: sock_ntop() must look at the family, and then pass a different pointer for each different socket address structure, since inet_ntop() requires a pointer to the binary address, not the socket address structure. sa_data won't work. For IPv4 it's the sin_addr member, normally at an offset of 4 bytes, while for IPv6 it's the sin6_addr member, at an offset of 8 bytes. My version of sock_ntop() also prints the port number. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 29 13:54:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25194; Mon, 29 Jul 96 13:54:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25188; Mon, 29 Jul 96 13:54:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA21547; Mon, 29 Jul 1996 13:49:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA05886; Mon, 29 Jul 1996 13:49:46 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA00736; Mon, 29 Jul 1996 16:40:05 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA15674; Mon, 29 Jul 1996 16:40:02 -0400 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id QAA13839 for ; Mon, 29 Jul 1996 16:45:41 GMT Message-Id: <199607291645.QAA13839@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: ipng@sunroof.eng.sun.com Subject: (IPng 1983) AH & Fragment header question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Jul 1996 16:45:40 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While burning out brain cells at a prodigious rate thinking about how IPsec is going to interact with IPv4 and IPv6, the following scenarios/cases came to mind: Case #1: (AH after fragment header) Assume a packet is sent in muliple fragments. Further assume that the non-fragmentable part starts with an AH header. After being reassembled by the destination node, is it correct to assume that the fragment header is not present in the final reassembled packet? This makes a difference in how the packet for the authentication header is processed and how the authentication data is generated. [ie. that the fragmentation process was completely transparent and thus need not be considered in this case.] Case #2: (AH before fragment header) Assume a packet is sent in multiple fragments. Further assume that the header before fragment header was an AH header (Why? I don't know but it is possible so I need to consider how to handle it. I wouldn't mind if this situation was ruled as not allowed) Thus the fragment header and the fragment carried by this packet is covered by the authentication header in this packet. When reassembling, is correct to require that all fragments contain an AH header with the same SPI value? Note that while RFC 1826 same text, it does not discuss the fragment header at all. RFC 1827 (which is referenced in RFC 1883) does not seem to have any relavent text at all. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 29 14:03:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25217; Mon, 29 Jul 96 14:03:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25208; Mon, 29 Jul 96 14:03:43 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA23234; Mon, 29 Jul 1996 13:59:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA08990; Mon, 29 Jul 1996 13:59:00 -0700 Received: from inner.net (todd.cs.nrl.navy.mil [132.250.90.8]) by inner.net (8.7.3/42) with ESMTP id PAA12907; Tue, 30 Jul 1996 15:21:34 -0400 Message-Id: <199607301921.PAA12907@inner.net> To: Matt Thomas Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1984) Re: AH & Fragment header question In-Reply-To: Your message of "Mon, 29 Jul 1996 16:45:40 -0000." <199607291645.QAA13839@whydos.lkg.dec.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Mon, 29 Jul 1996 16:57:22 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199607291645.QAA13839@whydos.lkg.dec.com>, you write: >Case #1: (AH after fragment header) > >Assume a packet is sent in muliple fragments. Further assume that the >non-fragmentable part starts with an AH header. After being reassembled >by the destination node, is it correct to assume that the fragment header >is not present in the final reassembled packet? Yes, take it out. You do a similar thing for AH/IPv4 when you re-assemble and then zero the fragment offset and MF fields. >This makes a difference >in how the packet for the authentication header is processed and how the >authentication data is generated. [ie. that the fragmentation process >was completely transparent and thus need not be considered in this case.] Yes. >Case #2: (AH before fragment header) Not valid -- AH happens above fragmentation. I thought the RFCs were fairly clear about that. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 29 14:25:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25292; Mon, 29 Jul 96 14:25:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25286; Mon, 29 Jul 96 14:23:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA27039; Mon, 29 Jul 1996 14:18:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA15926; Mon, 29 Jul 1996 14:18:20 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14939(6)>; Mon, 29 Jul 1996 14:18:10 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 29 Jul 1996 14:17:55 PDT To: Matt Thomas Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1985) Re: AH & Fragment header question In-Reply-To: matt's message of Mon, 29 Jul 96 09:45:40 -0800. <199607291645.QAA13839@whydos.lkg.dec.com> Date: Mon, 29 Jul 1996 14:17:55 PDT From: Steve Deering Message-Id: <96Jul29.141755pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, > Case #1: (AH after fragment header) > > Assume a packet is sent in muliple fragments. Further assume that the > non-fragmentable part starts with an AH header. Don't you mean the fragmentable part starts with an AH header, in this case? > After being reassembled > by the destination node, is it correct to assume that the fragment header > is not present in the final reassembled packet? Yes. the IPv6 spec, RFC 1883, says precisely that on the top of page 23. > Case #2: (AH before fragment header) > > Assume a packet is sent in multiple fragments. Further assume that the > header before fragment header was an AH header (Why? I don't know but > it is possible so I need to consider how to handle it. I wouldn't mind > if this situation was ruled as not allowed) Thus the fragment header > and the fragment carried by this packet is covered by the authentication > header in this packet. When reassembling, is correct to require that all > fragments contain an AH header with the same SPI value? Putting an AH before a Frag Header allowed, but not recommended. You shouldn't generate such fragment packets, but if you receive such packets, you should just go ahead and process the Auth Header in each fragment packet as you come to it, using whatever SPI is in the Auth Header. No need to verify that all fragments carry an AH and/or the same SPI -- it's up to the sender to decide what to send and to suffer the consequences of a silly choice. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 29 14:58:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25352; Mon, 29 Jul 96 14:58:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25346; Mon, 29 Jul 96 14:56:47 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA03222; Mon, 29 Jul 1996 14:52:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA27469; Mon, 29 Jul 1996 14:52:07 -0700 Received: from munin.fnal.gov ("port 2594"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I7NHNT3XKQ001AJK@FNAL.FNAL.GOV>; Mon, 29 Jul 1996 16:52:05 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id QAA18184; Mon, 29 Jul 1996 16:50:33 -0500 (CDT) Date: Mon, 29 Jul 1996 16:50:32 -0500 From: Matt Crawford Subject: (IPng 1986) Re: AH & Fragment header question In-Reply-To: "29 Jul 1996 16:45:40 -0000." <"199607291645.QAA13839"@whydos.lkg.dec.com> To: Matt Thomas Cc: ipng@sunroof.eng.sun.com Message-Id: <199607292150.QAA18184@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Case #1: (AH after fragment header) > Assume a packet is sent in muliple fragments. Further assume that the > non-fragmentable part starts with an AH header. That can't be. The unfragmentable part always starts with an IPv6 header. s/non-// ? That would be normal, and it's clear from 1883 that the reassembled packet has no fragment headers. > Case #2: (AH before fragment header) > Assume a packet is sent in multiple fragments. Further assume that the > header before fragment header was an AH header (Why? I don't know but > it is possible so I need to consider how to handle it. I wouldn't mind > if this situation was ruled as not allowed) Currently this is, as you'd expect, loudly forbidden by 1883 and softly forbidden by 1826. This leaves no (non-tunneling) way to push fragments through a firewall. > Thus the fragment header > and the fragment carried by this packet is covered by the authentication > header in this packet. When reassembling, is correct to require that all > fragments contain an AH header with the same SPI value? If AH before FH were to be allowed, I think the correct rule to impose would be that any AH before the FH should be discarded by the reassembling node without processing. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 30 21:27:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26230; Tue, 30 Jul 96 21:27:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26224; Tue, 30 Jul 96 21:27:03 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA08931; Tue, 30 Jul 1996 21:22:24 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id VAA07538; Tue, 30 Jul 1996 21:22:23 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id AAA14345; Wed, 31 Jul 1996 00:16:00 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27648; Wed, 31 Jul 1996 00:15:58 -0400 Message-Id: <9607310415.AA27648@fwasted.zk3.dec.com> To: Steve Deering Cc: Matt Thomas , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 1987) Re: AH & Fragment header question In-Reply-To: Your message of "Mon, 29 Jul 96 14:17:55 PDT." <96Jul29.141755pdt."75270"@digit.parc.xerox.com> Date: Wed, 31 Jul 96 00:15:58 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Case #2: (AH before fragment header) >> >> Assume a packet is sent in multiple fragments. Further assume that the >> header before fragment header was an AH header (Why? I don't know but >> it is possible so I need to consider how to handle it. I wouldn't mind >> if this situation was ruled as not allowed) Thus the fragment header >> and the fragment carried by this packet is covered by the authentication >> header in this packet. When reassembling, is correct to require that all >> fragments contain an AH header with the same SPI value? > >Putting an AH before a Frag Header allowed, but not recommended. You >shouldn't generate such fragment packets, but if you receive such packets, >you should just go ahead and process the Auth Header in each fragment packet >as you come to it, using whatever SPI is in the Auth Header. No need to >verify that all fragments carry an AH and/or the same SPI -- it's up to >the sender to decide what to send and to suffer the consequences of a >silly choice. Hmmm with all the should nots and I agree its silly so why not just outlaw it so we can drop such silly packets? /jim Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 30 22:34:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26297; Tue, 30 Jul 96 22:34:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26291; Tue, 30 Jul 96 22:34:34 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA13658; Tue, 30 Jul 1996 22:29:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA20101; Tue, 30 Jul 1996 22:29:54 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14993(1)>; Tue, 30 Jul 1996 22:29:46 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 30 Jul 1996 22:29:28 PDT To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1988) Re: AH & Fragment header question In-Reply-To: bound's message of Tue, 30 Jul 96 21:15:58 -0800. <9607310415.AA27648@fwasted.zk3.dec.com> Date: Tue, 30 Jul 1996 22:29:28 PDT From: Steve Deering Message-Id: <96Jul30.222928pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Putting an AH before a Frag Header allowed, but not recommended. You > >shouldn't generate such fragment packets, but if you receive such packets, > >you should just go ahead and process the Auth Header in each fragment packet > >as you come to it, using whatever SPI is in the Auth Header. No need to > >verify that all fragments carry an AH and/or the same SPI -- it's up to > >the sender to decide what to send and to suffer the consequences of a > >silly choice. > > Hmmm with all the should nots and I agree its silly ... Jim, I did not say it was silly. I said if a sender makes a silly choice (of which this *may* or *may not* be an example), then it suffers the consequences. > ...so why not just outlaw it so we can drop such silly packets? Because we can't tell in advance what might be silly and what might turn out to be useful. If you just process the packets as I suggest, like a simple automaton, then the senders have a reasonable chance of predicting what the effect of their choices may be, and if it turns out some day that, say, authenticating each fragment of a fragmented packet under a different SPI turns out to give some useful security properties, we can exploit that capability without going around and changing all the implementations. Besides, it costs extra instructions to test for "silliness" -- instructions that are almost never going to have any useful effect, assuming senders stay with the recommended header order. To summarize: - if senders conform to the recommended order, any tests for other orders are just wasted cycles. - if, in the future, a different order is recognized as useful, any tests for unexpected order would defeat that new use. Does that make sense? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 31 06:43:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26400; Wed, 31 Jul 96 06:43:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26394; Wed, 31 Jul 96 06:43:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA11229; Wed, 31 Jul 1996 06:38:30 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id GAA24523; Wed, 31 Jul 1996 06:38:29 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id JAA17101; Wed, 31 Jul 1996 09:09:58 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15484; Wed, 31 Jul 1996 09:09:51 -0400 Message-Id: <9607311309.AA15484@fwasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1989) Re: AH & Fragment header question In-Reply-To: Your message of "Tue, 30 Jul 96 22:29:28 PDT." <96Jul30.222928pdt."75270"@digit.parc.xerox.com> Date: Wed, 31 Jul 96 09:09:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Putting an AH before a Frag Header allowed, but not recommended. You > >shouldn't generate such fragment packets, but if you receive such packets, > >you should just go ahead and process the Auth Header in each fragment packet > >as you come to it, using whatever SPI is in the Auth Header. No need to > >verify that all fragments carry an AH and/or the same SPI -- it's up to > >the sender to decide what to send and to suffer the consequences of a > >silly choice. > > Hmmm with all the should nots and I agree its silly ... >Jim, > >I did not say it was silly. I said if a sender makes a silly choice (of >which this *may* or *may not* be an example), then it suffers the >consequences. ACK. Silly choice yes. >> ...so why not just outlaw it so we can drop such silly packets? >Because we can't tell in advance what might be silly and what might turn >out to be useful. If you just process the packets as I suggest, like a >simple automaton, then the senders have a reasonable chance of predicting >what the effect of their choices may be, and if it turns out some day that, >say, authenticating each fragment of a fragmented packet under a different >SPI turns out to give some useful security properties, we can exploit that >capability without going around and changing all the implementations. >Besides, it costs extra instructions to test for "silliness" -- instructions >that are almost never going to have any useful effect, assuming senders >stay with the recommended header order. To summarize: > > - if senders conform to the recommended order, any tests for other > orders are just wasted cycles. > > - if, in the future, a different order is recognized as useful, > any tests for unexpected order would defeat that new use. > >Does that make sense? Yes. I guess we need to cover the future potential case. I was just thinking if we did our job right with AH header and design of an SPI then one would suffice for all fragments. Also realizing that each SPI if different can require different set up for each AH header. That will have a significant cost to the system if different and do we not want to also reduce severe performance penalties in our thinking too? But if the argument to make sure we cover the special case to exploit which as you point out may save us later defining it and changing implementations wins over the trade-off of making a performance decision then this discussion is over. In real life for products that would not be the case unless I thought I could make gain from it in the market. The other case is that we create because of fragmentation the condition I hate in a kernel stack (which is OK in applications) of distributing cohesiveness of the modules. Processing AH or ESP within the implemenation is fairly straight forward on where and when at the IP layer. Fragmentation changes that slightly, but adding the SPIs can affect it futher. I would like to talk to Matt offline and determine exactly what the impact is and get back to you. OK.... I am just concerned we may have found an architectural flaw in our AH processing design. Maybe not. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com