From owner-ipng@sunroof.eng.sun.com Sun Aug 1 19:21:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA17540 for ipng-dist; Sun, 1 Aug 1999 19:02:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17533; Sun, 1 Aug 1999 19:02:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA13422; Sun, 1 Aug 1999 19:02:21 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA28546; Sun, 1 Aug 1999 19:02:19 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 817151A6; Sun, 1 Aug 1999 22:02:18 -0400 (EDT) To: Peter Tattam Cc: IPNG Mailing List , NGTRANS Mailing List Subject: Re: (ngtrans) Any calls for IPv6 over MS-DOS References: Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 01 Aug 1999 22:02:18 -0400 In-Reply-To: Peter Tattam's message of "Fri, 30 Jul 1999 10:41:20 +1000 (EST)" Message-ID: <87so63djo5.fsf@jekyll.piermont.com> Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Tattam writes: > I noticed a request on comp.protocols.tcp-ip.ibmpc for a DOS implementation of > IPv6. > > We have some DOS stuff that could be worked up to do it, but would take at > least a month or so to shoehorn it into a DOS TSR that would be practical in > size. > > Does anyone think this project is worth pursuing? DOS is still used as an embedded systems environment by many people. Whether that makes the market reasonable sized or important, I couldn't say. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 1 19:58:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA17614 for ipng-dist; Sun, 1 Aug 1999 19:40:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17596 for ; Sun, 1 Aug 1999 19:39:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA00796 for ; Sun, 1 Aug 1999 19:39:43 -0700 (PDT) Received: from loran.com (sprocket.loran.com [209.167.240.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA03835 for ; Sun, 1 Aug 1999 19:39:42 -0700 (PDT) Received: (qmail 7984 invoked by uid 501); 2 Aug 1999 02:39:30 -0000 From: Michael Slavitch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 1 Aug 1999 22:39:30 -0400 (EDT) To: perry@piermont.com Cc: Peter Tattam , IPNG Mailing List , NGTRANS Mailing List Subject: Re: (ngtrans) Any calls for IPv6 over MS-DOS In-Reply-To: <87so63djo5.fsf@jekyll.piermont.com> References: <87so63djo5.fsf@jekyll.piermont.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14245.1130.338876.137094@elvis.ottawa.loran.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Does anyone think this project is worth pursuing? > > DOS is still used as an embedded systems environment by many > people. Whether that makes the market reasonable sized or important, I > couldn't say. > > Perry As someone who cut his teeth in this market (sob) and still in touch with many slaving in it, it looks like Linux is displaing MS-DOS in this space, on a variety of processors. Praise whatever deity is appropriate. -- Michael Slavitch "I think it would be a good idea." Senior Consultant - Mohandas K. Gandhi (regarding Western Civilization) Loran Technologies Ottawa, Ontario -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 06:36:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA17832 for ipng-dist; Mon, 2 Aug 1999 06:13:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17825 for ; Mon, 2 Aug 1999 06:13:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA23570 for ; Mon, 2 Aug 1999 06:13:46 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13978 for ; Mon, 2 Aug 1999 06:13:46 -0700 (PDT) Received: from localhost (rglr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id JAA24433; Mon, 2 Aug 1999 09:11:00 -0400 (EDT) Date: Mon, 2 Aug 1999 09:11:00 -0400 From: Ray LaRocca To: ipng@sunroof.eng.sun.com cc: ipmembers@iol.unh.edu Subject: Re: UNH IPv6 Group Test Period In-Reply-To: <199907301730.NAA0000018531@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello All, It is important for you all to let me know where you are with your implementations (what you are interested in testing) so that we may better tailor the group test period to suit you. Here is a list of some input so far: 1. The recent additions to our IPv6 Test Suite: a. Redirect b. Path MTU c. Mobility 2. Transition Mechanisms 3. Dynamic Updates to DNS for IPv6 For more information on the test period see: www.iol.unh.edu Regards, -Ray /* * Ray LaRocca Lead Engineer, IP/Routing Consortium * Manager, FDDI Consortium * Email: rglr@iol.unh.edu * Tel: (603) 862-2804 InterOperability Lab * Lab Tel: (603) 862-0090 University of New Hampshire * Fax: (603) 862-4181 7 Leavitt Lane, Room 106 * Web: http://www.iol.unh.edu Durham, NH 03824-3525 */ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 08:40:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA18047 for ipng-dist; Mon, 2 Aug 1999 08:20:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18040 for ; Mon, 2 Aug 1999 08:19:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA03016 for ; Mon, 2 Aug 1999 08:19:53 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA22451 for ; Mon, 2 Aug 1999 09:19:50 -0600 (MDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA12285; Tue, 3 Aug 1999 01:19:45 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: IPv6 and Dynamic DNS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Aug 1999 01:19:45 +1000 Message-Id: <862.933607185@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message on the ipng list that reminded me I wanted to send this, Ray LaRocca said of the UNH IPv6 test suite ... | 3. Dynamic Updates to DNS for IPv6 Ppeaking of which, has anyone given any thought to how dynamic DNS update is going to be made to work for the IP6.INT domain? (That is, for the reverse translation). With IPv4, dynamic addresses come only from DHCP (or PPP servers or similar), and the assumption generally is that the the dhcp server (or whatever it is which assigned the address) has the necessary relationship with the in-addr.arpa zone file to have the authorityo to be able to perform an update. On the other hand, for the forward transmation (name -> address) it can be either that server, or (I believe) more likely, the node itself which has that authority (the node gets a name from somewhere, if the name comes from the dhcp server, then the dhcp server has the authority, if the name was provided some other way, then the authority can be provided along with it). For IPv6 there is normally no such server - nodes create their own IPv6 addresses (from information multicast by routers .. this explanation is for the benefit of namedroppers recipients). But there is not necessarily any relationship at all between the node and the network on which it is located. Eg: in Oslo at the IETF I was using IPv6, my laptop assigned itself an address (quicker than it ever managed to get an IPv4 address from the dhcp server - and there weren't any noticeable delays there either), but my laptop certainly didn't have permission to update the relevant IP6.INT zone file, and there was nothing else other than the laptop that knew what address it assigned to itself (unless someone was snooping on the DAD packets - which in this case they probably were, but which isn't normally to be expected). I could have easily had the laptop update the forward zone file (I didn't, but that's a separate issue) with its current IPv6 address, but how would I have gone about updating the reverse translation? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 09:41:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA18140 for ipng-dist; Mon, 2 Aug 1999 09:19:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18133 for ; Mon, 2 Aug 1999 09:19:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA11223 for ; Mon, 2 Aug 1999 09:19:41 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09557 for ; Mon, 2 Aug 1999 09:19:41 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA25633; Mon, 2 Aug 1999 12:19:31 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000012288; Mon, 2 Aug 1999 12:19:31 -0400 (EDT) From: Jim Bound Message-Id: <199908021619.MAA0000012288@quarry.zk3.dec.com> To: Robert Elz cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Tue, 03 Aug 1999 01:19:45 +1000." <862.933607185@munnari.OZ.AU> Date: Mon, 02 Aug 1999 12:19:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | 3. Dynamic Updates to DNS for IPv6 > >Ppeaking of which, has anyone given any thought to how dynamic DNS >update is going to be made to work for the IP6.INT domain? (That is, >for the reverse translation). It works now and we can test it at UNH with other vendors at the next event. >With IPv4, dynamic addresses come only from DHCP (or PPP servers or >similar), and the assumption generally is that the the dhcp server >(or whatever it is which assigned the address) has the necessary relationship >with the in-addr.arpa zone file to have the authorityo to be able to >perform an update. IPv6 will also support DHCPv6 as an alternative to using the router for your prefixes for addr conf too. >On the other hand, for the forward transmation (name -> address) it can >be either that server, or (I believe) more likely, the node itself which >has that authority (the node gets a name from somewhere, if the name comes >from the dhcp server, then the dhcp server has the authority, if the name >was provided some other way, then the authority can be provided along with it). Not entirely correct either. The node can do the update or the DHCPv6 server for the node. >For IPv6 there is normally no such server - nodes create their own IPv6 >addresses (from information multicast by routers .. this explanation is for >the benefit of namedroppers recipients). On the contrary. For initial deployment I am hearing customers do want to use DHCPv6 simply because the routers will not be ready in the market by the time the hosts are ready to deploy. Also customers will want the option of centralized assignment of addresses from a server to the client. >But there is not necessarily any relationship at all between the node and the >network on which it is located. Eg: in Oslo at the IETF I was using IPv6, >my laptop assigned itself an address (quicker than it ever managed to get an >IPv4 address from the dhcp server - and there weren't any noticeable delays >there either), but my laptop certainly didn't have permission to update the >relevant IP6.INT zone file, and there was nothing else other than the laptop >that knew what address it assigned to itself (unless someone was snooping on >the DAD packets - which in this case they probably were, but which isn't >normally to be expected). If the issue is authority then that is TSIG initially and then DNSSEC. Then its a matter of getting the key. For BIND folks this is in the 8.2 release and works with Dynamic Updates to DNS implementation APIs. >I could have easily had the laptop update the forward zone file (I didn't, >but that's a separate issue) with its current IPv6 address, but how would >I have gone about updating the reverse translation? With dynamic updates to DNS its just a PTR record for IPv6 like IPv4 under the IP6.INT domain. Maybe I am missing your issue as I don't see it? thanks /jim kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 10:18:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA18214 for ipng-dist; Mon, 2 Aug 1999 09:57:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18207 for ; Mon, 2 Aug 1999 09:57:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA20295 for ; Mon, 2 Aug 1999 09:57:36 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA00399 for ; Mon, 2 Aug 1999 10:57:31 -0600 (MDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA13042; Tue, 3 Aug 1999 02:54:51 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Jim Bound Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-Reply-To: Your message of "Mon, 02 Aug 1999 12:19:30 -0400." <199908021619.MAA0000012288@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Aug 1999 02:54:50 +1000 Message-Id: <1903.933612890@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 02 Aug 1999 12:19:30 -0400 From: Jim Bound Message-ID: <199908021619.MAA0000012288@quarry.zk3.dec.com> | IPv6 will also support DHCPv6 as an alternative to using the router for | your prefixes for addr conf too. OK, I should have been clearer, obviously if DHCPv6 is being used, then the DHCP server can do things for v6 exactly as for v4. I was concerned with the case where DHCPv6 isn't being used. | Not entirely correct either. The node can do the update or the DHCPv6 | server for the node. If we assume there is no DHCPv6 server (which for example I don't believe there was in Oslo) then it has to be the node, right? But from where is the node going to get the authority to do this? Typically it will have no knowledge at all of the net where it is being connected, which also implies that it can't know what credentials it can usefully supply to get permission to update the zone file. | If the issue is authority then that is TSIG initially and then DNSSEC. | Then its a matter of getting the key. Yes, exactly. That small matter. Does this imply that if I come visit you one day, you're going to hand over the key to your zone file to my laptop? | For BIND folks this is in the 8.2 | release and works with Dynamic Updates to DNS implementation APIs. Right now, I'm not concerned with the software to make this work, I know that's on the way. It is how it is supposed to be all glued together so it can work in practice. | With dynamic updates to DNS its just a PTR record for IPv6 like IPv4 | under the IP6.INT domain. Sure, I understand this much Jim.... | Maybe I am missing your issue as I don't see it? The point is where my node gets the authority to do the update (assuming that DHCPv6 isn't being used, if it was the server would just do the update, as for v4, that's easy to arrange to work). But we haven't moved to mandating DCHPv6 yet have we, autoconfig is still an option, right? So assuming that autoconfig is what my node does (and is what I do in fact do as I have a router which is sending out the RAs I need for this), where does my node manage to find the key to update some random network it happens to be connected to today? It can easily update the forward zone, as its domain name doesn't change, no matter where it connects, so configuring it with a key to permit that update is easy. But for the reverse zone file this doesn't look like quite such an easy problem (and it certainly can't be swept under the floor by saying "you should use DHCPv6 if you need to do that"). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 10:20:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA18223 for ipng-dist; Mon, 2 Aug 1999 10:00:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18216 for ; Mon, 2 Aug 1999 10:00:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA07471 for ; Mon, 2 Aug 1999 10:00:48 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01710 for ; Mon, 2 Aug 1999 11:00:46 -0600 (MDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id NAA20036; Mon, 2 Aug 1999 13:00:45 -0400 (EDT) Message-Id: <199908021700.NAA20036@cannes.aa.ans.net> To: ipng@sunroof.eng.sun.com cc: jyy@ans.net Subject: Re: Session Stability (was multi-homing vs route aggregation) Date: Mon, 02 Aug 1999 13:00:45 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have been reading this thread. Being an engineer and network architecture of large scaled networks (UUNET and ANSNET and way earlier NSFNET), I feel strongly that any solution we come up with here should also be operationally MANAGEABLE, that is, it scales operationally. Below is a proposal for thoughts and consideration. --Jessica ----------------------------------------------------------------------- Internet Engineering Task Force Jieyun (Jessica) Yu INTERNET DRAFT UUNET Expires February, 2000 August, 1999 A Simple Solution for IPv6 Multihoming Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract There is a challenge of providing IPv6 multihoming sites with the basic benefits such as redundancy and load sharing, and at the same time, scaling the global IPv6 routing table. It is equally challenging to provide a solution which is simple enough to be operational manageable. This document proposes a simple solution which meets the requirements and is also operationally manageable. 1. Purpose There is a challenge of providing IPv6 multihoming sites with the basic benefits such as redundancy and load sharing, and at the same time, scaling the global IPv6 routing table. It is equally Yu A Simple Solution for IPv6 Multihoming [Page 1] Internet Draft draft-yu-simple-ipv6multihoming-00.txt August 1999 challenging to provide a solution which is simple enough to be operational manageable. This document proposes a routing and addressing scheme that supports IPv6 multihoming which achieves the followings: a. Providing redundancy and load sharing for the multi-homed sites b. Scaling the global IPv6 Internet routing table c. Simple and operationally manageable 2. Proposal ISP-3 ---- ISP-4 | / | | / | | / | ISP-1 ---- ISP-2 link-1 \ / link-2 Customer-A A multi-homed customer will designate a primary ISP and receive IP address from its primary ISP's IPv6 aggregation block. In this example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A to the customer. Customer-A will advertise addr-1-A to ISP-1 and ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to ISP-1 only. ISP-1 will, of course, advertise its own aggregation Addr-1 to the entire Internet. For inbound traffic to Customer-A, traffic will first be forwarded to ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will then forward the traffic destined to Customer-A via its connection to ISP-2 and/or its direct link to customer-A, according to certain polices. Most common policy would be the use of the shortest exit. By using both connections to forward traffic to Customer-A, load sharing is achieved. For outbound traffic from Customer-A, ISP-1 and ISP-2 can announce default and/or specific prefixes based on customer-A's requirements and traffic originated from Customer-A will be forwarded accordingly. When the link between customer-A and ISP-2 (link-2 in the figure) goes down, all traffic will go in/out via the connection between Customer-A and ISP-1 (link-1 in the figure). Likewise, when link-1 is experiencing an outage, link-2 will be used for the traffic. This is because ISP-1 will continue announce its aggregate block (i.e. Addr- 1) to the entire Internet and ISP-2 will still advertise Addr-1-A to ISP-1, all the inbound traffic to the customer will be take the path: ISP-1 -> ISP-2 -> Customer-A. Outbound traffic will automatically fall to link-2. This way, redundancy is achieved. Yu A Simple Solution for IPv6 Multihoming [Page 2] Internet Draft draft-yu-simple-ipv6multihoming-00.txt August 1999 Same mechanism can be extended to those sites multihoming to more than two ISPs. Only those ISPs that the customer directly connected to would carry the more specific prefix assigned to the multi-homed customer. The more specific prefix announcement could be covered under the peering agreement between ISPs as stated in [RFC2546]. 3. Advantages of the proposal - Achieves the goal of scaling the global routing table. - It scales the global routing table. Only ISPs involved in the multihoming attachment need to know the more specific route of Addr-1. Other ISPs such as ISP-3 and ISP-4 in figure 1 do not need to know specifics. If the two involved ISPs has no direct connection, the more specific route would need to be carried by other ISPs in the path. This seems to be lesser a problem since ISP assigned with an Internet visible aggregate block usually has direct connection to each other. - It is really simple and thus more manageable and scalable operation wise. It does not require multiple addresses assigned all individual hosts of a multi-homed customer site, neither it requires O(N^2) tunnels among different ISP routers. 4. Concerns - The primary ISP of a multihoming customer (such as ISP-1 in the example) would need to do more work in terms of distributing the traffic among other connected ISPs and the customer link. This can be done using BGP policy (BGP community) and using shortest exit. It will also carry more traffic for the customer. However, this is a value added service to the customer and the primary ISP can charge more fees for such services. - The primary ISP is the sole interface for the multihomed customer to the Internet other than the ISPs the customer has directly connection with. Outages such as one between ISP-1 and ISP-4 would impact the reachability from customers of ISP-4 to Customer-A even though ISP-2 still has good connection to ISP-4. However, if the primary ISP is a good quality ISP, this sort of situation should happen rarely. The reason is that it's common practice that an ISP, especially good quality ISP, has multiple connections to other big ISPs at different geographical locations. Good quality ISPs also have robust network design to prevent any Yu A Simple Solution for IPv6 Multihoming [Page 3] Internet Draft draft-yu-simple-ipv6multihoming-00.txt August 1999 failure to impact the whole network. Choosing a good quality and robust ISP as primary ISP is a good practice. It is desirable to have solution which provides perfect redundancy and, at the same time, simplicity to scale management and operation. In the absence of a perfect solution, the trade-off needs to be made. The author believes that it is very important that the solution has to be simple and manageable. Manageability should be the top consideration. 5. Security Considerations Security considerations are out of scope of this document. 6. References [RFC2546] A. Durand and B. Buclin, "6Bone Routing Practice." RFC2546, March 1999.ftp://ftp.isi.edu/in-notes/rfc2546.txt. Author's Address Jieyun (Jessica) Yu UUNET Technology 880 Technology Dr. Ann Arbor, MI 48108 Phone: (734) 214-7314 EMail: jyy@uu.net Yu A Simple Solution for IPv6 Multihoming [Page 4] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 11:04:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA18392 for ipng-dist; Mon, 2 Aug 1999 10:44:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18385 for ; Mon, 2 Aug 1999 10:43:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA14392 for ; Mon, 2 Aug 1999 10:43:43 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11114 for ; Mon, 2 Aug 1999 10:43:41 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA05133; Mon, 2 Aug 1999 13:43:39 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000032040; Mon, 2 Aug 1999 13:43:39 -0400 (EDT) From: Jim Bound Message-Id: <199908021743.NAA0000032040@quarry.zk3.dec.com> To: Robert Elz cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Tue, 03 Aug 1999 02:54:50 +1000." <1903.933612890@munnari.OZ.AU> Date: Mon, 02 Aug 1999 13:43:39 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | If the issue is authority then that is TSIG initially and then DNSSEC. > | Then its a matter of getting the key. > >Yes, exactly. That small matter. Does this imply that if I come visit >you one day, you're going to hand over the key to your zone file to my >laptop? Well right now thats kind of how it must work. There is no key exchange that I am aware of we have agreed to for TSIG. For DNSSEC I believe we assume a PKI but don't quote me on that as I await that too. But sneaker net is in fact the mechanism. > | For BIND folks this is in the 8.2 > | release and works with Dynamic Updates to DNS implementation APIs. > >Right now, I'm not concerned with the software to make this work, I know >that's on the way. It is how it is supposed to be all glued together so >it can work in practice. Well its working in practice now in a sense with the DHCPv4 servers but as you say at least there is some "implied" authorziation btw the DHCPv4 server and the client. But not necessarily any real authority btw the DHCPv4 server and the DNS master of the zone. So I think the inherent problem is exchange of keys for DNSSEC. If we know what the answer is for that generically we know the answer for IPv6 and IPv4 IMO. For TSIG we will use what we can for our customers. > | Maybe I am missing your issue as I don't see it? >The point is where my node gets the authority to do the update (assuming >that DHCPv6 isn't being used, if it was the server would just do the >update, as for v4, that's easy to arrange to work). But we haven't >moved to mandating DCHPv6 yet have we, autoconfig is still an option, right? >So assuming that autoconfig is what my node does (and is what I do in fact >do as I have a router which is sending out the RAs I need for this), where >does my node manage to find the key to update some random network it happens >to be connected to today? 1. I would like to point out that because a DHCPv4ORv6 does the update does not mean its secure in DNS. 2. There is an M bit in stateless addr conf which right now the only solution being proposed is DHCPv6. 3. Right now in addrconf in the case of BIND there are mechanisms to build the key but we are just testing this now in 8.2. 4. As far as the IETF ruleset for authentication I am hoping thats in DNSSEC but I can't find it now. 5. It appears us vendors will deploy per #3 above and not wait for the issues with #4. So maybe the result of your mail is we need to define key exchange mechanisms as a standard for dyn upds to DNS? If so then I think its irrelevant if the update is done by the client or the server? Both need the same security measures. Also there is nothing to prevent an IPv4 DHC client to upate DNS without even going to the DHCPv4 server. We build rfc2136 so there would be no hard dependency on an intermediate (e.g. DHCP, SLP, etc) server for dynamic updates to dns. >It can easily update the forward zone, as its domain name doesn't change, >no matter where it connects, so configuring it with a key to permit that >update is easy. But for the reverse zone file this doesn't look like quite >such an easy problem (and it certainly can't be swept under the floor by >saying "you should use DHCPv6 if you need to do that"). I agree it should not be swept under the rug either nor did I suggest that in mail Sir........... I would argue there is no difference between either zone file once you have the credentials at the client (whether that be a dhcp server or a node that is just a client) you have the proper permission to speak with the server and the server knows the different btw name->address map updates and address->name updates. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 12:04:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA18494 for ipng-dist; Mon, 2 Aug 1999 11:45:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18487 for ; Mon, 2 Aug 1999 11:45:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA13125 for ; Mon, 2 Aug 1999 11:45:08 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12925 for ; Mon, 2 Aug 1999 12:45:05 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id NAA09712; Mon, 2 Aug 1999 13:45:00 -0500 (CDT) Message-Id: <199908021845.NAA09712@gungnir.fnal.gov> To: Jessica Yu Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of Mon, 02 Aug 1999 13:00:45 EDT. <199908021700.NAA20036@cannes.aa.ans.net> Date: Mon, 02 Aug 1999 13:44:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > MANAGEABLE, that is, it scales operationally. Below is a proposal for > thoughts and consideration. > --Jessica Jessica, Your draft is so succinct and clear that this demi-routing-clued reader can absorb it in minutes. Consider the situation after your model has been "symmetrized" -- that is, when both ISP-1 and ISP-2 play the role of primary ISP for Customer-A and assign it address space, and Customer-A announces two specific routes to each ISP, and each ISP then announces one of them to the other. I claim that this is only epsilon more complex than your model, since the same entities are communicating with each other at the same points and just announcing on additional prefix. Yet it solves one of your "concerns" items without damaging anything in the "advantages" section. I believe this symmetrized version is what the community is visualizing. It adds complexity in the hosts compared to yours, but most of that complexity has to be there anyway to support features like mobility, renumbering and site-local addressing. From the viewpoint of ISP operations and global routing, do you see any drawbacks? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 13:23:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA18653 for ipng-dist; Mon, 2 Aug 1999 13:08:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18646 for ; Mon, 2 Aug 1999 13:08:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA26196 for ; Mon, 2 Aug 1999 13:08:06 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06442 for ; Mon, 2 Aug 1999 13:08:05 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA262364; Mon, 2 Aug 1999 21:08:03 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA32526; Mon, 2 Aug 1999 21:08:02 +0100 (BST) Message-ID: <37A5FA2C.BF6DE4BD@hursley.ibm.com> Date: Mon, 02 Aug 1999 15:06:04 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Matt Crawford CC: Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) References: <199908021845.NAA09712@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think I agree with Matt. Another point: a *major* requirement is that IPv6 must allow for smooth prefix updates (a.k.a. renumbering). Matt's version seems to make that easy, i.e, at some point in the process of updating from Prefix 1 to Prefix 2, Prefix 1 becomes deprecated and slowly fades away. Another point is that none of this gets rid of the need for source and destination address selection mechanisms. Multiple prefixes are part of life with IPv6. Brian Matt Crawford wrote: > > > MANAGEABLE, that is, it scales operationally. Below is a proposal for > > thoughts and consideration. > > --Jessica > > Jessica, > > Your draft is so succinct and clear that this demi-routing-clued > reader can absorb it in minutes. > > Consider the situation after your model has been "symmetrized" -- > that is, when both ISP-1 and ISP-2 play the role of primary ISP for > Customer-A and assign it address space, and Customer-A announces two > specific routes to each ISP, and each ISP then announces one of them > to the other. I claim that this is only epsilon more complex than > your model, since the same entities are communicating with each other > at the same points and just announcing on additional prefix. Yet it > solves one of your "concerns" items without damaging anything in the > "advantages" section. > > I believe this symmetrized version is what the community is > visualizing. It adds complexity in the hosts compared to yours, but > most of that complexity has to be there anyway to support features > like mobility, renumbering and site-local addressing. From the > viewpoint of ISP operations and global routing, do you see any > drawbacks? > Matt > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 13:23:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA18644 for ipng-dist; Mon, 2 Aug 1999 13:05:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18637 for ; Mon, 2 Aug 1999 13:05:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA18022 for ; Mon, 2 Aug 1999 13:05:00 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA13319 for ; Mon, 2 Aug 1999 14:04:57 -0600 (MDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id UA15959; Tue, 3 Aug 1999 06:02:10 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Jim Bound Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-Reply-To: Your message of "Mon, 02 Aug 1999 13:43:39 -0400." <199908021743.NAA0000032040@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Aug 1999 06:02:09 +1000 Message-Id: <3405.933624129@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 02 Aug 1999 13:43:39 -0400 From: Jim Bound Message-ID: <199908021743.NAA0000032040@quarry.zk3.dec.com> | Well right now thats kind of how it must work. Yes, and that's what I was asking about, as in general, that's not a satisfactory method. Or not for the kind of dynamic information that is involved here (getting manually configured with a key is fine for the forward zone, as the name changes rarely, and this is easily possible - having to do the same for the address is beyond reasonable as a burden). | Well its working in practice now in a sense with the DHCPv4 servers but | as you say at least there is some "implied" authorziation btw the DHCPv4 | server and the client. But not necessarily any real authority btw the | DHCPv4 server and the DNS master of the zone. No, not necessarily, but it can usually be worked out, and this is the assumption that has generally been made, and which I think underpins the relevant DHCP options. That is, while there isn't necessarily a relationship between the admin of the DHCP server (who is allocating the addresses to various objects on the net) and the zone file maintainer for the in-addr.arpa (or ip6.int) zone file, who is publishing the assigned addresses, in most cases these two entities are likely to work closely together, and have arranged the mechanisms to do so - and if that involves allowing the DHCP server to dynamically update the zone file, then that will usually happen. For IPv4 this (or manually having an adress assigned, and having the zone file manually updated at the same time usually) are the only options. For IPv6 we have this alternate, and much simpler, mechanism. But it isn't going to be a viable mechanism unless we also have a way to get the DNS info updated - and right now I'm seeing nothing (not even any attempt) to find that method. Note that this really has nothing whatever to do with key exchange per se, though that may become a component. It is a question of authorisation, and where that comes from. Keys are just a method to demonstrate that authorisation exists, they don't provide it in the first place, and it is that first step that I don't see here. | 1. I would like to point out that because a DHCPv4ORv6 does the update | does not mean its secure in DNS. No, and this has nothing whatever do do with the question. | 2. There is an M bit in stateless addr conf which right now the only | solution being proposed is DHCPv6. Yes, I know, and if that method (any such method) is in use, then the problem I forsee doesn't arise. All the others you're alluding to are still there, but those are at least known, and being worked upon, so I'm not so worried about them. | 3. Right now in addrconf in the case of BIND there are mechanisms to | build the key but we are just testing this now in 8.2. This has nothing to do with the problem. | 4. As far as the IETF ruleset for authentication I am hoping thats in | DNSSEC but I can't find it now. I'm not sure what this means, but I suspect it is also missing the point. | 5. It appears us vendors will deploy per #3 above and not wait for the | issues with #4. Fine, but I still see nothing at all which addresses the problem here. | So maybe the result of your mail is we need to define key exchange | mechanisms as a standard for dyn upds to DNS? No, nothing like that at all. | If so then I think its irrelevant if the update is done by the client or | the server? Both need the same security measures. Yes, they do. The question is still how and where is the authorisation to use whatever security measures exist is granted. If a server is doing the update, this is easy, as the existence of the server is known, it can be allowed to use (via whatever mechanisms are appropriate) whatever it needs to get its job done. Since clients just appear, and the IPv6 autoconfig is supposed to let them just start running (assuming the net admin allows that, and remember I am assuming that here) I don't see how they're going to be authorised to do anything at all (related to the address). So we have no server (dhcp type server - this is the assumption) and unauthorised clients (not clients without a key - unauthorised clients). But we still have the ip6.int zone file to get updated, somehow. | Also there is nothing to prevent an IPv4 DHC client to upate DNS without | even going to the DHCPv4 server. No, of course not, assuming the authorisation exists. I believe that the general assumption is that it won't normally do that for the in-addr.arpa, since it isn't expected to have any a priori knowledge of what address it is going to be given, it also can't be expected to have any authorisation to make the update - however circumstances can be odd, and in some circumstances the client may be able to perform the update. The same would be true for IPv6 in similar circumstances. But this uninteresting case does nothing to solve the general problem. We get no closer to solve the problem by pointing out the cases in which the problem doesn't exist, unless you're also able to show that those cases cover all the relevant cases, and here, I don't believe that is possible. | I would argue there is no difference between either zone file once you have | the credentials at the client Of course. The question is where those credentials came from. I thought I had made that clear in the last mesage, if not in the first one. Perhaps I have this time? And once again, this has nothing to do with any kind of key distribution protocol - any of those must still require some kind of authentication before blindly handing out any key that some random client chooses to ask for. Its at that level that the problem arises here. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 16:55:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA18970 for ipng-dist; Mon, 2 Aug 1999 16:43:38 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18963 for ; Mon, 2 Aug 1999 16:43:31 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id QAA06471 for ipng@sunroof.eng.sun.com; Mon, 2 Aug 1999 16:41:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18945 for ; Mon, 2 Aug 1999 16:34:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA22962 for ; Mon, 2 Aug 1999 16:33:25 -0700 (PDT) Received: from toad.com (toad.com [140.174.2.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20365 for ; Mon, 2 Aug 1999 16:33:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id QAA21997; Mon, 2 Aug 1999 16:29:28 -0700 (PDT) Message-Id: <199908022329.QAA21997@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Robert Elz cc: Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net, gnu@toad.com Subject: Re: IPv6 and Dynamic DNS In-reply-to: <3405.933624129@munnari.OZ.AU> Date: Mon, 02 Aug 1999 16:29:27 -0700 From: John Gilmore Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For IPv6 we have this alternate, and much simpler, mechanism. But > it isn't going to be a viable mechanism unless we also have a way to > get the DNS info updated - and right now I'm seeing nothing (not > even any attempt) to find that method. I question the assertion that DNS info must be updated when an IPv6 node gets on a local Ethernet. If you're at home, your DNS forward and reverse info will be correct. If you're off visiting somewhere else, then it's not clear that you always want to repoint the forward entry, and if you aren't making a good forward entry then there's nothing to put into the reverse entry. You may well be right that IF you want to make a reverse entry, there's no good mechanism for it, but that's a separate issue than "dynamic IPv6 address assignment will fail unless we solve this critical issue". (In fact, if a DNS server receives a dynamic update for a reverse entry, and it can verify that the pointed-to forward entry matches, and the source address of the reverse entry is the address being updated, it could consider making the update. What can we do to improve this model so it need not trust the source address of the update packet?) John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 20:50:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA19098 for ipng-dist; Mon, 2 Aug 1999 20:41:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19091 for ; Mon, 2 Aug 1999 20:41:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA00474 for ; Mon, 2 Aug 1999 20:41:24 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA24563 for ; Mon, 2 Aug 1999 21:41:25 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id XAA23426; Mon, 2 Aug 1999 23:41:24 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000029031; Mon, 2 Aug 1999 23:41:23 -0400 (EDT) From: Jim Bound Message-Id: <199908030341.XAA0000029031@quarry.zk3.dec.com> To: Robert Elz cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Tue, 03 Aug 1999 06:02:09 +1000." <3405.933624129@munnari.OZ.AU> Date: Mon, 02 Aug 1999 23:41:23 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Your asking then where do the credentials come from to update the address->name mapping? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 2 20:52:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA19107 for ipng-dist; Mon, 2 Aug 1999 20:50:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19100 for ; Mon, 2 Aug 1999 20:50:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA06936 for ; Mon, 2 Aug 1999 20:49:57 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA25901 for ; Mon, 2 Aug 1999 21:49:55 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id XAA24106; Mon, 2 Aug 1999 23:49:54 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000000795; Mon, 2 Aug 1999 23:49:54 -0400 (EDT) From: Jim Bound Message-Id: <199908030349.XAA0000000795@quarry.zk3.dec.com> To: John Gilmore cc: Robert Elz , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Mon, 02 Aug 1999 16:29:27 PDT." <199908022329.QAA21997@toad.com> Date: Mon, 02 Aug 1999 23:49:53 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >(In fact, if a DNS server receives a dynamic update for a reverse >entry, and it can verify that the pointed-to forward entry matches, >and the source address of the reverse entry is the address being >updated, it could consider making the update. What can we do to improve >this model so it need not trust the source address of the update packet?) This is a question I can understand. Exactly. We have ddns working for both AAAA and PTR records from IPv6 addrconf. The issue is for my customers how is that made to be secure. What you ask is exactly what we need to solve. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 06:57:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA19411 for ipng-dist; Tue, 3 Aug 1999 06:46:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19404 for ; Tue, 3 Aug 1999 06:46:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA04597 for ; Tue, 3 Aug 1999 06:46:36 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA07635 for ; Tue, 3 Aug 1999 07:46:33 -0600 (MDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id NA01500; Tue, 3 Aug 1999 23:43:41 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: "Cutler, James R" Cc: Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-Reply-To: Your message of "Tue, 03 Aug 1999 06:37:30 -0400." <92D60A12331ED2119F5300A02461F04702A67B54@usahm009.exmi01.exch.eds.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Aug 1999 23:43:40 +1000 Message-Id: <19945.933687820@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 3 Aug 1999 06:37:30 -0400 From: "Cutler, James R" Message-ID: <92D60A12331ED2119F5300A02461F04702A67B54@usahm009.exmi01.exch.eds.com> | Can we backstep a bit and better define the business and technical need for | updating DNS reverse entries? This is certainly a valid question, and one of two responses I was half expecting. As long as we do it consciously, we can decide that the reverse lookups don't achieve anything that matters very much, and so we should just punt on how they would be automated (leave it to those who want them to pick their own way - using DHCPv6, or manually, or whatever). The other response I half expected was for someone to refer back to the "who are you" ICMP message that was once mooted as a possible method to perform this mapping - it has a host of other problems, but not the particular one raised. As long as the community decides, and makes known, the intended resolution of this - be it a solution I can't see, or one of the above, I'll be happy enough. I just don't want to see this issue ignored, so if someone is assuming that IP6.INT will just work, we either provide the mechanisms to make that so, or we educate them that it is not going to happen. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 08:18:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA19552 for ipng-dist; Tue, 3 Aug 1999 08:10:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19545 for ; Tue, 3 Aug 1999 08:10:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA13851 for ; Tue, 3 Aug 1999 08:10:45 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05255 for ; Tue, 3 Aug 1999 08:10:44 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id LAA21393; Tue, 3 Aug 1999 11:10:38 -0400 (EDT) Message-Id: <199908031510.LAA21393@cannes.aa.ans.net> To: "Matt Crawford" cc: Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Mon, 02 Aug 1999 13:44:59 CDT." <199908021845.NAA09712@gungnir.fnal.gov> Date: Tue, 03 Aug 1999 11:10:38 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford wrote: > > > MANAGEABLE, that is, it scales operationally. Below is a proposal for > > thoughts and consideration. > > --Jessica > > Jessica, > > Your draft is so succinct and clear that this demi-routing-clued > reader can absorb it in minutes. Thanks! > > Consider the situation after your model has been "symmetrized" -- > that is, when both ISP-1 and ISP-2 play the role of primary ISP for > Customer-A and assign it address space, and Customer-A announces two > specific routes to each ISP, and each ISP then announces one of them > to the other. I claim that this is only epsilon more complex than > your model, since the same entities are communicating with each other > at the same points and just announcing on additional prefix. Yet it > solves one of your "concerns" items without damaging anything in the > "advantages" section. > > I believe this symmetrized version is what the community is > visualizing. It adds complexity in the hosts compared to yours, but > most of that complexity has to be there anyway to support features > like mobility, renumbering and site-local addressing. From the > viewpoint of ISP operations and global routing, do you see any > drawbacks? > Matt I think routing wise, the proposal you outlined above would work. But I am really concerned about the requirement of multi-address per host, especially N (N>2) addresses per host is required if the site multihoming to N ISPs. I think it'd lead confusion in routing in the site and host management in general. The software of hosts and routers has to be more sophiscated. I personally tried multi-address (two addresses) on interfaces of site border routers to get around a problem in one of the network we built. That was not a good experience. The vendor just could not get the software work right. One major issue was it only allow the primary interface address not the secondary interface to pass dynamic routing information. It took the vendor a long time to fix this problem (by the way, the vendor is consider the lead in routing software). This was done just on a couple of routers, image to have hundreads and thousands of hosts with multiple addresses on each. Anyway, I suggest that before we jump into the multi-addressing scheme, let's throughly evaluate the complication and operation complexity associated with that. Thanks! --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 09:45:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA19710 for ipng-dist; Tue, 3 Aug 1999 09:33:54 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19703 for ; Tue, 3 Aug 1999 09:33:48 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA07174 for ipng@sunroof.eng.sun.com; Tue, 3 Aug 1999 09:32:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19341 for ; Tue, 3 Aug 1999 03:38:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA21194 for ; Tue, 3 Aug 1999 03:38:09 -0700 (PDT) Received: from ahmler2.mail.eds.com (ahmler2.mail.eds.com [192.85.154.76]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA03738 for ; Tue, 3 Aug 1999 04:38:08 -0600 (MDT) Received: from nnsa.eds.com (nnsa2.eds.com [192.85.154.30]) by ahmler2.mail.eds.com (8.9.3/8.9.3) with ESMTP id GAA04218; Tue, 3 Aug 1999 06:38:07 -0400 (EDT) Received: from usahm007.exmi01.exch.eds.com (usahm007.exmi01.exch.eds.com [207.37.138.147]) by nnsa.eds.com (8.9.3/8.9.3) with ESMTP id GAA03426; Tue, 3 Aug 1999 06:37:36 -0400 (EDT) Received: by usahm007.exmi01.exch.eds.com with Internet Mail Service (5.5.2448.0) id <30RD5FN9>; Tue, 3 Aug 1999 06:37:32 -0400 Message-ID: <92D60A12331ED2119F5300A02461F04702A67B54@usahm009.exmi01.exch.eds.com> From: "Cutler, James R" To: "'Robert Elz'" , Jim Bound Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: RE: IPv6 and Dynamic DNS Date: Tue, 3 Aug 1999 06:37:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can we backstep a bit and better define the business and technical need for updating DNS reverse entries? It seems clear that most usage is either: 1. for the convenience of the service provider, or 2. for "poor man's security". Is there another. Second, it seems that there is a clear differentiation between "just make the d... thing work", which autoconfiguration does admirably, and controlled update of DNS in response to address assignments. Whether one uses pure DHCP or adds a controlling element such as Lucent's QIP product, which manages both forward and reverse DNS entries, is determined by the network provider. It seems clear to me that autoconfiguration is the favored approach for small or temporary networks. The choice for large networks, as for example - EDS Intranet, may well be different. This implies that DNS updates from autoconfiguration may well not be a requirement. JimC -----Original Message----- From: Robert Elz [mailto:kre@MUNNARI.OZ.AU] Sent: Monday, August 02, 1999 4:02 PM To: Jim Bound Cc: ipng@sunroof.eng.sun.com; namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS Date: Mon, 02 Aug 1999 13:43:39 -0400 From: Jim Bound Message-ID: <199908021743.NAA0000032040@quarry.zk3.dec.com> | Well right now thats kind of how it must work. Yes, and that's what I was asking about, as in general, that's not a satisfactory method. Or not for the kind of dynamic information that is involved here (getting manually configured with a key is fine for the forward zone, as the name changes rarely, and this is easily possible - having to do the same for the address is beyond reasonable as a burden). | Well its working in practice now in a sense with the DHCPv4 servers but | as you say at least there is some "implied" authorziation btw the DHCPv4 | server and the client. But not necessarily any real authority btw the | DHCPv4 server and the DNS master of the zone. No, not necessarily, but it can usually be worked out, and this is the assumption that has generally been made, and which I think underpins the relevant DHCP options. That is, while there isn't necessarily a relationship between the admin of the DHCP server (who is allocating the addresses to various objects on the net) and the zone file maintainer for the in-addr.arpa (or ip6.int) zone file, who is publishing the assigned addresses, in most cases these two entities are likely to work closely together, and have arranged the mechanisms to do so - and if that involves allowing the DHCP server to dynamically update the zone file, then that will usually happen. For IPv4 this (or manually having an adress assigned, and having the zone file manually updated at the same time usually) are the only options. For IPv6 we have this alternate, and much simpler, mechanism. But it isn't going to be a viable mechanism unless we also have a way to get the DNS info updated - and right now I'm seeing nothing (not even any attempt) to find that method. Note that this really has nothing whatever to do with key exchange per se, though that may become a component. It is a question of authorisation, and where that comes from. Keys are just a method to demonstrate that authorisation exists, they don't provide it in the first place, and it is that first step that I don't see here. | 1. I would like to point out that because a DHCPv4ORv6 does the update | does not mean its secure in DNS. No, and this has nothing whatever do do with the question. | 2. There is an M bit in stateless addr conf which right now the only | solution being proposed is DHCPv6. Yes, I know, and if that method (any such method) is in use, then the problem I forsee doesn't arise. All the others you're alluding to are still there, but those are at least known, and being worked upon, so I'm not so worried about them. | 3. Right now in addrconf in the case of BIND there are mechanisms to | build the key but we are just testing this now in 8.2. This has nothing to do with the problem. | 4. As far as the IETF ruleset for authentication I am hoping thats in | DNSSEC but I can't find it now. I'm not sure what this means, but I suspect it is also missing the point. | 5. It appears us vendors will deploy per #3 above and not wait for the | issues with #4. Fine, but I still see nothing at all which addresses the problem here. | So maybe the result of your mail is we need to define key exchange | mechanisms as a standard for dyn upds to DNS? No, nothing like that at all. | If so then I think its irrelevant if the update is done by the client or | the server? Both need the same security measures. Yes, they do. The question is still how and where is the authorisation to use whatever security measures exist is granted. If a server is doing the update, this is easy, as the existence of the server is known, it can be allowed to use (via whatever mechanisms are appropriate) whatever it needs to get its job done. Since clients just appear, and the IPv6 autoconfig is supposed to let them just start running (assuming the net admin allows that, and remember I am assuming that here) I don't see how they're going to be authorised to do anything at all (related to the address). So we have no server (dhcp type server - this is the assumption) and unauthorised clients (not clients without a key - unauthorised clients). But we still have the ip6.int zone file to get updated, somehow. | Also there is nothing to prevent an IPv4 DHC client to upate DNS without | even going to the DHCPv4 server. No, of course not, assuming the authorisation exists. I believe that the general assumption is that it won't normally do that for the in-addr.arpa, since it isn't expected to have any a priori knowledge of what address it is going to be given, it also can't be expected to have any authorisation to make the update - however circumstances can be odd, and in some circumstances the client may be able to perform the update. The same would be true for IPv6 in similar circumstances. But this uninteresting case does nothing to solve the general problem. We get no closer to solve the problem by pointing out the cases in which the problem doesn't exist, unless you're also able to show that those cases cover all the relevant cases, and here, I don't believe that is possible. | I would argue there is no difference between either zone file once you have | the credentials at the client Of course. The question is where those credentials came from. I thought I had made that clear in the last mesage, if not in the first one. Perhaps I have this time? And once again, this has nothing to do with any kind of key distribution protocol - any of those must still require some kind of authentication before blindly handing out any key that some random client chooses to ask for. Its at that level that the problem arises here. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 12:40:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20096 for ipng-dist; Tue, 3 Aug 1999 12:21:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20089 for ; Tue, 3 Aug 1999 12:21:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA20355 for ; Tue, 3 Aug 1999 12:21:23 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15058 for ; Tue, 3 Aug 1999 12:21:18 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA02946; Tue, 3 Aug 1999 21:21:11 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA03756; Tue, 3 Aug 1999 21:21:11 +0200 (MET DST) Message-Id: <199908031921.VAA03756@givry.inria.fr> From: Francis Dupont To: "Matt Crawford" cc: Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of Mon, 02 Aug 1999 13:44:59 CDT. <199908021845.NAA09712@gungnir.fnal.gov> Date: Tue, 03 Aug 1999 21:21:09 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I believe this symmetrized version is what the community is visualizing. => this symmetrized version is very close to the "mutual backup" (draft-ietf-ngtrans-6bone-multi-01.txt section 5). If I take again Jessica's diagram: ISP-1 ---- ISP-2 link-1 \ / link-2 Customer-A The idea is simple, both ISP-1 and ISP-2 announce both ISP-1 and ISP-2 prefixes. With the standard BGP way to prefer shortest AS paths ISP-1 will be prefered for ISP-1 prefix routing and ISP-2 for ISP-2 prefix. This has wanted properties (good aggregation, insensitive to any single link/router/ISP failure, compatible with BGP default rule for route selection, ...). I know only two issues: this suppose a reciprocal agreement between ISP-1 and ISP-2, and this doesn't scale well with many ISPs (this is not transitive). One can easily make use of this, the only needed new thing is a link between ISP-1 and ISP-2 (not through the customer). In the G6 we have organized the G6 network (G6-bone) with both geographical and organization divisions, for instance INRIA Rocquencourt is near Paris and part of the INRIA organization, in order to make use of this we only need a link between Paris main point and INRIA main point: G6 /24 / \ Paris ---- INRIA /32 link-1 \ / link-2 INRIA near Paris /48 Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 12:45:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20105 for ipng-dist; Tue, 3 Aug 1999 12:28:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20098 for ; Tue, 3 Aug 1999 12:28:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA08136 for ; Tue, 3 Aug 1999 12:28:13 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17397 for ; Tue, 3 Aug 1999 12:28:12 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id PAA21319 for ; Tue, 3 Aug 1999 15:28:12 -0400 (EDT) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000011024; Tue, 3 Aug 1999 15:28:11 -0400 (EDT) Date: Tue, 3 Aug 1999 15:28:11 -0400 (EDT) From: Sowmini Varadhan Message-Id: <199908031928.PAA0000011024@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: RFC 2529 (6over4) Cc: varadhan@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Cyndi, We (the IPV6 team at Compaq) were looking at RFC 2529, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", and had some comments/questions that I have attached below. Could you please review and clarify? Thanks in advance, Sowmini ----------------------------------------------------------------------- This is a summary of comments received from Jim Bound, Mary Clouter, Blaise Corcoran, Gerri Harter, Jack McCann, Yannick Pouffary, Ken Powell, Sowmini Varadhan, Joe Vlcek, Eric Wong, and Vlad Yasevich, General comments It would aid readability if the spec unambiguously clarified the various steps leading up to the sending of a unicast packet on a 6-over-4 net. This could be done with an example that traces through some/all of the steps such as - send out multicast neighbor-discovery packets using the methods described in Section 6 - resolve the 6over4 link-layer address (defined in Section 5) of the next hop for the V6 destination - use this 6over4 link-layer address of the next hop as the V4 Destination address of the encapsulating header (Figure xxx in Section 3) for unicast V6 packets. It was not clear, when reading the spec, if the spec assumes that a node has "virtual interface" to the (virtual) 6over4 net, or does not make any such assumption. Abstract .. Section 1 Since this is a technique to send IPV6 over IPV4 over foo, where foo may be something other than ethernet, should we delete references to "virtual Ethernet" (line numbers listed below)? 42 IPv4 multicast as a "virtual Ethernet". 97 "6over4" and colloquially as "virtual Ethernet". Section 2 It was not clear why the spec rules (lines below) that the DF bit MUST NOT be set. Perhaps this injunction classifies as a "SHOULD NOT"? 121 ... However, the IPv4 "do not 122 fragment" bit MUST NOT be set in the encapsulating IPv4 header. Section 3 The reference to the "datalink" header below is confusing, because it is not clear if the intended datalink refers to the IPV4 header or the physical (e.g., ethernet) link header. 151 If there are IPv4 options, then padding SHOULD be added to the IPv4 152 header such that the IPv6 header starts on a boundary that is a 32- 153 bit offset from the end of the datalink header. Unless it changes the intended meaning, it appears that it could be stated more directly as: "If there are IPv4 options, then padding SHOULD be added to the IPv4 header such that the total size of the IPv4 header is a multiple of 32 bits". Question about the recommended default value of the TTL field- is there a heuristic behind the suggested value of 8? (Is it approximately 1/2 the diameter of a standard network IGP site?) There appears to be a hierarchy in the various methods to contain 6over4 multicasts within a site- specifically, it appears that TTL scoping becomes mandatory if administrative scoping (as described in RFC 2365) is not supported in the site. Should the 6over4 spec emphasize this? Section 4 See General comments regarding virtual interfaces to the 6over4 network- does the "IPv4 virtual interface" in line 182 refer to the virtual interface to the 6over4 network? If so, could the phrase "IPv4 virtual interface" be changed to "6over4 virtual interface"? If no assumptions are made about virtual interfaces to the 6over4 network, then the phrase should be left out. 182 The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is 183 formed by appending the Interface Identifier, as defined above, to 184 the prefix FE80::/64. Section 5 The zero byte padding used in the link layer option is conflicting with the position of padding chosen in the only other document that I see which attempts to define the format of Link-Layer address options. rfc2529 says: 198 199 +-------+-------+-------+-------+-------+-------+-------+-------+ 200 | Type |Length | must be zero | IPv4 Address | 201 +-------+-------+-------+-------+-------+-------+-------+-------+ 202 while draft-conta-ipv6-trans-tunnel-00.txt says 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | IPv4 | +- -+ 4 | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should the 2 be consistent? Section 7 Scaling issues: In a 6over4 network, each V6 multicast address potentially maps to a distinct V4 multicast group. For example, a node is required to compute and join the associated solicited-node multicast address for every unicast and anycast address it is assigned, and the the V4 multicast groups resulting from the 6over4 mapping could cause the multicast router at the site to handle over N IPV4 multicast addresses, where N is the number of IPV6 hosts using the 6over4 network. However, paragraph 1 252 The multicast mechanism described in Section 6 above appears to have 253 essentially the same scaling properties as native IPv6 over most 254 media, except for the slight reduction in MTU size which will 255 slightly reduce bulk throughput... does not fully address this aspect.. is it really true that the 6over4 multicast mechanism, with dependancies on V4 multicasting, scales like native IPV6? The ambivalency regarding assumptions about virtual interfaces to the 6over4 network led to some confusion about the interpretation of Section 7. (See General comments regarding virtual interfaces to the 6over4 network) If the spec does not (wish to) make any assumption about the presence of virtual interfaces to the 6over4 network, then it is not clear what sorts of tasks are implied by the "enabling" operation below: 264 ... Interfaces of the IPv6 router and hosts 265 will of course need to be enabled in "6over4" mode. In the fourth paragraph, 287 During transition, routers may need to advertise at least two IPv6 288 prefixes, one for the native LAN (e.g. Ethernet) and one for 289 "6over4". As with any IPv6 prefix assigned to an IPv6 subnet, the 290 latter MUST be unique within its scope, whether site-local or global 291 addressing is used. it would help if the need for two IPV6 prefixes was demonstrated with an example. It was not clear when a router "may need" the 2 prefixes. - if no assumptions are made about having a separate virtual interface to the 6over4 net, then it's not clear why/when the node would need 2 prefixes. - if, instead, the spec *does* assume that a node has a separate virtual interface to the 6over4 net, then the requirement of unique non-link-local addresses already mandates that the router must be advertising/using distinct IPv6 prefixes for the native LAN and the 6over4 network, so that the fourth paragraph is somewhat distracting and redundant? Similarly the "MUST" clause in the fifth paragraph could be clarified by an example, or a detailed justification. 293 Also note that when a router is handling both native LAN and "6over4" 294 on the same physical interface, during stateless autoconfiguration, 295 there is a period when IPv6 link-local addresses are used, in both 296 cases with the prefix FE80::/64. Note that the prefix-length for 297 these link-local adddress MUST then be 128 so that the two cases can 298 be distinguished. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 12:48:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20126 for ipng-dist; Tue, 3 Aug 1999 12:39:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20119 for ; Tue, 3 Aug 1999 12:39:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA04799 for ; Tue, 3 Aug 1999 12:39:35 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27999 for ; Tue, 3 Aug 1999 13:39:21 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA03003; Tue, 3 Aug 1999 21:39:19 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA02813; Tue, 3 Aug 1999 21:39:18 +0200 (MET DST) Message-Id: <199908031939.VAA02813@givry.inria.fr> From: Francis Dupont To: Jessica Yu cc: "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of Tue, 03 Aug 1999 11:10:38 EDT. <199908031510.LAA21393@cannes.aa.ans.net> Date: Tue, 03 Aug 1999 21:39:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: But I am really concerned about the requirement of multi-address per host, especially N (N>2) addresses per host is required if the site multihoming to N ISPs. => RFC 2260 (again) explains in its section 6 why a multi-homed site should have multiple prefixes (then multi-address per host). The text is about IPv4 with CIDR and the aggregation constraints of IPv6 are far stronger then this requirement will remain... In fact with IPv6 any interfaces should get two or more addresses, even on a mono-homed site, because of scoped addresses. Multi-address per host is an IPv6 fact and there are many available or proposed tools (like autoconfigurations, A6 and router renumbering) which should help us. I think it'd lead confusion in routing in the site and host management in general. The software of hosts and routers has to be more sophiscated. => I agree, the common multi-address support shows its limits (or its bugs) but it can (should!) be fixed (even by leading vendors in routing software :-). Anyway, I suggest that before we jump into the multi-addressing scheme, let's throughly evaluate the complication and operation complexity associated with that. => multihoming just makes it worse but this issue is there from the beginning of IPv6 (then it should be no more a real issue?) Thanks Francis.Dupont@inria.fr PS: Web "virtual-hosting" is another reason to support multi-addressing and one can put hundreds of addresses (=> performance issue too). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 14:11:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA20222 for ipng-dist; Tue, 3 Aug 1999 14:06:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20215 for ; Tue, 3 Aug 1999 14:06:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA28273 for ; Tue, 3 Aug 1999 14:06:12 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24079 for ; Tue, 3 Aug 1999 14:06:11 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id RAA22467; Tue, 3 Aug 1999 17:06:06 -0400 (EDT) Message-Id: <199908032106.RAA22467@cannes.aa.ans.net> To: Francis.Dupont@inria.fr cc: "Matt Crawford" , ipng@sunroof.eng.sun.com, jyy@ans.net Subject: Re: Session Stability (was multi-homing vs route aggregation) Date: Tue, 03 Aug 1999 17:06:05 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, > In your previous mail you wrote: > > But I am really concerned about the requirement of multi-address per host, > especially N (N>2) addresses per host is required if the site multihoming > to N ISPs. > >=> RFC 2260 (again) explains in its section 6 why a multi-homed site >>should have multiple prefixes (then multi-address per host). >The text is about IPv4 with CIDR and the aggregation constraints of >IPv6 are far stronger then this requirement will remain... I do not think RFC2260 suggests anything that multiple addresses should be assigned to each host as you mentioned. Please read it (again) carefully. >In fact with IPv6 any interfaces should get two or more addresses, >even on a mono-homed site, because of scoped addresses. >Multi-address per host is an IPv6 fact and there are many available >or proposed tools (like autoconfigurations, A6 and router renumbering) >which should help us. I (again) suggest that before we jump into the multi-addressing per host scheme, let's throughly evaluate the complication and operation complexity associated with that. We can ignore the issue but it won't go away. Didn't we tried it before with the multihoming routing issue? Now, we still have to face it. In the end, it's the network operators/engineers who are deciding if IPv6 should be deployed in their networks. If they are not convinced it's operational viable, what will happen? > > I think it'd lead confusion in routing in the site and host management in > general. The software of hosts and routers has to be more sophiscated. > >=> I agree, the common multi-address support shows its limits (or its bugs) >but it can (should!) be fixed (even by leading vendors in routing software :-). > Anyway, I suggest that before we jump into the multi-addressing scheme, > let's throughly evaluate the complication and operation complexity > associated with that. >=> multihoming just makes it worse but this issue is there from the >beginning of IPv6 (then it should be no more a real issue?) > >Thanks >Francis.Dupont@inria.fr >PS: Web "virtual-hosting" is another reason to support multi-addressing >and one can put hundreds of addresses (=> performance issue too). We are talking about scaling here. Operational complexity is far different between managing some multi-addressed 'web-hosting' servers vs. managing hundreds and thousands of multi-addressed hosts in a site. cheers! --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 16:23:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA20344 for ipng-dist; Tue, 3 Aug 1999 16:15:45 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20337 for ; Tue, 3 Aug 1999 16:15:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id QAA07609 for ipng@sunroof.eng.sun.com; Tue, 3 Aug 1999 16:13:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20321 for ; Tue, 3 Aug 1999 16:09:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA15569 for ; Tue, 3 Aug 1999 16:09:30 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08796 for ; Tue, 3 Aug 1999 16:09:30 -0700 (PDT) Received: from whistle.com (tlambert.whistle.com [207.76.205.208]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id QAA07261; Tue, 3 Aug 1999 16:02:15 -0700 (PDT) Message-ID: <37A773E7.676D5359@whistle.com> Date: Tue, 03 Aug 1999 15:57:43 -0700 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: "Cutler, James R" CC: "'Robert Elz'" , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS References: <92D60A12331ED2119F5300A02461F04702A67B54@usahm009.exmi01.exch.eds.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cutler, James R wrote: > > Can we backstep a bit and better define the business and > technical need for updating DNS reverse entries? It seems > clear that most usage is either: 1. for the convenience > of the service provider, or 2. for "poor man's security". > Is there another. I think it's mostly "poor man's security", so things like "sendmail" won't balk at talking to you. I believe the theory is that you can trust forward mappings, because of who owns the delegation, but you can't trust reverse mappings, mostly for the same reasons. To establish a trusted peer identity, a "getpeername()" is issued. We know that they aren't lying about their IP address becuse everyone disables source routing, and because they want packets back from us. We then do a "gethostbyaddr()" to get the canonical name, and then we look it up to see if it had the same IP address, because we trust the domain to serve us the IP address we are expecting. If we don't get this, then someone who owns the IP address, but not the domain, is spoofing us with an invalid name in their reverse map. I don't know how "poor" this really is; we are only interested in establishing that the forward and reverse mappings are transitive, so we know that whoever has the legally delegated ownership of the domain is who we are talking to, so that we can hold the domain owner accountable for the actions of an IP address. We may, additionally, use this to ensure that the domain claimed in data over the protocol transaction matches the domain of the owner of the IP address. This means that we hold the machine with that IP address accountable for providing valid data. This is a widely deployed SPAM countermeasure, based on the theory that: o Domains are expensive o IP address blocks are expensive o "Burning" either of these in order to SPAM should be a more expensive proposition than the value of SPAM'ming in the first place. This is also widely deployed for accounting records (logging, billing, etc.). > It seems clear to me that autoconfiguration is the > favored approach for small or temporary networks. The > choice for large networks, as for example - EDS Intranet, > may well be different. This implies that DNS updates from > autoconfiguration may well not be a requirement. I think you need to make a distinction between: o Machines you trust, because they are installed behind your firewall o Machines you trust because they are your customers o Machines you trust because the trust is temporary o Machine you don't trust, but which someone else might, based on their forward and reverse mappings being transitive I think the question comes down to a succinct "who owns the address assigned during autoconfiguration?". I think the answer is "partly the assignor, and partly the assignee". Then the question becomes "if I trust them enough to give them an address, why don't I trust them enough to accept a reverse mapping update from that address telling me who they think they are?". You could even be more explicit, and ask the question like this: "for a laptop in an airport access point, a telecommuting center, or a "wired" boardroom in which business between two companies is being conducted, how can I establish reverse mappings so that the laptop is not crippled in capability vis a vis a permanently installed workstation?". You might also ask "how can I do this such that I don't have to start trusting certificates and scanning laptop IR ports/WaveLAN cards as they enter my premesis?". I think this argument boils down to "why be protective of the reverse mappings at all, if they aren't useful for something about which we need to be protective?". One might take the view that, in the future, there will be no explicit Intranets, and what we now think of as an Intranet will be replaced by a virtual Intranet which consists of a VPN and some way to authenticate it to "get inside". In such a world, do we need to establish individual identity (setting aside the desirability of getting billed per-packet, which varies depending on whether or not you are a telco, and the personal privacy issues), or merely establish proxy identity, ala "they're inside, they must be trustworthy people". "Inside", in this case, being "the reverse mapping matches the forward mapping", until we can get around to implementing the world, above. -- Terry Lambert -- Whistle Communications, Inc. -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 18:56:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA20466 for ipng-dist; Tue, 3 Aug 1999 18:53:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20459 for ; Tue, 3 Aug 1999 18:52:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA28032 for ; Tue, 3 Aug 1999 18:52:49 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25243 for ; Tue, 3 Aug 1999 18:52:48 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id SAA13489; Tue, 3 Aug 1999 18:46:27 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id SAA07329; Tue, 3 Aug 1999 18:46:27 -0700 (PDT) Received: from tdc97-cyndi.tdc.3com.com (tdc27pc.tdc.3com.com [139.87.12.114]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id SAA11471; Tue, 3 Aug 1999 18:46:27 -0700 (PDT) Message-Id: <3.0.32.19990803183935.00f0dcdc@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 03 Aug 1999 18:39:35 -0700 To: Sowmini Varadhan , ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: Re: RFC 2529 (6over4) Cc: varadhan@zk3.dec.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Wow - I am delighted that you and your team have given it such a thorough review. At 03:28 PM 8/3/99 -0400, Sowmini Varadhan wrote: > > >Brian, Cyndi, > >We (the IPV6 team at Compaq) were looking at RFC 2529, "Transmission >of IPv6 over IPv4 Domains without Explicit Tunnels", and had some >comments/questions that I have attached below. Could you please >review and clarify? > >Thanks in advance, >Sowmini > >----------------------------------------------------------------------- >This is a summary of comments received from Jim Bound, Mary Clouter, >Blaise Corcoran, Gerri Harter, Jack McCann, Yannick Pouffary, Ken Powell, >Sowmini Varadhan, Joe Vlcek, Eric Wong, and Vlad Yasevich, > >General comments > >It would aid readability if the spec unambiguously clarified >the various steps leading up to the sending of a unicast packet on >a 6-over-4 net. This could be done with an example that traces >through some/all of the steps such as > - send out multicast neighbor-discovery packets > using the methods described in Section 6 > - resolve the 6over4 link-layer address (defined in Section 5) > of the next hop for the V6 destination > - use this 6over4 link-layer address of the next hop > as the V4 Destination address of the encapsulating header > (Figure xxx in Section 3) for unicast V6 packets. Since we modelled the draft directly from the RFC 2464, "Transmission of IPv6 Packets over Ethernet Networks" where there is no such section, we kept to that format except where comments from reviewers prompted us to add information - such as section 7 for Scaling and Transition Issues and the Appendix A that describes how the solicited node multicast addresses are constructed. However, it can certainly be made more clear with an overview of the concepts and the steps in the key goal of the mechanism. I think this overview would be better at the beginning, as a new section following the Introduction, before the specifics of the mechanism are detailed, rather than in another appendix. The other choice is to leave this RFC in the current terse style and provide the fuller description in an applicability statement RFC - this approach would contribute towards the progress of 6over4 as a standard, and since the text would be largely descriptive rather than a change to the specification, it might be the right direction to go with this - do you agree or not? > >It was not clear, when reading the spec, if the spec assumes that a >node has "virtual interface" to the (virtual) 6over4 net, or does not >make any such assumption. > >Abstract .. Section 1 > >Since this is a technique to send IPV6 over IPV4 over foo, >where foo may be something other than ethernet, should we >delete references to "virtual Ethernet" (line numbers listed below)? > > 42 IPv4 multicast as a "virtual Ethernet". > 97 "6over4" and colloquially as "virtual Ethernet". Both the "virtual interface" and the "virtual Ethernet" were terms introduced into the text from the implementation project at UCLA on the freeBSD platform. They are useful conceptual aids, not codified technical terms. They have worked for some people, but they evidently have not worked for you! I personally don't believe that the RFC should dictate a "virtual interface", rather that the internal representation of this is specific to an implementation, and outside the reach of standardization. If a MIB required somehow that an interface object exist to organize the various bits of information associated with this "virtual interface", then the term would become more solidly part of the spec. As for "virtual Ethernet", I find that many people do make a hard link between 6over4 and a physical Ethernet, which is not the intent. The use of the word "Ethernet" is to be evocative of the nice plug and play features that can be used on a multicast-capable subnet. It is NOT to imply that 6over4 is only good on LAN media. > >Section 2 > >It was not clear why the spec rules (lines below) that the >DF bit MUST NOT be set. Perhaps this injunction classifies as a "SHOULD NOT"? > 121 ... However, the IPv4 "do not > 122 fragment" bit MUST NOT be set in the encapsulating IPv4 header. > In the region of an IPv4 network that supports a 6over4 IPv6 subnet there may be IPv4 subnets with MTU smaller than Ethernet (we used the MTU of the Ethernet as a reasonable default for the MTU on 6over4). Even though at the IPv6 level, Path MTU will yield a high value, that piece of IPv4 with the smaller MTU will be invisible to the IPv6 Path MTU. Also, there are tricks on IPv4 multi-link PPP that force fragmentation of IPv4 frames to achieve a fairness (chop up FTP data frames so that smaller packets can be interleaved amoungst the fragments of the larger frame, sort of a mock-ATM strategy). I'm sure there are plenty of other reasons why setting the DF bit would create difficult to detect failures - I personally think the MUST NOT is right - how convinced are you that SHOULD NOT is right? >Section 3 > >The reference to the "datalink" header below is confusing, because it >is not clear if the intended datalink refers to the IPV4 header or >the physical (e.g., ethernet) link header. > 151 If there are IPv4 options, then padding SHOULD be added to the IPv4 > 152 header such that the IPv6 header starts on a boundary that is a 32- > 153 bit offset from the end of the datalink header. > >Unless it changes the intended meaning, it appears that it could >be stated more directly as: > "If there are IPv4 options, then padding SHOULD be added to the IPv4 > header such that the total size of the IPv4 header is a multiple of > 32 bits". Actually, I think the paragraph is unnecessary, as the IPv4 header MUST be padded to a multiple of 32 bits, as dictated by the IPv4 length field, which expresses the number of 32-bit words in the IPv4 header :-) Maybe we should remove the paragraph since it is not only unnecessary but confusing? > > >Question about the recommended default value of the TTL field- is >there a heuristic behind the suggested value of 8? (Is it approximately 1/2 the >diameter of a standard network IGP site?) > >There appears to be a hierarchy in the various methods to contain >6over4 multicasts within a site- specifically, it appears that TTL scoping >becomes mandatory if administrative scoping (as described in RFC 2365) >is not supported in the site. Should the 6over4 spec emphasize this? I think TTL scoping for multicast has been found to be unworkable - but is still a poor man's scooping tool. There is still work being done in deploying the admin scoping, but I think the basic rules for the organization-local scope have been established. Admittedly, establishing the perimeter of a 6over4 subnet is central to the concept, and that can usually be established with filters at the IPv4 level today, perhaps with more sophisticated techniques later on. This is probably appropriate material for that applicability statement. Do you agree or not? > > >Section 4 > >See General comments regarding virtual interfaces to the 6over4 network- >does the "IPv4 virtual interface" in line 182 refer to >the virtual interface to the 6over4 network? If so, could the phrase >"IPv4 virtual interface" be changed to "6over4 virtual interface"? > >If no assumptions are made about virtual interfaces to the 6over4 network, >then the phrase should be left out. > > 182 The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is > 183 formed by appending the Interface Identifier, as defined above, to > 184 the prefix FE80::/64. > I agree - this section needs some work to better "suspend" the 6over4 interface above the (possibly) physical interfaces from which it borrows an IPv4 address. IPv4 is the subnet. >Section 5 > >The zero byte padding used in the link layer option is conflicting with >the position of padding chosen in the only other document that I see >which attempts to define the format of Link-Layer address options. >rfc2529 says: > 198 > 199 +-------+-------+-------+-------+-------+-------+-------+-------+ > 200 | Type |Length | must be zero | IPv4 Address | > 201 +-------+-------+-------+-------+-------+-------+-------+-------+ > 202 >while draft-conta-ipv6-trans-tunnel-00.txt says > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 0 | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 2 | IPv4 | > +- -+ > 4 | Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 6 | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >Should the 2 be consistent? Do they need to be? I can't find this draft, but I did find the RFC2497 for shipping IPv6 over ARCNET, and the padding there is post the media address. I somehow think this is minor - is there a need for consistency? > >Section 7 >Scaling issues: In a 6over4 network, each V6 multicast address >potentially maps to a distinct V4 multicast group. For example, >a node is required to compute and join the associated solicited-node >multicast address for every unicast and anycast address it is assigned, >and the the V4 multicast groups resulting from the 6over4 mapping >could cause the multicast router at the site to handle over N >IPV4 multicast addresses, where N is the number of IPV6 hosts using the >6over4 network. However, paragraph 1 > > 252 The multicast mechanism described in Section 6 above appears to have > 253 essentially the same scaling properties as native IPv6 over most > 254 media, except for the slight reduction in MTU size which will > 255 slightly reduce bulk throughput... > >does not fully address this aspect.. is it really true that the 6over4 >multicast mechanism, with dependancies on V4 multicasting, scales like >native IPV6? Funny, I was worried about too many IPv6 addresses mapping to the same IPv4 multicast address, since we were hashing into only 16 bits. I think it probably remains to be seen, though the 6over4 domains are expected to be sparsely populated, and that the region each 6over4 domain subtends is not very large. Usage will tell. Also, this could provide a metric for what is a reasonable size of IPv4 network region to support a single 6over4 subnet. I don't know that we can specify it from here - perhaps another section in that applicability statement. It is not intended that there be one large 6over4 subnet that spans the entire Internet. It does not need to scale indefinitely - but it is good to understand the limits of it's scalability. The number of multicast addresses created within the IPv4 organization-local scope is one element that will determine the size to which a single 6over4 subnet can scale, and that will largely depend on the size of the multicast forwarding tables in the IPv4 routers. The amount of traffic is negligible. Most of the IPv4 multicast routers have ample space - they claim. The bigger concern I have is that there is talk about changing the model for IPv4 multicast, since they seem to be getting nowhere in the attempts to make interdomain multicast scale, and there is much talk of single sender groups being the priority, and difficulty when the sender does not already belong to the group (not on the distribution tree), because these groups of 6over4 are multiple-sender, and the sender is almost never also a receiver. As for scaling, I think pushing ND over IPv4 multicast will be able to take advantage of the IGMP snooping that is common now in LAN technologies. So it will scale much better on modern LANs than ND running directly on'the LAN. > >The ambivalency regarding assumptions about virtual interfaces to >the 6over4 network led to some confusion about the interpretation >of Section 7. (See General comments regarding virtual interfaces to >the 6over4 network) > >If the spec does not (wish to) make any assumption about the presence of >virtual interfaces to the 6over4 network, then it is not clear >what sorts of tasks are implied by the "enabling" operation below: > > 264 ... Interfaces of the IPv6 router and hosts > 265 will of course need to be enabled in "6over4" mode. I agree - the only interface is to IPv4. The physcial interface references is very misleading. The point is that these interfaces of IPv4 must be either included in the 6over4 subnet, or excluded, and that has to do with the establishing the perimeter of the administrative scoping multicast region. > >In the fourth paragraph, > > 287 During transition, routers may need to advertise at least two IPv6 > 288 prefixes, one for the native LAN (e.g. Ethernet) and one for > 289 "6over4". As with any IPv6 prefix assigned to an IPv6 subnet, the > 290 latter MUST be unique within its scope, whether site-local or global > 291 addressing is used. > >it would help if the need for two IPV6 prefixes was demonstrated with an >example. It was not clear when a router "may need" the 2 prefixes. > - if no assumptions are made about having a separate virtual interface > to the 6over4 net, then it's not clear why/when the node would need > 2 prefixes. > - if, instead, the spec *does* assume that a node has a separate > virtual interface to the 6over4 net, then the requirement of unique > non-link-local addresses already mandates that the router must be > advertising/using distinct IPv6 prefixes for the native LAN and the > 6over4 network, so that the fourth paragraph is somewhat distracting > and redundant? I agree - the 6over4 must really be disassociated from any physical interface that IPv4 has - or that IPv6 has, for that matter. > >Similarly the "MUST" clause in the fifth paragraph could be clarified >by an example, or a detailed justification. > > 293 Also note that when a router is handling both native LAN and "6over4" > 294 on the same physical interface, during stateless autoconfiguration, > 295 there is a period when IPv6 link-local addresses are used, in both > 296 cases with the prefix FE80::/64. Note that the prefix-length for > 297 these link-local adddress MUST then be 128 so that the two cases can > 298 be distinguished. I have no sympathy for this clause either - I think it was heavily influenced by the internals of the freeBSD implementation. The system within which I work would have no such problems, since the incoming path is still knowable at the IPv6 level, so it is trivial to distinguish IPv6 frames that come in on different interfaces even though their IPv6 address is identical. Cyndi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 3 18:57:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA20475 for ipng-dist; Tue, 3 Aug 1999 18:56:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20468 for ; Tue, 3 Aug 1999 18:55:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA01300 for ; Tue, 3 Aug 1999 18:55:44 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA26304 for ; Tue, 3 Aug 1999 18:55:43 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id VAA11195; Tue, 3 Aug 1999 21:55:42 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000013172; Tue, 3 Aug 1999 21:55:41 -0400 (EDT) From: Jim Bound Message-Id: <199908040155.VAA0000013172@quarry.zk3.dec.com> To: "Cutler, James R" cc: "'Robert Elz'" , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Tue, 03 Aug 1999 06:37:30 EDT." <92D60A12331ED2119F5300A02461F04702A67B54@usahm009.exmi01.exch.eds.com> Date: Tue, 03 Aug 1999 21:55:41 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Question for IPv6 stateless addrconf. Right now when you install and configure IPv6 from our implementation it asks you if you want dyn dns upds to be performed for you. It seems from your mail we should ask the question do you want forward mappings and reverse mappings for ip6.int within the zone of the domain of that network? So we need add more granularity to that set up interface? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 03:01:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA20921 for ipng-dist; Wed, 4 Aug 1999 02:58:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20914 for ; Wed, 4 Aug 1999 02:58:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA11445 for ; Wed, 4 Aug 1999 02:58:15 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA05236 for ; Wed, 4 Aug 1999 02:58:14 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA17642; Wed, 4 Aug 1999 11:58:12 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA14572; Wed, 4 Aug 1999 11:58:12 +0200 (MET DST) Message-Id: <199908040958.LAA14572@givry.inria.fr> From: Francis Dupont To: Sowmini Varadhan cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of Tue, 03 Aug 1999 15:28:11 EDT. <199908031928.PAA0000011024@quarry.zk3.dec.com> Date: Wed, 04 Aug 1999 11:58:06 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: General comments It was not clear, when reading the spec, if the spec assumes that a node has "virtual interface" to the (virtual) 6over4 net, or does not make any such assumption. => I implemented RFC 2529 some days ago then I read carefully the RFC and I have not exactly the same idea about it. I think the basic idea is very clear, the site is considered as a large LAN (named "virtual Ethernet" because >90% LANs are Ethernets), unicast and multicast transmissions are done by unicast and multicast IPv4 routing inside the site using IPv6 over IPv4 standard stuff. Then there are only three details to specify: - interface ID (just use :0:0:x.y.z.t as usual) - IPv4 in link-layer info (use 0:0:x:y:z:t, another mapping like x:y:z:t:0:0 is possible but I have to recognize I prefer the RFC 2529 one) - IPv6 to IPv4 multicast mapping (the RFC proposal is reasonnable even there is no real rationate for the default TTL) I have implemented it as a virtual interface but I agree you have other choices. In fact the only issue is if it is rather easy to translate IPv6 multicast joins into IPv4, leaves are near impossible to translate in BSD kernels. I have some parts of the initial FreeBSD work then I verified this is a real issue and I picked up the name (*). Regards Francis.Dupont@inria.fr PS: lines 297, 313 and 397: spelling errors PPS: (*) a real problem because now I have 4 flavors of IPv6 over IPv4: - automatic tunnels (SIT) - configured tunnels (CTI) - 6 over 4 (VET) - 6 to 4 (STF) (a clone of SIT with less than 10% of diffs) I'll add any other if you give to me both a spec and a name (:-)... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 04:30:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA20966 for ipng-dist; Wed, 4 Aug 1999 04:28:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20958 for ; Wed, 4 Aug 1999 04:27:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA04086 for ; Wed, 4 Aug 1999 04:27:51 -0700 (PDT) Received: from spine.adsl.duke.edu (spine.adsl.duke.edu [152.16.67.45]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19113 for ; Wed, 4 Aug 1999 04:27:51 -0700 (PDT) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.67.44]) by spine.adsl.duke.edu (8.8.7/8.8.7) with ESMTP id HAA00412; Wed, 4 Aug 1999 07:22:45 -0400 Received: from hygro.adsl.duke.edu (localhost [127.0.0.1]) by hygro.adsl.duke.edu (8.8.7/8.7.3) with ESMTP id HAA01732; Wed, 4 Aug 1999 07:28:57 -0400 Message-Id: <199908041128.HAA01732@hygro.adsl.duke.edu> To: Francis Dupont cc: Jessica Yu , "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-Reply-To: Message from Francis Dupont of "Tue, 03 Aug 1999 21:39:02 +0200." <199908031939.VAA02813@givry.inria.fr> Date: Wed, 04 Aug 1999 07:28:57 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > PS: Web "virtual-hosting" is another reason to support multi-addressing > and one can put hundreds of addresses (=> performance issue too). In the web world, this is apparently no longer a compelling argument for multiple addresses. This was an issue in older versions of HTTP (1.0). HTTP 1.1 fixed this problem, and indeed, extensions to 1.0 that have been widely deployed fixed this as well. My understanding is that this is no longer an issue today. I.e., today, HTTP queries sent to the server include the DNS name in the request (older versions included only the path to the right of the DNS name). Thus, one can have multiple DNS names map to the same address and everything works as intended. Note also that for virtual hosting, the prefix stays the same, only the interface ID part of an address needs to change. This is not multi-homing per se and doesn't impact route aggregation. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 05:16:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA20994 for ipng-dist; Wed, 4 Aug 1999 05:13:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20987 for ; Wed, 4 Aug 1999 05:13:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA05846 for ; Wed, 4 Aug 1999 05:13:15 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAB23276 for ; Wed, 4 Aug 1999 06:13:15 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id OAA19276; Wed, 4 Aug 1999 14:13:12 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA07857; Wed, 4 Aug 1999 14:13:12 +0200 (MET DST) Message-Id: <199908041213.OAA07857@givry.inria.fr> From: Francis Dupont To: Jessica Yu cc: "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of Tue, 03 Aug 1999 17:06:05 EDT. <199908032106.RAA22467@cannes.aa.ans.net> Date: Wed, 04 Aug 1999 14:13:11 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >=> RFC 2260 (again) explains in its section 6 why a multi-homed site >>should have multiple prefixes (then multi-address per host). >The text is about IPv4 with CIDR and the aggregation constraints of >IPv6 are far stronger then this requirement will remain... I do not think RFC2260 suggests anything that multiple addresses should be assigned to each host as you mentioned. Please read it (again) carefully. => there are two sections about address allocation and assignment in RFC 2260. The section 6 explain why a single address space or prefix is not a good solution (with two cases: an independent prefix or the prefix of one ISP) and the arguments are still (ie even more) valid in the IPv6 framework. The section 4 says "a particular node (host) may be assigned address(es) out of a single prefix, or may have addresses from different prefixes". Then RFC 2260 seems a bit ambiguous about this question (which is not in fact addressed by it)... I (again) suggest that before we jump into the multi-addressing per host scheme, let's throughly evaluate the complication and operation complexity associated with that. => we jumped into it as soon as aggregation became the important thing in addressing... We can ignore the issue but it won't go away. Didn't we tried it before with the multihoming routing issue? Now, we still have to face it. => this issue is not ignored but I expect this is solved in host and router kernels (modulo address selection which is still open). In the end, it's the network operators/engineers who are deciding if IPv6 should be deployed in their networks. If they are not convinced it's operational viable, what will happen? => I believe you have two concerns: - bugs in kernel code, for instance in router software with "secondary addresses" - management costs First point should be fixed (but I'd like to have a confirmation from head router vendors :-). Second point is supposed to be dealt with autoconfigurations, A6 RRs and router renumbering. In any cases we should try this in the reality then to switch to the 6bone mailing list? Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 05:21:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA21037 for ipng-dist; Wed, 4 Aug 1999 05:20:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21030 for ; Wed, 4 Aug 1999 05:20:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA06286 for ; Wed, 4 Aug 1999 05:20:03 -0700 (PDT) Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28088 for ; Wed, 4 Aug 1999 05:20:03 -0700 (PDT) Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Wed, 4 Aug 1999 13:19:16 +0100 Received: from zhard000.europe.nortel.com ([47.101.225.14]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id P2BCMRYB; Wed, 4 Aug 1999 13:19:12 +0100 Received: from europem01.nt.com (phard02m.europe.nortel.com [47.101.229.52]) by zhard000.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PLQ3CXTF; Wed, 4 Aug 1999 13:19:15 +0100 Message-ID: <37A82FFC.9BFA1CEC@europem01.nt.com> Date: Wed, 04 Aug 1999 13:20:12 +0100 From: "Andrew Macpherson" Organization: Nortel Networks X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Thomas Narten CC: Francis Dupont , Jessica Yu , Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) References: <199908041128.HAA01732@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mostly correct. One still needs "traditional multi-homing" for Secure Servers Thomas Narten wrote: > > > PS: Web "virtual-hosting" is another reason to support multi-addressing > > and one can put hundreds of addresses (=> performance issue too). > > In the web world, this is apparently no longer a compelling argument > for multiple addresses. This was an issue in older versions of HTTP > (1.0). HTTP 1.1 fixed this problem, and indeed, extensions to 1.0 that > have been widely deployed fixed this as well. My understanding is that > this is no longer an issue today. > > I.e., today, HTTP queries sent to the server include the DNS name in > the request (older versions included only the path to the right of the > DNS name). Thus, one can have multiple DNS names map to the same > address and everything works as intended. > > Note also that for virtual hosting, the prefix stays the same, only > the interface ID part of an address needs to change. This is not > multi-homing per se and doesn't impact route aggregation. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 05:32:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA21059 for ipng-dist; Wed, 4 Aug 1999 05:29:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21052 for ; Wed, 4 Aug 1999 05:29:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA26983 for ; Wed, 4 Aug 1999 05:29:41 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26150 for ; Wed, 4 Aug 1999 06:29:40 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id OAA19543; Wed, 4 Aug 1999 14:29:38 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA03213; Wed, 4 Aug 1999 14:29:37 +0200 (MET DST) Message-Id: <199908041229.OAA03213@givry.inria.fr> From: Francis Dupont To: Thomas Narten cc: Jessica Yu , "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of Wed, 04 Aug 1999 07:28:57 EDT. <199908041128.HAA01732@hygro.adsl.duke.edu> Date: Wed, 04 Aug 1999 14:29:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > PS: Web "virtual-hosting" is another reason to support multi-addressing > and one can put hundreds of addresses (=> performance issue too). In the web world, this is apparently no longer a compelling argument for multiple addresses... => yes, new HTTP has been fixed (then change "is" in "has been another ...") Note also that for virtual hosting, the prefix stays the same, only the interface ID part of an address needs to change. This is not multi-homing per se and doesn't impact route aggregation. => it has been only another reason... I don't think to have the same prefix makes things simpler too. I have added the post scriptum because in BSD kernels interface address code was improved only with an architectural bug fix and the replacement in some flavors of the linked list of addresses by a hash table. Motives were for the first point to get rid of an old bad choice and for the second point performance problem with "virtual-hosting". I think we can say that modern Unixes support multi-address without problems (ie without bugs), can't we? Regards Francis.Dupont@inria.fr PS: about multi-addresses I don't know how this works with DHCPv6 (I asked at the last IETF meeting then I expect to get an answer). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 08:09:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA21173 for ipng-dist; Wed, 4 Aug 1999 08:06:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21166 for ; Wed, 4 Aug 1999 08:06:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29547 for ; Wed, 4 Aug 1999 08:06:24 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15331 for ; Wed, 4 Aug 1999 08:06:23 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id LAA23612; Wed, 4 Aug 1999 11:06:12 -0400 (EDT) Message-Id: <199908041506.LAA23612@cannes.aa.ans.net> To: Francis.Dupont@inria.fr cc: "Matt Crawford" , ipng@sunroof.eng.sun.com, jyy@ans.net Subject: Re: Session Stability (was multi-homing vs route aggregation) Date: Wed, 04 Aug 1999 11:06:12 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The section 4 says "a particular node (host) may be assigned address(es) >out of a single prefix, or may have addresses from different prefixes". >Then RFC 2260 seems a bit ambiguous about this question (which is not >in fact addressed by it)... Siting this sentence and concluding that this document proposes or advocates multiaddress per host is a bit of stretch. The document mainly proposed is to assign address from each ISP to different subset of the hosts e.g. pref-A to a subset of host and pref-B to another subset. The assignment criteria is "to use the topological proximity of a node (host) to a particular ISP as a criteria for selecting" as described in section 4. The machenism proposed in rfc2260 does not whatsoever require all of the hosts assigned with multiple addresses each. It does not prevent someone for some reason like to do it. > I (again) suggest that before we jump into the multi-addressing > per host scheme, let's throughly evaluate the complication and > operation complexity associated with that. >=> we jumped into it as soon as aggregation became the important thing >in addressing... I do not want to be nasty here. But How many people who already jumped into multiaddress per host for all hosts in multihoming sites and even single-home sites have operational and engineering experiences of real networks? Has any implication as a result of this been discussed? > We can ignore the issue but it won't go away. Didn't we tried > it before with the multihoming routing issue? Now, we still > have to face it. > >=> this issue is not ignored but I expect this is solved in host and >router kernels (modulo address selection which is still open). > In the end, it's the network operators/engineers who are deciding > if IPv6 should be deployed in their networks. If they are not > convinced it's operational viable, what will happen? >=> I believe you have two concerns: > - bugs in kernel code, for instance in router software with > "secondary addresses" > - management costs >First point should be fixed (but I'd like to have a confirmation from >head router vendors :-). Second point is supposed to be dealt with >autoconfigurations, A6 RRs and router renumbering. >In any cases we should try this in the reality then to switch to >the 6bone mailing list? > Reality checking is really needed here. Again I suggest a thorough study is needed to evaluate the implication of requiring all hosts in a multihoming site (now someone even suggested that for sinlge-homed sites) with multiple addresses. I think I've made my point clear and should stop now. --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 09:48:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA21284 for ipng-dist; Wed, 4 Aug 1999 09:43:40 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21277 for ; Wed, 4 Aug 1999 09:43:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA08709 for ipng@sunroof.eng.sun.com; Wed, 4 Aug 1999 09:41:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20529 for ; Tue, 3 Aug 1999 20:36:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA27877 for ; Tue, 3 Aug 1999 20:36:56 -0700 (PDT) Received: from odie.av8.com (odie.av8.com [198.3.136.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA21593 for ; Tue, 3 Aug 1999 21:36:55 -0600 (MDT) Received: from daanders.gte.com (h132-197-204-177.gte.com [132.197.204.177]) by odie.av8.com (8.9.3/8.8.5) with SMTP id XAA28177; Tue, 3 Aug 1999 23:37:56 -0400 (EDT) Message-Id: <3.0.32.19990803233006.013af2f8@odie.av8.com> X-Sender: dean@odie.av8.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 03 Aug 1999 23:34:49 -0400 To: Terry Lambert , "Cutler, James R" From: Dean Anderson Subject: Re: IPv6 and Dynamic DNS Cc: "'Robert Elz'" , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Having reverse dns mappings is no security at all. Both are easily spoofed. Having a valid reverse map does not make the connection any more or less trustworthy. Only really stupid admins make trust decisions based on DNS information. Indeed, there is another just as invalid "security" idea that one should never use reverse mappings because the information might be used by crackers. Woe unto anyone who needs to get these two "security conscious" networks to speak to each other. One will not put out reverse maps, the other will not trust anyone whose reverse maps are not "correct". This is about as silly as believing that using RFC1918 addresses enhance security because they are "unroutable". Lets just let both of these go into the history of foolish ideas. Please don't build this foolishness into DNS. That would be a disaster. --Dean Around 03:57 PM 8/3/1999 -0700, rumor has it that Terry Lambert said: >Cutler, James R wrote: >> >> Can we backstep a bit and better define the business and >> technical need for updating DNS reverse entries? It seems >> clear that most usage is either: 1. for the convenience >> of the service provider, or 2. for "poor man's security". >> Is there another. > >I think it's mostly "poor man's security", so things like >"sendmail" won't balk at talking to you. > >I believe the theory is that you can trust forward mappings, >because of who owns the delegation, but you can't trust >reverse mappings, mostly for the same reasons. > >To establish a trusted peer identity, a "getpeername()" is >issued. We know that they aren't lying about their IP >address becuse everyone disables source routing, and >because they want packets back from us. > >We then do a "gethostbyaddr()" to get the canonical name, >and then we look it up to see if it had the same IP address, >because we trust the domain to serve us the IP address we >are expecting. If we don't get this, then someone who >owns the IP address, but not the domain, is spoofing us >with an invalid name in their reverse map. > > >I don't know how "poor" this really is; we are only >interested in establishing that the forward and reverse >mappings are transitive, so we know that whoever has >the legally delegated ownership of the domain is who we >are talking to, so that we can hold the domain owner >accountable for the actions of an IP address. > >We may, additionally, use this to ensure that the domain >claimed in data over the protocol transaction matches the >domain of the owner of the IP address. This means that >we hold the machine with that IP address accountable for >providing valid data. > >This is a widely deployed SPAM countermeasure, based on >the theory that: > >o Domains are expensive >o IP address blocks are expensive >o "Burning" either of these in order to SPAM should > be a more expensive proposition than the value of > SPAM'ming in the first place. > >This is also widely deployed for accounting records (logging, >billing, etc.). > > >> It seems clear to me that autoconfiguration is the >> favored approach for small or temporary networks. The >> choice for large networks, as for example - EDS Intranet, >> may well be different. This implies that DNS updates from >> autoconfiguration may well not be a requirement. > >I think you need to make a distinction between: > >o Machines you trust, because they are installed > behind your firewall > >o Machines you trust because they are your customers > >o Machines you trust because the trust is temporary > >o Machine you don't trust, but which someone else > might, based on their forward and reverse mappings > being transitive > >I think the question comes down to a succinct "who owns >the address assigned during autoconfiguration?". > >I think the answer is "partly the assignor, and partly >the assignee". Then the question becomes "if I trust >them enough to give them an address, why don't I trust >them enough to accept a reverse mapping update from that >address telling me who they think they are?". > > >You could even be more explicit, and ask the question >like this: "for a laptop in an airport access point, a >telecommuting center, or a "wired" boardroom in which >business between two companies is being conducted, how >can I establish reverse mappings so that the laptop is not >crippled in capability vis a vis a permanently installed >workstation?". > >You might also ask "how can I do this such that I don't >have to start trusting certificates and scanning laptop >IR ports/WaveLAN cards as they enter my premesis?". > > >I think this argument boils down to "why be protective >of the reverse mappings at all, if they aren't useful for >something about which we need to be protective?". > > >One might take the view that, in the future, there will >be no explicit Intranets, and what we now think of as >an Intranet will be replaced by a virtual Intranet which >consists of a VPN and some way to authenticate it to "get >inside". > >In such a world, do we need to establish individual >identity (setting aside the desirability of getting >billed per-packet, which varies depending on whether or >not you are a telco, and the personal privacy issues), >or merely establish proxy identity, ala "they're inside, >they must be trustworthy people". > >"Inside", in this case, being "the reverse mapping >matches the forward mapping", until we can get around >to implementing the world, above. > > >-- Terry Lambert >-- Whistle Communications, Inc. >-- terry@whistle.com >------------------------------------------------------------------- >This is formal notice under California Assembly Bill 1629, enacted >9/26/98 that any UCE sent to my email address will be billed $50 >per incident to the legally allowed maximum of $25,000. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 11:07:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA21489 for ipng-dist; Wed, 4 Aug 1999 11:00:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21482 for ; Wed, 4 Aug 1999 11:00:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08241 for ; Wed, 4 Aug 1999 11:00:04 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27480 for ; Wed, 4 Aug 1999 11:00:02 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA98002; Wed, 4 Aug 1999 19:00:00 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA29364; Wed, 4 Aug 1999 18:59:58 +0100 (BST) Message-ID: <37A87F28.5D788BEA@hursley.ibm.com> Date: Wed, 04 Aug 1999 12:58:00 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Francis Dupont CC: Sowmini Varadhan , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) References: <199908040958.LAA14572@givry.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This point came up in 6to4 as well and it seems to vary quite a bit between implementations. Personally I think referring to virtual or pseudo interface makes the concepts much clearer, but we probably need a phrase indicating that it is not an implementation requirement. Apart from that I think Cyndi has replied just about as I would have done, if she hadn't got there first. Sowmini, do you think there is any urgency to revise the RFC? Brian Francis Dupont wrote: > > In your previous mail you wrote: > > General comments > > It was not clear, when reading the spec, if the spec assumes that a > node has "virtual interface" to the (virtual) 6over4 net, or does not > make any such assumption. > > => I implemented RFC 2529 some days ago then I read carefully the RFC > and I have not exactly the same idea about it. > I think the basic idea is very clear, the site is considered as a large > LAN (named "virtual Ethernet" because >90% LANs are Ethernets), unicast > and multicast transmissions are done by unicast and multicast IPv4 > routing inside the site using IPv6 over IPv4 standard stuff. > Then there are only three details to specify: > - interface ID (just use :0:0:x.y.z.t as usual) > - IPv4 in link-layer info (use 0:0:x:y:z:t, another mapping like > x:y:z:t:0:0 is possible but I have to recognize I prefer the RFC 2529 one) > - IPv6 to IPv4 multicast mapping (the RFC proposal is reasonnable even > there is no real rationate for the default TTL) > I have implemented it as a virtual interface but I agree you have other > choices. In fact the only issue is if it is rather easy to translate > IPv6 multicast joins into IPv4, leaves are near impossible to translate > in BSD kernels. I have some parts of the initial FreeBSD work then I verified > this is a real issue and I picked up the name (*). > > Regards > > Francis.Dupont@inria.fr > > PS: lines 297, 313 and 397: spelling errors > PPS: (*) a real problem because now I have 4 flavors of IPv6 over IPv4: > - automatic tunnels (SIT) > - configured tunnels (CTI) > - 6 over 4 (VET) > - 6 to 4 (STF) (a clone of SIT with less than 10% of diffs) > I'll add any other if you give to me both a spec and a name (:-)... > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 11:18:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA21629 for ipng-dist; Wed, 4 Aug 1999 11:12:11 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21618 for ; Wed, 4 Aug 1999 11:12:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA09084 for ipng@sunroof.eng.sun.com; Wed, 4 Aug 1999 11:10:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21450 for ; Wed, 4 Aug 1999 10:49:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA05505 for ; Wed, 4 Aug 1999 10:49:48 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22663 for ; Wed, 4 Aug 1999 10:49:48 -0700 (PDT) Received: from whistle.com (tlambert.whistle.com [207.76.205.208]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id KAA57716; Wed, 4 Aug 1999 10:40:55 -0700 (PDT) Message-ID: <37A87A12.F73E7D1B@whistle.com> Date: Wed, 04 Aug 1999 10:36:18 -0700 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Dean Anderson CC: "Cutler, James R" , "'Robert Elz'" , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS References: <3.0.32.19990803233006.013af2f8@odie.av8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dean Anderson wrote: > > Having reverse dns mappings is no security at all. Both are > easily spoofed. Having a valid reverse map does not make > the connection any more or less trustworthy. Only really > stupid admins make trust decisions based on DNS information. How do you spoof a forward mapping, without exploiting some known (and presumably, fixed) bug? I trust . to not lie about the delegation of .com.; I trust .com. to not lie about the delegation of .whistle.com.; I trust .whistle.com. to not lie about host names in its zone of control, or its delegations, and so on. Consider that if I define "fred.whistle.com" in my DNS to point to 198.3.136.10, I am establishing a name in the whistle.com domain for this IP address. It matters very little that I don't own STARSHIP.av8.com (your machine, which has that IP address), I am permitted to name it within any domain for which control has been delegated to me by . and .com. (and so on). But I can not update the reverse record for 198.3.136.10, because that has been delegated to .arpa. by ., and then subsequently to starship.av8.com., and I can't change that because I'm not in charge of any of the intermediates that are between . and you. This trust is implicit in the organization of the DNS (try to get certificates added to the top level servers; I dare you; I double-dog dare you -- others have tried). You can lie in a forward record, but you can't lie in the reverse unless you own the IP address mapping. And if you own the IP address mapping, both the domain name and the IP address are logged, so welcome to the RBL, buddy: you'll never send email to me from that IP address again, and I don't give a damn what you name it. > Indeed, there is another just as invalid "security" idea > that one should never use reverse mappings because the > information might be used by crackers. I think you meant "provide", not "use", right? > Woe unto anyone who needs to get these two > "security conscious" networks to speak to each other. > One will not put out reverse maps, the other will not > trust anyone whose reverse maps are not "correct". Yes. The latter set is pretty much a 1:1 intersection set with "anyone who runs sendmail 8.9.x or above in its default configuration". Per address, time-limited certificate would be a better soloution to this problem. Unfortunately, there is still an RSA patent or two in the way of that being standardized without inviting patent infringement. If this impacts someone's ability to SPAM -- so the hell what? It's _intended_ to. > This is about as silly as believing that using RFC1918 > addresses enhance security because they are "unroutable". > Lets just let both of these go into the history of foolish > ideas. > > Please don't build this foolishness into DNS. That would > be a disaster. It's already implicit to DNS's delegation-based organization (see above: it is deployed as a technical soloution to a social problem -- "ya cann'a change the laws of physics", so we design our laws of physics so "ya cann'a misbehave"). In your opinion, what is the proper purpose of reverse records, if one is not to look them up, or trust their contents should one be so "foolish" as to look them up? Is it for displaying in browsers and log files, allowing the humans who configured them to lie, by proxy, to the humans whose programs look them up? And if you answer none of the other questions, whatsoever: What is the rationale for not allowing a machine, granted a particular address, to set its reverse record? The actual agency we are talking about trusting is the address delegation agency. If we decide to not trust them, then we can dike their entire authority block out of the list of people to whom we are willing to talk. -- Terry Lambert -- Whistle Communications, Inc. -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 11:59:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA21740 for ipng-dist; Wed, 4 Aug 1999 11:24:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21733 for ; Wed, 4 Aug 1999 11:24:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA28067 for ; Wed, 4 Aug 1999 11:24:06 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09052 for ; Wed, 4 Aug 1999 11:24:05 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA203378; Wed, 4 Aug 1999 19:23:59 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA16666; Wed, 4 Aug 1999 19:23:54 +0100 (BST) Message-ID: <37A884C5.270A0BD8@hursley.ibm.com> Date: Wed, 04 Aug 1999 13:21:57 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Jessica Yu CC: Francis.Dupont@inria.fr, Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) References: <199908041506.LAA23612@cannes.aa.ans.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jessica Yu wrote: ... > > I (again) suggest that before we jump into the multi-addressing > > per host scheme, let's throughly evaluate the complication and > > operation complexity associated with that. > > >=> we jumped into it as soon as aggregation became the important thing > >in addressing... > > I do not want to be nasty here. But How many people who already > jumped into multiaddress per host for all hosts in multihoming > sites and even single-home sites have operational and engineering > experiences of real networks? Well, I did for a while, and we renumbered it too. Given the choice between renumbering each host instantaneously, and running with multiple prefixes for a few months (or indefinitely), I'll choose multiple prefixes *any* time. This has been built into the IPv6 model for ever and it isn't going to be an ugly add-on, so I see no reason to fear it unduly. And whatever the solution for long-term multihoming, we *must* support multiple prefixes for renumbering purposes. > ... Has any implication as a result > of this been discussed? Yes, the biggest worry is DNS and that is where the A6 record came from. Since a principal objective here is perfect or near-perfect provider aggregation, I can't see anything but improvement in routing operations. Wouldn't IPv4 routing be easier with perfect CIDR aggregation (one CIDR block per ISP)? Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 12:22:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA21805 for ipng-dist; Wed, 4 Aug 1999 11:56:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21798 for ; Wed, 4 Aug 1999 11:56:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA17705 for ; Wed, 4 Aug 1999 11:56:23 -0700 (PDT) Received: from cannes.aa.ans.net (cannes.aa.ans.net [147.225.32.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23767 for ; Wed, 4 Aug 1999 11:56:24 -0700 (PDT) Received: from localhost (jyy@localhost) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id OAA24547; Wed, 4 Aug 1999 14:56:06 -0400 (EDT) Message-Id: <199908041856.OAA24547@cannes.aa.ans.net> To: Brian E Carpenter cc: Jessica Yu , Francis.Dupont@inria.fr, Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Wed, 04 Aug 1999 13:21:57 CDT." <37A884C5.270A0BD8@hursley.ibm.com> Date: Wed, 04 Aug 1999 14:56:06 -0400 From: Jessica Yu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > I (again) suggest that before we jump into the multi-addressing >> > per host scheme, let's throughly evaluate the complication and >> > operation complexity associated with that. >> >> >=> we jumped into it as soon as aggregation became the important thing >> >in addressing... >> >> I do not want to be nasty here. But How many people who already >> jumped into multiaddress per host for all hosts in multihoming >> sites and even single-home sites have operational and engineering >> experiences of real networks? > >Well, I did for a while, and we renumbered it too. Given the choice >between renumbering each host instantaneously, and running with >multiple prefixes for a few months (or indefinitely), I'll choose >multiple prefixes *any* time. This has been built into the IPv6 model >for ever and it isn't going to be an ugly add-on, so I see no >reason to fear it unduly. And whatever the solution for long-term >multihoming, we *must* support multiple prefixes for renumbering .purposes. To me, supporting multiple prefixes and providing options for operators (if they choose to use it while re-numbering) is very different than deploying a routing system which absolutely requires multiple prefixes per host i.e. the multiple addresses on each host have to be there all the time. >> ... Has any implication as a result >> of this been discussed? > >Yes, the biggest worry is DNS and that is where the A6 record came from. >Since a principal objective here is perfect or near-perfect >provider aggregation, I can't see anything but improvement in >routing operations. Wouldn't IPv4 routing be easier with >perfect CIDR aggregation (one CIDR block per ISP)? But there are other mechanisms to achieve routing aggregation while not requiring every host assigned with multiple addresses. draft-yu-simple-ipv6multihoming-00.txt is one of them. cheers! --Jessica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 12:22:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA21789 for ipng-dist; Wed, 4 Aug 1999 11:50:38 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21782 for ; Wed, 4 Aug 1999 11:50:28 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA09150 for ipng@sunroof.eng.sun.com; Wed, 4 Aug 1999 11:48:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21746 for ; Wed, 4 Aug 1999 11:47:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA16059 for ; Wed, 4 Aug 1999 11:47:45 -0700 (PDT) Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20160 for ; Wed, 4 Aug 1999 11:47:46 -0700 (PDT) Received: from nnsa.eds.com (nnsa2.eds.com [192.85.154.30]) by ns1.eds.com (8.9.3/8.9.1) with ESMTP id OAA05265; Wed, 4 Aug 1999 14:47:44 -0400 (EDT) Received: from usahm007.exmi01.exch.eds.com (usahm007.exmi01.exch.eds.com [207.37.138.147]) by nnsa.eds.com (8.9.3/8.9.3) with ESMTP id OAA27662; Wed, 4 Aug 1999 14:47:13 -0400 (EDT) Received: by usahm007.exmi01.exch.eds.com with Internet Mail Service (5.5.2448.0) id <30RD7J8W>; Wed, 4 Aug 1999 14:47:08 -0400 Message-ID: <92D60A12331ED2119F5300A02461F04702A67B73@usahm009.exmi01.exch.eds.com> From: "Cutler, James R" To: "'terry@whistle.com'" Cc: "'ipng@sunroof.eng.sun.com'" , "'namedroppers@internic.net'" Subject: FW: IPv6 and Dynamic DNS Date: Wed, 4 Aug 1999 14:47:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Terry Lambert wrote: In your opinion, what is the proper purpose of reverse records, if one is not to look them up, or trust their contents should one be so "foolish" as to look them up? What is the rationale for not allowing a machine, granted a particular address, to set its reverse record? Cutler Replied: In today's network, reverse records are generally created for the convenience of the network provider. They are useful for simplifying log analysis, especially for things like sendmail logs and traceroute. In well controlled networks, reverse records are invaluable for diagnostics for other application environments. There is nothing "foolish" about this. Assuming any security implication of reverse resolution, though, would generally be foolish. A typical rationale for not allowing a machine to set it's reverse record is that it is the responsibility of DHCP to do so. Another is that the network provider may desire to label the addresses with permanent labels, regardless of what mobile users may or may not happen to use them. Again - this is for the convenience of the network provider. Nothing an end user does (which requires a TCP/IP connection) should require knowledge of either the assigned address or the reverse lookup of the assigned address. NOTE. The position stated above is independent of IPv4 versus IPv6, or even the address assignment method - it applies to static address assignments as well. Conclusion: It is probably unwise to complicate Stateless Autoconfiguration in IPv6 with any DNS issues. As I understand it, the Draft Standard implicitly assumes some prior knowledge of destination addresses, or at least a nameserver address. Where this is not viable, DHCP is always an option for host stack configuration. The DHCP provider will then make the decision on how and whether to do any DNS updates at all. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 13:00:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA21977 for ipng-dist; Wed, 4 Aug 1999 12:41:54 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21968 for ; Wed, 4 Aug 1999 12:41:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id MAA09204 for ipng@sunroof.eng.sun.com; Wed, 4 Aug 1999 12:39:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21824 for ; Wed, 4 Aug 1999 12:13:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA24754 for ; Wed, 4 Aug 1999 12:13:18 -0700 (PDT) Received: from akira.aus.us.mids.org (akira.aus.us.mids.org [38.159.59.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01146 for ; Wed, 4 Aug 1999 12:13:18 -0700 (PDT) Received: from mids.org (localhost [127.0.0.1]) by akira.aus.us.mids.org (8.9.2/8.9.2) with ESMTP id OAA29359; Wed, 4 Aug 1999 14:10:48 -0500 (CDT) Message-Id: <199908041910.OAA29359@akira.aus.us.mids.org> From: "John S. Quarterman" To: Terry Lambert Cc: "John S. Quarterman" cc: Dean Anderson , "Cutler, James R" , "'Robert Elz'" , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Wed, 04 Aug 1999 10:36:18 PDT." <37A87A12.F73E7D1B@whistle.com> Date: Wed, 04 Aug 1999 14:10:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Dean Anderson wrote: >> >> Having reverse dns mappings is no security at all. Both are >> easily spoofed. Having a valid reverse map does not make >> the connection any more or less trustworthy. Only really >> stupid admins make trust decisions based on DNS information. > >How do you spoof a forward mapping, without exploiting >some known (and presumably, fixed) bug? > > >I trust . to not lie about the delegation of .com.; I trust >.com. to not lie about the delegation of .whistle.com.; I >trust .whistle.com. to not lie about host names in its zone >of control, or its delegations, and so on. You break into the machine that is serving whistle.com and you change its DNS records. Doubtless others have also been attacked by this method. Checking forward against reverse DNS is still better than nothing. A cracker must at least crack both servers to fake that, or use some other, perhaps more difficult, method. Thanks, John -- John S. Quarterman President, Matrix Information and Directory Services (MIDS) mids@mids.org, http://www.mids.org, +1-512-451-7602, fax: +1-512-452-0127 1106 Clayton Lane, Suite 501W, Austin, TX 78723, U.S.A. See our new Matrix IQ: http://www.miq.net/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 13:16:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA22085 for ipng-dist; Wed, 4 Aug 1999 13:08:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22078 for ; Wed, 4 Aug 1999 13:08:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA11070 for ; Wed, 4 Aug 1999 13:08:13 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26229 for ; Wed, 4 Aug 1999 13:08:11 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 838561A6; Wed, 4 Aug 1999 16:08:09 -0400 (EDT) To: "John S. Quarterman" Cc: Terry Lambert , Dean Anderson , "Cutler, James R" , "'Robert Elz'" , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS References: <199908041910.OAA29359@akira.aus.us.mids.org> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 04 Aug 1999 16:08:09 -0400 In-Reply-To: "John S. Quarterman"'s message of "Wed, 04 Aug 1999 14:10:47 -0500" Message-ID: <87yafr1f86.fsf@jekyll.piermont.com> Lines: 44 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Faking DNS replies is bloody easy. Queries and replies are matched up with a 16 bit number, so even if you randomize the numbers, brute force will allow you to insert spoofed information at least part of the time. If you can sniff a network that you're attacking, getting hosts to believe totally faked up DNS replies is even easier. Good security never relies on DNS information (unless you are using signed records with the DNS security extensions).l "John S. Quarterman" writes: > >How do you spoof a forward mapping, without exploiting > >some known (and presumably, fixed) bug? > > > > > >I trust . to not lie about the delegation of .com.; I trust > >.com. to not lie about the delegation of .whistle.com.; I > >trust .whistle.com. to not lie about host names in its zone > >of control, or its delegations, and so on. > > You break into the machine that is serving whistle.com > and you change its DNS records. Doubtless others have > also been attacked by this method. > > Checking forward against reverse DNS is still better than nothing. > A cracker must at least crack both servers to fake that, or use > some other, perhaps more difficult, method. > > Thanks, > John > -- > John S. Quarterman > President, Matrix Information and Directory Services (MIDS) > mids@mids.org, http://www.mids.org, +1-512-451-7602, fax: +1-512-452-0127 > 1106 Clayton Lane, Suite 501W, Austin, TX 78723, U.S.A. > See our new Matrix IQ: http://www.miq.net/ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 13:35:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA22165 for ipng-dist; Wed, 4 Aug 1999 13:26:25 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22158 for ; Wed, 4 Aug 1999 13:25:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id NAA09470 for ipng@sunroof.eng.sun.com; Wed, 4 Aug 1999 13:23:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22115 for ; Wed, 4 Aug 1999 13:22:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA25234 for ; Wed, 4 Aug 1999 13:22:12 -0700 (PDT) Received: from xfrsparc.tic.com (www.st-michaels.org [206.225.55.38]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02379 for ; Wed, 4 Aug 1999 13:22:09 -0700 (PDT) Received: from casa-pc.tic.com (casa-pc.tic.com [206.225.55.34]) by xfrsparc.tic.com (8.9.1/8.9.1) with ESMTP id PAA07275; Wed, 4 Aug 1999 15:22:04 -0500 (CDT) Received: from casa-pc.tic.com by casa-pc.tic.com (8.9.3/sub.1.6) id PAA01952; Wed, 4 Aug 1999 15:22:04 -0500 Message-Id: <199908042022.PAA01952@casa-pc.tic.com> To: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Wed, 04 Aug 1999 14:10:47 CDT." <199908041910.OAA29359@akira.aus.us.mids.org> Date: Wed, 04 Aug 1999 15:22:04 -0500 From: Smoot Carl-Mitchell Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >John Quarterman wrote: >>Dean Anderson wrote: >>> >>> Having reverse dns mappings is no security at all. Both are >>> easily spoofed. Having a valid reverse map does not make >>> the connection any more or less trustworthy. Only really >>> stupid admins make trust decisions based on DNS information. > >You break into the machine that is serving whistle.com >and you change its DNS records. Doubtless others have >also been attacked by this method. One can also conceive of a person in the middle attacks where DNS responses are changed in flight. Given there is no authentication of DNS responses, the system pretty much trusts that everyone with authoritative DNS servers will handle their site security in a reasonable manner. Strong cryptographic authentication would be ideal, but is probably overkill for most applications and would likely add too much overhead to DNS because all apps do not need that level of security or trust. >Checking forward against reverse DNS is still better than nothing. >A cracker must at least crack both servers to fake that, or use >some other, perhaps more difficult, method. John is correct. It is not perfect, but it does prevent the more obvious and easy DNS spoofing types of attacks. If I had a really sensitive service I was offering and I really wanted to be sure of the identity of the client connecting to my service, I would not trust the DNS information, but instead rely on some other cryptographically secure method. Smoot Carl-Mitchell -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 13:56:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA22268 for ipng-dist; Wed, 4 Aug 1999 13:52:28 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22261 for ; Wed, 4 Aug 1999 13:52:22 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id NAA09630 for ipng@sunroof.eng.sun.com; Wed, 4 Aug 1999 13:50:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22224 for ; Wed, 4 Aug 1999 13:50:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA20834 for ; Wed, 4 Aug 1999 13:50:05 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14354 for ; Wed, 4 Aug 1999 13:50:04 -0700 (PDT) Received: from whistle.com (tlambert.whistle.com [207.76.205.208]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA69202; Wed, 4 Aug 1999 13:48:08 -0700 (PDT) Message-ID: <37A8A5F3.6592C4BB@whistle.com> Date: Wed, 04 Aug 1999 13:43:31 -0700 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: "Cutler, James R" CC: "'ipng@sunroof.eng.sun.com'" , "'namedroppers@internic.net'" Subject: Re: FW: IPv6 and Dynamic DNS References: <92D60A12331ED2119F5300A02461F04702A67B73@usahm009.exmi01.exch.eds.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cutler, James R wrote: > In today's network, reverse records are generally created > for the convenience of the network provider. They are > useful for simplifying log analysis, especially for things > like sendmail logs and traceroute. You can't trust a reverse record for logging, unless you (minimally) also log the IP address. This is truly minimal, in that it requires a human to be able to determine that "somenthing fishy is going on", by somehow realizing that the IP address and the DNS name do not, in fact correlate. Human beings, being what they are, are unlikely to notice logging of intrusions, etc., unless the domain name doesn't match the one they are expecting. To alleviate this, most programs that rely on reverse records for logging purposed will do a forward lookup of the reported name, and if the result does not match the IP address being reversed, note the fact at a high importance that the name is probably being spoofed. > In well controlled networks, reverse records are > invaluable for diagnostics for other application > environments. There is nothing "foolish" about this. > > Assuming any security implication of reverse resolution, > though, would generally be foolish. I think your statement about highly controlled environments contradicts your statement about security implications. If the environment is controlled, then implications may be safely drawn. > A typical rationale for not allowing a machine to set > it's reverse record is that it is the responsibility of > DHCP to do so. This rationale, incorrectly assumes the existance of a DHCP service. Ad hoc networking was one of the intended design goals of IPv6. Additionally, much work has been done to support ad hoc networking of IPv4 hosts, including current drafts which document the process which is used by Windows 98 in the absence of a DHCP server. > Another is that the network provider may desire to label > the addresses with permanent labels, regardless of what > mobile users may or may not happen to use them. Again - > this is for the convenience of the network provider. This is most generally applied to dialup lines in the absence of DDNS. Note that DDNS does not require DHCP to implement login based name assignment; updates may result from RADIUS authentication, instead. Indeed, common practice for POP provisioning is to purchase POP access from a large provider, such as UUNET. The routing requirements for address block assignmnets in IPv4 dictate that, in order to minimize the size of the the routing tables required to that which will fit into a routers memory, the destination for the POP has no control over even static IP address assignments. That is, DHCP is not an apropriate, nor even a capable, technology for implementing such topologies, since the address blocks are assigned to the terminal servers, not some DHCP server somewhere. The communication mechanism between the POP provider and the intended back end server (in general, the RADIUS "realm") is via proxy of RADIUS acconting records to the back end server. DDNS updates for such transient connections may _only_ be made as a result of the RADIUS traffic. > Nothing an end user does (which requires a TCP/IP > connection) should require knowledge of either the > assigned address or the reverse lookup of the assigned > address. On this we agree. On the other hand, practical realities which result from the lack of a DNSSEC umbrella covering the _entire_ DNS deployment as it currently exists means that, while nothing the end user does should require knowledge of either the assigned address or the reverse lookup of the assigned address, the same is not true of _servers with whom the end user intends to communicate_. > NOTE. The position stated above is independent of IPv4 > versus IPv6, or even the address assignment method - it > applies to static address assignments as well. Theoretically, yes. Practically, servers _are_ using, and _will continue using, for the forseeable future_, the correlation between IP address block assignments (with an implied trust in the central assignment authority and its delegates) and domain name assignments (with an implied trust in the central assignment authority and its delegates). If you don't like this, then you need to establish standards which can be used in place of this. But this trust model is Best Current Practice, as it stands today. > Conclusion: > > It is probably unwise to complicate Stateless Autoconfiguration > in IPv6 with any DNS issues. For a full DNSSEC IPv6, I agree with this statement, as well. > As I understand it, the Draft Standard implicitly assumes > some prior knowledge of destination addresses, or at least > a nameserver address. Where this is not viable, DHCP is > always an option for host stack configuration. Stack configuration, or just default route and DNS server location configuration? IMO, stacks should autoconfigure. > The DHCP provider will then make the decision on how and > whether to do any DNS updates at all. Service Location Protocol, via multicast, is another (probably better than wedging DHCP into IPv6 and making exceptions for autoconfiguration) option. With it you can ask "where is my default route?" or "where is my DNS server?" without having to ask for an address assignment at the same time. Consider the network capable device which you would rather not have to expliciitly configure, either at the front panel, or via a DHCP configuration record somewhere (e.g. a printer, scanner, document capture device, network attached storage, IPv4 NAT gateway, SOCKS-5 proxy, default home page, POP3 server, SMTP relay server, HTTP proxy, any-other-browser/PC-option-you-can-think-of-configuring, etc.). A future which requires DHCP is a future which requires humans to configure things they ought not have to configure. The set of things which fall into the category of things which humans ought not have to configure? Everything. -- Terry Lambert -- Whistle Communications, Inc. -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 14:15:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA22356 for ipng-dist; Wed, 4 Aug 1999 14:10:56 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22349 for ; Wed, 4 Aug 1999 14:10:51 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id OAA09701 for ipng@sunroof.eng.sun.com; Wed, 4 Aug 1999 14:09:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22337 for ; Wed, 4 Aug 1999 14:08:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA25931 for ; Wed, 4 Aug 1999 14:08:34 -0700 (PDT) Received: from torque.pothole.com ([209.94.126.199]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21452 for ; Wed, 4 Aug 1999 15:08:32 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id RAA13845; Wed, 4 Aug 1999 17:08:09 -0400 (EDT) Message-Id: <199908042108.RAA13845@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Mon, 02 Aug 1999 23:49:53 EDT." <199908030349.XAA0000000795@quarry.zk3.dec.com> Date: Wed, 04 Aug 1999 17:08:09 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How is the problem of a DNS server telling if an update to the inverse zone is authorized different from a DHCP server telling if a request for an address is authorized? Don't DHCP servers generally give out addresses to anyone who asks so a machine that can spoof Ether addresses can exhaust it? If so, why wouldn't you expect the same machine to be able to fill the inverse zone with crap? If there is a solution to client-to-DHCP autentication, presumably it would work for client-to-inverse-zone-DNS-server. Donald PS: I think having the inverse tree is very useful. I also think it is reasonable to verify the results of the inverse look up against the forward look up in many circumstances. For example, if the forward tree was secured using DNSSEC but the inverse tree were not, the forward verification would actually give you a lot of confidence. From: Jim Bound X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedro ppers@internic.net using -f Message-Id: <199908030349.XAA0000000795@quarry.zk3.dec.com> To: John Gilmore cc: Robert Elz , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net In-reply-to: Your message of "Mon, 02 Aug 1999 16:29:27 PDT." <199908022329.QAA21997@toad.com> Date: Mon, 02 Aug 1999 23:49:53 -0400 >>(In fact, if a DNS server receives a dynamic update for a reverse >>entry, and it can verify that the pointed-to forward entry matches, >>and the source address of the reverse entry is the address being >>updated, it could consider making the update. What can we do to improve >>this model so it need not trust the source address of the update packet?) > >This is a question I can understand. Exactly. We have ddns working for >both AAAA and PTR records from IPv6 addrconf. The issue is for my >customers how is that made to be secure. What you ask is exactly what >we need to solve. > >/jim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 15:00:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA22517 for ipng-dist; Wed, 4 Aug 1999 14:55:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22510 for ; Wed, 4 Aug 1999 14:55:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA18448 for ; Wed, 4 Aug 1999 14:55:29 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12810 for ; Wed, 4 Aug 1999 14:55:28 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24339; Wed, 4 Aug 1999 17:55:24 -0400 (EDT) Message-Id: <199908042155.RAA24339@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: IPv6 Router Alert Option to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 04 Aug 1999 17:55:23 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider IPv6 Router Alert Option as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 18, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6router-alert-05.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 15:06:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA22542 for ipng-dist; Wed, 4 Aug 1999 15:04:22 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22535 for ; Wed, 4 Aug 1999 15:04:15 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id PAA09760 for ipng@sunroof.eng.sun.com; Wed, 4 Aug 1999 15:02:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22474 for ; Wed, 4 Aug 1999 14:37:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA21048 for ; Wed, 4 Aug 1999 14:37:56 -0700 (PDT) Received: from akira.aus.us.mids.org (akira.aus.us.mids.org [38.159.59.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04542 for ; Wed, 4 Aug 1999 15:37:57 -0600 (MDT) Received: from vyoma.mids.org (IDENT:root@vyoma.acsu.buffalo.edu [128.205.7.147]) by akira.aus.us.mids.org (8.9.2/8.9.2) with ESMTP id QAA09565; Wed, 4 Aug 1999 16:37:49 -0500 (CDT) Received: from vyoma.acsu.buffalo.edu (jsq@localhost [127.0.0.1]) by vyoma.mids.org (8.8.7/8.8.7) with ESMTP id QAA02088; Wed, 4 Aug 1999 16:35:09 -0500 Message-Id: <199908042135.QAA02088@vyoma.mids.org> From: "John S. Quarterman" To: perry@piermont.com cc: "John S. Quarterman" , Terry Lambert , Dean Anderson , "Cutler, James R" , "'Robert Elz'" , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "04 Aug 1999 16:08:09 EDT." <87yafr1f86.fsf@jekyll.piermont.com> Date: Wed, 04 Aug 1999 16:35:08 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Faking DNS replies is bloody easy. Queries and replies are matched up >with a 16 bit number, so even if you randomize the numbers, brute >force will allow you to insert spoofed information at least part of >the time. If you can sniff a network that you're attacking, getting >hosts to believe totally faked up DNS replies is even easier. If you can sniff a network you're attacking, of course you can do just about anything. >Good security never relies on DNS information (unless you are using >signed records with the DNS security extensions).l Who recommended relying on DNS information? All said was it was better than nothing, and it forced crackers to use more difficult methods, which yes, include the kind of spoofing you mention. I figured we were all familiar with those and it wasn't necessary to spell them out. Could we move on to something other than this dead horse. John > >"John S. Quarterman" writes: >> >How do you spoof a forward mapping, without exploiting >> >some known (and presumably, fixed) bug? >> > >> > >> >I trust . to not lie about the delegation of .com.; I trust >> >.com. to not lie about the delegation of .whistle.com.; I >> >trust .whistle.com. to not lie about host names in its zone >> >of control, or its delegations, and so on. >> >> You break into the machine that is serving whistle.com >> and you change its DNS records. Doubtless others have >> also been attacked by this method. >> >> Checking forward against reverse DNS is still better than nothing. >> A cracker must at least crack both servers to fake that, or use >> some other, perhaps more difficult, method. >> >> Thanks, >> John >> -- >> John S. Quarterman >> President, Matrix Information and Directory Services (MIDS) >> mids@mids.org, http://www.mids.org, +1-512-451-7602, fax: +1-512-452-0127 >> 1106 Clayton Lane, Suite 501W, Austin, TX 78723, U.S.A. >> See our new Matrix IQ: http://www.miq.net/ >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 4 19:19:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA22822 for ipng-dist; Wed, 4 Aug 1999 19:16:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22815 for ; Wed, 4 Aug 1999 19:16:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA02566 for ; Wed, 4 Aug 1999 19:16:01 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27588 for ; Wed, 4 Aug 1999 20:15:59 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id MAA01669; Thu, 5 Aug 1999 12:15:25 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Thu, 5 Aug 1999 12:15:25 +1000 (EST) From: Peter Tattam To: Jessica Yu cc: Francis.Dupont@inria.fr, Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-Reply-To: <199908041506.LAA23612@cannes.aa.ans.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 4 Aug 1999, Jessica Yu wrote: > >The section 4 says "a particular node (host) may be assigned address(es) > >out of a single prefix, or may have addresses from different prefixes". > >Then RFC 2260 seems a bit ambiguous about this question (which is not > >in fact addressed by it)... > > Siting this sentence and concluding that this document proposes > or advocates multiaddress per host is a bit of stretch. The > document mainly proposed is to assign address from each ISP to > different subset of the hosts e.g. pref-A to a subset of host > and pref-B to another subset. The assignment criteria is "to > use the topological proximity of a node (host) to a particular > ISP as a criteria for selecting" as described in section 4. > > The machenism proposed in rfc2260 does not whatsoever require > all of the hosts assigned with multiple addresses each. It > does not prevent someone for some reason like to do it. > > > I (again) suggest that before we jump into the multi-addressing > > per host scheme, let's throughly evaluate the complication and > > operation complexity associated with that. > > >=> we jumped into it as soon as aggregation became the important thing > >in addressing... > > I do not want to be nasty here. But How many people who already > jumped into multiaddress per host for all hosts in multihoming > sites and even single-home sites have operational and engineering > experiences of real networks? Has any implication as a result > of this been discussed? > > > We can ignore the issue but it won't go away. Didn't we tried > > it before with the multihoming routing issue? Now, we still > > have to face it. > > > >=> this issue is not ignored but I expect this is solved in host and > >router kernels (modulo address selection which is still open). > > > In the end, it's the network operators/engineers who are deciding > > if IPv6 should be deployed in their networks. If they are not > > convinced it's operational viable, what will happen? > > >=> I believe you have two concerns: > > - bugs in kernel code, for instance in router software with > > "secondary addresses" > > - management costs > >First point should be fixed (but I'd like to have a confirmation from > >head router vendors :-). Second point is supposed to be dealt with > >autoconfigurations, A6 RRs and router renumbering. > >In any cases we should try this in the reality then to switch to > >the 6bone mailing list? > > > > Reality checking is really needed here. Again I suggest a thorough > study is needed to evaluate the implication of requiring all hosts > in a multihoming site (now someone even suggested that for sinlge-homed > sites) with multiple addresses. I think I've made my point clear and > should stop now. Hear, Hear... Peter > > --Jessica > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 01:53:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA23078 for ipng-dist; Thu, 5 Aug 1999 01:51:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23070 for ; Thu, 5 Aug 1999 01:51:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA27434 for ; Thu, 5 Aug 1999 01:51:05 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08522 for ; Thu, 5 Aug 1999 02:51:05 -0600 (MDT) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.9.3/8.8.5) with ESMTP id KAA05367; Thu, 5 Aug 1999 10:51:01 +0200 (MET DST) Message-Id: <4.2.0.58.19990805090029.00bf9160@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 05 Aug 1999 09:12:51 +0200 To: "Cutler, James R" , "'terry@whistle.com'" From: Alain Durand Subject: Re: FW: IPv6 and Dynamic DNS Cc: "'ipng@sunroof.eng.sun.com'" , "'namedroppers@internic.net'" In-Reply-To: <92D60A12331ED2119F5300A02461F04702A67B73@usahm009.exmi01.e xch.eds.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 14:47 04/08/99 -0400, Cutler, James R wrote: >Nothing an end user does (which requires a TCP/IP connection) should require >knowledge of either the assigned address or the reverse lookup of the >assigned address. There are several places where reverse lookup is used today. I do not want to enter in the debate to know if this is good security practise or not, I'm just saying this is used. 1) .rhost mechanism 2) some FTP anonymous server insist that you have a PTR record. If you don't, they do not accept FTP connections. 3) anti-spaming rules in SMTP servers. Same thing, if the SMTP client address does not resolve to a valid PTR, some SMTP servers will refuse to get the mail. For those reasons, I'm now manually entering PTR records for my v6 hosts (most of them use stateless autoconf). My life as netadmin will be much easier when I'll have DHCPv6 do that for me. Of course, one can still argue that, if you're visiting a foreign network, not having a valid PTR record might be a feature :-) - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 04:12:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA23319 for ipng-dist; Thu, 5 Aug 1999 04:07:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23312 for ; Thu, 5 Aug 1999 04:07:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA00388 for ; Thu, 5 Aug 1999 04:07:35 -0700 (PDT) Received: from spmler1.mail.eds.com (ns3.eds.com [194.128.225.190]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28594 for ; Thu, 5 Aug 1999 05:07:35 -0600 (MDT) Received: from nnse.eds.com (nnse.eds.com [205.191.69.78]) by spmler1.mail.eds.com (8.9.3/8.9.3) with ESMTP id MAA06245 for ; Thu, 5 Aug 1999 12:09:25 +0100 (BST) Received: from gbspm002.exemhub.exch.eds.com (localhost [127.0.0.1]) by nnse.eds.com (8.9.3/8.9.3) with ESMTP id MAA01674 for ; Thu, 5 Aug 1999 12:02:49 +0100 (BST) Received: by GBSPM002 with Internet Mail Service (5.5.2448.0) id ; Thu, 5 Aug 1999 12:02:47 +0100 Message-ID: From: "Leone, Guido" To: "'IPNG'" Subject: I:IPv6 Implementation for large corporation Date: Thu, 5 Aug 1999 11:43:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id EAA23313 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, we should extend this request for documentation/suggestions to ongoing planning: is the transition to IPv6 currently included on planned activities (not only as a strategic item) somewhere (large private corporations or public institutions) ? > ---------- > Da: Ta,Phong G.[SMTP:pta@mitre.org] > Inviato: mercoledì 21 luglio 1999 20.30 > A: ipng@sunroof.eng.sun.com > Oggetto: IPv6 Implementation for large corporation > > Hi, > > Are there any documentations about IPv6 implementation issues for large > corporation? Any suggestion is welcome. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 06:36:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA23430 for ipng-dist; Thu, 5 Aug 1999 06:31:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23423 for ; Thu, 5 Aug 1999 06:31:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA16142 for ; Thu, 5 Aug 1999 06:31:04 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26271 for ; Thu, 5 Aug 1999 07:31:03 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id JAA04092; Thu, 5 Aug 1999 09:31:02 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000014492; Thu, 5 Aug 1999 09:31:01 -0400 (EDT) From: Jim Bound Message-Id: <199908051331.JAA0000014492@quarry.zk3.dec.com> To: Thomas Narten cc: Francis Dupont , Jessica Yu , "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Wed, 04 Aug 1999 07:28:57 EDT." <199908041128.HAA01732@hygro.adsl.duke.edu> Date: Thu, 05 Aug 1999 09:31:01 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >> PS: Web "virtual-hosting" is another reason to support multi-addressing >> and one can put hundreds of addresses (=> performance issue too). >In the web world, this is apparently no longer a compelling argument >for multiple addresses. This was an issue in older versions of HTTP >(1.0). HTTP 1.1 fixed this problem, and indeed, extensions to 1.0 that >have been widely deployed fixed this as well. My understanding is that >this is no longer an issue today. Your missing the point I think. The market does not have to give us in the standards arena compelling arguments. IPv6 supports multiple addresses for Interfaces. How they want to use that is their choice and I can think of two reasons why a server would want to support 3 addresses on one interface on a link. If you are hinting you would like to change what the Ipv6 architecture permits then just say so and get it on the table! >I.e., today, HTTP queries sent to the server include the DNS name in >the request (older versions included only the path to the right of the >DNS name). Thus, one can have multiple DNS names map to the same >address and everything works as intended. Fine but we cannot force all to do this in this manner, its a choice HTTP 1.1 provides not a mandate. There is also an issue with Firewalls and Ingress filtering which want real IP addresses used. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 06:37:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA23440 for ipng-dist; Thu, 5 Aug 1999 06:35:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23433 for ; Thu, 5 Aug 1999 06:35:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA16394 for ; Thu, 5 Aug 1999 06:35:21 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13986 for ; Thu, 5 Aug 1999 06:35:21 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id JAA04772; Thu, 5 Aug 1999 09:35:20 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000032480; Thu, 5 Aug 1999 09:35:20 -0400 (EDT) From: Jim Bound Message-Id: <199908051335.JAA0000032480@quarry.zk3.dec.com> To: Jessica Yu cc: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Mon, 02 Aug 1999 13:00:45 EDT." <199908021700.NAA20036@cannes.aa.ans.net> Date: Thu, 05 Aug 1999 09:35:19 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jessica, >I have been reading this thread. Being an engineer and network architecture >of large scaled networks (UUNET and ANSNET and way earlier NSFNET), I feel >strongly that any solution we come up with here should also be operationally >MANAGEABLE, that is, it scales operationally. Below is a proposal for >thoughts and consideration. Nice to see proposals occasionaly of late from folks whose job code is "engineer". I think your proposal is excellent, elegant, and makes good engineering design tradeoffs for the network. Consider me a proponent of this and I have seen no mail that counters your idea or proposal. This will work and maintain aggregation. Good Job, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 06:42:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA23471 for ipng-dist; Thu, 5 Aug 1999 06:40:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23464 for ; Thu, 5 Aug 1999 06:40:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA07254 for ; Thu, 5 Aug 1999 06:40:14 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28744 for ; Thu, 5 Aug 1999 07:40:14 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id JAA21836; Thu, 5 Aug 1999 09:40:13 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000029543; Thu, 5 Aug 1999 09:40:13 -0400 (EDT) From: Jim Bound Message-Id: <199908051340.JAA0000029543@quarry.zk3.dec.com> To: Brian E Carpenter cc: Matt Crawford , Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Mon, 02 Aug 1999 15:06:04 CDT." <37A5FA2C.BF6DE4BD@hursley.ibm.com> Date: Thu, 05 Aug 1999 09:40:13 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >Another point is that none of this gets rid of the need for >source and destination address selection mechanisms. Multiple >prefixes are part of life with IPv6. Your pushing this now very hard and in 6to4 and in mail. I am going to start its own mail thread so we can discuss what it means and ramifications. I want this discussed in depth and by the community it needs rigorous debate and discussion as it affects Hosts and Routers greatly. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 07:20:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23538 for ipng-dist; Thu, 5 Aug 1999 07:18:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23531 for ; Thu, 5 Aug 1999 07:17:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA16350 for ; Thu, 5 Aug 1999 07:17:50 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26245 for ; Thu, 5 Aug 1999 07:17:49 -0700 (PDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA28585; Thu, 5 Aug 1999 10:17:48 -0400 (EDT) Received: by anw.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id KAA0000968153; Thu, 5 Aug 1999 10:17:40 -0400 (EDT) Date: Thu, 5 Aug 1999 10:17:40 -0400 (EDT) From: Sowmini Varadhan Message-Id: <199908051417.KAA0000968153@anw.zk3.dec.com> To: cmj@3Com.com, ipng@sunroof.eng.sun.com, varadhan@zk3.dec.com Subject: Re: RFC 2529 (6over4) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From cmj@3Com.com Tue Aug 3 21:53:19 1999 >>It was not clear why the spec rules (lines below) that the >>DF bit MUST NOT be set. Perhaps this injunction classifies as a "SHOULD NOT"? >> 121 ... However, the IPv4 "do not >> 122 fragment" bit MUST NOT be set in the encapsulating IPv4 header. >> >In the region of an IPv4 network that supports a 6over4 IPv6 subnet there >may be IPv4 subnets with MTU smaller than Ethernet (we used the MTU of >the Ethernet as a reasonable default for the MTU on 6over4). Even though >at the IPv6 level, Path MTU will yield a high value, that piece of IPv4 >with the smaller MTU will be invisible to the IPv6 Path MTU. Also, there >are tricks on IPv4 multi-link PPP that force fragmentation of IPv4 frames >to achieve a fairness (chop up FTP data frames so that smaller packets >can be interleaved amoungst the fragments of the larger frame, sort of >a mock-ATM strategy). I'm sure there are plenty of other reasons why >setting the DF bit would create difficult to detect failures - I personally >think the MUST NOT is right - how convinced are you that SHOULD NOT is >right? IMHO we need to establish a good reason ("prove") that the DF bit must never, ever be set before we mandate it as a MUST NOT. I can see that setting the DF bit has the potential to create dropped packets and be inconvenient (and therefore SHOULD NOT be set). However, I don't see how this can create a gross error or disruption of the network. OTOH, there may be situations (e.g., tunnel PMTU) that *do* require the DF bit to be set. In addition, note that Section 7.2 of RFC 2473 addresses the situation when the DF bit is set on the IPV4 packet header, so this should allow some method of failure detection. >>The reference to the "datalink" header below is confusing, because it >>is not clear if the intended datalink refers to the IPV4 header or >>the physical (e.g., ethernet) link header. >> 151 If there are IPv4 options, then padding SHOULD be added to the >IPv4 >> 152 header such that the IPv6 header starts on a boundary that is a >32- >> 153 bit offset from the end of the datalink header. >> >>Unless it changes the intended meaning, it appears that it could >>be stated more directly as: >> "If there are IPv4 options, then padding SHOULD be added to the IPv4 >> header such that the total size of the IPv4 header is a multiple of >> 32 bits". > >Actually, I think the paragraph is unnecessary, as the IPv4 header MUST >be padded to a multiple of 32 bits, as dictated by the IPv4 length field, >which expresses the number of 32-bit words in the IPv4 header :-) Maybe >we should remove the paragraph since it is not only unnecessary but >confusing? I'd vote to have it removed, if/when the opportunity presents itself. >> >>The zero byte padding used in the link layer option is conflicting with >>the position of padding chosen in the only other document that I see >>which attempts to define the format of Link-Layer address options. >>rfc2529 says: >> 198 >> 199 +-------+-------+-------+-------+-------+-------+-------+-------+ >> 200 | Type |Length | must be zero | IPv4 Address | >> 201 +-------+-------+-------+-------+-------+-------+-------+-------+ >> 202 >>while draft-conta-ipv6-trans-tunnel-00.txt says >> 0 1 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 0 | Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 2 | IPv4 | >> +- -+ >> 4 | Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 6 | Padding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>Should the 2 be consistent? > >Do they need to be? I can't find this draft, but I did find the >RFC2497 for shipping IPv6 over ARCNET, and the padding there is >post the media address. I somehow think this is minor - is there >a need for consistency? Yes, I think there's a need for consistency! Both configured tunnels and the 6over4 conceptually use IPV4 as the link-layer, and there can only be one kind of link-layer address for any particular link type, right? Besides, I believe that it's cleaner from an implementation standpoint- the implementation does not have to keep track of the type of encapsulation (6over4 vs configured) when parsing incoming link-layer address options. If we all accept the premise that they should both be consistent, then the question becomes- "which spec needs to conform?". The answer to that probably depends on which is more widely implemented at the current time, I guess. >>The ambivalency regarding assumptions about virtual interfaces to >>the 6over4 network led to some confusion about the interpretation >>of Section 7. (See General comments regarding virtual interfaces to >>the 6over4 network) >> >>If the spec does not (wish to) make any assumption about the presence of >>virtual interfaces to the 6over4 network, then it is not clear >>what sorts of tasks are implied by the "enabling" operation below: >> >> 264 ... Interfaces of the IPv6 router and hosts >> 265 will of course need to be enabled in "6over4" mode. > >I agree - the only interface is to IPv4. The physcial interface >references is very misleading. The point is that these interfaces >of IPv4 must be either included in the 6over4 subnet, or excluded, >and that has to do with the establishing the perimeter of the >administrative scoping multicast region. > >> >>In the fourth paragraph, >> >> 287 During transition, routers may need to advertise at least two IPv6 >> 288 prefixes, one for the native LAN (e.g. Ethernet) and one for >> 289 "6over4". As with any IPv6 prefix assigned to an IPv6 subnet, the >> 290 latter MUST be unique within its scope, whether site-local or >global >> 291 addressing is used. >> >>it would help if the need for two IPV6 prefixes was demonstrated with an >>example. It was not clear when a router "may need" the 2 prefixes. >> - if no assumptions are made about having a separate virtual interface >> to the 6over4 net, then it's not clear why/when the node would need >> 2 prefixes. >> - if, instead, the spec *does* assume that a node has a separate >> virtual interface to the 6over4 net, then the requirement of unique >> non-link-local addresses already mandates that the router must be >> advertising/using distinct IPv6 prefixes for the native LAN and the >> 6over4 network, so that the fourth paragraph is somewhat distracting >> and redundant? > >I agree - the 6over4 must really be disassociated from any physical >interface that IPv4 has - or that IPv6 has, for that matter. Not sure what you agree with :-).. do you agree with "it's not clear why/when the node would need 2 prefixes", or do you agree with "the fourth paragraph is distracting etc."? I think either a clarification or paragraph-deletion is called for here? > >> >>Similarly the "MUST" clause in the fifth paragraph could be clarified >>by an example, or a detailed justification. >> >> 293 Also note that when a router is handling both native LAN and >"6over4" >> 294 on the same physical interface, during stateless >autoconfiguration, >> 295 there is a period when IPv6 link-local addresses are used, in both >> 296 cases with the prefix FE80::/64. Note that the prefix-length for >> 297 these link-local adddress MUST then be 128 so that the two >cases can >> 298 be distinguished. > >I have no sympathy for this clause either - I think it was heavily >influenced by the internals of the freeBSD implementation. The >system within which I work would have no such problems, since the >incoming path is still knowable at the IPv6 level, so it is trivial >to distinguish IPv6 frames that come in on different interfaces even >though their IPv6 address is identical. Good to hear that. We were all intrigued, esp. with the cross-referencing between Section 4 and the MUST clause above and were wondering if we were missing something subtle here. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 07:24:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23564 for ipng-dist; Thu, 5 Aug 1999 07:23:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23553 for ; Thu, 5 Aug 1999 07:23:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA09891 for ; Thu, 5 Aug 1999 07:23:08 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27758 for ; Thu, 5 Aug 1999 07:23:08 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA13305; Thu, 5 Aug 1999 10:23:06 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000014376; Thu, 5 Aug 1999 10:23:05 -0400 (EDT) From: Jim Bound Message-Id: <199908051423.KAA0000014376@quarry.zk3.dec.com> To: Jessica Yu cc: Francis.Dupont@inria.fr, "Matt Crawford" , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Wed, 04 Aug 1999 11:06:12 EDT." <199908041506.LAA23612@cannes.aa.ans.net> Date: Thu, 05 Aug 1999 10:23:04 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I do not want to be nasty here. But How many people who already > jumped into multiaddress per host for all hosts in multihoming > sites and even single-home sites have operational and engineering > experiences of real networks? Has any implication as a result > of this been discussed? I don't this is nasty at all. I do in building IP stacks and Jessica is correct the complexity once I have to deal with multiple addresses is an order of magnitude more complex in software. Then it gets even more complex for the user mgmt folks in engineering that have to make it appear simple. There are some special cases for customers where having two addresses for an interface have proved useful and that is the case of dual rail ethernet. Also my read of 2260 where a pipe to another ISP is permitted would also work with one address. >Reality checking is really needed here. Again I suggest a thorough >study is needed to evaluate the implication of requiring all hosts >in a multihoming site (now someone even suggested that for sinlge-homed >sites) with multiple addresses. I think I've made my point clear and >should stop now. I agree with this concern and will add I would like to see a discussion of at a minimum how the software will work to drive this. In the meantime we can adopt Jessica's proposal for the 6bone and it will work. We can discuss and define other solutions for more complex needs we are hearing here while we deploy Jessica's draft. I propose we just get Jessica input on her proposal as it stands if it needs any tightening up, etc.. and get this deployed on the 6bone now. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 07:40:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23601 for ipng-dist; Thu, 5 Aug 1999 07:37:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23594 for ; Thu, 5 Aug 1999 07:37:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA26483 for ; Thu, 5 Aug 1999 07:37:30 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02103 for ; Thu, 5 Aug 1999 07:37:29 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA30394; Thu, 5 Aug 1999 10:37:26 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000001993; Thu, 5 Aug 1999 10:37:21 -0400 (EDT) From: Jim Bound Message-Id: <199908051437.KAA0000001993@quarry.zk3.dec.com> To: "John S. Quarterman" cc: Terry Lambert , Dean Anderson , "Cutler, James R" , "'Robert Elz'" , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Wed, 04 Aug 1999 14:10:47 CDT." <199908041910.OAA29359@akira.aus.us.mids.org> Date: Thu, 05 Aug 1999 10:37:21 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Checking forward against reverse DNS is still better than nothing. >A cracker must at least crack both servers to fake that, or use >some other, perhaps more difficult, method. Wisdom I agree with. Look folks I am trying to ship a product I think doing this is prudent for now. Once the standards folks (me included) define a better solution I will do that too. I am shipping this to the public for now. Still not sure on what options I should give them in the user interface to set up what happens though. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 07:52:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23644 for ipng-dist; Thu, 5 Aug 1999 07:50:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23637 for ; Thu, 5 Aug 1999 07:50:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28796 for ; Thu, 5 Aug 1999 07:50:39 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22438 for ; Thu, 5 Aug 1999 08:50:37 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id AAA15078; Fri, 6 Aug 1999 00:48:53 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 6 Aug 1999 00:48:52 +1000 (EST) From: Peter Tattam To: Jim Bound cc: Brian E Carpenter , Matt Crawford , Jessica Yu , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-Reply-To: <199908051340.JAA0000029543@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 5 Aug 1999, Jim Bound wrote: > Hi Brian, > > >Another point is that none of this gets rid of the need for > >source and destination address selection mechanisms. Multiple > >prefixes are part of life with IPv6. > > Your pushing this now very hard and in 6to4 and in mail. I am going to > start its own mail thread so we can discuss what it means and > ramifications. I want this discussed in depth and by the community it > needs rigorous debate and discussion as it affects Hosts and Routers > greatly. > > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > Ok. I'll make a few assertions about a "typical" environment, and tell a story or two. In Aus & UK, there is a TV program called "Hypothetical"... imagine this... cameras zooming in on the presenter... While most implementations are conceding that multiple addresses should be implementable, and indeed they are, *how* do I choose a source address that will give me the best performance. In a typical working environment, I have one interface. It has many addresses. (my site uses provider A, B & C) There are no hints from the network as to which address I source my packets with because I'm not allowed to participate in any routing protocols. The only time I get hints are when part of my network is down in that it tells me that one particular address should not be used, but under normal conditions the only way I can tell which network is the best at any particular time is to try pinging with a source address from either of the providers. I've only got one router visible to me, hence I only ever configure one default route. The router advertisement always gives me the the list of addresses in roughly the same order but sometimes the implementation alters the order somewhat, placing the slowest link at the start of the list. One of the addresses sometimes gives me much poorer response time because it's really only a secondary link that my provider uses as a backup, and that provider has staffing problems... occasionally their frame relay network goes a bit hazy and starts routing packets via Hong Kong. They often don't get to it for several hours, usually when one of my staff finally figures that it's not regular congestion and there really is a problem & rings them. One day the network is so unstable that any one or more of my addresses doesn't respond or goes up & down like a yoyo. (In real life, someone put a back hoe through the fibre optic cable, and it's the main line out of town. Two of my providers use this cable physically and the other doesn't). BTW, providers A & B are in a legal battle and have as a result no peering arrangements any more. Provider C doesn't care and has peerings with both, but then provider A threatens to block C's traffic if it doesn't drop peering with B. C obliges, but then B gets annoyed. Peerings are opened and shut at the rate of 1 per week until C eventually gives up after a month and doesn't bother peering any more. Provider A also has a relationship with the optic cable company and could make things nasty for the other two if it really wanted to. Meanwhile, the fibre has been fixed, but is still a litte flakey. As a result, C has picked up a lot of traffic from A & B's customers because they also have a satellite link and this saves the day for them. A couple of month's later, the fibre is now stable and traffic is back to normal. A & B have settled their dispute, but C is now locked out of the peering arrangement because they stole many of A & B's customers. At around the same time, there is a solar storm which knocks out quite a number of channels of the main satellite service that C uses. Because of all the extra customers, he is now *really* stretched to the limit & his service is now *really* bad. My boss now shows up... the machine that was configured and working last week is not working very well, but his secretary's machine is going just dandy. They are trying to send a large file through to India which is worth a very large contract. It keeps failing because the network is still unstable with provider A & B keep dropping in & out alternatively. The attachment would normally take 3 hours to send to India because the client at the other end is operating in a less than optimal location in the phone system. This is the third time they have tried to send it. The first time it got through till 90%, the second time 40% and the last time 50%. Unfortunately as a test of concetp, we are an "IPv6 only" shop, we were so sure that those larger addresses would solve everything. He plonks on my table the detailed recommendation that I gave him 6 months ago that we go "IPv6" because it is a superior system. I leave the room wondering how I'm going to keep up the house payments now that I have been demoted to tech support officer grade 1. Under this scenario, which system will survive the best, IPv4 or IPv6. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 07:52:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23635 for ipng-dist; Thu, 5 Aug 1999 07:49:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23628 for ; Thu, 5 Aug 1999 07:49:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA22346 for ; Thu, 5 Aug 1999 07:49:11 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21870 for ; Thu, 5 Aug 1999 08:49:11 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA18576; Thu, 5 Aug 1999 10:49:10 -0400 (EDT) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000019331; Thu, 5 Aug 1999 10:49:10 -0400 (EDT) Date: Thu, 5 Aug 1999 10:49:10 -0400 (EDT) From: Sowmini Varadhan Message-Id: <199908051449.KAA0000019331@quarry.zk3.dec.com> To: Francis.Dupont@inria.fr, brian@hursley.ibm.com Subject: Re: RFC 2529 (6over4) Cc: ipng@sunroof.eng.sun.com, varadhan@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From: Brian E Carpenter > >Apart from that I think Cyndi has replied just about as I would >have done, if she hadn't got there first. Sowmini, do you think >there is any urgency to revise the RFC? I think some fixing is called for, before it goes to Draft Standard. One concern though is the dependancy on RFC 2365- as Cyndi points out cmj> I think TTL scoping for multicast has been found to be unworkable - but cmj> is still a poor man's scooping tool. There is still work being done in cmj> deploying the admin scoping, ... But, until 2365 is widely deployed, all testing will have to rely on TTL scoping of multicasts, and this has ramifications on product planning. What do you think? --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 07:56:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23696 for ipng-dist; Thu, 5 Aug 1999 07:55:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23689 for ; Thu, 5 Aug 1999 07:55:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29902 for ; Thu, 5 Aug 1999 07:55:24 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08281 for ; Thu, 5 Aug 1999 07:55:23 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA32338; Thu, 5 Aug 1999 10:52:28 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA32532; Thu, 5 Aug 1999 10:52:30 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id KAA17810; Thu, 5 Aug 1999 10:52:47 -0400 (EDT) Message-Id: <199908051452.KAA17810@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Thu, 05 Aug 1999 09:31:01 EDT." <199908051331.JAA0000014492@quarry.zk3.dec.com> Date: Thu, 05 Aug 1999 10:52:47 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I believe multiple addresses per interface are a fact of life (i.e., scoping). In addition, I think they offer potential to help with route scaling (i.e., multiple address per ISP connection). I was simply pointing out that in the specific case of web servers (where virtual hosting is very popular today), one doesn't need multiple addresses to do this. This is already established practice through HTTP improvements. > >I.e., today, HTTP queries sent to the server include the DNS name in > >the request (older versions included only the path to the right of the > >DNS name). Thus, one can have multiple DNS names map to the same > >address and everything works as intended. > Fine but we cannot force all to do this in this manner, its a choice > HTTP 1.1 provides not a mandate. There is also an issue with Firewalls > and Ingress filtering which want real IP addresses used. The market has apparently already spoken on this issue. The mods are deployed today. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 09:14:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA23850 for ipng-dist; Thu, 5 Aug 1999 09:10:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23843 for ; Thu, 5 Aug 1999 09:10:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02498 for ; Thu, 5 Aug 1999 09:10:49 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08452 for ; Thu, 5 Aug 1999 09:10:48 -0700 (PDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA14580 for ; Thu, 5 Aug 1999 12:10:47 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000984442; Thu, 5 Aug 1999 12:10:32 -0400 (EDT) From: Jim Bound Message-Id: <199908051610.MAA0000984442@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com cc: bound@zk3.dec.com Subject: IPv6 Src/Dst Address Pairing Date: Thu, 05 Aug 1999 12:10:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have an issue that 6to4 in ngntrans and some believe in Multihoming that hosts (clients) should pair Dst addresses with correct Src addresses. This thread should not discuss the present src address selection drafts which do not address this specific issue. But just a node selecting src addresses for dst addresses passed to the transport of an IPv6 implementation and the tools and parts we must use to select the src address and scoping. That should have a different thread. The issue here is DNS returns addresses. When that happens some suggest that the client when sending a packet the client "somewhere" have a piece of software that takes each dst address and maps the best src address to each dst address, and then use the best src/dst address pair for packet transmission. First DNS does not or cannot do that today from the DNS server for the client so thats not an option as the DNS server does not know all the clients source addresses. Also the DNS server has no way of ordering the DST addresses in any meaningful way except maybe for scoping like site addresses if we permit them in the DNS. So this means a client would take 1 to N DST addresses given to them from the DNS while the client is awaiting a response from getipnodebyname or getaddrinfo, and do this processing while the client waits. Here is what the ramifications are to implementations: 1. The client takes 1 to N addresses off the DNS set returned and performs an I/O access to the place in the IPv6 implementation to access all potential src addresses on the platform. This is most likely multiple reads and causes a context switch on the platform. Unless one keeps an updated file to be read on the client of src addresses available. If such a file is kept then it will add new code to every utility that adds or alters or deletes addresses on the platform and in many places for many implementations and I do not believe that to be optimal. I suppose an implementation could map the interface structures to a file via a memory mapping but it is not 100% full proof to be guranteed. 2. Once the client now has those src addresses start the compare using longest match or some other algorithm to find the best src address to match a dst address. Then store that result with some kind of weight in some datastructure. Then proceed to compare the next dst address in a loop (might be able to be done recursively). 3. During step 2 above also do the src address selection criteria specified in the std src address selections being proposed (e.g. scoping, deprecated, interface index). 4. Now pass back the pair to the client application? But there is no API to do this today but could be done in getaddrinfo possibly. But if the client does not want to send the src address when sending the packet then after step 3 that software would have to update the implementation kernel stack to know to use this src address with this particular client send operation. I will note doing steps 1-3 inside the kernel of implementations where the stack resides is not an option as DNS libs are not available they would have to be pushed into the stack (the 1 to N) DST addresses returned from DNS. Then do steps 1-3 in the kernel. But then the client may not know what DST address was used. Please lets discuss the entire issue. I think there are many reasons we have not done this already for TCP/IP and DNS address returns. It is just to much of a burdeon for IP Hosts and for routers even worse. Doing this is a very very bad idea because the engineering and performance costs are to high for the benefit. I have more to say but will stop here. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 09:31:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA23898 for ipng-dist; Thu, 5 Aug 1999 09:25:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23891 for ; Thu, 5 Aug 1999 09:25:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA06238 for ; Thu, 5 Aug 1999 09:25:17 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13895 for ; Thu, 5 Aug 1999 09:25:16 -0700 (PDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA16188; Thu, 5 Aug 1999 12:25:16 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000986070; Thu, 5 Aug 1999 12:25:00 -0400 (EDT) From: Jim Bound Message-Id: <199908051625.MAA0000986070@anw.zk3.dec.com> To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) In-reply-to: Your message of "Thu, 05 Aug 1999 10:52:47 EDT." <199908051452.KAA17810@cichlid.raleigh.ibm.com> Date: Thu, 05 Aug 1999 12:24:59 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK..Tom... I know this has come up in other forums and just checking.. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 10:13:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA24061 for ipng-dist; Thu, 5 Aug 1999 10:10:06 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24054 for ; Thu, 5 Aug 1999 10:10:01 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id KAA11023 for ipng@sunroof.eng.sun.com; Thu, 5 Aug 1999 10:08:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23764 for ; Thu, 5 Aug 1999 08:19:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA15616 for ; Thu, 5 Aug 1999 08:19:32 -0700 (PDT) Received: from gateway.gtech.com (gateway.gtech.com [156.24.1.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA04075 for ; Thu, 5 Aug 1999 09:19:32 -0600 (MDT) Received: (qmail 11677 invoked from network); 5 Aug 1999 15:19:31 -0000 Received: from ops.soft.gtech.com (HELO ops.gtech.com) (156.24.33.7) by gateway.mis.gtech.com with SMTP; 5 Aug 1999 15:19:31 -0000 Received: from rimail01.mis.gtech.com (rimail01.mis.gtech.com [156.24.14.43]) by ops.gtech.com (8.8.8+Sun/8.8.8) with ESMTP id LAA10918; Thu, 5 Aug 1999 11:19:29 -0400 (EDT) Message-Id: <199908051519.LAA10918@ops.gtech.com> Received: by rimail01.mis.gtech.com with Internet Mail Service (5.5.2448.0) id ; Thu, 5 Aug 1999 11:18:22 -0400 From: GTECH-BR01 at GTECH-BEL-HUB To: "\"cmj@3Com.com\" " , "\"ipng@sunroof.eng.sun.com\" " , "\"varadhan@zk3.dec.com\" " , "\"Sowmini Varadhan\" " Subject: RE: RFC 2529 (6over4) Date: Thu, 5 Aug 1999 17:10:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From cmj@3Com.com Tue Aug 3 21:53:19 1999 >>It was not clear why the spec rules (lines below) that the >>DF bit MUST NOT be set. Perhaps this injunction classifies as a "SHOULD NOT"? >> 121 ... However, the IPv4 "do not >> 122 fragment" bit MUST NOT be set in the encapsulating IPv4 header. >> >In the region of an IPv4 network that supports a 6over4 IPv6 subnet there >may be IPv4 subnets with MTU smaller than Ethernet (we used the MTU of >the Ethernet as a reasonable default for the MTU on 6over4). Even though >at the IPv6 level, Path MTU will yield a high value, that piece of IPv4 >with the smaller MTU will be invisible to the IPv6 Path MTU. Also, there >are tricks on IPv4 multi-link PPP that force fragmentation of IPv4 frames >to achieve a fairness (chop up FTP data frames so that smaller packets >can be interleaved amoungst the fragments of the larger frame, sort of >a mock-ATM strategy). I'm sure there are plenty of other reasons why >setting the DF bit would create difficult to detect failures - I personally >think the MUST NOT is right - how convinced are you that SHOULD NOT is >right? IMHO we need to establish a good reason ("prove") that the DF bit must never, ever be set before we mandate it as a MUST NOT. I can see that setting the DF bit has the potential to create dropped packets and be inconvenient (and therefore SHOULD NOT be set). However, I don't see how this can create a gross error or disruption of the network. OTOH, there may be situations (e.g., tunnel PMTU) that *do* require the DF bit to be set. In addition, note that Section 7.2 of RFC 2473 addresses the situation when the DF bit is set on the IPV4 packet header, so this should allow some method of failure detection. >>The reference to the "datalink" header below is confusing, because it >>is not clear if the intended datalink refers to the IPV4 header or >>the physical (e.g., ethernet) link header. >> 151 If there are IPv4 options, then padding SHOULD be added to the >IPv4 >> 152 header such that the IPv6 header starts on a boundary that is a >32- >> 153 bit offset from the end of the datalink header. >> >>Unless it changes the intended meaning, it appears that it could >>be stated more directly as: >> "If there are IPv4 options, then padding SHOULD be added to the IPv4 >> header such that the total size of the IPv4 header is a multiple of >> 32 bits". > >Actually, I think the paragraph is unnecessary, as the IPv4 header MUST >be padded to a multiple of 32 bits, as dictated by the IPv4 length field, >which expresses the number of 32-bit words in the IPv4 header :-) Maybe >we should remove the paragraph since it is not only unnecessary but >confusing? I'd vote to have it removed, if/when the opportunity presents itself. >> >>The zero byte padding used in the link layer option is conflicting with >>the position of padding chosen in the only other document that I see >>which attempts to define the format of Link-Layer address options. >>rfc2529 says: >> 198 >> 199 +-------+-------+-------+-------+-------+-------+-------+-------+ >> 200 | Type |Length | must be zero | IPv4 Address | >> 201 +-------+-------+-------+-------+-------+-------+-------+-------+ >> 202 >>while draft-conta-ipv6-trans-tunnel-00.txt says >> 0 1 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 0 | Type | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 2 | IPv4 | >> +- -+ >> 4 | Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 6 | Padding | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>Should the 2 be consistent? > >Do they need to be? I can't find this draft, but I did find the >RFC2497 for shipping IPv6 over ARCNET, and the padding there is >post the media address. I somehow think this is minor - is there >a need for consistency? Yes, I think there's a need for consistency! Both configured tunnels and the 6over4 conceptually use IPV4 as the link-layer, and there can only be one kind of link-layer address for any particular link type, right? Besides, I believe that it's cleaner from an implementation standpoint- the implementation does not have to keep track of the type of encapsulation (6over4 vs configured) when parsing incoming link-layer address options. If we all accept the premise that they should both be consistent, then the question becomes- "which spec needs to conform?". The answer to that probably depends on which is more widely implemented at the current time, I guess. >>The ambivalency regarding assumptions about virtual interfaces to >>the 6over4 network led to some confusion about the interpretation >>of Section 7. (See General comments regarding virtual interfaces to >>the 6over4 network) >> >>If the spec does not (wish to) make any assumption about the presence of >>virtual interfaces to the 6over4 network, then it is not clear >>what sorts of tasks are implied by the "enabling" operation below: >> >> 264 ... Interfaces of the IPv6 router and hosts >> 265 will of course need to be enabled in "6over4" mode. > >I agree - the only interface is to IPv4. The physcial interface >references is very misleading. The point is that these interfaces >of IPv4 must be either included in the 6over4 subnet, or excluded, >and that has to do with the establishing the perimeter of the >administrative scoping multicast region. > >> >>In the fourth paragraph, >> >> 287 During transition, routers may need to advertise at least two IPv6 >> 288 prefixes, one for the native LAN (e.g. Ethernet) and one for >> 289 "6over4". As with any IPv6 prefix assigned to an IPv6 subnet, the >> 290 latter MUST be unique within its scope, whether site-local or >global >> 291 addressing is used. >> >>it would help if the need for two IPV6 prefixes was demonstrated with an >>example. It was not clear when a router "may need" the 2 prefixes. >> - if no assumptions are made about having a separate virtual interface >> to the 6over4 net, then it's not clear why/when the node would need >> 2 prefixes. >> - if, instead, the spec *does* assume that a node has a separate >> virtual interface to the 6over4 net, then the requirement of unique >> non-link-local addresses already mandates that the router must be >> advertising/using distinct IPv6 prefixes for the native LAN and the >> 6over4 network, so that the fourth paragraph is somewhat distracting >> and redundant? > >I agree - the 6over4 must really be disassociated from any physical >interface that IPv4 has - or that IPv6 has, for that matter. Not sure what you agree with :-).. do you agree with "it's not clear why/when the node would need 2 prefixes", or do you agree with "the fourth paragraph is distracting etc."? I think either a clarification or paragraph-deletion is called for here? > >> >>Similarly the "MUST" clause in the fifth paragraph could be clarified >>by an example, or a detailed justification. >> >> 293 Also note that when a router is handling both native LAN and >"6over4" >> 294 on the same physical interface, during stateless >autoconfiguration, >> 295 there is a period when IPv6 link-local addresses are used, in both >> 296 cases with the prefix FE80::/64. Note that the prefix-length for >> 297 these link-local adddress MUST then be 128 so that the two >cases can >> 298 be distinguished. > >I have no sympathy for this clause either - I think it was heavily >influenced by the internals of the freeBSD implementation. The >system within which I work would have no such problems, since the >incoming path is still knowable at the IPv6 level, so it is trivial >to distinguish IPv6 frames that come in on different interfaces even >though their IPv6 address is identical. Good to hear that. We were all intrigued, esp. with the cross-referencing between Section 4 and the MUST clause above and were wondering if we were missing something subtle here. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 15:12:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA24618 for ipng-dist; Thu, 5 Aug 1999 15:07:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24611 for ; Thu, 5 Aug 1999 15:07:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA12761 for ; Thu, 5 Aug 1999 15:07:01 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21941 for ; Thu, 5 Aug 1999 16:06:59 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA671552 for ; Thu, 5 Aug 1999 23:06:57 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA21442 for ; Thu, 5 Aug 1999 23:06:56 +0100 (BST) Message-ID: <37AA0A84.3C59C124@hursley.ibm.com> Date: Thu, 05 Aug 1999 17:04:52 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) References: <199908051417.KAA0000968153@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sowmini Varadhan wrote: ... > >>The zero byte padding used in the link layer option is conflicting with > >>the position of padding chosen in the only other document that I see > >>which attempts to define the format of Link-Layer address options. > >>rfc2529 says: > >> 198 > >> 199 +-------+-------+-------+-------+-------+-------+-------+-------+ > >> 200 | Type |Length | must be zero | IPv4 Address | > >> 201 +-------+-------+-------+-------+-------+-------+-------+-------+ > >> 202 > >>while draft-conta-ipv6-trans-tunnel-00.txt says > >> 0 1 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> 0 | Type | Length | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> 2 | IPv4 | > >> +- -+ > >> 4 | Address | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> 6 | Padding | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>Should the 2 be consistent? > > > >Do they need to be? I can't find this draft, but I did find the > >RFC2497 for shipping IPv6 over ARCNET, and the padding there is > >post the media address. I somehow think this is minor - is there > >a need for consistency? > > Yes, I think there's a need for consistency! Both configured tunnels > and the 6over4 conceptually use IPV4 as the link-layer, and there can > only be one kind of link-layer address for any particular link type, right? > > Besides, I believe that it's cleaner from an implementation standpoint- > the implementation does not have to keep track of the type of > encapsulation (6over4 vs configured) when parsing incoming link-layer > address options. > > If we all accept the premise that they should both be consistent, then the > question becomes- "which spec needs to conform?". The answer to that probably > depends on which is more widely implemented at the current time, I guess. If we change this it is a change to the wire protocol and it invalidates the existing implementations; it also means the document has to be recycled at Proposed Standard. So we would have to be *very* sure that we want to change it. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 15:13:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA24633 for ipng-dist; Thu, 5 Aug 1999 15:10:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24626 for ; Thu, 5 Aug 1999 15:09:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA16266 for ; Thu, 5 Aug 1999 15:09:50 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29577 for ; Thu, 5 Aug 1999 15:09:49 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA347978 for ; Thu, 5 Aug 1999 23:09:47 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA18200 for ; Thu, 5 Aug 1999 23:09:46 +0100 (BST) Message-ID: <37AA0B2C.63BCB89D@hursley.ibm.com> Date: Thu, 05 Aug 1999 17:07:40 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) References: <199908051449.KAA0000019331@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sowmini Varadhan wrote: ... > cmj> I think TTL scoping for multicast has been found to be unworkable - but > cmj> is still a poor man's scooping tool. There is still work being done in > cmj> deploying the admin scoping, ... > > But, until 2365 is widely deployed, all testing will have to rely on > TTL scoping of multicasts, and this has ramifications on product planning. > > What do you think? Frankly, multicast itself is not that widely deployed. I'd be reluctant to specify a bad solution on the grounds that the good solution is too new. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 15:40:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA24699 for ipng-dist; Thu, 5 Aug 1999 15:36:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24692 for ; Thu, 5 Aug 1999 15:36:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA17918 for ; Thu, 5 Aug 1999 15:36:28 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA09441 for ; Thu, 5 Aug 1999 15:36:27 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id AAA20181; Fri, 6 Aug 1999 00:36:05 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id AAA09438; Fri, 6 Aug 1999 00:36:04 +0200 (MET DST) Message-Id: <199908052236.AAA09438@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: John Gilmore , Robert Elz , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of Mon, 02 Aug 1999 23:49:53 EDT. <199908030349.XAA0000000795@quarry.zk3.dec.com> Date: Fri, 06 Aug 1999 00:36:03 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >(In fact, if a DNS server receives a dynamic update for a reverse >entry, and it can verify that the pointed-to forward entry matches, >and the source address of the reverse entry is the address being >updated, it could consider making the update. What can we do to improve >this model so it need not trust the source address of the update packet?) This is a question I can understand. Exactly. We have ddns working for both AAAA and PTR records from IPv6 addrconf. The issue is for my customers how is that made to be secure. What you ask is exactly what we need to solve. => I have in my TODO list the same kind of tools (ie. something which updates AAAA & PTR RRs from IPv6 addrconf/neighbor discovery). Of course we have the same problem and the current proposed solution is to use TSIG, the future solution is to provide this service via DHCPv6. Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 5 16:06:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA24747 for ipng-dist; Thu, 5 Aug 1999 16:01:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24740 for ; Thu, 5 Aug 1999 16:01:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA22881 for ; Thu, 5 Aug 1999 16:01:30 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11549 for ; Thu, 5 Aug 1999 17:01:29 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id AAA174434; Fri, 6 Aug 1999 00:01:27 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id AAA28504; Fri, 6 Aug 1999 00:01:25 +0100 (BST) Message-ID: <37AA174A.376C712E@hursley.ibm.com> Date: Thu, 05 Aug 1999 17:59:22 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Jim Bound CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing References: <199908051610.MAA0000984442@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > We have an issue that 6to4 in ngntrans and some believe in Multihoming > that hosts (clients) should pair Dst addresses with correct Src > addresses. The reason I'm pushing this is that I see it as a serious operational issue once we start having multiple prefixes, which IMHO we certainly will get sooner or later. If we don't do it right we will end up with very non-optimal routing. This matters just as much as host (in)efficiency so we have to find the right tradeoff > > This thread should not discuss the present src address selection drafts which > do not address this specific issue. But just a node selecting src > addresses for dst addresses passed to the transport of an IPv6 > implementation and the tools and parts we must use to select the src > address and scoping. That should have a different thread. > > The issue here is DNS returns addresses. When that happens some suggest > that the client when sending a packet the client "somewhere" have a > piece of software that takes each dst address and maps the best src > address to each dst address, and then use the best src/dst address pair > for packet transmission. > > First DNS does not or cannot do that today from the DNS server for the > client so thats not an option as the DNS server does not know all the > clients source addresses. Also the DNS server has no way of ordering > the DST addresses in any meaningful way except maybe for scoping like > site addresses if we permit them in the DNS. Absolutely. Asking DNS to do anything other than return an unordered list of addresses would be crazy. > > So this means a client would take 1 to N DST addresses given to them > from the DNS while the client is awaiting a response from > getipnodebyname or getaddrinfo, and do this processing while the client > waits. Exactly, i.e. this process is added to the generic DNS overhead befor you get to call open(). Can you quantify this? Given that DNS lookups take up to seconds, how much extra overhead time are we talking here? > > Here is what the ramifications are to implementations: > > 1. The client takes 1 to N addresses off the DNS set returned and > performs an I/O access to the place in the IPv6 implementation > to access all potential src addresses on the platform. This is > most likely multiple reads and causes a context switch on > the platform. I/O access? Why on earth? I'd expect the stack simply to know its current interface/address pairings in a (small) table. >... Unless one keeps an updated file to be read You don't mean a disk file do you? Why not a simple data structure in the stack? > on the client of src addresses available. If such a file is > kept then it will add new code to every utility that adds or > alters or deletes addresses on the platform and in many places > for many implementations Yes, for sure > ...and I do not believe that to be > optimal. Is this an overhead that matters? Is it on any critical paths? > ...I suppose an implementation could map the interface > structures to a file via a memory mapping but it is not > 100% full proof to be guranteed. I assumed that the stack would simply have this available anyway for other reasons. > > 2. Once the client now has those src addresses start the compare > using longest match or some other algorithm to find the > best src address to match a dst address. Then store that > result with some kind of weight in some datastructure. Then > proceed to compare the next dst address in a loop (might > be able to be done recursively). Correct. This is also where you would insert heuristics and maybe refer to some current "network weather" info to choose a path. But it is on the path to open() not per-packet. > > 3. During step 2 above also do the src address selection criteria > specified in the std src address selections being proposed (e.g. > scoping, deprecated, interface index). Yes, a few more instructions per loop. > > 4. Now pass back the pair to the client application? But there > is no API to do this today but could be done in getaddrinfo > possibly. The idea was to pass back an ordered list of addresses from getipnodebyname() and suggest that the upper layer uses the first one unless it wants to override. That way the API doesn't change one bit. > ...But if the client does not want to send the src > address when sending the packet then after step 3 that software > would have to update the implementation kernel stack to know > to use this src address with this particular client send > operation. Exactly, that would be another problem if changing the API. > > I will note doing steps 1-3 inside the kernel of implementations where > the stack resides is not an option as DNS libs are not available they > would have to be pushed into the stack (the 1 to N) DST addresses > returned from DNS. Then do steps 1-3 in the kernel. But then the > client may not know what DST address was used. It chooses, see above. > > Please lets discuss the entire issue. I think there are many reasons we > have not done this already for TCP/IP and DNS address returns. It is > just to much of a burdeon for IP Hosts and for routers even worse. Routers don't have to do this, except when acting as hosts themselves. > Doing this is a very very bad idea because the engineering and > performance costs are to high for the benefit. I'd like numbers: what's the % overhead on a complete DNS lookup followed by an open? Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 00:00:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA25040 for ipng-dist; Thu, 5 Aug 1999 23:57:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25033 for ; Thu, 5 Aug 1999 23:57:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA19718 for ; Thu, 5 Aug 1999 23:57:21 -0700 (PDT) Received: from ns1.digital.fr (ns1.digital.fr [193.56.15.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06933 for ; Thu, 5 Aug 1999 23:57:19 -0700 (PDT) Received: from batman.vbo.dec.com (batman.vbo.dec.com [16.36.208.15]) by ns1.digital.fr (8.8.8/8.8.8) with ESMTP id IAA16763; Fri, 6 Aug 1999 08:56:59 +0200 (MET DST) Received: from becomm.ebo.dec.com (becomm.ebo.dec.com [16.184.208.35]) by batman.vbo.dec.com (8.8.8/8.8.8) with SMTP id IAA11738; Fri, 6 Aug 1999 08:56:27 +0200 (MET DST) Received: from [16.184.242.232] by becomm.ebo.dec.com; (5.65v4.0/1.1.8.2/07Mar96-0221PM) id AA16208; Fri, 6 Aug 1999 08:56:25 +0200 Message-Id: <37AA8711.37BA6905@ebo.dec.com> Date: Fri, 06 Aug 1999 08:56:17 +0200 From: Hans-Peter Durand Reply-To: durand@ebo.dec.com Organization: COMPAQ Computer Corporation X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: de Mime-Version: 1.0 To: Alain Durand Cc: "Cutler, James R" , "'terry@whistle.com'" , "'ipng@sunroof.eng.sun.com'" , "'namedroppers@internic.net'" Subject: Re: FW: IPv6 and Dynamic DNS References: <4.2.0.58.19990805090029.00bf9160@brahma.imag.fr> Content-Type: multipart/mixed; boundary="------------3BA3B380016453B5246516DD" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------3BA3B380016453B5246516DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alain Durand wrote: > At 14:47 04/08/99 -0400, Cutler, James R wrote: > >Nothing an end user does (which requires a TCP/IP connection) should require > >knowledge of either the assigned address or the reverse lookup of the > >assigned address. > > There are several places where reverse lookup is used today. > I do not want to enter in the debate to know if this is good security > practise or not, I'm just saying this is used. > > 1) .rhost mechanism > > 2) some FTP anonymous server insist that you have a PTR record. > If you don't, they do not accept FTP connections. > > 3) anti-spaming rules in SMTP servers. Same thing, if the SMTP > client address does not resolve to a valid PTR, some SMTP servers > will refuse to get the mail. > There are also ERP (enterprise resscource planning) applications around that need the reverse lookup. Such applications are business driven and not by technology. The networks must be higway for informations. > > For those reasons, I'm now manually entering PTR records for my v6 hosts > (most of them use stateless autoconf). My life as netadmin will be much > easier when I'll have DHCPv6 do that for me. > As feedback from my customers, they will not accept a manual maintentance of the ip6.int domin. Besides: Lot of customers have severe problems to maintain their reverselookup in the IPv4 world unless they use a special DNS. -- \\""""// (0 0) +---------------------oOO---------(_)--------------------------------+ |Hans-Peter Durand E-Mail: hanspeter.durand@compaq.com| |COMPAQ Computer Corporation durand@ebo.dec.com| |Murtenstrasse 137a, Voice: +41 79 311 10 54| |CH-3001 Berne, Switzerland Fax: +41 31 381 56 73| +---------------------------------------------oOO--------------------+ |__|__| || || ooO Ooo --------------3BA3B380016453B5246516DD Content-Type: text/x-vcard; charset=us-ascii; name="durand.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Hans-Peter Durand Content-Disposition: attachment; filename="durand.vcf" begin:vcard n:Durand;Hans-Peter x-mozilla-html:TRUE org:Compaq Computer Corporation adr:;;Murtenstrasse 137a;Berne;Berne;CH-3001;Switzerland version:2.1 email;internet:durand@ebo.dec.com title:Senior Consultant tel;fax:+41 79 311 10 54 tel;home:+41 33 222 25 41 tel;work:+41 79 311 10 54 x-mozilla-cpt:;0 fn:Hans-Peter Durand end:vcard --------------3BA3B380016453B5246516DD-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 01:52:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA25108 for ipng-dist; Fri, 6 Aug 1999 01:49:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25101 for ; Fri, 6 Aug 1999 01:49:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA15128 for ; Fri, 6 Aug 1999 01:49:25 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA06475 for ; Fri, 6 Aug 1999 02:49:23 -0600 (MDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id IA07513; Fri, 6 Aug 1999 18:49:01 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-Reply-To: Your message of "Fri, 06 Aug 1999 00:36:03 +0200." <199908052236.AAA09438@givry.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Aug 1999 18:49:00 +1000 Message-Id: <6479.933929340@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 06 Aug 1999 00:36:03 +0200 From: Francis Dupont Message-ID: <199908052236.AAA09438@givry.inria.fr> | => I have in my TODO list the same kind of tools (ie. something which | updates AAAA & PTR RRs from IPv6 addrconf/neighbor discovery). This one is interesting, and is the first real suggestion I have seen that there might be a solution. The question that James Cutler asked - whether we need bother with PTR records at all is certainly a valid one. Unfortunately, most of the discussion that followed, which concentrated on what security exists with PTR records was way off the point - totally irrelevant. Francis - I'd very much appreciate a brief message on just how your proposed tools might go about this task. It doesn't seem to me that it is going to be trivial, though I can see it might be possible. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 02:48:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA25145 for ipng-dist; Fri, 6 Aug 1999 02:45:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25138 for ; Fri, 6 Aug 1999 02:45:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA17395 for ; Fri, 6 Aug 1999 02:45:22 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA14968 for ; Fri, 6 Aug 1999 03:45:20 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id TAA24072; Fri, 6 Aug 1999 19:45:10 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 6 Aug 1999 19:45:10 +1000 (EST) From: Peter Tattam To: Robert Elz cc: Francis Dupont , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-Reply-To: <6479.933929340@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 6 Aug 1999, Robert Elz wrote: > Date: Fri, 06 Aug 1999 00:36:03 +0200 > From: Francis Dupont > Message-ID: <199908052236.AAA09438@givry.inria.fr> > > | => I have in my TODO list the same kind of tools (ie. something which > | updates AAAA & PTR RRs from IPv6 addrconf/neighbor discovery). > > This one is interesting, and is the first real suggestion I have seen that > there might be a solution. > > The question that James Cutler asked - whether we need bother with PTR > records at all is certainly a valid one. Unfortunately, most of the > discussion that followed, which concentrated on what security exists > with PTR records was way off the point - totally irrelevant. > > Francis - I'd very much appreciate a brief message on just how your > proposed tools might go about this task. It doesn't seem to me that > it is going to be trivial, though I can see it might be possible. > > kre I can see some considerable problems if the client initiates contact with the DNS servers since typically ND & stateless config would probably be done at kernel level. Usually DNS related stuff happens at user level in my experience. Mixing the two might be a bit of a headache, but not impossible. >From a general point of view, I see two ways to approach the problem. a) The host machine pushes the information into the DNS system. b) The DNS system pulls the information from the host machines as needed. There are different security implications for each approach. I personally favour the second approach via a "who are you" style of query. In my DNS server, I have a feature to automatically synthesize PTR records from A and AAAA records. It works fine, and you can also add manual entries if you want. One *could* synthesize a DNS entry symbolically I guess. The typical sequence of events would be. 1. Some host requests a PTR query of the DNS server. 2. DNS server does a "who are you" to Ipv6 address. (Filtered of course by site). 3. Machine can then reply a "real" name (manually configured) or "undefined". 4a. If "real" name, a verification has to be made for a duplicate name in the DNS. If there's a clash then change it to "undefined". 4b. If "undefined", the DNS server synthesizes a symbolic name to represent that host. Format to be defined... 5. The DNS server then enters this name as a PTR record. An AAAA record could also be synthesized if the the PTR and AAAA records are on the same site. Looking up an AAAA record is more complicated when AAAA & PTR are on different DNS servers. This could be done in several ways. a) modifying DNS to allow an inverse query on the PTR record (impractical). The AAAA server then queries it's known list of PTR servers for required information. You might as well have the AAAA & PTR servers integrated anyway in this case as this would simply degenerate into a classic AAAA query on the PTR server. b) doing a multicast on the entire site for a FQDN. This might not be very popular at all. There are problems when the SOA server is some distance from the site network. c) having some kind of feedback from the PTR server to other AAAA servers. This would require the design of an out of band (from DNS point of view) mechanism to convey the information. Another idea comes to mind, and that is each IPv6 stack act as a mini DNS server configured with all the correct information relating to what addresses are already configured. However, one then has the problem of grafting the host into the DNS tree. This could potentially by done using some kind of mechanism that allows immediate DNS children to be reliably sought. I could do a whole lot of hand waving here, but I think it would degenerate into a method very similar to what I suggested earlier. Finally, if a push solution is sought, then we would have to define a way for the DNS tree to be updated. My understanding is that the DNS tree is effectively read only when queried through the resolver process. I'm not really up to speed on DNS research, and maybe there are extensions that allow grafting to be done.. (recipe for major trouble if you ask me though :) Just my random thoughts on the issue Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 04:18:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA25289 for ipng-dist; Fri, 6 Aug 1999 04:15:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25282 for ; Fri, 6 Aug 1999 04:15:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA15189 for ; Fri, 6 Aug 1999 04:15:33 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA22843 for ; Fri, 6 Aug 1999 04:15:31 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id VAA06684; Fri, 6 Aug 1999 21:15:28 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Fri, 6 Aug 1999 21:15:28 +1000 (EST) From: Peter Tattam To: IPNG Mailing List cc: namedroppers@internic.net, Francis Dupont Subject: Re: IPv6 and Dynamic DNS 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 One other thought I have had is to use a totally synthesized system. To implement this would simply require some naming conventions. We would use the lower 64 bits of the address to form a token representing the host. An example would be the best way to explain. My host for example would be 0200-F8FF-FE20-7CF8.ip6.trumpet.net. AAAA 3ffe:8000:1:::200:F8FF:FE20:7CF8 The PTR record would be 8.f.c.7.0.2.e.f.f.f.8.f.0.0.2.0.0.0.0.0.1.0.0.0.0.0.0.8.e.f.f.3.ip6.int. PTR 0200-F8FF-FE20-7CF8.ip6.trumpet.net. I think my example is correct (please pardon any mistakes). As long as the naming convention was adhered to, a quick verification can be made for the validity of each type of entry. The unsynthesised part is still under the control of the DNS system. All that's needed is that the DNS servers synthesize according to the rules. This fits the stateless autoconfig model fairly well too. It satisfies the requirement of one-one correspondence between the names, and should correlate well with actual IP addresses. An additional sanity check can be made to prevent spoofing as the lower 64 bit components of each side should always match. The only configuration requirement that the DNS servers need is to know which which site network (upper 64 bits) that is is allowed to synthesize. Apologies if this has already been thought of, or is already in an I-D. This could be implemented with binary labels as well, but would require a fair bit more work than this current idea. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 07:22:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA25403 for ipng-dist; Fri, 6 Aug 1999 07:19:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25396 for ; Fri, 6 Aug 1999 07:19:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA24468 for ; Fri, 6 Aug 1999 07:19:07 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08030 for ; Fri, 6 Aug 1999 08:19:06 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA16069 for ; Fri, 6 Aug 1999 09:19:03 -0500 (CDT) Message-Id: <199908061419.JAA16069@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of Thu, 05 Aug 1999 17:04:52 CDT. <37AA0A84.3C59C124@hursley.ibm.com> Date: Fri, 06 Aug 1999 09:19:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If we all accept the premise that they should both be consistent, then the > > question becomes- "which spec needs to conform?". The answer to that > > probably depends on which is more widely implemented at the current time, > > I guess. Let's see, you're talking about an inconsistency of debatable importance between an RFC at PS status and an *expired* internet draft; have I got it right? Let me think about that for a millisecond. I've searched RFC's several different ways and can't find any other which specify a source/target link-layer address option. Can we move on now? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 07:56:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA25597 for ipng-dist; Fri, 6 Aug 1999 07:53:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25590 for ; Fri, 6 Aug 1999 07:53:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA14165 for ; Fri, 6 Aug 1999 07:53:46 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19266 for ; Fri, 6 Aug 1999 08:53:45 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA203036; Fri, 6 Aug 1999 15:53:42 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA21764; Fri, 6 Aug 1999 15:53:29 +0100 (BST) Message-ID: <37AAF66E.6427BEA0@hursley.ibm.com> Date: Fri, 06 Aug 1999 09:51:26 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Jessica Yu CC: Francis.Dupont@inria.fr, Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) References: <199908041856.OAA24547@cannes.aa.ans.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jessica, I read your draft again yesterday (it was short enough to get through it on my bus ride home:) I agree with Jim. We should try to deploy this. It only solves a subset of the problem, i.e. it only covers certain types of outage and it doesn't help with prefix updates, but within these limits I can't see a problem. I think we should also try Matt Crawford's symmetric variant. And we should also continue to develop the slightly more sophisticated scheme presented in Oslo, and ensure that we can support prefix updates too. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 08:12:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA25634 for ipng-dist; Fri, 6 Aug 1999 08:09:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25627 for ; Fri, 6 Aug 1999 08:09:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29487 for ; Fri, 6 Aug 1999 08:09:31 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25599 for ; Fri, 6 Aug 1999 09:09:30 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA19735; Fri, 6 Aug 1999 11:09:29 -0400 (EDT) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000000101; Fri, 6 Aug 1999 11:09:29 -0400 (EDT) Date: Fri, 6 Aug 1999 11:09:29 -0400 (EDT) From: Sowmini Varadhan Message-Id: <199908061509.LAA0000000101@quarry.zk3.dec.com> To: crawdad@fnal.gov, ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) Cc: varadhan@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From owner-ipng@sunroof.eng.sun.com Fri Aug 6 10:24:17 1999 > >> > If we all accept the premise that they should both be consistent, then the >> > question becomes- "which spec needs to conform?". The answer to that >> > probably depends on which is more widely implemented at the current time, >> > I guess. > >Let's see, you're talking about an inconsistency of debatable >importance between an RFC at PS status and an *expired* internet >draft; have I got it right? Let me think about that for a >millisecond. > >I've searched RFC's several different ways and can't find any other >which specify a source/target link-layer address option. > I hope there was more substance to my mail than just that. I am well aware that source/target link-layer address options are not defined in any RFC for configured tunnels. However, the fact remains that there was once a draft defining this, and that configured tunnels do happen to be more widely implemented and tested than 6over4, so that there is/was a possibility that the obsoleted link-layer option implementations were already established. Apparently it's not an issue.. >Can we move on now? Sure. There are other issues, to which I am still waiting for a response- Having read RFC 2529, I'm still not convinced, for example that the setting of the DF bit is a MUST NOT. Also, there did not seem to be any discussion of the scalability of V4 multicasting, considering its lack of deployment (for which I am sure, there's a reason), and the dependancies between 6over4 (with all its virtues) and V4 multicasting. Are we going to spend a few milliseconds in the RFC/mailing list going over these details? --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 09:31:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA25765 for ipng-dist; Fri, 6 Aug 1999 09:24:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25758 for ; Fri, 6 Aug 1999 09:24:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA05644 for ; Fri, 6 Aug 1999 09:24:11 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24165 for ; Fri, 6 Aug 1999 10:24:09 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA73514; Fri, 6 Aug 1999 17:23:54 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA20958; Fri, 6 Aug 1999 17:23:32 +0100 (BST) Message-ID: <37AB0B7C.230F71EA@hursley.ibm.com> Date: Fri, 06 Aug 1999 11:21:16 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Sowmini Varadhan CC: crawdad@fnal.gov, ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) References: <199908061509.LAA0000000101@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sowmini, This is an approved IETF proposed standard. That means that for an implementor, there is no choice right now: what the RFC says is what you implement, right? When we discuss the advancement of the standard, we should indeed discuss whether to make changes in view of experience, and your experience will be a key part of that. Personally I agree with Matt, there is no reason to make a change for consistency with Alex's old draft. I can't remember why we right-justified the field; possibly it looked better from an alignment point of view. Fundamentally it doesn't matter, so why change it, absent a running-code reason to do so? About DF: We tend not to put rationales in RFCs, and I would have to go back into some ancient archives to find the discussion on this. I think the point is that since we cannot rely on IPv4 MTU discovery being deployed everywhere, setting DF would in some circumstances *guarantee* the loss of all 6over4 packets and this would be very hard to diagnose operationally. A SHOULD NOT doesn't protect against this. Can you come up with a case where setting DF would be a good thing to do? Brian Sowmini Varadhan wrote: > > >From owner-ipng@sunroof.eng.sun.com Fri Aug 6 10:24:17 1999 > > > >> > If we all accept the premise that they should both be consistent, then the > >> > question becomes- "which spec needs to conform?". The answer to that > >> > probably depends on which is more widely implemented at the current time, > >> > I guess. > > > >Let's see, you're talking about an inconsistency of debatable > >importance between an RFC at PS status and an *expired* internet > >draft; have I got it right? Let me think about that for a > >millisecond. > > > >I've searched RFC's several different ways and can't find any other > >which specify a source/target link-layer address option. > > > > I hope there was more substance to my mail than just that. > > I am well aware that source/target link-layer address options are not > defined in any RFC for configured tunnels. However, the fact remains > that there was once a draft defining this, and that configured tunnels do > happen to be more widely implemented and tested than 6over4, so that > there is/was a possibility that the obsoleted link-layer option > implementations were already established. Apparently it's not an issue.. > > >Can we move on now? > > Sure. There are other issues, to which I am still waiting for a response- > Having read RFC 2529, I'm still not convinced, for example > that the setting of the DF bit is a MUST NOT. > Also, there did not seem to be any discussion of the > scalability of V4 multicasting, considering its lack of deployment > (for which I am sure, there's a reason), and the dependancies > between 6over4 (with all its virtues) and V4 multicasting. > > Are we going to spend a few milliseconds in the RFC/mailing list > going over these details? > > --Sowmini > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 09:46:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA25802 for ipng-dist; Fri, 6 Aug 1999 09:42:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25795 for ; Fri, 6 Aug 1999 09:41:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09159 for ; Fri, 6 Aug 1999 09:41:52 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24679 for ; Fri, 6 Aug 1999 09:41:50 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA16955; Fri, 6 Aug 1999 11:41:45 -0500 (CDT) Message-Id: <199908061641.LAA16955@gungnir.fnal.gov> To: "Peter Ford (Exchange)" Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of Fri, 06 Aug 1999 07:51:12 PDT. <078292D50C98D2118D090008C7E9C6A6017942C1@STAY.platinum.corp.microsoft.com> Date: Fri, 06 Aug 1999 11:41:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > as I remember neighbor discovery, a client can passively addrconf (to coin a > verb). > > It sure would be nice if you could force some sort of "hard" addrconf so > that servers on the network would know who is "on a wire", this would allow > ... You can, through the flags that the router includes with the advertisement of each prefix. It's all in 2461. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 09:54:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA25840 for ipng-dist; Fri, 6 Aug 1999 09:51:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25833 for ; Fri, 6 Aug 1999 09:51:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA29259 for ; Fri, 6 Aug 1999 09:51:50 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05661 for ; Fri, 6 Aug 1999 10:51:49 -0600 (MDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA24505; Fri, 6 Aug 1999 12:51:49 -0400 (EDT) Received: by anw.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000633628; Fri, 6 Aug 1999 12:51:48 -0400 (EDT) Date: Fri, 6 Aug 1999 12:51:48 -0400 (EDT) From: Sowmini Varadhan Message-Id: <199908061651.MAA0000633628@anw.zk3.dec.com> To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) Cc: varadhan@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From brian@hursley.ibm.com Fri Aug 6 12:28:08 1999 > >About DF: We tend not to put rationales in RFCs, and I would >have to go back into some ancient archives to find the >discussion on this. It would be nice to cross-reference the above documents if possible, for the benefit of folks such as myself. > I think the point is that since we cannot >rely on IPv4 MTU discovery being deployed everywhere, setting >DF would in some circumstances *guarantee* the loss of all >6over4 packets and this would be very hard to diagnose >operationally. But that's precisely my point. Yes, I agree that the DF bit can cause a hard-to-diagnose scenario and therefore SHOULD NOT (as defined in RFC 2119) be set under most commonly occurring cases ; but I'm having a hard time seeing why it should never be set either (i.e. RFC 2119's MUST NOT) >Can you come up with a case where setting DF would be a good >thing to do? Maybe I can't come up with that special case for DF today due to a lack of vision on my part. However, my inability to come up with a case for DF does not conclusively establish why the DF is to be outlawed. Which is why I feel it's a SHOULD NOT. Yes? --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 11:15:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA26022 for ipng-dist; Fri, 6 Aug 1999 11:11:42 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26015 for ; Fri, 6 Aug 1999 11:11:35 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA12074 for ipng@sunroof.eng.sun.com; Fri, 6 Aug 1999 11:09:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25707 for ; Fri, 6 Aug 1999 08:26:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA18139 for ; Fri, 6 Aug 1999 08:26:58 -0700 (PDT) Received: from pool.pipex.net (pool.pipex.net [158.43.128.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA01760 for ; Fri, 6 Aug 1999 09:26:57 -0600 (MDT) Received: (qmail 20543 invoked from smtpd); 6 Aug 1999 15:26:56 -0000 Received: from ncam078.cam.uk.internal (HELO uu.net) (172.31.1.78) by pool.cam.uk.internal with SMTP; 6 Aug 1999 15:26:56 -0000 Message-ID: <37AAFF2B.AC1B208@uu.net> Date: Fri, 06 Aug 1999 16:28:43 +0100 From: Guy Davies Organization: UUNET, An MCI WorldCom Company X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Jessica Yu , Francis.Dupont@inria.fr, Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: Session Stability (was multi-homing vs route aggregation) References: <199908041856.OAA24547@cannes.aa.ans.net> <37AAF66E.6427BEA0@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > Jessica, > > I read your draft again yesterday (it was short enough to get through > it on my bus ride home:) > > I agree with Jim. We should try to deploy this. It only solves > a subset of the problem, i.e. it only covers certain types > of outage and it doesn't help with prefix updates, but within > these limits I can't see a problem. > > I think we should also try Matt Crawford's symmetric variant. UUNET-UK did this last year with ATT-LABS-EUROPE for our mutual "customer" DIT-NG. It seemed to work within the limited scope of the 6bone activity at that time. The issue of source selection didn't come up but it may be that we just weren't breaking so the resillience wasn't being tested ;-) Guy > And we should also continue to develop the slightly more > sophisticated scheme presented in Oslo, and ensure that we can > support prefix updates too. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Guy Davies UUNET, An MCI WorldCom Company Senior Network Engineer 332 Science Park, Cambridge, e: Guy.Davies@uk.uu.net United Kingdom, CB4 4BZ t: +44 (1223) 250457 m: +44 (7771) 907481 f: +44 (1223) 250412 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 11:15:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA26012 for ipng-dist; Fri, 6 Aug 1999 11:10:53 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26005 for ; Fri, 6 Aug 1999 11:10:48 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id LAA12045 for ipng@sunroof.eng.sun.com; Fri, 6 Aug 1999 11:09:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25578 for ; Fri, 6 Aug 1999 07:53:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA27597 for ; Fri, 6 Aug 1999 07:53:12 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19119 for ; Fri, 6 Aug 1999 08:53:11 -0600 (MDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 6 Aug 1999 07:51:14 -0700 Message-ID: <078292D50C98D2118D090008C7E9C6A6017942C1@STAY.platinum.corp.microsoft.com> From: "Peter Ford (Exchange)" To: "'Robert Elz'" , Francis Dupont Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: RE: IPv6 and Dynamic DNS Date: Fri, 6 Aug 1999 07:51:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk as I remember neighbor discovery, a client can passively addrconf (to coin a verb). It sure would be nice if you could force some sort of "hard" addrconf so that servers on the network would know who is "on a wire", this would allow routers to do host based routing, build more accurate topology databases (a BIG request from customers), etc. peter -----Original Message----- From: Robert Elz [mailto:kre@MUNNARI.OZ.AU] Sent: Friday, August 06, 1999 1:49 AM To: Francis Dupont Cc: ipng@sunroof.eng.sun.com; namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS Date: Fri, 06 Aug 1999 00:36:03 +0200 From: Francis Dupont Message-ID: <199908052236.AAA09438@givry.inria.fr> | => I have in my TODO list the same kind of tools (ie. something which | updates AAAA & PTR RRs from IPv6 addrconf/neighbor discovery). This one is interesting, and is the first real suggestion I have seen that there might be a solution. The question that James Cutler asked - whether we need bother with PTR records at all is certainly a valid one. Unfortunately, most of the discussion that followed, which concentrated on what security exists with PTR records was way off the point - totally irrelevant. Francis - I'd very much appreciate a brief message on just how your proposed tools might go about this task. It doesn't seem to me that it is going to be trivial, though I can see it might be possible. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 11:15:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA26031 for ipng-dist; Fri, 6 Aug 1999 11:11:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26024 for ; Fri, 6 Aug 1999 11:11:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA17215 for ; Fri, 6 Aug 1999 11:11:46 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07188 for ; Fri, 6 Aug 1999 12:11:45 -0600 (MDT) Received: from [171.68.180.124] ([171.70.127.18]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA01522 for ; Fri, 6 Aug 1999 11:11:45 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: Date: Fri, 6 Aug 1999 11:11:39 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: IPv6 in the news Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, a couple of recent news articles about IPv6: - The Economist magazine, current issue (dated July 31 - Aug 6), page 69. (Also available at www.economist.com, but only for subscribers.) - http://news.com/News/Item/0,4,0-40127,00.html?st.ne.140.head Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 12:19:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA26145 for ipng-dist; Fri, 6 Aug 1999 11:48:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26138 for ; Fri, 6 Aug 1999 11:47:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA05925 for ; Fri, 6 Aug 1999 11:47:47 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20335 for ; Fri, 6 Aug 1999 12:47:46 -0600 (MDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA24997; Fri, 6 Aug 1999 11:47:42 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA10067; Fri, 6 Aug 1999 11:47:42 -0700 (PDT) Received: from tellurium (usr-modem2.nsd.3com.com [129.213.205.122]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id LAA12651; Fri, 6 Aug 1999 11:47:40 -0700 (PDT) Message-Id: <3.0.2.32.19990806114448.01293240@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 06 Aug 1999 11:44:48 -0700 To: Brian E Carpenter , ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: Re: RFC 2529 (6over4) In-Reply-To: <37AA0B2C.63BCB89D@hursley.ibm.com> References: <199908051449.KAA0000019331@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are many myths about the actual deployment of IP multicast. It is difficult for me to assess he true extent of deployment. Our corporate network has been multicast enabled for years, and we periodically blast the face of the president (or some other executive) across the network for people world-wide to witness from the comforts of their office - I don't know if that counts for you. It is clearly having a major struggle in the inter-domain - those problems are not going to be solved easily. However, 6over4 is probably not an inter-domain solution, rather an intra-domain, which is why the admin scope of organization-local was chosen. As to the deployment of admin scoping, it is deployable via filters in reasonable implementations of IP multicast, and is independent of any particular multicast routing protocol. Even if you are using simply DVMRP and MOSPF the filters can be configured. Cyndi At 05:07 PM 8/5/99 -0500, Brian E Carpenter wrote: >Sowmini Varadhan wrote: >... >> cmj> I think TTL scoping for multicast has been found to be unworkable - but >> cmj> is still a poor man's scooping tool. There is still work being done in >> cmj> deploying the admin scoping, ... >> >> But, until 2365 is widely deployed, all testing will have to rely on >> TTL scoping of multicasts, and this has ramifications on product planning. >> >> What do you think? > >Frankly, multicast itself is not that widely deployed. I'd be >reluctant to specify a bad solution on the grounds that the good >solution is too new. > > Brian >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 12:19:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA26156 for ipng-dist; Fri, 6 Aug 1999 11:50:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26149 for ; Fri, 6 Aug 1999 11:49:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA27631 for ; Fri, 6 Aug 1999 11:49:53 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15239 for ; Fri, 6 Aug 1999 11:49:52 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA25571; Fri, 6 Aug 1999 11:49:46 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA10652; Fri, 6 Aug 1999 11:49:45 -0700 (PDT) Received: from tellurium (usr-modem2.nsd.3com.com [129.213.205.122]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id LAA12733; Fri, 6 Aug 1999 11:49:43 -0700 (PDT) Message-Id: <3.0.2.32.19990806114651.01294460@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 06 Aug 1999 11:46:51 -0700 To: Brian E Carpenter , ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: Re: RFC 2529 (6over4) In-Reply-To: <37AA0A84.3C59C124@hursley.ibm.com> References: <199908051417.KAA0000968153@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I really can't understand why anyone would use ND or Redirects over a configured tunnel. The Link-Layer address option is for ND and Redirects, isn't it? Is there another use? Cyndi At 05:04 PM 8/5/99 -0500, Brian E Carpenter wrote: >Sowmini Varadhan wrote: >... >> >>The zero byte padding used in the link layer option is conflicting with >> >>the position of padding chosen in the only other document that I see >> >>which attempts to define the format of Link-Layer address options. >> >>rfc2529 says: >> >> 198 >> >> 199 +-------+-------+-------+-------+-------+-------+-------+-------+ >> >> 200 | Type |Length | must be zero | IPv4 Address | >> >> 201 +-------+-------+-------+-------+-------+-------+-------+-------+ >> >> 202 >> >>while draft-conta-ipv6-trans-tunnel-00.txt says >> >> 0 1 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> 0 | Type | Length | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> 2 | IPv4 | >> >> +- -+ >> >> 4 | Address | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> 6 | Padding | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>Should the 2 be consistent? >> > >> >Do they need to be? I can't find this draft, but I did find the >> >RFC2497 for shipping IPv6 over ARCNET, and the padding there is >> >post the media address. I somehow think this is minor - is there >> >a need for consistency? >> >> Yes, I think there's a need for consistency! Both configured tunnels >> and the 6over4 conceptually use IPV4 as the link-layer, and there can >> only be one kind of link-layer address for any particular link type, right? >> >> Besides, I believe that it's cleaner from an implementation standpoint- >> the implementation does not have to keep track of the type of >> encapsulation (6over4 vs configured) when parsing incoming link-layer >> address options. >> >> If we all accept the premise that they should both be consistent, then the >> question becomes- "which spec needs to conform?". The answer to that probably >> depends on which is more widely implemented at the current time, I guess. > >If we change this it is a change to the wire protocol and it invalidates >the existing implementations; it also means the document has to be >recycled at Proposed Standard. So we would have to be *very* sure >that we want to change it. > > Brian >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 12:20:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA26173 for ipng-dist; Fri, 6 Aug 1999 11:59:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26166 for ; Fri, 6 Aug 1999 11:58:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA27601 for ; Fri, 6 Aug 1999 11:58:38 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18320 for ; Fri, 6 Aug 1999 11:58:37 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA26599; Fri, 6 Aug 1999 11:51:55 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA11499; Fri, 6 Aug 1999 11:51:55 -0700 (PDT) Received: from tellurium (usr-modem2.nsd.3com.com [129.213.205.122]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id LAA12772; Fri, 6 Aug 1999 11:51:51 -0700 (PDT) Message-Id: <3.0.2.32.19990806114859.01294460@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 06 Aug 1999 11:48:59 -0700 To: Sowmini Varadhan , brian@hursley.ibm.com, ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: Re: RFC 2529 (6over4) Cc: varadhan@zk3.dec.com In-Reply-To: <199908061651.MAA0000633628@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I really think that the black hole caused by an IPv4 segment of the path with a smaller MTU than ethernet would be a major reason to make the use of DF a MUST NOT. Cyndi At 12:51 PM 8/6/99 -0400, Sowmini Varadhan wrote: >>From brian@hursley.ibm.com Fri Aug 6 12:28:08 1999 >> >>About DF: We tend not to put rationales in RFCs, and I would >>have to go back into some ancient archives to find the >>discussion on this. > >It would be nice to cross-reference the above documents if possible, >for the benefit of folks such as myself. > >> I think the point is that since we cannot >>rely on IPv4 MTU discovery being deployed everywhere, setting >>DF would in some circumstances *guarantee* the loss of all >>6over4 packets and this would be very hard to diagnose >>operationally. > >But that's precisely my point. Yes, I agree that the DF bit can cause >a hard-to-diagnose scenario and therefore SHOULD NOT (as defined in RFC 2119) >be set under most commonly occurring cases ; but I'm having a hard time >seeing why it should never be set either (i.e. RFC 2119's MUST NOT) > >>Can you come up with a case where setting DF would be a good >>thing to do? > >Maybe I can't come up with that special case for DF today due >to a lack of vision on my part. However, my inability to come >up with a case for DF does not conclusively establish why >the DF is to be outlawed. Which is why I feel it's a SHOULD NOT. Yes? > >--Sowmini >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 12:43:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA26300 for ipng-dist; Fri, 6 Aug 1999 12:32:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26287 for ; Fri, 6 Aug 1999 12:32:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA16594 for ; Fri, 6 Aug 1999 12:31:52 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05621 for ; Fri, 6 Aug 1999 13:31:52 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id PAA05794; Fri, 6 Aug 1999 15:31:44 -0400 (EDT) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000005463; Fri, 6 Aug 1999 15:31:40 -0400 (EDT) Date: Fri, 6 Aug 1999 15:31:40 -0400 (EDT) From: Sowmini Varadhan Message-Id: <199908061931.PAA0000005463@quarry.zk3.dec.com> To: brian@hursley.ibm.com, cmj@luxor.ewd.3com.com, ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From owner-ipng@sunroof.eng.sun.com Fri Aug 6 15:21:43 1999 > >I really can't understand why anyone would use ND or Redirects >over a configured tunnel. The Link-Layer address option is for ND >and Redirects, isn't it? Is there another use? > >Cyndi > At one point (about the same time last year), Cisco routers were sending us link-layer address options with their router advertisements. I'm not sure if they still do this. I'm also not sure how useful it was intended to be, but we had to parse it all the same. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 12:58:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA26359 for ipng-dist; Fri, 6 Aug 1999 12:54:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26352 for ; Fri, 6 Aug 1999 12:54:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA16363 for ; Fri, 6 Aug 1999 12:54:01 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13421 for ; Fri, 6 Aug 1999 13:54:00 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id PAA07286; Fri, 6 Aug 1999 15:53:54 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000011286; Fri, 6 Aug 1999 15:53:53 -0400 (EDT) From: Jim Bound Message-Id: <199908061953.PAA0000011286@quarry.zk3.dec.com> To: Robert Elz cc: Francis Dupont , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Fri, 06 Aug 1999 18:49:00 +1000." <6479.933929340@munnari.OZ.AU> Date: Fri, 06 Aug 1999 15:53:53 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | => I have in my TODO list the same kind of tools (ie. something which | updates AAAA & PTR RRs from IPv6 addrconf/neighbor discovery). >This one is interesting, and is the first real suggestion I have seen that >there might be a solution. Hmmm. already wrote the code to do this and it work and I said so in my first response to your mail ???? This runs now on Compaq Tru64 UNIX. If you have an Alpha you can pull our v6 kit and test it at munnrai. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 13:03:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA26391 for ipng-dist; Fri, 6 Aug 1999 13:01:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26384 for ; Fri, 6 Aug 1999 13:01:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA21185 for ; Fri, 6 Aug 1999 13:01:18 -0700 (PDT) Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA10420 for ; Fri, 6 Aug 1999 13:01:18 -0700 (PDT) Received: from (alderhill) [131.243.136.213] by mail1.es.net with smtp (Exim 1.81 #2) id 11CqB2-0006NQ-00; Fri, 6 Aug 1999 13:01:16 -0700 Message-Id: <4.1.19990806123136.00b644c0@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 06 Aug 1999 13:01:10 -0700 To: IPng List From: Bob Fink Subject: first production IPv6 prefix allocated by ARIN to ESnet (2001:0400::/35) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 community, Good news! The first production IPv6 prefix has been assigned by ARIN to ESnet (2001:0400::/35). This is a milestone for IPv6. Those networks that had previously requested sTLAs should now reapply to their respective registries (APNIC, ARIN and RIPE-NCC) for them. I have already been getting requests from these registries for validation that requestors qualify under the 6bone bootstrap policy. I would like to thank everyone involved over the last 2 1/2 years in the development of the Aggregatable Global Unicast Address Format and the policies regarding their allocation/assignment. I've included a short history and timeline of this effort below. I would especially like to commend the registries, both for their efforts to provide meaningful stewardship over the IPv6 address space, and for quickly starting the allocation process after IAB/IANA/RIR agreements on allocation policy were finalized. So many thanks to the APNIC, ARIN and RIPE-NCC staff! Regards, Bob === Fall 1996 - Mike O'Dell 8+8 (aka GSE) proposal to replace Provider Based Unicast Addressing for IPv6 Feb 1997 - Interim IPng WG meeting in Palo Alto to review 8+8 - some ideas kept, some discarded Apr 1997 - IPng WG meeting in Memphis - first idea of Aggregatable Unicast Addressing formulated May 1997 - Aggregatable Unicast Addressing draft and 6bone Test TLA draft released Oct 1997 - 6bone converts to Aggregatable Unicast Addressing under 3FFE::/16 Test TLA Jan 1998 - discussions begin between IAB/IETF, IANA, ARIN, APNIC and RIPE-NCC on policy to assign production TLAs Jul 1998 - RFC 2374, An IPv6 Aggregatable Global Unicast Address Format, published as Proposed Standard Aug 1998 - First requests for SubTLAs (sTLA) made to ARIN, APNIC and RIPE-NCC Jul 1999 - Oslo IETF - Final policy on assigning sTLAs reached (July 14) Jul 20 1999 - First sTLA request (by ESnet) made under new policy submitted to ARIN Jul 21 1999 - First sTLA request approved (for ESnet) by ARIN (July 21) pending billing Jul 31 1999 - First IPv6 production prefix (sTLA = 2001:0400::/35) assigned (to ESnet) -end -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 13:31:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA26472 for ipng-dist; Fri, 6 Aug 1999 13:24:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26465 for ; Fri, 6 Aug 1999 13:24:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA11611 for ; Fri, 6 Aug 1999 13:24:02 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24585 for ; Fri, 6 Aug 1999 14:24:01 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id QAA09364; Fri, 6 Aug 1999 16:23:57 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000017876; Fri, 6 Aug 1999 16:23:56 -0400 (EDT) From: Jim Bound Message-Id: <199908062023.QAA0000017876@quarry.zk3.dec.com> To: Cyndi Jung cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of "Fri, 06 Aug 1999 11:44:48 PDT." <3.0.2.32.19990806114448.01293240@mailhost.ewd.3com.com> Date: Fri, 06 Aug 1999 16:23:56 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cyndi, Here is the bottom line. If 2365 is not on the street now after some time. We have to make choices as vendors which transition mechanisms we deploy first, next, and next++++. If we can use 6over4 with the multicast that is out there today then I think it has a good chance to hit deployment for "first" or "next" if it requires 2365 as the spec says now with no statements other than that then its "next++++" we are better off letting customers use configured tunnels and using natpt, siit and other mecahanisms intially. I will not support using 6over4 to get 2365 deployed either. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 14:08:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA26670 for ipng-dist; Fri, 6 Aug 1999 14:04:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26660 for ; Fri, 6 Aug 1999 14:04:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA18229 for ; Fri, 6 Aug 1999 14:04:47 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08848 for ; Fri, 6 Aug 1999 15:04:45 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id RAA11647; Fri, 6 Aug 1999 17:04:45 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000026286; Fri, 6 Aug 1999 17:04:44 -0400 (EDT) From: Jim Bound Message-Id: <199908062104.RAA0000026286@quarry.zk3.dec.com> To: Brian E Carpenter cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing In-reply-to: Your message of "Thu, 05 Aug 1999 17:59:22 CDT." <37AA174A.376C712E@hursley.ibm.com> Date: Fri, 06 Aug 1999 17:04:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >The reason I'm pushing this is that I see it as a serious >operational issue once we start having multiple prefixes, which >IMHO we certainly will get sooner or later. If we don't do it >right we will end up with very non-optimal routing. This matters >just as much as host (in)efficiency so we have to find the right >tradeoff I simply don't any issues at all that cannot be resolved without what your asking. Maybe if you could articulate exactly the problems you see we can have that discussion, as of right now I don't see why your concerned and it could be I assume a different fix. >> So this means a client would take 1 to N DST addresses given to them >> from the DNS while the client is awaiting a response from >> getipnodebyname or getaddrinfo, and do this processing while the client >> waits. >Exactly, i.e. this process is added to the generic DNS overhead >befor you get to call open(). Can you quantify this? Given that DNS >lookups take up to seconds, how much extra overhead time are we >talking here? What do you mean call "open". This will happen when you call getipnodebyname or getaddrinfo? >> Here is what the ramifications are to implementations: >> >> 1. The client takes 1 to N addresses off the DNS set returned and >> performs an I/O access to the place in the IPv6 implementation >> to access all potential src addresses on the platform. This is >> most likely multiple reads and causes a context switch on >> the platform. >I/O access? Why on earth? I'd expect the stack simply to know its >current interface/address pairings in a (small) table. Brian bare with me here. That stack is in the kernel. Any OS I have ever worked with as an engineer divides the OS into User Space (DNS, APIs, Telnet) ------------------------------- Kernel Space (IP RFCs, IF-Datastructures etc) What I mean't here was an "ioctl" to access the interface structures in the kernel. They are not sitting in user space today like many other config parameters on a platform. The stack also lives in kernel space not user space, for future discussion. >>... Unless one keeps an updated file to be read > >You don't mean a disk file do you? Why not a simple data structure >in the stack? One option would be to keep a file or datastructure in user space to read within the DNS application the address pairs. As opposed to accessing the kernel each time for each API setting this mechanism off. >> on the client of src addresses available. If such a file is >> kept then it will add new code to every utility that adds or >> alters or deletes addresses on the platform and in many places >> for many implementations > >Yes, for sure That will takes years to get fixed as note is my guess. Just like the way everyone ignored the IETF on storing static stuff in their implementations for renumbering. Which I agree is a bad thing but engineering managers are not going to fix it unless customers ask for it not because we ask for it in the IETF. Likewise for src/dst addr compares. >> ...and I do not believe that to be >> optimal. >Is this an overhead that matters? Is it on any critical paths? Its the overhead mostly. Not sure what you mean by critical path in this context? >> ...I suppose an implementation could map the interface >> structures to a file via a memory mapping but it is not >> 100% full proof to be guranteed. > >I assumed that the stack would simply have this available >anyway for other reasons. It does but see my comments about stack above. >> 2. Once the client now has those src addresses start the compare >> using longest match or some other algorithm to find the >> best src address to match a dst address. Then store that >> result with some kind of weight in some datastructure. Then >> proceed to compare the next dst address in a loop (might >> be able to be done recursively). >Correct. This is also where you would insert heuristics and maybe >refer to some current "network weather" info to choose a path. >But it is on the path to open() not per-packet. I am not following your "open" word here? >> 3. During step 2 above also do the src address selection criteria >> specified in the std src address selections being proposed (e.g. >> scoping, deprecated, interface index). >>Yes, a few more instructions per loop. >> 4. Now pass back the pair to the client application? But there >> is no API to do this today but could be done in getaddrinfo >> possibly. >The idea was to pass back an ordered list of addresses from >getipnodebyname() and suggest that the upper layer uses the >first one unless it wants to override. That way the API >doesn't change one bit. Sure it does. Right now hostent only contains a singluar ordered list of addresses it does not denote the concept of any tuple. This is definitely a change to the API. There is a workaround though. >>> ...But if the client does not want to send the src >>> address when sending the packet then after step 3 that software >>> would have to update the implementation kernel stack to know >>> to use this src address with this particular client send >>> operation. > >Exactly, that would be another problem if changing the API. But the API does change Brian. Also most apps let the kernel pick the src address and do not send it to the kernel where the stack lives. >> I will note doing steps 1-3 inside the kernel of implementations where >> the stack resides is not an option as DNS libs are not available they >> would have to be pushed into the stack (the 1 to N) DST addresses >> returned from DNS. Then do steps 1-3 in the kernel. But then the >> client may not know what DST address was used. >It chooses, see above. That won't work. >> Doing this is a very very bad idea because the engineering and >> performance costs are to high for the benefit. >I'd like numbers: what's the % overhead on a complete DNS lookup >followed by an open? Please define what you mean by open. I will think about a % for you. I will also add that this is a lot of software logic to put into a critical path application set on our platforms when you have not stated in detail the reason this is even required. I will analyze the cost of code per CPU cycles you go tell us why you want this in detail OK. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 14:20:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA26731 for ipng-dist; Fri, 6 Aug 1999 14:17:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26724 for ; Fri, 6 Aug 1999 14:16:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA22291 for ; Fri, 6 Aug 1999 14:16:56 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13219 for ; Fri, 6 Aug 1999 15:16:55 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA98758; Fri, 6 Aug 1999 22:16:53 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA24376; Fri, 6 Aug 1999 22:16:48 +0100 (BST) Message-ID: <37AB5043.1CFD5E43@hursley.ibm.com> Date: Fri, 06 Aug 1999 16:14:43 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Sowmini Varadhan CC: ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) References: <199908061651.MAA0000633628@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sowmini, Your argument is exactly what leads me to the MUST NOT conclusion. Because it may cause very hard problems, don't do it. SHOULD NOT leaves the door open to implementors to do the wrong thing. Brian Sowmini Varadhan wrote: > > >From brian@hursley.ibm.com Fri Aug 6 12:28:08 1999 > > > >About DF: We tend not to put rationales in RFCs, and I would > >have to go back into some ancient archives to find the > >discussion on this. > > It would be nice to cross-reference the above documents if possible, > for the benefit of folks such as myself. > > > I think the point is that since we cannot > >rely on IPv4 MTU discovery being deployed everywhere, setting > >DF would in some circumstances *guarantee* the loss of all > >6over4 packets and this would be very hard to diagnose > >operationally. > > But that's precisely my point. Yes, I agree that the DF bit can cause > a hard-to-diagnose scenario and therefore SHOULD NOT (as defined in RFC 2119) > be set under most commonly occurring cases ; but I'm having a hard time > seeing why it should never be set either (i.e. RFC 2119's MUST NOT) > > >Can you come up with a case where setting DF would be a good > >thing to do? > > Maybe I can't come up with that special case for DF today due > to a lack of vision on my part. However, my inability to come > up with a case for DF does not conclusively establish why > the DF is to be outlawed. Which is why I feel it's a SHOULD NOT. Yes? > > --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 15:09:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA26810 for ipng-dist; Fri, 6 Aug 1999 15:03:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26803 for ; Fri, 6 Aug 1999 15:03:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA12199 for ; Fri, 6 Aug 1999 15:03:43 -0700 (PDT) Received: from frantic.bsdi.com ([209.173.194.226]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21279 for ; Fri, 6 Aug 1999 15:03:42 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id RAA01295; Fri, 6 Aug 1999 17:03:04 -0500 (CDT) Date: Fri, 6 Aug 1999 17:03:04 -0500 (CDT) From: David Borman Message-Id: <199908062203.RAA01295@frantic.bsdi.com> To: cmj@3Com.com, ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Fri, 06 Aug 1999 11:48:59 -0700 > From: Cyndi Jung > Subject: Re: RFC 2529 (6over4) > > I really think that the black hole caused by an IPv4 segment of > the path with a smaller MTU than ethernet would be a major reason > to make the use of DF a MUST NOT. I think the setting of the DF bit should be at least SHOULD NOT, not MUST NOT. Why would a segment with less than an ethernet MTU be a black hole? The whole point of setting the DF bit is to allow you to discover the MTU of the path. In the case of 6over4, if you discover a link with an MTU less than 1300 (1280 minimum MTU for IPv6 plus 20 bytes for IPv6 header), then for that host you have discovered that the Path MTU is too small, so you turn off the setting of the DF bit for that host, and let it fragment the packet and send it on. The point is that you only set the DF bit in the IPv4 header if you are planning on doing IPv4 Path MTU Discovery. If you find that the discovered MTU doesn't give you a usable path, then you stop setting the DF bit. Also, it might be that you only set the DF bit for TCP packets. As for real black holes (gateways that discard packets due to the DF bit being set, but don't generate an appropriate ICMP message), we shouldn't be limiting the design of a protocol based on bad implementations, the bad implementations should be fixed. > >>From brian@hursley.ibm.com Fri Aug 6 12:28:08 1999 > >>... > >>Can you come up with a case where setting DF would be a good > >>thing to do? If you have two IPv6 hosts, each connected to an fddi ring, using 6over4 between them other over a path that has ethernet in the middle, it would be good to know that so that they don't keep sending fddi size packets that have to be fragmented/reassembled. If you can't set the DF bit, you can't do Path MTU discovery and hence you can't find that out. Sure, it takes some thinking and extra code to do it right, but if the implementor is willing to do the work, why should the protocol prohibit it? -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 15:53:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA26852 for ipng-dist; Fri, 6 Aug 1999 15:45:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26845 for ; Fri, 6 Aug 1999 15:45:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA19413 for ; Fri, 6 Aug 1999 15:45:39 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04491 for ; Fri, 6 Aug 1999 15:45:38 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA114150; Fri, 6 Aug 1999 23:45:35 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA21950; Fri, 6 Aug 1999 23:45:32 +0100 (BST) Message-ID: <37AB6510.D2C5E13A@hursley.ibm.com> Date: Fri, 06 Aug 1999 17:43:28 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: David Borman CC: cmj@3com.com, ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) References: <199908062203.RAA01295@frantic.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, I think the point is that IPv6 will do MTU discovery anyway; so there is no need to do it at the IPv4 level too. Brian David Borman wrote: > > > Date: Fri, 06 Aug 1999 11:48:59 -0700 > > From: Cyndi Jung > > Subject: Re: RFC 2529 (6over4) > > > > I really think that the black hole caused by an IPv4 segment of > > the path with a smaller MTU than ethernet would be a major reason > > to make the use of DF a MUST NOT. > > I think the setting of the DF bit should be at least SHOULD NOT, > not MUST NOT. > > Why would a segment with less than an ethernet MTU be a black > hole? The whole point of setting the DF bit is to allow you to > discover the MTU of the path. In the case of 6over4, if you > discover a link with an MTU less than 1300 (1280 minimum MTU > for IPv6 plus 20 bytes for IPv6 header), then for that host > you have discovered that the Path MTU is too small, so you turn > off the setting of the DF bit for that host, and let it fragment > the packet and send it on. > > The point is that you only set the DF bit in the IPv4 header if > you are planning on doing IPv4 Path MTU Discovery. If you find > that the discovered MTU doesn't give you a usable path, then you > stop setting the DF bit. Also, it might be that you only set the > DF bit for TCP packets. > > As for real black holes (gateways that discard packets due to the > DF bit being set, but don't generate an appropriate ICMP message), > we shouldn't be limiting the design of a protocol based on bad > implementations, the bad implementations should be fixed. > > > >>From brian@hursley.ibm.com Fri Aug 6 12:28:08 1999 > > >>... > > >>Can you come up with a case where setting DF would be a good > > >>thing to do? > > If you have two IPv6 hosts, each connected to an fddi ring, using > 6over4 between them other over a path that has ethernet in the middle, > it would be good to know that so that they don't keep sending fddi > size packets that have to be fragmented/reassembled. If you can't > set the DF bit, you can't do Path MTU discovery and hence you can't > find that out. > > Sure, it takes some thinking and extra code to do it right, but > if the implementor is willing to do the work, why should the > protocol prohibit it? > > -David Borman, dab@bsdi.com > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 20:03:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA27146 for ipng-dist; Fri, 6 Aug 1999 20:00:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27139 for ; Fri, 6 Aug 1999 20:00:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA00894 for ; Fri, 6 Aug 1999 20:00:48 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA04966 for ; Fri, 6 Aug 1999 21:00:47 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id XAA28366; Fri, 6 Aug 1999 23:00:46 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000017469; Fri, 6 Aug 1999 23:00:45 -0400 (EDT) From: Jim Bound Message-Id: <199908070300.XAA0000017469@quarry.zk3.dec.com> To: Peter Tattam cc: Robert Elz , Francis Dupont , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Fri, 06 Aug 1999 19:45:10 +1000." Date: Fri, 06 Aug 1999 23:00:45 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, >I can see some considerable problems if the client initiates contact with the >DNS servers since typically ND & stateless config would probably be done at >kernel level. Usually DNS related stuff happens at user level in my >experience. Mixing the two might be a bit of a headache, but not impossible. ND and Addrconf it is true are processed as ICMP msgs at the network layer (by design in IPv6) which is often referenced as the kernel. But the "daemons" for managing and processing ND and Addrconf are done in user space. This is one of the reasons why we defined the Adv API rfc2292, and is being reviewed for updates to fix things we found from implementing it now by Erik Nordmark. Basically ICMP filters are processed via raw sockets and those parts in ND which identify Stateless Addrconf are processed by a daemon. Similar to the fact that most routing is done by daemons too not in kernel space but in user space. So the update to DNS is from user space in this case. But the addresses are maintained in the kernel on the normal BSD like ifnet structure. Also DHCPv6 will be forked, threaded, whatever because of what is told to the Addrconf modules within the ND daemon to start a DHCPv6 client or not and what it can and cannot do (see Addrconf spec). /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 6 22:44:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA27208 for ipng-dist; Fri, 6 Aug 1999 22:41:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27201 for ; Fri, 6 Aug 1999 22:41:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA18468 for ; Fri, 6 Aug 1999 22:41:40 -0700 (PDT) Received: from frantic.bsdi.com ([209.173.194.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA23753 for ; Fri, 6 Aug 1999 23:41:40 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id AAA01914; Sat, 7 Aug 1999 00:39:49 -0500 (CDT) Date: Sat, 7 Aug 1999 00:39:49 -0500 (CDT) From: David Borman Message-Id: <199908070539.AAA01914@frantic.bsdi.com> To: brian@hursley.ibm.com Subject: Re: RFC 2529 (6over4) Cc: cmj@3com.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Fri, 06 Aug 1999 17:43:28 -0500 > From: Brian E Carpenter > Subject: Re: RFC 2529 (6over4) > > Dave, I think the point is that IPv6 will do MTU discovery anyway; > so there is no need to do it at the IPv4 level too. Not true. The IPv6 MTU discovery will not learn anything about the section of the path that is traversed as 6over4 packets. Once the packet is encapsulated, if the DF bit is not set, it will just go on its way, getting fragmented as needed, and reassembled at the other IPv4 side. To the IPv6 code, it looks like the packet took 1 hop, and did it successfully in one piece. So, IPv6 can't discover the smaller MTU along the 6over4 path, unless the DF bit is set in the outer IPv4 packet. 6over4 is really no different than ESP/AH tunnels with respect to Path MTU discovery, the same basic issues are involved in both cases. See Section 6.1 of RFC 2401. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 7 03:47:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA27319 for ipng-dist; Sat, 7 Aug 1999 03:44:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27312 for ; Sat, 7 Aug 1999 03:44:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA29576 for ; Sat, 7 Aug 1999 03:44:31 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA19006 for ; Sat, 7 Aug 1999 04:44:24 -0600 (MDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA26774; Sat, 7 Aug 1999 20:41:13 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Jim Bound Cc: Francis Dupont , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-Reply-To: Your message of "Fri, 06 Aug 1999 15:53:53 -0400." <199908061953.PAA0000011286@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Aug 1999 20:41:12 +1000 Message-Id: <13821.934022472@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 06 Aug 1999 15:53:53 -0400 From: Jim Bound Message-ID: <199908061953.PAA0000011286@quarry.zk3.dec.com> | Hmmm. already wrote the code to do this and it work and I said so in | my first response to your mail ???? Maybe I misread Francis' message, but I thought he was saying something different than your message suggested. You said ... || The node can do the update or the DHCPv6 || server for the node. While I have no doubt that's true, it isn't the case that is of interest, and it isn't what I thought that Francis was proposing. That is, right now, I'm only interested in the case where there is no DHCPv6 server (stateless autoconf) and the node has no authority to do anything to the appropriate DNS server. Hence, something else would have to do the update, some other way. Of course, I may have totally misunderstood Francis' idea, which is why I asked for more details. It's also possible that your code already does something which you didn't explicitly say, or which I just missed (then, and again now). | This runs now on Compaq Tru64 UNIX. If you have an Alpha you can pull | our v6 kit and test it at munnrai. I do (munnari is an alpha, though it isn't going to start running any experimental code). I have run an earlier version of your code, it worked fine, then the alphastation I was running it on got an updated version of Dunix (this was before the Tru64 name appeared) and the IPv6 stuff vanished... I did look at getting an updated version, but it seemed to want more red tape than I felt like indulging in, so I didn't bother (for the earlier version it was just there, and I ftp'd and installed it). I haven't looked to see what the current procedure is for a while though, so I guess I should go back to your web site and have another look. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 7 23:58:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA27913 for ipng-dist; Sat, 7 Aug 1999 23:55:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27906 for ; Sat, 7 Aug 1999 23:55:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA00108 for ; Sat, 7 Aug 1999 23:55:34 -0700 (PDT) Received: from docws002.shl.com (docws002.shl.com [159.249.56.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08704 for ; Sun, 8 Aug 1999 00:55:34 -0600 (MDT) Received: from ottmsooc01.ott.shl.com (ottmsooc01.ooc.shl.com [159.249.112.24]) by docws002.shl.com (8.9.1/8.9.1) with ESMTP id CAA23750; Sun, 8 Aug 1999 02:16:10 -0600 (MDT) Received: by ottmsooc01.ooc.shl.com with Internet Mail Service (5.5.2448.0) id ; Sun, 8 Aug 1999 02:56:09 -0400 Message-ID: <61DFFB631AA0D1118CC900805F6FAE730359474F@OTTFW02> From: "ELAYOUBI, Issam" To: "'ipng@sunroof.eng.sun.com'" Cc: "'Sowmini Varadhan'" Subject: RE: RFC 2529 (6over4) Date: Sun, 8 Aug 1999 02:55:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk G'day all, I'm not sure if you're referring to a routing protocol update, such as RIP, OSPF, etc. or the Cisco Discovery Protocol (CDP) which operates at the Data Link between Cisco equipment whether they are switches or routers. The routing protocol don't advertise Link-Layer addresses, however, the CDP does. Cisco provides mechanisms to turn-off that feature. Its usefulness is to allow Cisco equipment to establish communication between each other for management purposes and provides a mean of troubleshooting communication links in the absence of a routing (Layer 3) protocol. Little overhead, yet a powerful tool with controlled advertisement. Cheers, Issam. -----Original Message----- From: Sowmini Varadhan [mailto:varadhan@zk3.dec.com] Sent: Friday, August 06, 1999 3:32 PM To: brian@hursley.ibm.com; cmj@luxor.ewd.3com.com; ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) >From owner-ipng@sunroof.eng.sun.com Fri Aug 6 15:21:43 1999 > >I really can't understand why anyone would use ND or Redirects >over a configured tunnel. The Link-Layer address option is for ND >and Redirects, isn't it? Is there another use? > >Cyndi > At one point (about the same time last year), Cisco routers were sending us link-layer address options with their router advertisements. I'm not sure if they still do this. I'm also not sure how useful it was intended to be, but we had to parse it all the same. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 8 15:13:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA28469 for ipng-dist; Sun, 8 Aug 1999 15:10:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28462 for ; Sun, 8 Aug 1999 15:10:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA24771 for ; Sun, 8 Aug 1999 15:10:45 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18106 for ; Sun, 8 Aug 1999 16:10:44 -0600 (MDT) Received: from whistle.com (tlambert.whistle.com [207.76.205.208]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id PAA96556; Sun, 8 Aug 1999 15:04:59 -0700 (PDT) Message-ID: <37ADFDF2.FD31F226@whistle.com> Date: Sun, 08 Aug 1999 15:00:18 -0700 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Robert Elz CC: Jim Bound , Francis Dupont , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS References: <13821.934022472@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Jim Bound wrote: > || The node can do the update or the DHCPv6 > || server for the node. > > While I have no doubt that's true, it isn't the case that > is of interest, and it isn't what I thought that Francis > was proposing. > > That is, right now, I'm only interested in the case where > there is no DHCPv6 server (stateless autoconf) and the node > has no authority to do anything to the appropriate DNS > server. Hence, something else would have to do the update, > some other way. I totally agree. The interesting case is stateless autoconf; perhaps I'm not asking the question correctly, since it seems to me that I should probably no more trust the host name in the DHCP request than I would trust a reverse update not made by proxy through the DHCP server. Assumption: The visiting machine will get a forward record pointing to its configured address put into its _home_ DNS, somehow. That is, the machine keeps its identity, regardless of where it obtains its network connectivity. Question: How does the visiting machine get a reverse record _without human intervention_? > Of course, I may have totally misunderstood Francis' idea, > which is why I asked for more details. > > It's also possible that your code already does something > which you didn't explicitly say, or which I just missed > (then, and again now). If so, I missed it too. From what I gather, if it did the job, it could only be applied to close neighbors, which shoots down discovering the intended name of a visiting machine, since it's in a foreign DNS. This is really, really painful for things like dial-on-demand mail servers that need to send an ETRN. I have a design that works now without resorting to SMTP AUTH (or my own, CALLID) extension for IPv4, but it relies on RADIUS accounting records, which give poor disconnection notification. I was hoping that there would be something more elegant on the horizon. 8-(. -- Terry Lambert -- Whistle Communications, Inc. -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 06:20:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA28800 for ipng-dist; Mon, 9 Aug 1999 06:17:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28793 for ; Mon, 9 Aug 1999 06:17:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA28224 for ; Mon, 9 Aug 1999 06:17:36 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11517 for ; Mon, 9 Aug 1999 06:17:36 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id JAA16402; Mon, 9 Aug 1999 09:17:31 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000012675; Mon, 9 Aug 1999 09:17:30 -0400 (EDT) From: Jim Bound Message-Id: <199908091317.JAA0000012675@quarry.zk3.dec.com> To: Robert Elz cc: Jim Bound , Francis Dupont , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Sat, 07 Aug 1999 20:41:12 +1000." <13821.934022472@munnari.OZ.AU> Date: Mon, 09 Aug 1999 09:17:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, | Hmmm. already wrote the code to do this and it work and I said so in | my first response to your mail ???? >Maybe I misread Francis' message, but I thought he was saying something >different than your message suggested. You said ... || The node can do the update or the DHCPv6 || server for the node. >While I have no doubt that's true, it isn't the case that is of interest, >and it isn't what I thought that Francis was proposing. In my sentence above "node can do the update" I was implying you would know I would do it based on an ND+addrconf msg giving me the address. Anyway I have already implemented what Francis is speaking of and my first sentence the referenced mail above was asking for us to test this at UNH this Novemeber. Sorry for my assumptions in my mail maybe I could have saved a lot of mail had I been more verbose. Anyway what Francis stated we will all do as IPv6 implementors one way or the other. The reason is that unlike IPv4 a customer can deploy IPv6 without DHCPv6 (its a choice). When the node gets addresses in that case from Stateless addrconf DNS will have to be updated by the node itself without a server. >That is, right now, I'm only interested in the case where there is no >DHCPv6 server (stateless autoconf) and the node has no authority to do >anything to the appropriate DNS server. Hence, something else would >have to do the update, some other way. I would suggest if there is no DHCPv6 server and the node does not have the authority to do anything to the DNS server then nothing is done as there are only two ways this can happen: 1. the node itself has authority to update the DNS. 2. the node uses DHCPv6 to update the DNS and the DHCPv6 server has that authority. >Of course, I may have totally misunderstood Francis' idea, which is why I >asked for more details. I am not sure now??? >It's also possible that your code already does something which you didn't >explicitly say, or which I just missed (then, and again now). No I did not say explicitly; ND sends Rtr Adv and sets the A bit for stateless. ND also sends Prefixes that can be used for addrconf by nodes on the link. The ND daemon sees this set and will now take prefixes and form addresses (DAD and all req processing assumed for the EUI link-local part). The ND dameon takes the preifx and EUI per IPv6 over foo spec and forms an IPv6 address. Puts that into the NUD processing and puts that address on the set of IPv6 Interface structures for the node in the kernel. Starts the necessary timers for the address to reach deprecation state, and the next state etc.. So all the IPv6 processing is now done for the address to be usable. Now the ND daemon takes that address and updates the AAAA and PTR records per RFC 2136 dynamic updates to DNS using BIND as our implementation. Right now we do that without security. Working now with BIND 8.2 to use TSIG to verify that the node is infact able to update the DNS. So TSIG would be used to verify the node can do updates to AAAA and PTR records (this is all transparent to the A6 record issues as that change will be in libraries behind the ND app daemon in our resolver when it happens). > | This runs now on Compaq Tru64 UNIX. If you have an Alpha you can pull > | our v6 kit and test it at munnrai. >I do (munnari is an alpha, though it isn't going to start running any >experimental code). I have run an earlier version of your code, it >worked fine, then the alphastation I was running it on got an updated >version of Dunix (this was before the Tru64 name appeared) and the >IPv6 stuff vanished... I did look at getting an updated version, but >it seemed to want more red tape than I felt like indulging in, so I >didn't bother (for the earlier version it was just there, and I ftp'd >and installed it). I haven't looked to see what the current procedure is >for a while though, so I guess I should go back to your web site and >have another look. Red tape sucks I agree. We try to avoid it when possible. We have a mail address you can send to get help and support on the web page if it gets bogus doing anything with our kit. We usually respond in less than 24 hours (one of us on the eng team will respond to). Now once DHCPv6 exists (hopefully real soon too) we will have to have a config switch to ask the user do you want DHCPv6 server to do your DNS updates. In IPv6 unlike IPv4 stateless and stateful can coexist and be running simultaneously. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 07:44:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA28861 for ipng-dist; Mon, 9 Aug 1999 07:41:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28854 for ; Mon, 9 Aug 1999 07:41:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA03988 for ; Mon, 9 Aug 1999 07:41:09 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20673 for ; Mon, 9 Aug 1999 08:40:57 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA02348; Mon, 9 Aug 1999 09:40:39 -0500 (CDT) Message-Id: <199908091440.JAA02348@gungnir.fnal.gov> To: Terry Lambert Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of Sun, 08 Aug 1999 15:00:18 PDT. <37ADFDF2.FD31F226@whistle.com> Date: Mon, 09 Aug 1999 09:40:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Assumption: > > The visiting machine will get a forward record > pointing to its configured address put into its > _home_ DNS, somehow. That is, the machine keeps > its identity, regardless of where it obtains its > network connectivity. > > Question: > > How does the visiting machine get a reverse record > _without human intervention_? I think we all agree that there's no Truly Secure way to do it. So we're trying to agree on a Pretty Good algorithm. I suggest that the update to the reverse zone involve a check that the subject address isn't already allocated, a cross-check of the forward zone and a challenge-reponse interaction with the subject address. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 08:54:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA28977 for ipng-dist; Mon, 9 Aug 1999 08:51:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28970 for ; Mon, 9 Aug 1999 08:51:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA28933 for ; Mon, 9 Aug 1999 08:51:08 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16398 for ; Mon, 9 Aug 1999 09:51:04 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA258022; Mon, 9 Aug 1999 16:50:43 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA26524; Mon, 9 Aug 1999 16:50:40 +0100 (BST) Message-ID: <37AEF856.F2BDB10C@hursley.ibm.com> Date: Mon, 09 Aug 1999 10:48:38 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: David Borman CC: cmj@3com.com, ipng@sunroof.eng.sun.com, Richard Draves Subject: Re: RFC 2529 (6over4) References: <199908070539.AAA01914@frantic.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David, You're causing me second thoughts about this. Rich Draves, as an implementor, do you have a comment? Brian David Borman wrote: > > > Date: Fri, 06 Aug 1999 17:43:28 -0500 > > From: Brian E Carpenter > > Subject: Re: RFC 2529 (6over4) > > > > Dave, I think the point is that IPv6 will do MTU discovery anyway; > > so there is no need to do it at the IPv4 level too. > > Not true. The IPv6 MTU discovery will not learn anything about > the section of the path that is traversed as 6over4 packets. Once > the packet is encapsulated, if the DF bit is not set, it will just > go on its way, getting fragmented as needed, and reassembled at > the other IPv4 side. To the IPv6 code, it looks like the packet > took 1 hop, and did it successfully in one piece. So, IPv6 can't > discover the smaller MTU along the 6over4 path, unless the DF bit > is set in the outer IPv4 packet. > > 6over4 is really no different than ESP/AH tunnels with respect to > Path MTU discovery, the same basic issues are involved in both > cases. See Section 6.1 of RFC 2401. > > -David Borman, dab@bsdi.com -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div On assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 09:55:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA29093 for ipng-dist; Mon, 9 Aug 1999 09:51:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29086 for ; Mon, 9 Aug 1999 09:51:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA06908 for ; Mon, 9 Aug 1999 09:51:26 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24540 for ; Mon, 9 Aug 1999 09:51:23 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA89296; Mon, 9 Aug 1999 17:51:21 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA26434; Mon, 9 Aug 1999 17:51:16 +0100 (BST) Message-ID: <37AF0684.5355455F@hursley.ibm.com> Date: Mon, 09 Aug 1999 11:49:08 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Jim Bound CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing References: <199908062104.RAA0000026286@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > >The reason I'm pushing this is that I see it as a serious > >operational issue once we start having multiple prefixes, which > >IMHO we certainly will get sooner or later. If we don't do it > >right we will end up with very non-optimal routing. This matters > >just as much as host (in)efficiency so we have to find the right > >tradeoff > > I simply don't any issues at all that cannot be resolved without what > your asking. > > Maybe if you could articulate exactly the problems you see we can have > that discussion, as of right now I don't see why your concerned and it > could be I assume a different fix. An IPv6 network is supposed to have aggregator-based addressing, which means that we should be *much* closer than today to a simple mapping of addresses to topology, as long as we stay "below" the default-free part of the address hierarchy. In other words, if you take any two IPv6 addresses and look for their longest common prefix, the longer that common prefix is, the closer the two hosts are in the topology. For better performance we should (in general, not always) use topologically shorter paths. That means, I believe, that given a choice of destination addresses from a given source, we can & should optimise paths (assuming rational routing tables) by choosing the destination address with the longest match prefix. Given a choice of both source and destination addresses the same is basically true. [I'm ignoring the scope issues but they don't change the argument much. It's also a fact that 6to4 has a basic problem if we don't address this.] This can't be free and given TLA addressing I don't see it can be done anywhere but in the host, so as noted below there is a tradeoff here. > > >> So this means a client would take 1 to N DST addresses given to them > >> from the DNS while the client is awaiting a response from > >> getipnodebyname or getaddrinfo, and do this processing while the client > >> waits. > > >Exactly, i.e. this process is added to the generic DNS overhead > >befor you get to call open(). Can you quantify this? Given that DNS > >lookups take up to seconds, how much extra overhead time are we > >talking here? > > What do you mean call "open". This will happen when you call > getipnodebyname or getaddrinfo? Sorry, using personal shorthand. In plain English I mean when you send the first packet, i.e. you've also done a socket call and then either a connect or a write. What I'm interested to understand is the overhead both in processor time and in real time of running this extra algorithm as part of the total time to send the first packet. > > >> Here is what the ramifications are to implementations: > >> > >> 1. The client takes 1 to N addresses off the DNS set returned and > >> performs an I/O access to the place in the IPv6 implementation > >> to access all potential src addresses on the platform. This is > >> most likely multiple reads and causes a context switch on > >> the platform. > > >I/O access? Why on earth? I'd expect the stack simply to know its > >current interface/address pairings in a (small) table. > > Brian bare with me here. That stack is in the kernel. Any OS I have > ever worked with as an engineer divides the OS into > > User Space (DNS, APIs, Telnet) > > ------------------------------- > > > Kernel Space (IP RFCs, IF-Datastructures etc) > > What I mean't here was an "ioctl" to access the interface structures in > the kernel. They are not sitting in user space today like many other > config parameters on a platform. The stack also lives in kernel space > not user space, for future discussion. Understood, ioctl makes sense. > > >>... Unless one keeps an updated file to be read > > > >You don't mean a disk file do you? Why not a simple data structure > >in the stack? > > One option would be to keep a file or datastructure in user space to > read within the DNS application the address pairs. As opposed to > accessing the kernel each time for each API setting this mechanism off. Yes but I agree that's pretty messy. > >> on the client of src addresses available. If such a file is > >> kept then it will add new code to every utility that adds or > >> alters or deletes addresses on the platform and in many places > >> for many implementations > > > >Yes, for sure > > That will takes years to get fixed as note is my guess. Just like the > way everyone ignored the IETF on storing static stuff in their > implementations for renumbering. Which I agree is a bad thing but > engineering managers are not going to fix it unless customers ask for it > not because we ask for it in the IETF. Likewise for src/dst addr compares. > > >> ...and I do not believe that to be > >> optimal. > > >Is this an overhead that matters? Is it on any critical paths? > > Its the overhead mostly. Not sure what you mean by critical path in > this context? See above, is it on the path to sending the first packet on a socket? > > >> ...I suppose an implementation could map the interface > >> structures to a file via a memory mapping but it is not > >> 100% full proof to be guranteed. > > > >I assumed that the stack would simply have this available > >anyway for other reasons. > > It does but see my comments about stack above. Yep > > >> 2. Once the client now has those src addresses start the compare > >> using longest match or some other algorithm to find the > >> best src address to match a dst address. Then store that > >> result with some kind of weight in some datastructure. Then > >> proceed to compare the next dst address in a loop (might > >> be able to be done recursively). > > >Correct. This is also where you would insert heuristics and maybe > >refer to some current "network weather" info to choose a path. > >But it is on the path to open() not per-packet. > > I am not following your "open" word here? I mean it's once per socket not once per packet. > >> 3. During step 2 above also do the src address selection criteria > >> specified in the std src address selections being proposed (e.g. > >> scoping, deprecated, interface index). > > >>Yes, a few more instructions per loop. > > >> 4. Now pass back the pair to the client application? But there > >> is no API to do this today but could be done in getaddrinfo > >> possibly. > > >The idea was to pass back an ordered list of addresses from > >getipnodebyname() and suggest that the upper layer uses the > >first one unless it wants to override. That way the API > >doesn't change one bit. > > Sure it does. Right now hostent only contains a singluar ordered list > of addresses it does not denote the concept of any tuple. > This is definitely a change to the API. > There is a workaround though. I think I meant the workaround:-) 1. During getipnodebyname, the API runs the full heuristic and chooses a src/dest pair. 2. But getipnodebyname returns exactly what it does today, a list of dest addresses - the only difference is that it is sorted. 3. When the first packet comes down through the socket, the src address is selected as per Rich's draft. If the app has used the *first* dest address from the list, it will get the same src address as in step 1. > > >>> ...But if the client does not want to send the src > >>> address when sending the packet then after step 3 that software > >>> would have to update the implementation kernel stack to know > >>> to use this src address with this particular client send > >>> operation. > > > >Exactly, that would be another problem if changing the API. > > But the API does change Brian. > Also most apps let the kernel pick the src address and do not send it to > the kernel where the stack lives. See previous comment, the idea would be to preserve exactly that. > > >> I will note doing steps 1-3 inside the kernel of implementations where > >> the stack resides is not an option as DNS libs are not available they > >> would have to be pushed into the stack (the 1 to N) DST addresses > >> returned from DNS. Then do steps 1-3 in the kernel. But then the > >> client may not know what DST address was used. > > >It chooses, see above. > > That won't work. Indeed not, I was wrong. The socket client can't know. > > >> Doing this is a very very bad idea because the engineering and > >> performance costs are to high for the benefit. > > >I'd like numbers: what's the % overhead on a complete DNS lookup > >followed by an open? > > Please define what you mean by open. > > I will think about a % for you. As noted, the correct question is what's the overhead on the complete path from calling getipnodebyname to sending the first packet. And what's the overhead in real time, given a typical DNS wait. > I will also add that this is a lot of software logic to put into a > critical path application set on our platforms when you have not stated > in detail the reason this is even required. I will analyze the cost of > code per CPU cycles you go tell us why you want this in detail OK. See the explanation at the top. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 14:53:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA29987 for ipng-dist; Mon, 9 Aug 1999 14:49:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29980 for ; Mon, 9 Aug 1999 14:48:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA08788 for ; Mon, 9 Aug 1999 14:48:56 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16613 for ; Mon, 9 Aug 1999 15:48:55 -0600 (MDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id VAA25956; Mon, 9 Aug 1999 21:48:33 GMT Message-Id: <199908092148.VAA25956@orchard.arlington.ma.us> To: "Matt Crawford" cc: Terry Lambert , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-Reply-To: Message from "Matt Crawford" of "Mon, 09 Aug 1999 09:40:38 CDT." <199908091440.JAA02348@gungnir.fnal.gov> Date: Mon, 09 Aug 1999 17:48:33 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think we all agree that there's no Truly Secure way to do it. So > we're trying to agree on a Pretty Good algorithm. I suggest that the > update to the reverse zone involve a check that the subject address > isn't already allocated, a cross-check of the forward zone and a > challenge-reponse interaction with the subject address. How about taking advantage of the TTL=255 hack? (i.e., any packet recieved with a TTL=255 hasn't gone through a router, and thus, must have originated from a directly-connected system? this is already used by the v6 neighbor discovery protocol). You then put a proxy connected to each wire which is set up to use stateless autoconfig which is trusted to update the inverse-zone for that wire... - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 16:51:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA00193 for ipng-dist; Mon, 9 Aug 1999 16:48:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00186 for ; Mon, 9 Aug 1999 16:48:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA06068 for ; Mon, 9 Aug 1999 16:48:06 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA00525 for ; Mon, 9 Aug 1999 17:48:05 -0600 (MDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id QAA22830; Mon, 9 Aug 1999 16:40:56 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id QAA12578; Mon, 9 Aug 1999 16:40:55 -0700 (PDT) Received: from tellurium (usr-modem25.nsd.3com.com [129.213.205.145]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id QAA03530; Mon, 9 Aug 1999 16:40:53 -0700 (PDT) Message-Id: <3.0.2.32.19990809163804.0091fabc@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Mon, 09 Aug 1999 16:38:04 -0700 To: Jim Bound From: Cyndi Jung Subject: Re: RFC 2529 (6over4) Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: <199908062023.QAA0000017876@quarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, 2365 is not a protocol - it is a "best common practise", an agreement on the division of the class-D address space into scopes. The part that does work already is organization-local, because IP multicast works already within an organization - it is the global scope, the inter-domain part, that is still a mess. Fortunately, organization-local scope multicast addresses do not require global coordination like the global scope addresses do - they are sort of a "net10" of the class-D address space. Cyndi At 04:23 PM 8/6/99 -0400, Jim Bound wrote: >Cyndi, > >Here is the bottom line. If 2365 is not on the street now after some >time. We have to make choices as vendors which transition mechanisms we >deploy first, next, and next++++. If we can use 6over4 with the >multicast that is out there today then I think it has a good chance to >hit deployment for "first" or "next" if it requires 2365 as the spec >says now with no statements other than that then its "next++++" we are >better off letting customers use configured tunnels and using natpt, >siit and other mecahanisms intially. > >I will not support using 6over4 to get 2365 deployed either. > >/jim > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 17:59:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA00246 for ipng-dist; Mon, 9 Aug 1999 17:56:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00239 for ; Mon, 9 Aug 1999 17:56:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA18552 for ; Mon, 9 Aug 1999 17:56:09 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA23275 for ; Mon, 9 Aug 1999 18:56:08 -0600 (MDT) From: Masataka Ohta Message-Id: <199908100032.JAA06671@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA06671; Tue, 10 Aug 1999 09:32:11 +0900 Subject: Re: IPv6 and Dynamic DNS To: crawdad@fnal.gov (Matt Crawford) Date: Tue, 10 Aug 99 9:32:11 JST Cc: terry@whistle.com, ipng@sunroof.eng.sun.com, namedroppers@internic.net In-Reply-To: <199908091440.JAA02348@gungnir.fnal.gov>; from "Matt Crawford" at Aug 9, 99 9:40 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt; > I think we all agree that there's no Truly Secure way to do it. So > we're trying to agree on a Pretty Good algorithm. Silly agreement. Stateless autoconfiguration has absolutely no security. The only reasonable way to go is to abandon stateless autoconfiguration except for an isolated small LAN. Note that even dentists' offices need global connectivity with reasonable security. That something has interoperable implementations does not mean it useful in the real world. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 20:39:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA00373 for ipng-dist; Mon, 9 Aug 1999 20:36:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00366 for ; Mon, 9 Aug 1999 20:36:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA03392 for ; Mon, 9 Aug 1999 20:36:10 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA29869 for ; Mon, 9 Aug 1999 21:36:10 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Aug 1999 20:29:25 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2448.0) id ; Mon, 9 Aug 1999 20:29:24 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145156FD@RED-MSG-50> From: Richard Draves To: "'Brian E Carpenter'" , David Borman Cc: cmj@3com.com, ipng@sunroof.eng.sun.com Subject: RE: RFC 2529 (6over4) Date: Mon, 9 Aug 1999 20:29:17 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (As an aside, I would really rather not change the source/target link-layer address option format for 6over4. We have deployed the existing format. And the current format aligns the IPv4 address, if you care about that.) About the DF bit and PMTU discovery... I'm having trouble understanding how PMTU discovery at the IPv4 layer would usefully interact with 6over4. At least the way our implementation works (and this is universal I would guess - RFC 2461 specifies a LinkMTU conceptual variable this way), a node maintains a link MTU that applies to all neighbors on the link. Suppose IPv4 PMTU discovery gave you different v4 PMTUs for different 6over4 neighbors. Since there's only one link MTU, we would need to use the minimum of the different PMTUs I suppose. With implementations like ours, the only way in which the link MTU can be large is if all 6over4 neighbors are reachable with the large MTU, in which case the large 6over4 MTU should be configurable with a Router Advertisement. You don't need v4 PMTU. Note - it would be useful if section 2 of RFC 2529 specified that the default MTU of 1480 can be raised to a specified upper-bound as well as lowered via Router Advertisements. Although there's a little conflict with RFC 2461 (Neighbor Discovery) section 6.3.4: If the MTU option is present, hosts SHOULD copy the option's value into LinkMTU so long as the value is greater than or equal to the minimum link MTU [IPv6] and does not exceed the default LinkMTU value specified in the link type specific document (e.g., [IPv6-ETHER]). Whereas for 6over4 you want to have a default LinkMTU of 1480, but allow RAs to specify a larger LinkMTU up to ~64K. It's a little tricky to have an implementation that would allow a different link MTU for different neighbors on the link. For example, what MTU would the sender use for a multicast destination? Just allow fragmentation for multicast destinations? So I guess I can imagine a 6over4 implementation that would use v4 PMTU discovery, but it's a stretch. Rich > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, August 09, 1999 8:49 AM > To: David Borman > Cc: cmj@3com.com; ipng@sunroof.eng.sun.com; Richard Draves > Subject: Re: RFC 2529 (6over4) > > > David, > > You're causing me second thoughts about this. Rich Draves, as > an implementor, do you have a comment? > > Brian > > David Borman wrote: > > > > > Date: Fri, 06 Aug 1999 17:43:28 -0500 > > > From: Brian E Carpenter > > > Subject: Re: RFC 2529 (6over4) > > > > > > Dave, I think the point is that IPv6 will do MTU discovery anyway; > > > so there is no need to do it at the IPv4 level too. > > > > Not true. The IPv6 MTU discovery will not learn anything about > > the section of the path that is traversed as 6over4 packets. Once > > the packet is encapsulated, if the DF bit is not set, it will just > > go on its way, getting fragmented as needed, and reassembled at > > the other IPv4 side. To the IPv6 code, it looks like the packet > > took 1 hop, and did it successfully in one piece. So, IPv6 can't > > discover the smaller MTU along the 6over4 path, unless the DF bit > > is set in the outer IPv4 packet. > > > > 6over4 is really no different than ESP/AH tunnels with respect to > > Path MTU discovery, the same basic issues are involved in both > > cases. See Section 6.1 of RFC 2401. > > > > -David Borman, dab@bsdi.com > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter (IAB Chair) > Program Director, Internet Standards & Technology, IBM Internet Div > On assignment for IBM at http://www.iCAIR.org > Non-IBM email: brian@icair.org > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 20:51:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA00412 for ipng-dist; Mon, 9 Aug 1999 20:48:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00405 for ; Mon, 9 Aug 1999 20:48:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA04191 for ; Mon, 9 Aug 1999 20:48:46 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA02019 for ; Mon, 9 Aug 1999 21:48:46 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Aug 1999 20:43:18 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Mon, 9 Aug 1999 20:43:17 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145156FF@RED-MSG-50> From: Richard Draves To: "'Brian E Carpenter'" , Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Src/Dst Address Pairing Date: Mon, 9 Aug 1999 20:43:13 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, have you had a chance to review source address selection: http://www.ietf.org/internet-drafts/draft-draves-ipngwg-simple-srcaddr-01.tx t About destination address ordering, to reiterate a point - we are talking about just changing the order in which getipnodebyname returns addresses. So this is just an implementation change, it involves no changes to the API or to applications. I think the implementation change can be quite simple and low-overhead. The getipnodebyname() user-space library implementation can make system calls (ioctls or whatever) to retrieve information about source addresses. To reduce the overhead of the extra system calls, it can cache the information. For example cache it for one second. (Getting a sufficiently precise time in user space does not require a system call in most implementations - it's often done by reading from memory that is mapped read-only from the kernel.) This should reduce the added system call burden sufficiently. A few extra system calls a second will not be measurable. Thanks, Rich > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, August 09, 1999 9:49 AM > To: Jim Bound > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 Src/Dst Address Pairing > > > Jim, > > > >The reason I'm pushing this is that I see it as a serious > > >operational issue once we start having multiple prefixes, which > > >IMHO we certainly will get sooner or later. If we don't do it > > >right we will end up with very non-optimal routing. This matters > > >just as much as host (in)efficiency so we have to find the right > > >tradeoff > > > > I simply don't any issues at all that cannot be resolved > without what > > your asking. > > > > Maybe if you could articulate exactly the problems you see > we can have > > that discussion, as of right now I don't see why your > concerned and it > > could be I assume a different fix. > > An IPv6 network is supposed to have aggregator-based addressing, > which means that we should be *much* closer than today to a simple > mapping of addresses to topology, as long as we stay "below" > the default-free part of the address hierarchy. In other words, > if you take any two IPv6 addresses and look for their longest > common prefix, the longer that common prefix is, the closer > the two hosts are in the topology. For better performance > we should (in general, not always) use topologically shorter > paths. > > That means, I believe, that given a choice of destination addresses > from a given source, we can & should optimise paths (assuming rational > routing tables) by choosing the destination address with the > longest match prefix. Given a choice of both source and destination > addresses the same is basically true. [I'm ignoring the scope issues > but they don't change the argument much. It's also a fact that > 6to4 has a basic problem if we don't address this.] > > This can't be free and given TLA addressing I don't see it can be done > anywhere but in the host, so as noted below there is a tradeoff here. > > > > > >> So this means a client would take 1 to N DST addresses > given to them > > >> from the DNS while the client is awaiting a response from > > >> getipnodebyname or getaddrinfo, and do this processing > while the client > > >> waits. > > > > >Exactly, i.e. this process is added to the generic DNS overhead > > >befor you get to call open(). Can you quantify this? Given that DNS > > >lookups take up to seconds, how much extra overhead time are we > > >talking here? > > > > What do you mean call "open". This will happen when you call > > getipnodebyname or getaddrinfo? > > Sorry, using personal shorthand. In plain English I mean when you > send the first packet, i.e. you've also done a socket call and > then either a connect or a write. What I'm interested to > understand is the overhead both in processor time and in real time > of running this extra algorithm as part of the total time > to send the first packet. > > > > >> Here is what the ramifications are to implementations: > > >> > > >> 1. The client takes 1 to N addresses off the DNS set > returned and > > >> performs an I/O access to the place in the IPv6 > implementation > > >> to access all potential src addresses on the > platform. This is > > >> most likely multiple reads and causes a context switch on > > >> the platform. > > > > >I/O access? Why on earth? I'd expect the stack simply to know its > > >current interface/address pairings in a (small) table. > > > > Brian bare with me here. That stack is in the kernel. Any > OS I have > > ever worked with as an engineer divides the OS into > > > > User Space (DNS, APIs, Telnet) > > > > ------------------------------- > > > > > > Kernel Space (IP RFCs, IF-Datastructures etc) > > > > What I mean't here was an "ioctl" to access the interface > structures in > > the kernel. They are not sitting in user space today like > many other > > config parameters on a platform. The stack also lives in > kernel space > > not user space, for future discussion. > > Understood, ioctl makes sense. > > > > >>... Unless one keeps an updated file to be read > > > > > >You don't mean a disk file do you? Why not a simple data structure > > >in the stack? > > > > One option would be to keep a file or datastructure in user space to > > read within the DNS application the address pairs. As opposed to > > accessing the kernel each time for each API setting this > mechanism off. > > Yes but I agree that's pretty messy. > > > >> on the client of src addresses available. If such a file is > > >> kept then it will add new code to every utility that adds or > > >> alters or deletes addresses on the platform and in > many places > > >> for many implementations > > > > > >Yes, for sure > > > > That will takes years to get fixed as note is my guess. > Just like the > > way everyone ignored the IETF on storing static stuff in their > > implementations for renumbering. Which I agree is a bad thing but > > engineering managers are not going to fix it unless > customers ask for it > > not because we ask for it in the IETF. Likewise for > src/dst addr compares. > > > > >> ...and I do not believe that to be > > >> optimal. > > > > >Is this an overhead that matters? Is it on any critical paths? > > > > Its the overhead mostly. Not sure what you mean by critical path in > > this context? > > See above, is it on the path to sending the first packet on a socket? > > > > > >> ...I suppose an implementation could map the interface > > >> structures to a file via a memory mapping but it is not > > >> 100% full proof to be guranteed. > > > > > >I assumed that the stack would simply have this available > > >anyway for other reasons. > > > > It does but see my comments about stack above. > > Yep > > > > > >> 2. Once the client now has those src addresses start > the compare > > >> using longest match or some other algorithm to find the > > >> best src address to match a dst address. Then store that > > >> result with some kind of weight in some datastructure. Then > > >> proceed to compare the next dst address in a loop (might > > >> be able to be done recursively). > > > > >Correct. This is also where you would insert heuristics and maybe > > >refer to some current "network weather" info to choose a path. > > >But it is on the path to open() not per-packet. > > > > I am not following your "open" word here? > > I mean it's once per socket not once per packet. > > > >> 3. During step 2 above also do the src address > selection criteria > > >> specified in the std src address selections being > proposed (e.g. > > >> scoping, deprecated, interface index). > > > > >>Yes, a few more instructions per loop. > > > > >> 4. Now pass back the pair to the client application? But there > > >> is no API to do this today but could be done in getaddrinfo > > >> possibly. > > > > >The idea was to pass back an ordered list of addresses from > > >getipnodebyname() and suggest that the upper layer uses the > > >first one unless it wants to override. That way the API > > >doesn't change one bit. > > > > Sure it does. Right now hostent only contains a singluar > ordered list > > of addresses it does not denote the concept of any tuple. > > This is definitely a change to the API. > > There is a workaround though. > > I think I meant the workaround:-) > > 1. During getipnodebyname, the API runs the full heuristic and chooses > a src/dest pair. > > 2. But getipnodebyname returns exactly what it does today, a list > of dest addresses - the only difference is that it is sorted. > > 3. When the first packet comes down through the socket, the src > address is selected as per Rich's draft. If the app has used the > *first* dest address from the list, it will get the same src address > as in step 1. > > > > > >>> ...But if the client does not want to send the src > > >>> address when sending the packet then after step 3 > that software > > >>> would have to update the implementation kernel > stack to know > > >>> to use this src address with this particular client send > > >>> operation. > > > > > >Exactly, that would be another problem if changing the API. > > > > But the API does change Brian. > > Also most apps let the kernel pick the src address and do > not send it to > > the kernel where the stack lives. > > See previous comment, the idea would be to preserve exactly that. > > > > > >> I will note doing steps 1-3 inside the kernel of > implementations where > > >> the stack resides is not an option as DNS libs are not > available they > > >> would have to be pushed into the stack (the 1 to N) DST addresses > > >> returned from DNS. Then do steps 1-3 in the kernel. > But then the > > >> client may not know what DST address was used. > > > > >It chooses, see above. > > > > That won't work. > > Indeed not, I was wrong. The socket client can't know. > > > > > >> Doing this is a very very bad idea because the engineering and > > >> performance costs are to high for the benefit. > > > > >I'd like numbers: what's the % overhead on a complete DNS lookup > > >followed by an open? > > > > Please define what you mean by open. > > > > I will think about a % for you. > > As noted, the correct question is what's the overhead on the > complete path from calling getipnodebyname to sending the first > packet. And what's the overhead in real time, given a typical > DNS wait. > > > I will also add that this is a lot of software logic to put into a > > critical path application set on our platforms when you > have not stated > > in detail the reason this is even required. I will analyze > the cost of > > code per CPU cycles you go tell us why you want this in detail OK. > > See the explanation at the top. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 21:10:03 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA00443 for ipng-dist; Mon, 9 Aug 1999 21:06:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00436 for ; Mon, 9 Aug 1999 21:06:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA02921 for ; Mon, 9 Aug 1999 21:06:17 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA14047 for ; Mon, 9 Aug 1999 21:06:16 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id AAA19480; Tue, 10 Aug 1999 00:06:14 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000011717; Tue, 10 Aug 1999 00:06:07 -0400 (EDT) From: Jim Bound Message-Id: <199908100406.AAA0000011717@quarry.zk3.dec.com> To: Cyndi Jung cc: Jim Bound , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of "Mon, 09 Aug 1999 16:38:04 PDT." <3.0.2.32.19990809163804.0091fabc@mailhost.ewd.3com.com> Date: Tue, 10 Aug 1999 00:06:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi Cyndi, >2365 is not a protocol - it is a "best common practise", an agreement >on the division of the class-D address space into scopes. The part >that does work already is organization-local, because IP multicast works >already within an organization - it is the global scope, the inter-domain >part, that is still a mess. Fortunately, organization-local scope >multicast addresses do not require global coordination like the >global scope addresses do - they are sort of a "net10" of the class-D >address space. I understood that. But until folks support the inter-domain whats the default? I think its based on the TTL? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 21:48:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA00483 for ipng-dist; Mon, 9 Aug 1999 21:45:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00476 for ; Mon, 9 Aug 1999 21:45:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA14258 for ; Mon, 9 Aug 1999 21:45:31 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13105 for ; Mon, 9 Aug 1999 22:45:31 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id AAA21076; Tue, 10 Aug 1999 00:45:31 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000031986; Tue, 10 Aug 1999 00:45:30 -0400 (EDT) From: Jim Bound Message-Id: <199908100445.AAA0000031986@quarry.zk3.dec.com> To: Brian E Carpenter cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing In-reply-to: Your message of "Mon, 09 Aug 1999 11:49:08 CDT." <37AF0684.5355455F@hursley.ibm.com> Date: Tue, 10 Aug 1999 00:45:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >An IPv6 network is supposed to have aggregator-based addressing, >which means that we should be *much* closer than today to a simple >mapping of addresses to topology, as long as we stay "below" >the default-free part of the address hierarchy. In other words, >if you take any two IPv6 addresses and look for their longest >common prefix, the longer that common prefix is, the closer >the two hosts are in the topology. For better performance >we should (in general, not always) use topologically shorter >paths. > >That means, I believe, that given a choice of destination addresses >from a given source, we can & should optimise paths (assuming rational >routing tables) by choosing the destination address with the >longest match prefix. Given a choice of both source and destination >addresses the same is basically true. [I'm ignoring the scope issues >but they don't change the argument much. It's also a fact that >6to4 has a basic problem if we don't address this.] >This can't be free and given TLA addressing I don't see it can be done >anywhere but in the host, so as noted below there is a tradeoff here. 6to4 will work without this major fix to the hosts. But the issue is far beyond just 6to4. In the interim a fix is for nodes to not use multiple addresses for destinations in the DNS. Then src addr selection will work. It certainly cannot be a MUST in 6to4 IMO. >> What do you mean call "open". This will happen when you call >> getipnodebyname or getaddrinfo? >Sorry, using personal shorthand. In plain English I mean when you >send the first packet, i.e. you've also done a socket call and >then either a connect or a write. What I'm interested to >understand is the overhead both in processor time and in real time >of running this extra algorithm as part of the total time >to send the first packet. OK I now see your term. There are 3 approaches to resolve this each with different affects to the system. >> That will takes years to get fixed as note is my guess. Just like the >> way everyone ignored the IETF on storing static stuff in their >> implementations for renumbering. Which I agree is a bad thing but >> engineering managers are not going to fix it unless customers ask for it >> not because we ask for it in the IETF. Likewise for src/dst addr compares. >> >> >> ...and I do not believe that to be >> >> optimal. >> >> >Is this an overhead that matters? Is it on any critical paths? >> >> Its the overhead mostly. Not sure what you mean by critical path in >> this context? > >See above, is it on the path to sending the first packet on a socket? Yes definitely. >I mean it's once per socket not once per packet. Yes once per socket. But imagine a server that opens 2K sockets and this is small for some servers. The cost is 2K times what-we-add-to-do -this. This is something I find very frustrating trying to bring implementation performance issues to some discussions. The performance cost is exponential as that cost is activiated, until we all really figure out how to use SMP and Parallel Processing better and we have not yet in the industry though it is beginning to happen now, but not typically in the network stack arena on hosts. >1. During getipnodebyname, the API runs the full heuristic and chooses >a src/dest pair. >2. But getipnodebyname returns exactly what it does today, a list >of dest addresses - the only difference is that it is sorted. >3. When the first packet comes down through the socket, the src >address is selected as per Rich's draft. If the app has used the >*first* dest address from the list, it will get the same src address >as in step 1. Yes that is the workaround. >> >> >>> ...But if the client does not want to send the src >> >>> address when sending the packet then after step 3 that software >> >>> would have to update the implementation kernel stack to know >> >>> to use this src address with this particular client send >> >>> operation. >> > >> >Exactly, that would be another problem if changing the API. >> >> But the API does change Brian. >> Also most apps let the kernel pick the src address and do not send it to >> the kernel where the stack lives. > >See previous comment, the idea would be to preserve exactly that. As long as part of your "open" the client does not want to hard code the source address and some apps do that today. >As noted, the correct question is what's the overhead on the >complete path from calling getipnodebyname to sending the first >packet. And what's the overhead in real time, given a typical >DNS wait. Agreed. Also all apps that exist today that select a src address this will not work until they are ported to change. Note this strategy also says nodes applications cannot select a src address, and that is not going to fly IMO. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 9 22:18:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA00518 for ipng-dist; Mon, 9 Aug 1999 22:07:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00511 for ; Mon, 9 Aug 1999 22:06:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA06541 for ; Mon, 9 Aug 1999 22:06:19 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA26354 for ; Mon, 9 Aug 1999 22:06:19 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id BAA23346; Tue, 10 Aug 1999 01:06:18 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id BAA0000032720; Tue, 10 Aug 1999 01:06:18 -0400 (EDT) From: Jim Bound Message-Id: <199908100506.BAA0000032720@quarry.zk3.dec.com> To: Richard Draves cc: "'Brian E Carpenter'" , Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing In-reply-to: Your message of "Mon, 09 Aug 1999 20:43:13 PDT." <4D0A23B3F74DD111ACCD00805F31D810145156FF@RED-MSG-50> Date: Tue, 10 Aug 1999 01:06:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >Jim, have you had a chance to review source address selection: >http://www.ietf.org/internet-drafts/draft-draves-ipngwg-simple-srcaddr-01.tx >t Yes but not for this discussion per your note in the draft: This document does not address the more general problem of choosing the "best" destination address / source address pair for communication with another node, given a set of possible destination addresses and a set of possible source addresses. I reviewed it but it needs a thorough engineering review and that I have not done yet. But that will get done before the Wash D.C. meeting at my end for sure. >About destination address ordering, to reiterate a point - we are talking >about just changing the order in which getipnodebyname returns addresses. So >this is just an implementation change, it involves no changes to the API or >to applications. Yes per Brian and my discussion it does if you use the workaround discussed, but not as the API works today. >I think the implementation change can be quite simple and low-overhead. The >getipnodebyname() user-space library implementation can make system calls >(ioctls or whatever) to retrieve information about source addresses. To >reduce the overhead of the extra system calls, it can cache the information. >For example cache it for one second. (Getting a sufficiently precise time in >user space does not require a system call in most implementations - it's >often done by reading from memory that is mapped read-only from the kernel.) >This should reduce the added system call burden sufficiently. A few extra >system calls a second will not be measurable. I laid all this out in my mail to Brian and in much greater detail than you present back to me. Guess you did not read that mail. But this is exactly what I stated. In fact there is an issue with keeping the cache updated, and from what I know of most OS's mapping upward from kernel space to user space is more of a trick than the reverse. It will have to read via an ioctl type call. And the other issues I stated when a net utility changes the src addresses and the cache you speak of has not been updated. Also another statement from your draft applies here: The rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of source address. This blows away the entire idea to send the dst addresses in a sorted order if the src selected by the application choice of the source address is not the same as the one that would have been selected by the kernel mode. If the overhead is 2 seconds it is to much. This has to be measured and I will not guess what it is and then as I just told Brian when 1000 getipnodenames are called from 1000 threads on a server each of them may have to deal with this process and that needs to be checked too. Also don't forget the extra load, store, compare for each address coming back from DNS this has a cost in the overhead too. I believe your making assumptions about implementations and performance that really need to be verified before this is even considered. And also the issues around applications that will not support this well by selecting a contrary source address. And the net utilities that will alter the src address during a getipnodebyname operation right before the src address was deprecated, invalidated (valid timer expires), or ifconfig just deletes it. But thats why I started this thread so implementors like you can bring all our knowledge together to discuss it. Which we are doing now. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 05:48:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA00833 for ipng-dist; Tue, 10 Aug 1999 05:46:11 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00826 for ; Tue, 10 Aug 1999 05:46:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA02461 for ; Tue, 10 Aug 1999 05:46:02 -0700 (PDT) Received: from monza.broadswitch.se ([195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03073 for ; Tue, 10 Aug 1999 06:46:01 -0600 (MDT) Received: by MONZA with Internet Mail Service (5.5.2448.0) id ; Tue, 10 Aug 1999 14:45:55 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD08DB8B@MONZA> From: Thomas Eklund To: ipng@sunroof.eng.sun.com Subject: Updating the goals/milestones Date: Tue, 10 Aug 1999 14:45:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I think its time to update the IETF homepage of IPNG wg with current goals/milestones for 99 and 2000.. -- Thomas Eklund -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 07:54:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA00897 for ipng-dist; Tue, 10 Aug 1999 07:50:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00890 for ; Tue, 10 Aug 1999 07:50:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA14285 for ; Tue, 10 Aug 1999 07:50:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10324 for ; Tue, 10 Aug 1999 08:50:10 -0600 (MDT) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id HAA04674; Tue, 10 Aug 1999 07:50:07 -0700 (PDT) Message-Id: <3.0.5.32.19990810074815.03376ce0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Aug 1999 07:48:15 -0700 To: Thomas Eklund From: Bob Hinden Subject: Re: Updating the goals/milestones Cc: ipng@sunroof.eng.sun.com In-Reply-To: <45AFD48D077ED211BB4700A0C9DCE8FD08DB8B@MONZA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Yes, you are correct. An updated charter is on my plate. Bob At 02:45 PM 8/10/99 +0200, Thomas Eklund wrote: >Hi, >I think its time to update the IETF homepage of IPNG wg with current >goals/milestones for 99 and 2000.. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 10:08:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA01099 for ipng-dist; Tue, 10 Aug 1999 10:04:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01092 for ; Tue, 10 Aug 1999 10:03:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA25500 for ; Tue, 10 Aug 1999 10:03:50 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA06454 for ; Tue, 10 Aug 1999 11:03:49 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Aug 1999 09:17:54 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Tue, 10 Aug 1999 09:17:55 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515701@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" Cc: "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 Src/Dst Address Pairing Date: Tue, 10 Aug 1999 09:17:50 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >About destination address ordering, to reiterate a point - > we are talking > >about just changing the order in which getipnodebyname > returns addresses. So > >this is just an implementation change, it involves no > changes to the API or > >to applications. > > Yes per Brian and my discussion it does if you use the workaround > discussed, but not as the API works today. I don't understand this comment... The way the API works today, it returns a list of addresses. This would not change. Applications would not change. > ... In fact there is an issue with > keeping the cache > updated, and from what I know of most OS's mapping upward from kernel > space to user space is more of a trick than the reverse. It will have > to read via an ioctl type call. > > And the other issues I stated when a net utility changes the src > addresses and the cache you speak of has not been updated. To review - we are talking about the getipnodebyname() implementation caching in its user-level data structures some information about the node's source addresses. I think cache update is very easy, just refresh the cache if it is more than a second stale. If the node's addresses should happen to change in that second, so what. The worst that can happen is that getipnodebyname() briefly returns some addresses in one order instead of another order. This is inconsequential compared to the coarse TTL invalidation used by DNS name resolution. The suggestion of mapping kernel memory was just an aside, dealing with how to implement a fast get-current-time operation. Most operating systems have a fast get-current-time operation that does not make a system call, and often the underlying trick involves mapped memory. But that's an aside. > Also another > statement from your draft applies here: > > The rules specified in this document MUST NOT be construed to > override an application or upper-layer's explicit choice of source > address. > > This blows away the entire idea to send the dst addresses in a sorted > order if the src selected by the application choice of the source > address is not the same as the one that would have been > selected by the > kernel mode. Yes certainly, if the application specifies a "bad" source address there's nothing the implementation can do about it. However in my experience, most applications do not specify a source address. Off hand, I think none of the applications we have ported to v6 specify a source address. > If the overhead is 2 seconds it is to much. This has to be > measured and > I will not guess what it is and then as I just told Brian when 1000 > getipnodenames are called from 1000 threads on a server each > of them may > have to deal with this process and that needs to be checked too. > Also don't forget the extra load, store, compare for each > address coming > back from DNS this has a cost in the overhead too. Suppose some busy process is doing 1000s of getipnodebynames. Then with the caching that I suggest, there would be at most one extra system call per second. This is negligible overhead. The cost of some compares/sorting would also be negligible compared to the rest of the getipnodebyname overhead. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 11:08:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA01187 for ipng-dist; Tue, 10 Aug 1999 11:03:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01180 for ; Tue, 10 Aug 1999 11:02:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08443 for ; Tue, 10 Aug 1999 11:02:52 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20345 for ; Tue, 10 Aug 1999 11:02:51 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id OAA17472; Tue, 10 Aug 1999 14:02:50 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000023950; Tue, 10 Aug 1999 14:02:50 -0400 (EDT) From: Jim Bound Message-Id: <199908101802.OAA0000023950@quarry.zk3.dec.com> To: Richard Draves cc: "'Jim Bound'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing In-reply-to: Your message of "Tue, 10 Aug 1999 09:17:50 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515701@RED-MSG-50> Date: Tue, 10 Aug 1999 14:02:49 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Yes per Brian and my discussion it does if you use the workaround >> discussed, but not as the API works today. > >I don't understand this comment... The way the API works today, it returns a >list of addresses. This would not change. Applications would not change. When I say API I am including the implementation behind the API and that has to change, I agree the hostent structure is left unaltered. Also there is another issue here. BIND as a DNS implementation will based on a config switch round robin the addresses returned based on load balancing. If the addresses are re-ordered then this breaks what BIND has done. I am just pointing this out. >> ... In fact there is an issue with >> keeping the cache >> updated, and from what I know of most OS's mapping upward from kernel >> space to user space is more of a trick than the reverse. It will have >> to read via an ioctl type call. >> >> And the other issues I stated when a net utility changes the src >> addresses and the cache you speak of has not been updated. >To review - we are talking about the getipnodebyname() implementation >caching in its user-level data structures some information about the node's >source addresses. I think cache update is very easy, just refresh the cache >if it is more than a second stale. If the node's addresses should happen to >change in that second, so what. The worst that can happen is that >getipnodebyname() briefly returns some addresses in one order instead of >another order. This is inconsequential compared to the coarse TTL >invalidation used by DNS name resolution. DNS name resolution exists today and is done. This is new work and added complexity to host software to support multihoming. The TTL argument above is a red herring and not relevant IMO. >The suggestion of mapping kernel memory was just an aside, dealing with how >to implement a fast get-current-time operation. Most operating systems have >a fast get-current-time operation that does not make a system call, and >often the underlying trick involves mapped memory. But that's an aside. Excuse me. But the above is irrelevant too. Mapping cache and getting times are two different things all together. >> Also another >> statement from your draft applies here: >> >> The rules specified in this document MUST NOT be construed to >> override an application or upper-layer's explicit choice of source >> address. >> >> This blows away the entire idea to send the dst addresses in a sorted >> order if the src selected by the application choice of the source >> address is not the same as the one that would have been >> selected by the >> kernel mode. >Yes certainly, if the application specifies a "bad" source address there's >nothing the implementation can do about it. However in my experience, most >applications do not specify a source address. Off hand, I think none of the >applications we have ported to v6 specify a source address. So what that does not change the case when it happens. Maybe you have not ported enough applications. >> If the overhead is 2 seconds it is to much. This has to be >> measured and >> I will not guess what it is and then as I just told Brian when 1000 >> getipnodenames are called from 1000 threads on a server each >> of them may >> have to deal with this process and that needs to be checked too. >> Also don't forget the extra load, store, compare for each >> address coming >> back from DNS this has a cost in the overhead too. >Suppose some busy process is doing 1000s of getipnodebynames. Then with the >caching that I suggest, there would be at most one extra system call per >second. This is negligible overhead. The cost of some compares/sorting would >also be negligible compared to the rest of the getipnodebyname overhead. I don't buy the caching you suggest but do agree that if I were to store the results and then refresh in some manner it would reduce the overhead for multiple accesses to locate the source addresses. But the operation still must be peformed N times. In the scheme of everything that happens with the implementation of getipnodebyname such a new feature is negligible, but it adds additonal work for the host and another place we have to support and it will cost us money to do it. Also another place we need to verify performance issues. Also I don't think prototype or research when I am working on this stuff but product quality and product affect for IPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 12:00:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA01249 for ipng-dist; Tue, 10 Aug 1999 11:56:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01238 for ; Tue, 10 Aug 1999 11:55:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA00251 for ; Tue, 10 Aug 1999 11:55:52 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26595 for ; Tue, 10 Aug 1999 12:55:52 -0600 (MDT) Received: from whistle.com (tlambert.whistle.com [207.76.205.208]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id LAA08775; Tue, 10 Aug 1999 11:51:19 -0700 (PDT) Message-ID: <37B073BA.4B35698C@whistle.com> Date: Tue, 10 Aug 1999 11:47:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Masataka Ohta CC: Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS References: <199908100032.JAA06671@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta wrote: > > Matt; > > > I think we all agree that there's no Truly Secure way to do it. So > > we're trying to agree on a Pretty Good algorithm. > > Silly agreement. > > Stateless autoconfiguration has absolutely no security. > > The only reasonable way to go is to abandon stateless > autoconfiguration except for an isolated small LAN. > > Note that even dentists' offices need global connectivity with > reasonable security. > > That something has interoperable implementations does not mean it > useful in the real world. This is a nice pie-in-the-sky sentiment which assumes that people are willing (or even able) to deploy DHCP servers (presumably US$7000+ NT systems) at dentist's offices. People won't do this to obtain the dubious benefit of paying Microsoft ewnough money to purchase an economy automobile. Both: draft-ietf-dnsind-local-names-07.txt draft-ietf-dhc-ipv4-autoconfig-04.txt specify mechanisms for implementing IPv4 stateless autoconfiguration for ad hoc networks. While these are drafts, they document existing practice, which is defacto standard (driven by Microsoft's client OS's). Just because we don't want to do the work to make this work transparently *and* securely, doesn't mean that people will not choose to discard security in favor of convenience to route around, frankly, "our brain damage"; for IPv4, Windows 98 and successors _already_ route around your desire to control stateless autoconfiguration. A simple analogy is the "roaming" cell phone. The cell phone is permitted to obtain dialtone anywhere, regardless of whether a particular company likes the idea that someone could enter their premesis, and place a phone call from inside their building. IPv6 Stateless Auto-Configuration is tantamount to dial tone. It is ridiculous to consider trying to control dial tone on a per cell phone basis at each of the cells. For IPv4, I think the security argument is specious; in particular, it's most likely that any ad hoc networking will find itself occurring behind a network address translation perimeter, if it finds itself with WAN access at all. For IPv6, there is a very real danger that ad hoc networks will find themselves with non-translated addresses that give them WAN connectivity. I will go further: this _will_ happen. It is expedient, it is convenient, and it is less work than the alternative. The only issue is whether your products let them have a reverse mapping, or not. If not, and it is found to be an inconvenience, they will buy someone else's products, and your point of view loses dejure instead of defacto. If you wish to make this less likely, the answer is simple: make what you want to happen be less work for the end user than what you don't want to happen. To do this for IPv6, you would have to redefine the entire autoconfiguration space as non-routable, and requiring address translation to be routable. This will happen when pigs fly, mostly because the routability of addresses obtained via Stateless Auto-Configuration is intentional: it was an intended design goal. Note: IPv4 has defined a mechanism which allows administrative refusal for Stateless Auto-Configuration of IPv4 Clients: draft-ietf-dhc-autoconfig-04.txt IPv6 (rightly) lacks a similar mechanism, since there is not a requirement for administrative cooperation for WAN connectivity (i.e. IPv6 Stateless Auto-Configuration results in an address that is routable, and does not require a cooperating Network Address Translation gateway). As it is, I believe that most printers and other network attached devices will, in the near (i.e. IPv4) future, request an address via DHCP, and, failing to find one in a small business, will engage in IPv4 Auto-Configuration via the IANA registered LINKLOCAL net. This will be driven by compatability with Windows 98 and Windows 2000 IPv4 Auto-Configuration. After doing this, I expect that there will either be a vendor proprietary availability broadcast, with a client installation piece (e.g. HP JetSend), and/or an SLP SA availability broadcast; this is because these mechanisms map most closely to what a Windows client in an enterprise environment would see as a "Network Neighborhood" that correctly presents the current topology of the network. Because this will be implemented for enterprises, it will be used in small offices, such as your dentist's office example; regardless of the suitability of doing this, I again predict: this _will_ happen. People do not want to configure DHCP servers. Neither do they want to configure client machines, nor printers. In order to expand into the available market, e.g. the small business, branch office, SOHO market, [read: no MIS department] vendors must accept this as a reality. Implementors do not drive technology standards, consumers do; this is the lesson of VHS vs. Beta. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 12:23:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA01279 for ipng-dist; Tue, 10 Aug 1999 12:18:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01272 for ; Tue, 10 Aug 1999 12:18:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA03082 for ; Tue, 10 Aug 1999 12:18:33 -0700 (PDT) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA24641 for ; Tue, 10 Aug 1999 12:18:32 -0700 (PDT) Received: (qmail 8373 invoked from network); 10 Aug 1999 19:18:28 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 10 Aug 1999 19:18:28 -0000 Received: from sunshine.arin.net (sunshine.arin.net [192.149.252.183]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA12239; Tue, 10 Aug 1999 15:18:27 -0400 (EDT) Received: from localhost (kerr@localhost) by sunshine.arin.net (8.9.3/8.9.3) with SMTP id PAA07718; Tue, 10 Aug 1999 15:18:26 -0400 (EDT) X-Authentication-Warning: sunshine.arin.net: kerr owned process doing -bs Date: Tue, 10 Aug 1999 15:18:25 -0400 (EDT) From: Shane Kerr To: Terry Lambert cc: Masataka Ohta , Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS [vaguely-off-topic] In-Reply-To: <37B073BA.4B35698C@whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 10 Aug 1999, Terry Lambert wrote: > This is a nice pie-in-the-sky sentiment which assumes that people are > willing (or even able) to deploy DHCP servers (presumably US$7000+ NT > systems) at dentist's offices. $250 will get you a PC fully capable of running Linux or FreeBSD with a DHCP server (and a WWW server, a SENDMAIL server, a FTP server, Samba, an NFS server, a DNS server, a POP3 server, an IMAP server, and an SQL server). Make that $275 with a network card and modem. This is a dentist's office we're talking about after all, not Amazon.com! [snip] > This will be driven by compatability with Windows 98 and Windows 2000 > IPv4 Auto-Configuration. [snip] > People do not want to configure DHCP servers. Neither do they want to > configure client machines, nor printers. In order to expand into the > available market, e.g. the small business, branch office, SOHO market, > [read: no MIS department] vendors must accept this as a reality. Having said that, I agree with this. :) Ease of use kicks ass. Hell, *I* don't want to configure a DHCP server, even if it only takes 5 minutes to do so. In my home, safely ensconced behind my firewall, I'd rather just plug and chug. -- Shane Kerr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 14:29:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA01431 for ipng-dist; Tue, 10 Aug 1999 14:21:53 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01424 for ; Tue, 10 Aug 1999 14:21:48 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id OAA15739 for ipng@sunroof.eng.sun.com; Tue, 10 Aug 1999 14:20:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00414 for ; Mon, 9 Aug 1999 20:49:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA01726 for ; Mon, 9 Aug 1999 20:49:46 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA02216 for ; Mon, 9 Aug 1999 21:49:46 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA21692 for ; Tue, 10 Aug 1999 12:49:45 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA27796 for ; Tue, 10 Aug 1999 12:49:44 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA17913 for ; Tue, 10 Aug 1999 12:49:42 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: KAME stable release 19990809 From: core@kame.net X-Mailer: Mew version 1.94b47 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990810124903N.kazu@iijlab.net> Date: Tue, 10 Aug 1999 12:49:03 +0900 X-Dispatcher: imput version 990731(IM118) Lines: 64 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As usual, KAME Project has released "stable" packages of IPv6/IPsec network code for FreeBSD 2.2.8/3.2, NetBSD 1.4, and BSD/OS 3.1. These packages are free of charge but absolutely no warranty. They are avaiable from the following web site: http://www.kame.net/ NOTE: IF YOU GAIN ACCESS TO THIS WEB PAGE OVER IPv6, THE TURTLE WILL DANCE. The changes from the previous official release are shown below. These packages have been tested by the TAHI team(http://www.tahi.org). --KAME Project ---from here Here are summary of recent changes prior to this STABLE kit (19990802). <> <> - More spec-conformant source address selection for NA output. - ND6 IsRouter behavior against redirect packet is fixed. - On router, ND6 code wrongly generated too many redirects toward source. It is now fixed. - NetBSD now uses single source code for tcp4/6. - IPv6 path mtu discovery for NetBSD. - Kernel data structure for prefix management is splitted to router (advertise) side and host (receive) side. <> - Partly sync'ed to new advanced API, 2292bis. - IPV6_CKSUM now works correctly against jumbograms. <> - New IPsec policy engine on all the platforms. - IPv4 tunnel/transport mode, and IPv6 tunnel/transport mode can be generated. IPv6 tunnel mode cannot be imposed on a packet forwarding case at this moment so there's no router use for it, though. - IPsec code was too strict about SA direction (inbound, outbound or bidirectional). - Separated IPSEC_ESP from IPSEC kernel config option for countries where crypto export is restricted (for example, united states). - IPComp (IP payload compression) support. <> - rtsol: timing parameter fixed to conform to ND6 draft. - bgpd: properly handle an empty AS path. - ftp: protection against bogus return code from some of ftp daemons. - pim6dd: filtering (configured pruning) of multicast routing-capable interfaces. - Various additions, such as pim6sd (PIM multicast routing on IPv6, sparse mode), tftp/tftpd on NetBSD, and so forth. - net.inet6.ip6.kame_version sysctl MIB (which shows the KAME version you are using). <> - ATM PVC pseudo interface support in KAME/NetBSD. - ALTQ is upgraded. - ports/pkgsrc: upgraded base version for many items in the collection. - ports/pkgsrc additions: pfs, rsync - ports/pkgsrc removals: IM ---to here -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 15:00:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA01479 for ipng-dist; Tue, 10 Aug 1999 14:56:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01472 for ; Tue, 10 Aug 1999 14:55:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA03641 for ; Tue, 10 Aug 1999 14:55:58 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05629 for ; Tue, 10 Aug 1999 15:55:56 -0600 (MDT) From: Masataka Ohta Message-Id: <199908102132.GAA10727@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA10727; Wed, 11 Aug 1999 06:32:33 +0900 Subject: Re: IPv6 and Dynamic DNS To: kerr@arin.net (Shane Kerr) Date: Wed, 11 Aug 99 6:32:32 JST Cc: terry@whistle.com, mohta@necom830.hpcl.titech.ac.jp, crawdad@fnal.gov, ipng@sunroof.eng.sun.com, namedroppers@internic.net In-Reply-To: ; from "Shane Kerr" at Aug 10, 99 3:18 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shane Karr; > > This is a nice pie-in-the-sky sentiment which assumes that people are > > willing (or even able) to deploy DHCP servers (presumably US$7000+ NT > > systems) at dentist's offices. > > $250 will get you a PC fully capable of running Linux or FreeBSD with a There is a >$200 box of a DHCP server. Or, for example, your router can have default installation of DHCP server which randomly assignes IP addresses from lower half address ranges of subnets served by each interface, which, in practice, as good as stateless autoconfiguration. However, without configuration, there is no security. > Having said that, I agree with this. :) Ease of use kicks ass. Hell, > *I* don't want to configure a DHCP server, even if it only takes 5 minutes > to do so. In my home, safely ensconced behind my firewall, I'd rather > just plug and chug. Or, for example, your firewall can have default installation of DHCP server which randomly assignes IP addresses from lower half address ranges of subnets served by each interface, which, in practice, as good as stateless autoconfiguration. However, without configuration, not even 5 minutes of it, your firewall offer no security. No security implies no security for DNS dynamic update, of course. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 15:24:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA01548 for ipng-dist; Tue, 10 Aug 1999 15:20:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01541 for ; Tue, 10 Aug 1999 15:20:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA28645 for ; Tue, 10 Aug 1999 15:20:29 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15925 for ; Tue, 10 Aug 1999 15:20:28 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id PAA06783; Tue, 10 Aug 1999 15:20:15 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id PAA15154; Tue, 10 Aug 1999 15:20:15 -0700 (PDT) Received: from tellurium (usr-modem19.nsd.3com.com [129.213.205.139]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id PAA25716; Tue, 10 Aug 1999 15:20:13 -0700 (PDT) Message-Id: <3.0.2.32.19990810151725.00904880@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Tue, 10 Aug 1999 15:17:25 -0700 To: Richard Draves , "'Brian E Carpenter'" , David Borman From: Cyndi Jung Subject: RE: RFC 2529 (6over4) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D810145156FD@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A very compelling argument for the DF bit to MUST NOT be set. Thanks - I feel quite confident about it now. Cyndi At 08:29 PM 8/9/99 -0700, Richard Draves wrote: >(As an aside, I would really rather not change the source/target link-layer >address option format for 6over4. We have deployed the existing format. And >the current format aligns the IPv4 address, if you care about that.) > >About the DF bit and PMTU discovery... > >I'm having trouble understanding how PMTU discovery at the IPv4 layer would >usefully interact with 6over4. At least the way our implementation works >(and this is universal I would guess - RFC 2461 specifies a LinkMTU >conceptual variable this way), a node maintains a link MTU that applies to >all neighbors on the link. Suppose IPv4 PMTU discovery gave you different v4 >PMTUs for different 6over4 neighbors. Since there's only one link MTU, we >would need to use the minimum of the different PMTUs I suppose. > >With implementations like ours, the only way in which the link MTU can be >large is if all 6over4 neighbors are reachable with the large MTU, in which >case the large 6over4 MTU should be configurable with a Router >Advertisement. You don't need v4 PMTU. > >Note - it would be useful if section 2 of RFC 2529 specified that the >default MTU of 1480 can be raised to a specified upper-bound as well as >lowered via Router Advertisements. Although there's a little conflict with >RFC 2461 (Neighbor Discovery) section 6.3.4: > If the MTU option is present, hosts SHOULD copy the option's value > into LinkMTU so long as the value is greater than or equal to the > minimum link MTU [IPv6] and does not exceed the default LinkMTU value > specified in the link type specific document (e.g., [IPv6-ETHER]). >Whereas for 6over4 you want to have a default LinkMTU of 1480, but allow RAs >to specify a larger LinkMTU up to ~64K. > >It's a little tricky to have an implementation that would allow a different >link MTU for different neighbors on the link. For example, what MTU would >the sender use for a multicast destination? Just allow fragmentation for >multicast destinations? So I guess I can imagine a 6over4 implementation >that would use v4 PMTU discovery, but it's a stretch. > >Rich > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian@hursley.ibm.com] >> Sent: Monday, August 09, 1999 8:49 AM >> To: David Borman >> Cc: cmj@3com.com; ipng@sunroof.eng.sun.com; Richard Draves >> Subject: Re: RFC 2529 (6over4) >> >> >> David, >> >> You're causing me second thoughts about this. Rich Draves, as >> an implementor, do you have a comment? >> >> Brian >> >> David Borman wrote: >> > >> > > Date: Fri, 06 Aug 1999 17:43:28 -0500 >> > > From: Brian E Carpenter >> > > Subject: Re: RFC 2529 (6over4) >> > > >> > > Dave, I think the point is that IPv6 will do MTU discovery anyway; >> > > so there is no need to do it at the IPv4 level too. >> > >> > Not true. The IPv6 MTU discovery will not learn anything about >> > the section of the path that is traversed as 6over4 packets. Once >> > the packet is encapsulated, if the DF bit is not set, it will just >> > go on its way, getting fragmented as needed, and reassembled at >> > the other IPv4 side. To the IPv6 code, it looks like the packet >> > took 1 hop, and did it successfully in one piece. So, IPv6 can't >> > discover the smaller MTU along the 6over4 path, unless the DF bit >> > is set in the outer IPv4 packet. >> > >> > 6over4 is really no different than ESP/AH tunnels with respect to >> > Path MTU discovery, the same basic issues are involved in both >> > cases. See Section 6.1 of RFC 2401. >> > >> > -David Borman, dab@bsdi.com >> >> -- >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> Brian E Carpenter (IAB Chair) >> Program Director, Internet Standards & Technology, IBM Internet Div >> On assignment for IBM at http://www.iCAIR.org >> Non-IBM email: brian@icair.org >> >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 15:45:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA01591 for ipng-dist; Tue, 10 Aug 1999 15:40:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01584 for ; Tue, 10 Aug 1999 15:40:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA04360 for ; Tue, 10 Aug 1999 15:40:42 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24478 for ; Tue, 10 Aug 1999 15:40:41 -0700 (PDT) Received: from whistle.com (tlambert.whistle.com [207.76.205.208]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id PAA23799; Tue, 10 Aug 1999 15:35:23 -0700 (PDT) Message-ID: <37B0A83E.251BC6BB@whistle.com> Date: Tue, 10 Aug 1999 15:31:26 -0700 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Shane Kerr CC: Masataka Ohta , Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS [vaguely-off-topic] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Shane Kerr wrote: > > On Tue, 10 Aug 1999, Terry Lambert wrote: > > > This is a nice pie-in-the-sky sentiment which assumes that > > people are willing (or even able) to deploy DHCP servers > > (presumably US$7000+ NT systems) at dentist's offices. > > $250 will get you a PC fully capable of running Linux or > FreeBSD with a DHCP server (and a WWW server, a SENDMAIL > server, a FTP server, Samba, an NFS server, a DNS server, > a POP3 server, an IMAP server, and an SQL server). Make > that $275 with a network card and modem. This is a > dentist's office we're talking about after all, not > Amazon.com! As the person who wrote the orignal 386BSD FAQ and 386BSD patchkit, which later resulted in FreeBSD, among other significant BSD contributions, such as loadable kernel modules, and as a Senior Software Engineer at a company that has been shipping an embedded system product based on FreeBSD to do exactly what you describe for over 3 years and 10's of thousands of units, I am well aware of this. 8-). Unimpressed, my dentist still says "Free what?". 8-(. We are in the realm of people who buy their computer equipment at OfficeMax, or, on a good day and if they are in the right region of the US, from Fry's. They either buy what they see advertised, or they buy what their computer guy tells them to buy (probably based on how much margin he gets from the deal). These people are buying service, and they are buying what they are told to buy. If you are contributing to an IETF group discussion at all, you are the road crew. The average driver really doesn't care what you do, so long as you don't close too many lanes at once, they don't get rock chips on their windshield, and the bridges don't collapse. This is for whom you are building. The point of this posting is to support the idea that people are going to do what's easy, not what's right, and if you offer them a choice between easy+wrong and hard+right, they are going to pick easy+wrong almost every time (c.v. PAP/CHAP, the Windows 95 "remember this password for next time" checkbox, etc., etc.). So I think it's not a good idea to offer an option which is labelled as "wrong" (or, conversely, to label as "wrong" an option which is offered). [ ... ] > > People do not want to configure DHCP servers. Neither do > > they want to configure client machines, nor printers. In > > order to expand into the available market, e.g. the small > > business, branch office, SOHO market, [read: no MIS > > department] vendors must accept this as a reality. > > Having said that, I agree with this. :) Ease of use kicks > ass. Hell, *I* don't want to configure a DHCP server, even > if it only takes 5 minutes to do so. In my home, safely > ensconced behind my firewall, I'd rather just plug and chug. And you are educated on what it takes to do this; consider my poor dentist, who is confused when the Windows 98 box he just bought at OfficeMax asks where his LDAP server lives (I told him he can just ignore it -- before that he was afraid to hit "Enter", and afraid to turn the machine off). IMO, any requirement that gets in the way of spontaneous networking by non-computer professional end users is by definition a bad thing. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 16:42:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA01704 for ipng-dist; Tue, 10 Aug 1999 16:35:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01697 for ; Tue, 10 Aug 1999 16:35:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA15556 for ; Tue, 10 Aug 1999 16:35:45 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA15487 for ; Tue, 10 Aug 1999 17:35:44 -0600 (MDT) From: Masataka Ohta Message-Id: <199908102315.IAA11005@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA11005; Wed, 11 Aug 1999 08:15:14 +0900 Subject: Re: IPv6 and Dynamic DNS To: terry@whistle.com (Terry Lambert) Date: Wed, 11 Aug 99 8:15:14 JST Cc: mohta@necom830.hpcl.titech.ac.jp, crawdad@fnal.gov, ipng@sunroof.eng.sun.com, namedroppers@internic.net In-Reply-To: <37B073BA.4B35698C@whistle.com>; from "Terry Lambert" at Aug 10, 99 11:47 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Terry; > A simple analogy is the "roaming" cell phone. The roaming cell phone has configured state, which is, to some extent, kept secret, which is why, unlike stateless autoconfiguration, it has some security. > While these > are drafts, they document existing practice, which is > defacto standard (driven by Microsoft's client OS's). As you know, Microsoft OS has nothing to do with security a lot to do with stateful configuration. So? Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 17:01:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA01769 for ipng-dist; Tue, 10 Aug 1999 16:57:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01762 for ; Tue, 10 Aug 1999 16:56:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA05064 for ; Tue, 10 Aug 1999 16:56:55 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA23140 for ; Tue, 10 Aug 1999 17:56:53 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA01863; Wed, 11 Aug 1999 08:56:36 +0900 (JST) To: Terry Lambert cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net In-reply-to: terry's message of Tue, 10 Aug 1999 11:47:22 MST. <37B073BA.4B35698C@whistle.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: security in stateless autoconfiguration From: itojun@iijlab.net Date: Wed, 11 Aug 1999 08:56:36 +0900 Message-ID: <1861.934329396@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Terry, >For IPv4, I think the security argument is specious; in >particular, it's most likely that any ad hoc networking >will find itself occurring behind a network address >translation perimeter, if it finds itself with WAN access >at all. >For IPv6, there is a very real danger that ad hoc networks >will find themselves with non-translated addresses that >give them WAN connectivity. >I will go further: this _will_ happen. It is expedient, >it is convenient, and it is less work than the alternative. >The only issue is whether your products let them have a >reverse mapping, or not. If not, and it is found to be an >inconvenience, they will buy someone else's products, and >your point of view loses dejure instead of defacto. What do you referring here with the word "security"? There are many "security"-ish things involved here; - security of stateless autoconfiguration itself: - malicious end node that visits Ethernet hookup in dentist office will get access to other node in the dentist office. - (similarly) mailicious user will get global address by stateless autoconfig. - malicious router connected to dentist office network will be able to capture every outgoing packets from the dentist office - end node at dentist office will automatically be visible to worldwide by using stateless autoconfig I suspect you meant the last one, but that is not the only one. And the last one is not really true I believe. You can announce RAs with site-local prefixes to avoid end nodes to be visible from outside world. I agree that there's no per-host policy control about the reachability (there's subnet-grain control only), but stateless autoconfig does not always mean worldwide reachability. And you seem to say that IPv4 world is safe because you have NAT. NAT does not provide security at all. Malicious outside node can inject the inside node any tcp options as he like. I maybe missing your point.... itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 17:44:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA01860 for ipng-dist; Tue, 10 Aug 1999 17:40:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01853 for ; Tue, 10 Aug 1999 17:40:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA24760 for ; Tue, 10 Aug 1999 17:40:35 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07482 for ; Tue, 10 Aug 1999 18:40:35 -0600 (MDT) Received: from whistle.com (tlambert.whistle.com [207.76.205.208]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id RAA30437; Tue, 10 Aug 1999 17:35:08 -0700 (PDT) Message-ID: <37B0C44F.65F3C061@whistle.com> Date: Tue, 10 Aug 1999 17:31:11 -0700 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Masataka Ohta CC: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS References: <199908102315.IAA11005@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta wrote: > > Terry; > > > A simple analogy is the "roaming" cell phone. > > The roaming cell phone has configured state, which is, to > some extent, kept secret, which is why, unlike stateless > autoconfiguration, it has some security. I could argue the cell phone security at length; I won't. What we are really begging here is the question of why people believe that one must secure reverse records against modification by the machine to which the record applies; what is expected to be won by this? Paul Vixie's question about whether this is really applicable to namedroppers contains the assumption that allowing reverse records to be updated by machines whose IP address they point to is somehow "bad". Is this an autoconfiguration "design flaw", or is it really a (potentially) invalid assumption about which DNS UPDATE transactions need to be protected? I believe this is the question namedroppers must answer, before the problem can be dropped squarely into the lap IPNG as "not a DNS problem". Here are two scenarios for an unsecured reverse record update for a particular IP address being allowed for the machine assigned the IP address to which the record applies. It is "secured" by: o Ensuring that the machine is only updating the record the network implictly granted it ownership of by permitting the access by the IP address, and the routing its packets o Refusing the update if the forward mapping of the name does not result in the IP address, a transaction requiring authentication or signature Worst case, we end up with a machine which modifies its reverse record to not match the forward record using a two stage process of modifying the forward record twice, and, again, applications will refuse to talk to it. We could work around this by ensuring the TTL on the reverse is less than the TTL on the forward, or, more anally, we could verify the forward match each time before responding to requests for the reverse. Posit: If it is insufficient to do forward/reverse checks of the DNS for a machine, then it is equally insufficient to permit routing of packets for a local address for which a reverse mapping does not exist. Let me know if you think the following scenario list is incomplete: Scenario #1: If we update our reverse record so that it doesn't match our forward record, applications (e.g. sendmail) will refuse to talk to us. There is no benefit to lying about your host name in a reverse record; futher, the update is not permitted, if doing so causes it to not match your forward record. --- Scenario #2: On the other hand, if we allow the machine which we admit currently owns the IP address to modify the reverse record for that IP address, then we are still protected by the security applied to the forward record, since the forward record can enforce a shared secret for machines in its zone of control. This enforcement is allowable, because we presumably have an administrative relationship with the DNS containing the forward record. --- Intentional abuse: Absolutely worst case, we have someone who gets their IP address at your business (e.g. because you allow them to do so by not turning off the IR port on the conference table), updates the forward via a secured method, updates the reverse because of the relaxed checking, and SPAM's from it using their own domain name, removing their ability to repeat the event in the future, and very clearly identifying the culpable authority. Alternately, they get an address and an assigned host name in your address block via DHCP, and SPAM from that, instead, making you the liable party and damaging the utility of your non-autoconfiguration space IP address block. This is worse. > As you know, Microsoft OS has nothing to do with security > a lot to do with stateful configuration. > > So? So everyone is going to have to interoperate with Microsoft software, whether they like it or not; that's just a fact of life: if you are a server, you have to expect Microsoft clients for the forseeable future. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 17:46:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA01878 for ipng-dist; Tue, 10 Aug 1999 17:44:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01871 for ; Tue, 10 Aug 1999 17:44:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA04463 for ; Tue, 10 Aug 1999 17:44:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA10200 for ; Tue, 10 Aug 1999 17:44:38 -0700 (PDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA24500; Tue, 10 Aug 1999 17:44:05 -0700 (PDT) Message-Id: <3.0.5.32.19990810174304.03387200@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 10 Aug 1999 17:43:04 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Minutes from IPng WG meetings in Oslo IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Minutes of the meetings of the IPng Working Group in Oslo, July 1999 Meetings chaired by Bob Hinden / Nokia Minutes recorded by Allison Mankin / ISI ---------------------------------------------------------------------- Wednesday, July 14 ------------------ I. Agenda Bashing It was reiterated that Steve Deering was unable to attend Oslo because of a family emergency. Dave Johnson announced that the mobile-ipv6 draft was resubmitted just before meeting, and it is very close to final, but still needs to have added clarification about IPSEC. No major agenda item about it in this IETF's meetings, but attendees invited to comment on IPSEC there if needed, or else via the email list. II. Document Status - Bob Hinden, RFC: Basic API published as RFC2553. Approved for PS by IESG: Jumbograms. IETF Last Call completed for DS: Addressing Architecture and Aggregatable Global Unicast - the IESG needs reports of experience with scoped multicast forwarding and there is IESG concern about how to standardize architecture docs. Does DS need to wait until a large enough deployment has occurred to indicate how scalable the addresses are? During IETF week, there are some offline discussions related to the 8+8 decision; the IAB workshop on the Network Layer recommended talking about it. IETF Last Call completed for PS: Router Renumbering is back at IESG, and they are not waiting for a revision. DNS extensions - dependent docs have been approved, but the draft is waiting for revisions covering how to handle resolver behavior during the AAAA/A6 transition - an update is on today's agenda. Multicast Listener Discovery is ready for IESG ballot. Submitted to IESG for PS: Router Alert - WG last call finished without comments today, so it will be sent to IESG now. Submitted to IESG for Informational: The GSE analysis was at the IESG for a long time. About two weeks ago, the authors received a security review from Steve Bellovin, requested by the IESG. Steve, the authors, some ADs, and Bob Hinden were to meet during Oslo to discuss the review, and there will probably be a document revision. WG Last Call completed for Informational: The initial sub-TLA assignments draft was never submitted to IESG because preliminary discussions with the IANA and registry people suggested we wait for action by them. Their action has happened: there will be an announcement at the plenary tonight that the IANA has delegated the first allotments of sub-TLA space to the three registries. A Method for Flexible Assignment - This draft is close to be ready for submission, but the author has been asked to revise it some to provide more context. The Case for IPv6 - Some comments are being forwarded to the authors. Note that this document will be sent to IESG as an IAB doc, not IPNGWG. III. Updates - Matt Crawford, FNAL DNS Lookups: IETF Last Call was issued 14 June. Remaining issue is specification of resolver behavior during the aaaa to a6 transition - the straw man proposal for this had very light discussion on the mailing list. ICMP Name Lookups: Near ready for WG Last Call - one known issue is that the lookup request hashes the name using a CRC32, noting that this should be fine because it is not a hash for security purposes. Some people have asked that it use an IPSEC hash instead, simply because IPSEC hashes already have been implemented in stack and will not entail extra code. Matt noted finally that there has been no complaint about the draft's specified multicast address. Other: There are potential interactions between Router Renumbering and mobility: for instance, if you set or clear the R flag in the router advertisement. Question is how to minimize the coupling of the two documents so as not to delay the standards track progress of either one. Hinden commented that RR was further along than IPv6 Mobility, so perhaps the right thing would be for the latter to reference the former. Hinden took an action to ask Thomas Narten for an AD opinion on this, since Thomas was not in the room at that point. There are similar interactions between RR and the site-prefixes draft. Questions: Itojun asked when A6 will be implemented. Answer: Bind 9 will have it. The last word Matt had was that its ETA is the coming fall, but Matt got that update 3 months ago. IV. CSI - Hiroshi Kitamura, NEC The Secretariat republished the original draft as 01 instead of using the updated text. This presentation is an update from his presentation at last IETF. Connection/Link Status Investigation (CSI) is a traceroute or pathchar type mechanism using one new HBH option and three new ICMPv6 messages - - CSI HBH option - ICMPv6 Status Request/Status Reply/Status Report The basic mechanism is to send a message with a pre-allocated space for each hop to record the requested information in. Scalability of this space is handled by having a node which fills the remaining space send a Status Report back and forward on the Request with the original space now cleared for new information. The CSI option may be disabled by nodes and then they mark a bitmap with 0 in the position of the skipped node. This mechanism is limited to 24 hops. A change between the 00 and 01drafts was to eliminate the version field, and plan on using a new investigation type code when going to a new version of a particular investigation type. Issues include: which address to record from among all assigned to an interface. The proposal would be to use rules like those for source address selection, keyed to the destination address in the ICMPv6 header. To economize on the space, there is a mechanism for IP address compression - in a large scale net: record upper part, small scale net: lower part. The speaker did not address how you would determine and specify which compression mode to use. The speaker stated why CSI can be said to be simple to implement: none of the envisioned investigation type responses have to be rapidly processed in the routers and they do not require intelligence or complexity there - the model is that the data is collected by the requester and analyzed offline. The speaker has implemented a tool called tracestatus, and suggests it can replace ping and traceroute. The code may be released soon. Comments - Comment: It's less simple than traceroute, which requires nothing on routers. It is also not true that you can simplify by saying no security considerations enter into it. Answer: there are security considerations in draft 01. Answering about traceroute: if the function had been seen as necessary early on in the IPv4 development, then maybe the IPv4 designers would have chosen to create something like CSI, but IPv4 option problems ruled out that thinking later. Crawford: Note that timestamp definitions within the draft are inconsistent. Asks if it is necessary that this be ICMP? Suggests that the option field might also need to include a Router Alert. Can routers disable some types of data but allow others? Answer - that can be set as a policy but as currently specified, the replies cannot tell the requester about the specifics. Durand asks if this is a working group item - Hinden says not sure if WG supports. Similar 1997 proposal by Durand and others did not have working group support. Preference by Hinden now is keep as individual submission until work is more mature. If people disagree with that, say something now. Author is asked to label next draft as individual submission, not draft-ipngwg-hbh-etc.. Haskins - this might belong in operations area. V. UDP-Lite - Lars-Ake Larzon , Lulea University The presentation proposed a small change to UDP aimed at realtime applications in error-prone environments. IP in cellular nets experiences errors and delay, and there is an increasing interest in the use of error-tolerant codecs to get tolerable performance for realtime flows. For this, the IP/UDP checksumming is not optimal - UDP will drop damaged packets which the error-tolerant codecs delivered as damaged but usable. And, of course, disabling the UDP checksum with a zero value as in IPv4 is not permitted for IPv6. Transport layer properties wanted for the realtime applications over cell - low complexity for low protocol overhead, checksum coverage of just the protocol headers, allowance of delivery of damaged frames. Proposed solution: UDP's packet length field is redundant because the IP header has it too - so replace it with a field called Checksum Coverage that specifies how much of packet beginning of the UDP header should be covered by the checksum. If checksum coverage is less than packet length then that remaining part of packet will not be checksummed. Examples: - Voice over IP (VoIP) using IP/UDP/RTP - cover only headers - VoIP with compressed RTP - with checksum covering only the headers, they have measured that there are 40% fewer context synchronization losses and TWICE will succeed more often. More details on this will be presented to the AVT WG on Thursday. - 64 kbps PCM audio over cellular - normally cellular would not be used for this voice encoding because of its too limited bandwidth. However, there are tests of using it and recovering from the extensive packet losses. More packets get through when UDP-Lite is used; a clicking sound occurs from data corruption in the packet, which the application can filter out. One of the arguments for standardizing on UDP-Lite is low deployment cost, because it can look exactly like regular UDP by simply having the full length in the Coverage Field. It could be deployed as a separate protocol parallel to UDP, but the speaker asks consideration for replacing UDP in IPv6 with UDP-Lite, since there has been limited deployment to date. Comments: Hinden: First thought is that UDP is usually considered in transport area. On the other hand, IPNGWG has changed the checksum of TCP/UDP so it's probably OK to consider UDP-Lite here. Comment: Doesn't this conflict with having underlying protocols that are checksummed themselves, like PPP radio? Answer: link protocols for IP over cellular are not settled yet, and there is ongoing work on link layers that deliver the damaged frames. Draves: how does an application ask for less coverage? Answer: the default behavior is to look like ordinary UDP, and in their implementation, the application uses a socket option to set lesser coverage. Comment: this WG made UDP unsafe for the applications described by requiring the checksum, unlike IPv4, so it is our responsibility to fix the problem. The commenter also agrees that the data link layers haven't been fully defined for newer digital cellular such as UMTS. Crawford: Though new transport doesn't necessarily belong here, this WG also has worked on jumbograms, and note this would interact with jumbograms. Hinden: note a new comment on checksum limitations for very large datagrams that the IESG had the authors to that draft. Speaker: we think being able to specify coverage only as far as 64K would be OK, but also, the semantic of zero in the Coverage field, meaning the entire packet is covered, means you can request coverage of the whole jumbogram. Hinden took an action to talk to the ADs. He'd lean to making a separate UDP because there have already been investments in UDP as is. Another of the authors of UDP-Lite added as a last word that the changes to UDP are 2 lines of code. VI. TAHI Project: IPv6 Code Verification - Nobuo Okaba, Yokagawa Electric Corp. The TAHI project was started in 1998, funded by the Japanese government. Its objectives are conformance and interoperability tests for IPv6, to be made publicly available. The current coverage is 106 tests for hosts, taking about 6 hours to complete, and 56 for routers taking about 3.5 hours. Unattended operation works fine. Among tests of basic function still to be done are: RS/RA functions of the router and Redirect. The implementations that have been tested so far are Hitachi NR60, various versions of KAME, and some NEC prototype host code. The development plan is to complete the basic spec by 8/99, ICMPv6 by 10/99, IPSEC by 12/99, v6/v4 Tunnel by 12/99, Address Architecture by 12/99. Testing on the ipv6-unified kernel will be started next month. Test package releases are planned every two months. Results for both KAME and ipv6-unified will be published. Both the test spec and testing code will be published. Plan an interop event in October in Japan. Begin checking the TAHI web site for these various developments in August 1999 - www.tahi.org Itojun: Can you describe how TAHI is distinguished from UNH. Answer: a major difference is that all the test programs will be openly available, as will test results such as the ipv6-unified. Dave Johnson: When will TAHI make tests for mobile IPv6. Answer: sometime in 2000. Dave: January looks open. A demo in the IETF laptop room was available by arrangement. Code to be tested is welcome. One can get in touch using contact@tahi.org or nobuo_okabe@yokogawa.co.jp. Question: are the tests hand-coded in C or using a specification language? Answer: in C. VII. IPv6 in GSM-like Infrastructure - Hossam Afifi, INRIA Sophia The hypothesis of this presentation was that the IP over cell phone standards currently being developed for GSM and its successors could fail to be deployed because of complexity, and, in that circumstance, an IPv6 stack for current GSM could become a viable standard. IPv6 can provide improvement and simplification of GSM networking . Draft-afifi-sixtel-00.txt, by the speaker, Jim Bound and Laurent Toutain is the basis of the talk. GSM has a few 100 million users today - both voice and data modems. It is a success story like the Internet. There is a standard for data transfer over wireless, GPRS, which is viewed as an extension to GSM. Hypothesis is that it is not successful like GSM. It is currently standardized but not widely deployed. UMTS (3GPP) and IMT2000, representing the next generation, are not yet standardized. There are two kinds of mobility in GSM, from cell to cell within one switch (MSC) and between MSCs. The Home Database is with your home MSC, and the Visitor Database is updated when you change MSC. The GSM functions are in a Call Management layer, Mobility Management layer, and Radio Resource layer. GPRS does not use this architecture, but has a different fixed database structure. You can have equipment that is GSM only, GPRS only, or both. GPRS has many complex services, including a reliable multicast. Frame Relay is used between base stations and the databases. A slide showed GPRS as having complex protocol stacks in the database (SGSN) and base stations. A simple way to add IPv6 to cell telephony is just to use Francis Dupont's IPv6-supporting device driver for GSM modems. The accepted view is that IPv6 should be added to the GPRS protocol architecture, but since GPRS is not deployed and is such a mess, the suggestion is to bypass it and architect just for GSM. The draft covers what was proposed in more detail. Highlights: - Place an IPv6 Router over an adaptation layer over the stack in the MSC. - Design the needed adaptation layer in IETF, and go to ETSI to suggest changes as needed to Call Management and Mobility Management. - The architecture would be one MSC/subnet. - Some needed additions are header compression and mux/demux. - Use IPv6 mobility for the inter-MSC mobility. - Have DHCPv6 give the address to a phone on turn-on and add IPSEC to the Call Management layer. - Have DHCPv6 and IPv6 interact on the move to a new MSC, with support for this in Mobility Management The speaker concluded suggesting a poll of whether this proposal is useful, whether to work on it in the WG, and if there would be concurrence about the work suggested to be done in ETSI. Comments - Eklund: Much of what they would do is already part of GPRS. For instance, it already includes the ability to choose IPv6 instead of IPv4. The suggestions represent misunderstanding of GPRS. Eklund's opinion is that no operator would adopt this scheme. Answer: an operator Afifi is working with is unhappy with the prospective performance of GPRS and its complex stack and has expressed interest in bypassing GPRS. Eklund - the cost of building an alternative means that all operators are going to use GPRS. I Hakkunen: Also thinks the authors misunderstand what is happening in GPRS. GPRS is complex because it needs to be. The end result of the suggested use of GSM would be as complex as GPRS because it would have to be. Answer: GSM is deployed today. What is the guarantee that GPRS will be deployed? Hakkunen: Cannot speak officially, but there is very high pressure for GPRS deployment, and thinks it will be deployed. Tsirtsis: This is for a good cause, but you could spend a lot of time trying to get ETSI to change existing standards, or work in the early days of something that isn't hard and fast yet, and the latter would be more effective. So IETF should even go beyond GPRS and be longer term. Suggestion is to go to UMTS instead. Comment: About the poor performance of GPRS, in normal GSM traffic, the occasional free slots in the TDM timeslotting scheme are retrofitted for GPRS. It performs so badly, because there is little allocation for it yet. Answer: Another reason why GPRS isn't attractive for the IPv6 over cell. Hakkunen: Some people are proposing the GPRS stack for UMTS. If IETF could convince UMTS people to use this solution instead, this would be most effective. Hinden: When I first saw the GPRS stack, I saw it as too complex too. However, it is not certain that this WG can have this work in its charter. Rather, it seems appropriate to ask the Internet ADs about looking at the whole IP over cellular media topic. Hinden took an action to bring it up to the Internet ADs. Perkins: Timing matters. Make a working group item related to this now would make it more real. Hinden: It's too late to affect GPRS. Hinden: Suggests this draft remain an individual submission. VIII. Preferred Format for Literal IPv6 Addresses in URLs - Hinden The major goal of the format is to make cut and paste of IPv6 literal addresses into browsers easy. The draft is browser focused - there are URLs in a lot of places and it is hard to fix parsing software everywhere. In the draft in its 01 version, the format is to enclose the literal address in square brackets. There have been implementations demonstrating feasibility in MS IE, Mozilla, and Lynx - these are not production implementations, but their coverage is good. Hinden would like to start WG Last Call for this to go to PS, continuing to omit the issue of literal support for non-browser uses of URL. But it is noted that the IPv6 service location protocol drafters may be able to use this too. Itojun: Is it legal to have a square bracket around a regular URL with FQDN? His implementation accepts finding square brackets there. Answer: We shouldn't require that it do. Draves: MSRIPv6 IE also accepts square brackets around the FQDN as an implementation byproduct. Comment: Every example has an explicit :80, why? Answer: This was just to show there would be no problem between the address use of ':' and the port use of ':'. Examples without the port will be included too. Itojun: please show examples with 3ffe in lower case, not only upper. Perkins: Service location protocol for IPv6 is done and is just waiting for this format to get settled. They will reference the draft. Narten: SLPv6 is not quite ready, because they need to include rules about server source address use when multihomed - these should be reviewed by IPNGWG. In fact, SLPv6 should become an IPNGWG document, because the SLP working group is trying to shut down. IX. Privacy Extensions for Stateless Address Autoconfiguration - Narten, IBM The constancy of the Interface ID could (in some cases) be used for tracking individuals, for instance when the device stays with the user, like a PDA. A server could tell when you were at home, office, travelling, based on the changing prefixes. The proposed extension for privacy is optional because it is not a concern for everyone. In particular, servers already have a permanent DNS name, so that is already an identifier for them. Also, many are used to having a stable IPv4 address, for instance because the DHCP spec encourages giving the same address. Finally, sites may want to be able to track use easily, and having nodes be able to become anonymous would be viewed as a cost to them. Solution requirements: - Interface identifier must change over time. - It does not need to be cryptographically random, just unpredictable to an outside observer. If there is stable storage, the draft provides an algorithm for creating a new IID, otherwise it is to be pseudo-randomly generated. The algorithm briefly is to append the IID to a 64-bit history value, compute the MD5 message digest, take the first 64 bits for the temporary IID, use the temporary as the next history value. Issues - How frequently to recommend changing? The initial approach is at each restart (system reboot). An assumption is that this is a client-only solution. A device that's both a server and a client may want to use the constant IID for server use and this stuff for its client communications. Then one has to get into source address selection issues. Should this be specified as for use in global addresses? Collision avoidance - in autoconfiguration now, DAD halts the process when a duplicate is discovered. But for privacy IID selection purposes, there should be a retry mechanism. Is it reasonable to assume that the IEEE identifier will remain private to node? If it is known already, the generation algorithm may be predictable. An observer on the same link will certainly know it. (Comment by someone: this is not for privacy on the same link). The alternative is not to use the constant IID as a seed. Avoiding using it is easy, assuming that systems can be expected to generate a pseudo-random number reasonably well. Comments - Crawford: Let people choose their own threat model and decide for themselves how often to take a dose of this privacy drug. On the other hand, when restart-based model is not used, some more problems arise: on changing IID without a restart, the system has to track addresses in use already, in open connections, and unlike prefix-changing, it does not get external cues (router advertisements) to start doing so. Perkins: Wonders why it is believed that the history list is simpler than trying to do a new random number each time. No need to overspecify: a default method for generating the privacy IID is not needed for interoperation. Also, with respect to the analogy to prefix-changing, note that address lifetimes are upper bounds - the system is free to stop using some prefix when it wants to. Answer: It may be hard to track upper layer users of addresses with the defunct IID, especially UDP. Afifi: For this to work, DHCP servers would need modifications, because clients are identified by their MAC addresses. Answer: If you are using DHCP, you have to generate a normal link-layer address, not use an anonymized one. Nordmark: Is it a privacy concern that DHCP servers know the constant IIDs of systems? Answer: DHCP is supposed to be trusted. Hinden: You may not trust a DHCP server you are visiting. Hinden: The draft will need revision. Narten: Could the WG comment on whether the simple first cut in the draft is enough. Draves: Would like to see it include reboot-less change that can be done more frequently. Others nod. Ahltorp: Who will get to use the IID when a duplicate is found? Answer: The original owner. Unlike with ARP, there is no problem that the cache could be corrupted. Question: But if it's a duplicate of a system that is temporarily down, especially of a server that cannot change? Answer: This case is okay, because the server should using an IID with the global-bit. Still, partition could cause problems for the DAD/retry. Comment: Make the random generation a good function, likelihood of collision low. Itojun: Definitely agrees that the frequency of change should be a choice of user. It's fine to change at reboot time, but give warnings about issues in reboot-less change. Comment: There is another case for needing to use both modes of address simultaneously. Many client-only systems will have to keep a stable address for the backward translation of name required by some servers (some telnetd's, smtpd's) and choose to use the private address only for applications without this constraint. Answer: The draft doesn't go into this case, because it is a bit of a rathole. For instance, how will applications decide? Draves: Have stable address be deprecated and private preferred? Answer: That doesn't help for the client-only two-mode case. Draves: It does help for server/client on one system case. Comment: It may be that DHCP must give out the private addresses because people are manually configuring addresses with the low-numbered IIDs such as ::1. It would be bad if there are collisions for those. They have local-bit set to true, so they are in same space as the generated private IIDs. Narten: Note that in the draft, the last thing that is done is to set the bit to local. Nordmark: DHCP also sets the bit to local, so there is the prospect of collision with DHCP-assigned addresses. Given the amount of space, it is not such a big collision risk, but maybe further structuring of the addresses could be considered. Answer: could consider getting an EUI prefix for these... X. Update to Advanced API - Erik Nordmark, Sun Since the time of the LA IETF, implementors have found it too complex, so the update simplifies it by providing less flexibility. A goal is to allow implementations to support both the old API (RFC2292) and this new API. The high order bits of changes between the RFC and this draft are summarized here: - Biggest change was to remove IPV6_PKTOPTIONS feature that set many options by recursion - it was not possible to know the behavior if one of many being set failed - did the others take effect anyway? Sticky options can now be set with individual setsockopt calls. - Added IPV6_RTHDRDSTOPTS to control DSTOPTS that show up before routing header, since can no longer control that with omnibus of IPV6_PKTOPTIONS. - Removed the ability to be able to specify HBH and DSTOPTS with multiple ancillary data items. Now application is responsible for formatting the whole extension header, so protocol stack does not have to guess the alignment restrictions etc. - Added separate IPV6_RECVxxx options to enable the receipt of the corresponding ancillary data items. Now the applications uses getsockopt to retrieve any sticky options it has set with setsockopt. - Clarified how and when TCP returns ancillary data items - it must when the content changes from one segment to another, but not necessarily on each data receive when the content does not change. These are not all the changes - see list in draft. Some TODO items are still extant: - Add mechanism to avoid fragmentation by sending at the minimum IPv6 MTU, for instance, this would be useful for a DNS server that does not want to do Path MTU discovery for a single reply. - Add MTU notification so that UDP apps can participate in PMTU discovery. This could be an ancillary data items received without any data, IPV6_PATHMTU, enabled with IPV6_RECV_PATHMTU. - Add reachability confirmation for UDP and raw socket apps to allow them to talk to Neighbor Discovery to defer NUD probes. This could be an ancillary data item for sendmsg with zero length called IPV6_REACHCONF. Due to shortage of time, the meeting was advised to look in the draft for the list of open issues. Implementors need to inspect this draft carefully. Is anything missing? The authors wants to do one more crank on it and then be done. Itojun: It is actually desirable that 2292 and 2292bis both be supported? If so, 2292bis should have words saying it is an addition. Answer: Do people need backward compatibility? Please speak up. The actual preference is that 2292bis should obsolete 2292, but it depends on the state of implementations. XI. Site Prefixes in Neighbor Discovery - Erik Nordmark, Sun Brief summary of the spec - Store site-local address in the DNS - RRset contains just site-locals if not connected, site-locals and globals if connected. Routers advertise the global prefixes for the site, typically as a /48 in the RA prefix options The resolver/getipnodebyname() filters the RRset - Test: one or more global addresses falls in site prefix - Exclude site-locals if not true The draft is 03. Changes since previous draft include: format change in option to make better fit with Router Renumbering; change the rules about suppressing global addresses returned from DNS to suppress only those that match the global prefixes received from the RAs; refine the text to handle case when DNS has only site-local addresses in it (in a non-connected site). Defined multi-sited nodes (with a single domain name) and tried to flesh out options in this case; specified that multi-sited nodes can use the site-local listings of only one site - a multihomed node must have a different domain name for each site if it wants to use site-local addresses in all its sites. For more additions and details, see the draft. There was a shortage of time for the presentation. The text was changed to reference AAAA/A6 instead of AAAA. But should it refer just to A6? Open issue - should the protocol advertise a human-readable name for each site? Deering has suggested this for multicast scopes in the past, as something useful for application user interfaces. (For instance, a user could be asked whether she wanted campus or office). It would be possible to add an ND option for the human-readable site name. Next steps: Get the basic rule (that all implementations, including those that do not implement ND site-local extensions, ignore site-locals received in the DNS RRset) into the implementations. The presentation ran out of time as the meeting time ended, so the request was made that discussion start on the mailing list about what the progress should be for this draft. Thursday, July 15 ----------------- Hinden announced (following from an announcement by Mike Roberts, temporary president of ICANN, at the IETF plenary the night before) that IANA has officially made the first delegation of IPv6 sub-TLAs to the Regional Internet Registries - we're not done, but this is another important step. The second session of IPNGWG was dedicated to multihoming. There was one item left over from the first session agenda, to be covered very quickly: XII. IPv6 Inverse Neighbor Discovery - Thomas Narten, IBM This is a document by Alex Conta that started in the ION WG. The IESG thought it needed more work after ION sent it to them following their WG last call. It was specified as a Frame Relay-related standard , but Narten pointed out that the Inverse ND is more general than its FR application, so Alex moved the FR-specific stuff into an Appendix, leaving the generic ND material in the main text The WG is requested to comments on it to Alex as soon as possible and an IPNGWG Last Call is requested to take place a few weeks following Oslo. Multihoming Agenda XIII. Overview of IP(v6) Multihoming Issues- Deering, presented by Rich Draves, Microsoft Research The agenda and starting points for this WG discussion were developed by a small design team put together by the WG chairs, which met or teleconferenced several times in June. It was emphasized that the design team results have no special status, but just were to serve as starting point for WG discussion Multihoming issues arise: Node Site There are pretty close analogies between the node and site cases. Note multihoming is dynamic - hosts, sites can acquire or lose addresses - can be multihomed for an interval. Multihoming issues are not new with IPv6, but the host ones are more prevalent or maybe more of an issue with IPv6 because of its support for multiple addresses per interface, for multiple scopes, for renumbering, and for transition scenarios introducing new interfaces, such as 6to4. Sites are equally likely to be multihomed in IPv4 or v6, but IPv6 may introduce the situation that sites are to get/use a different prefix with each ISP, rather than punching holes. Issues of - - Multiple Addresses for a Node: choice of source address, apps that use addresses as peer identifiers. - Multiple Interfaces for a Node: same issues, plus others such as that redirect only works if the sender uses the addresses of the outgoing and not those of other interfaces. Load-sharing across interfaces becomes possible, may or may not be desired. - Multiple Prefixes for a Site: policy-based preferences for using one prefix or not. - Multiple Attachment Points for a Site: will need to use right attachment - some of this is the domain of routing protocols, but not entirely. Load-sharing may be desired. How to receive packets for prefix of one attachment when it is down, but another is up. If ISP is doing ingress filtering, definitely need to choose prefix for source address that matches attachment being used. This is an incomplete list of the many issues. Not all of these need to be resolved by the WG now, as we have lived with them in IPv4 for a long time. Figure out the key ones. Generalized Host Multihoming - Hosts may have multiple local addresses (LA) and local interfaces (LI), and hosts may peer with multiple remote addresses (RA). For each triple chooses a particular path. There's a range of possible capabilities: - At session initiation time, for instance, TCP connect, choose the triple most likely to work (e.g. longest prefix match) - Try multiple triples/paths till one works - Iterate them over multiple sessions - Try them all and measure somehow which one is best - Keep history/experience - For an ongoing session, detect failure of current path and move - For an ongoing session, detect availability of a better path and move - Spread session traffic across multiple paths Later presentations will go into detail of proposed solutions chosen from above space. Different Models for Multiple Interface These were discussed as outgoing, but each has a version for incoming too: - Strong: the source address MUST belong to the originating interface - Semi-strong: the source address SHOULD belong to the originating interface - Weak: the source address MAY belong to any interface of the originating host Another take on these models is to consider whether the stack can choose the interface to use freely or not, when the application has picked the interface it wants to use. Advantages of Different Models The weak model has is simpler to implement because you go into the routing table and just get whatever match to the destination address is found. The strong model requires constraining what you can take from routing table. In IPv6, implementations already have this problem/ feature of routing-table lookup to some extent because of the presence of scoped addresses, so the semi-strong model looks promising intrinsically. Additional Near-Term Point - Consider using RFC 2260 - see Itojun's presentation to follow this. IPv6 Features for (Future) Use in Resolving Multihoming Issues - Globally-unique Node ID - e.g. when the interface ID is autoconfigured using an Ethernet MAC address, with bit indicating it is globally unique. The bit was added to the IID field to give potential for future transports to use the IID alone for transport control block lookup. - Router Renumbering - border routers can feed prefixes to the routers within the site, and it could be used to control what prefixes are used. - Use of Site-Local Addresses - to give intra-site communications immunity from external multihoming effects. - Exchange-based Addressing - assign a single TLA to a set of interconnected ISPs, and do flat routing among customers of exchange. Pros: multihomed sites can have a single prefix across their multiple attachments; also, sites avoid renumbering when they change ISPs. The standard IPv6 address architecture has the capability of doing this. Conclusions Do a few simple things now. Keep the WG focus on: - Heuristics for source and destination address selection - Some aspects of trying multiple paths - RFC 2260 And provide a host architecture that can evolve to support better multihoming support in the future. Multihoming will continue to be a rich source of problems. This presentation and the next two presentations are meant to be one group's contribution to the WG discussion. Comments - Perkins: Multihoming issues have come up in mobility. IPv6 must decide whether use careof or home address. Some Stanford University work developed the concept of a mobility address policy table, which seems as if it would be generalizable. How the table was populated was for future study. A pointer was sent to the mailing list. Hinden: From some points of view, mobility is another class of solutions for multihoming. Perkins: People should consider Erik Nordmark's presentation to mobility WG with implicit tunnels. Narten: But note the main focus of the ideas from our design team is not what happens when connection is already up and something happens, but rather what happens at the outset of connections. XIV. Multihoming: RFC2260 Approach - Jun-ichiro Hagino (Itojun), Research Laboratory, Internet Initiative Japan Focus is on multihoming support that is possible now. This talk covers the router stuff: Goal is to try to deliver packets of any (source, destination) during failure of one or more of the site exit links IPv4 uses portable addresses so that prefixes of one provider can be advertised out of another provider's attachment point. In IPv6, the portable address concept is not there, and advertisements should be more restricted. The next talk by Rich Draves will be about end2end stuff: Goal is to try to find the best (source, destination) on connection establishment, and perhaps in more advanced phases, to switch to a better (source, destination) during the course of a connection. RFC2260 One of the approaches in RFC2260 guarantees no extra routing announcement to outside and is friendly with IPv6 aggregation policy. Sites get ISP-provided addresses from multiple ISPs and are assumed to route them locally. For IPv4, the assumption is that a site has a region for each ISP's addresses, and routing exchange within the site for communication without going outside. IPv6 is different in making it easy for every end host to get addresses from each of the ISPs if that is desired. Let there be a site with a blue ISP and a red ISP, with the red site border router advertising the red prefix into the red ISP and the blue site border router advertising blue prefix into the blue ISP. and the internal routing stated above. Next: establish an IP in IP tunnel from the blue site border router to the red ISP border router and vice versa. In the stable state: announce the blue prefix from the red-to-blue tunnel endpoint in the blue ISP router. When the blue-blue link fails, so that the stronger route advertising the blue prefix into the blue ISP has failed, only then will the tunnel backup route be used and the blue prefix traffic will tunnel to and from the red site border router. There will be no advertisement of the blue prefix by the red ISP, so aggregation is not broken. IPv6 Extensions of RFC 2260 - - Address assignment: the two (or more) ISP prefixes could be assigned in separate regions of the site, as in IPv4, or throughout the site, or a combination of some mixed regions and other distinct regions. - Packets can survives ISP filters - use RFC2260 in reverse direction and site router tunnels the packet (source routing might be needed?). Scalability in a Very Large Site - Do not try to make a full-mesh configuration of tunnels, because it's too much mess. In an example where it's easy to see the suitable partial mesh: the two ISPs of the site portion located in Japan back each other up, the two ISPs of the site portion located in the US back each other up, but there is no backup between the countries. Conclusions - RFC 2260 is a good base for IPv6 multihoming - it is aggregation-friendly and does not encourage use of portable addresses. It is an operational solution - no change to protocol code. Will ISPs be able to do 2260? Some BGP gurus in Japan have said they find it feasible. Scalability - guideline document needed. Note - Dupont draft talking about RFC 2260 should be reviewed. Comments - Dupont: About 2260 in general, it is complex to set it up, and it is hard to find the expertise for running it. Many ISP policies are prohibitive of it. Finally, it does not help at all if the provider border router goes down, only if the link goes down. So 2260 is more than nothing, but not very capable. Itojun will try in his home. Mankin: we should set up some trials on the 6bone. Hinden: This is one tool for multihoming, but not a complete handling of the issues. Note that link failures are more common that router failures. Dupont: in the context where the exit router on the site is the ISP border router (belongs to the ISP), then a link failure amounts to an ISP router failure and is not cured by 2260. Nordmark: What about the potential for distributing the injected route with IBGP as in 2260? Comment: One could have a concern with AS number space consumption being increased by multihoming and 2260 does not help with that. Itojun: It would be possible to do something with another routing protocol than BGP. Tsirtsis: It sounds good to combine 2260 with router renumbering as the earlier presentation said, so that when the link fails (or the router fails), nodes are told to change prefix. Itojun: Still RFC 2260 is a good starting point XV. Design Team's Proposal for IPv6 Multihoming - Rich Draves, Microsoft Research Goals - Support multihomed sites - Remove temptation to break the provider addressing plan and aggregation - more scalable routing is something IPv6 has to come through with. - Site availability is a key requirement. - Maintaining existing connections is a bonus, but not crucial - making sure new connections can be established goes very far. Business- critical apps are designed to be able to restart after a broken connection and otherwise recover if TCP breaks. - Helping multihomed hosts deal is also a bonus, but is not as critical an issue as making multihomed sites work properly. Changes should be kept minimal changes - not rock boat - No protocol changes - No TCP/UDP implementation changes - No API changes - No application changes. Ideally nobody would have to do anything and we'll fix these issues :) Finally an evolvable solution is needed. Grand Outline Phase 1 - required work for WG - RFC2260 approach - Source address selection - Destination address ordering Phase 1.5 - is this required? - TCP tries multiple source addresses Phase 2 - future work? - Additional APIs, e.g. connect to a DNS name - Centralize destination/source address selection (DNS...) Phase 3 - definitely in future - Adjusting paths after probing Phase 1 - Required Work on Source Address Selection Using longest-matching prefix. Getipnodebyname - ordering of destination addresses returned by DNS leads to source address selection in IPv6 stack. Pluses, Minuses, Questions: +Minimal changes +Scope/prefix matching - local, site, both of you have addresses from ISP A. ? Incorporate TCP feedback - to influence future decisions. - Does not try all pairs - for each destination, will only choose one column - Apps are responsible for any probing of the multiple destination addresses - some already do, but most don't - Another drawback is the need for feedback from the application to know when communication is successful, so a UDP without feedback can't tell you an address is ok ? Big timeouts during trying list ? Because of having decentralized the source/address selection, it is harder for administrators to insert their own controls Why Not Just Use RFC2260? - It doesn't help you find common scope/prefix - It doesn't help multihomed hosts, whereas the above architecture does help some - It doesn't deal with ISP/router failures, just ISP/link failure - Using a tunnel is inefficient - ISPs are willing? As far the design team could find out (admittedly not having searched exhaustively), none have implemented or tried using RFC2260. It is an extra burden. And why should an ISP help you to use another ISP? Why Not Use Address Selection/Ordering Only and Not RFC2260? Consider: Site 1 connected to ISP A and ISP B, Site 2 only connected to ISP A Site 1 has node with address 1a, 1b, Site 2 has node with address 2a Site 1 will want to use 1a to talk to Site 2. If the link between Site 1 and ISP A fails, then when it uses ISP B to initiate a TCP connection to Site 2, it fails. Question - Zill: Why not use routing headers? Answer: The team thought about doing so and it has possibilities. The use of router renumbering cited by Dupont and others also has possibilities. Phase 1.5 - is it required? TCP tries multiple source addresses - it would be necessary to work out the details. It would be an implementation change, not a change to the protocol. RFC2260 would not be needed for basic availability. All destination/source address pairs would get tried, but there would be a tendency for them to be tried in the wrong order because connect would choose one at a time of one's own interface prefixes at a time - trying <1a-2a> <1a-2b> instead of <1a-2a> <1b-2b>. Comments - Dupont: You could fix this with a new ICMP message to say change source address. Answer: This would require more work from the router, having to look at the source addresses being used - team talked about it, but... Crawford: It wouldn't work for this case anyway. Phase 2 - Future Work? Stack maintains host cache database DNS-based API - TCP: connect (DNS-name) - UDP: connect (DNS-name) - this would return to the applications a sorted list of destination/source pairs - UDP/etc: Would need an API addition to do update-database. This is because the stack can't tell if communications are working (even the app may not know). This is why the UDP:connect gives the application back a list of address pairs. Phase 3 - Definitely Future Work - Builds on the host cache database - Modify TCP for survivability, renumbering - security? - NUD-like probing for best destination/source pair - would have to control the overhead and load on this? An application could be willing to pay with some extra packets for large gain of a better path. Phase 1 Detailing: Source Address Selection Draft - 01 - Only applies when application has not specified source address - Define candidate set of source addresses, define pair-wise source address comparison - Always attempts communication using some source address - an alternative philosophy would be to fail in some cases, e.g. your peer has a global address but you have no global source address available. Philosophy in draft is to try anyway, because it might work and if so, it's better than nothing. Cases when you don't have appropriate scope address are probably due to misconfiguration. To fix the problem, administrator may need to be able use the communication. Nordmark: You can make the case especially in multicast, because peers may actually be on your link, and you have no way to know. Answer: This can be true in unicast too, for instance, you may have only a global for someone on your link. Nordmark: unlike in the multicast case, that can only be due to misconfiguration. Candidate Source Address Set - Do routing lookup, take all addresses of interface - RECOMMEND just using addresses assigned to outgoing interface, but permit use of addresses assigned to other interfaces (depending on the kind of peer - when talking to a routing peer, you MUST use an address belonging to the interface). - Question to WG - Under what circumstances (if any) should we allow use of addresses not assigned to the sending interface? Maybe if all prefixes on the sending interface are deprecated? Source Address Comparison - Series of tie-breakers: scope, preferred/deprecated, longest-matching-prefix - Scenario A. Global destination address - pick from 1. link-local source address or 2. deprecated global source address... - Scenario B. Site-local destination address - pick from 1. deprecated site-local source address or 2. preferred global source address. - Answers in draft now A.2, B.2 - Deering and Hinden school of thought is never to use a deprecated source address if you have any alternative. A answer would be 1. Hinden: Rationale is that site-local meant you were not supposed to communicate outside your site or else there was an error so that you didn't get your new global prefix. If you start the connection with the deprecated address, the site administrators won't find out about the mistake quickly. Draves: That's one school of thought. The alternative view is that the administrator who made the mistake may need ability to use the deprecated to be able to fix the screw-up. Hinden: let those administrators use a telnet that allows you to pick your choice of source address including breaking these rules. Elz: Don't forget these rules are only deals for when the application doesn't choose its own source address. You need some apps to be able to do this. Destination Address Ordering No draft yet - Try address with smallest scope first. - Try addresses that have longest possible match with a potential source address, if there is a choice within scope. - Don't unnecessarily perturb the DNS order. If you imagine this as a sort, you want it to be like a stable sort, so if you have a tie, you don't change the order. - Avoid extra system calls in the common case, cache in system library, so as not to have multiple calls down into stack for all those addresses. Discussion of scopes and destination address choice Elz: going to write a draft where DNS only returns highest scope and nodes when they connect algorithmically create smaller scope to use. If packet gets through and you have a site-local response back, then change to site-local. You can do this independent of what application requests. Draves: Some dangers, including that it would add latency. Elz: Would only add small amount if site is not too big a thing. Nordmark: Version 00 of the site-local draft had something like this, but it provides less administrative control, for instance you don't have option of leaving out the site-local address entries from the DNS for nodes you know are frequently mobile. You might want to have that admin control. Elz: Mobile IPv6 has arranged for site-local addresses to work. Anyway, will write up his draft. The Grand Outline discussion was consensus of the design team - Phase 1 solves the most pressing problems. Discussion - Dupont: TCP survivability/renumbering is entirely solved by mobility mechanisms. Narten: Have to disagree, because with mobility, you know when you've moved, but when a link goes down, or something other than router advertisements cause a new prefix to be needed, it is not as clearcut for the sender to know. The change is harder. Dupont: Have implemented it. It works. Carpenter: Change term renumbering to something like prefix migration - your home address is what's going to disappear at the end of the prefix migration. Nordmark: If we'd have done Phase 2 two years ago, it would have been phased in with the new API, but there are perhaps enough people porting applications now, that the Phase 2 API could not be included in some implementations. miss some. Hinden: This isn't an advanced API, it's more basic than basic. Itojun: There are already many applications using the basic API, so please don't drop it. Cheshire - MacOS connects using DNS names and it works fine - AF-DNS family name Carpenter: It would be nice because it's a fairly concrete interpretation of having APIs with a level of abstraction from network layer. Good news because architecture justified, bad news if it carried along some delay. Hinden: It might be good that we don't standardize APIs. Status - The source address selection draft is out there for working group review. XVI. Next Steps / Bob Hinden Hinden summarized the discussion to focus on some next steps/actions. No voices said not to do Phase 1 - so the next step is either to add to the source selection document to include destination ordering as well, or make a new document for it. Action - Continue source/destination selection draft(s). Heard fairly strongly that there is value in doing Phase 2 - the DNS-based API part. We could do something very simple and use it to get experience. This doesn't break any existing applications and not all applications have been ported to IPv6. Also we would hope IPv6 encourages some new applications, so even if the all ports are done, here are new users of APIs to come. Action - Start Simple IPv6 API Crawford: An addition to this would be to use SRV records to find out the ports too. Some negative responses to this from the room. Action on 2260 - Next step is to have serious conversations with ISPs and routing experts - maybe there are serious reasons on their part not using it. To the design team's not very broad knowledge, it has not been implemented. Elz: Note the two ways to talk to ISP: saying something would be technically nice to do versus saying there are tens of millions in it for them if they do it. Provided a few well-heeled subscribers demand RFC 2260, it will be thereafter be provided everyone. Nordmark: ISPs often don't like tunnels because of issues with transit or non-transit. They are known not to like 6bone tunnels. Action - Investigate RFC2260 - Get more ISP opinions - Consult routing experts - Conduct 6bone tests Carpenter: Randy Bush said RFC 2260 has not been used in IPv4 because it is too complex. This could be a chicken-and-egg problem. Hinden: Things do change, this is the Internet after all Shand: Did a draft on this sort of topic 3-4 years ago. He will look and see if it has any interesting ideas to revive. Dupont: A lengthy draft on this stuff was just revived by NGTRANS. It should be moved to IPNGWG. XVII. Interim Meeting It would be useful to have an interim meeting focused on multihoming. When - last week in September is one thought of chairs. A question is whether it would be good to have it adjacent to an IPv6 Forum meeting? Carpenter: Consider whether or not to broaden scope to prefix migration (renumbering) in general - got clear message from ISPs in context of last week's workshop. Hinden: good idea. Others concur. Carpenter: Prefix migration was Mike O'Dell's phrase, by the way. Fink: Adjacency to IPv6 Forum meeting does not have strong value to our community. Blanchet: First one is just between NANOG and Internet2 members' meeting anyway. Nordmark: How many went to IPv6 Forum meetings this week? Hinden: They were for limited invitees, and not advertised. Hinden: Please send a message to chairs if you can host the interim meeting and when you can host it. Fink: Suggest not broaden scope too much, e.g. to include an NGTRANS meeting, because this would dilute the ability to get things done. Looking at some of the transition mechanisms, it may prove a good idea to have interim specific narrow micro-working groups for making NGTRANS progress. -------------------------------------------------------------- Meeting Adjourned -------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 17:49:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA01903 for ipng-dist; Tue, 10 Aug 1999 17:47:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01896 for ; Tue, 10 Aug 1999 17:47:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA04917 for ; Tue, 10 Aug 1999 17:47:32 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09639 for ; Tue, 10 Aug 1999 18:47:31 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id UAA05824; Tue, 10 Aug 1999 20:47:30 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000022008; Tue, 10 Aug 1999 20:47:29 -0400 (EDT) From: Jim Bound Message-Id: <199908110047.UAA0000022008@quarry.zk3.dec.com> To: Cyndi Jung cc: Richard Draves , "'Brian E Carpenter'" , David Borman , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of "Tue, 10 Aug 1999 15:17:25 PDT." <3.0.2.32.19990810151725.00904880@mailhost.ewd.3com.com> Date: Tue, 10 Aug 1999 20:47:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cyndi, >A very compelling argument for the DF bit to MUST NOT be set. >Thanks - I feel quite confident about it now. I felt Dave and Sowmini's arguments were more compelling that the above should be SHOULD NOT. Rich provided a good sophist argument which attempts to reduce the need of the DF bit, but does not address the issue that it could be used and useful for the future. Hence, all logic and 23 years of engineering experience and shipping products tells me I would rather have it be SHOULD NOT in case we have to use it. I think we need to be a bit liberal here rather than conservative. As far as implementations there is only one and I think its just a research effort? But if its not I would be glad to be wrong. I know Francis is working on it now, and would really like to hear Francis's view on this too? p.s. Also Sowmini and Dave are engineers working on IPv6 products and in Dave's case his group has shipped a real IPv6 product. So that counts more for me too, if this is just to pare down to philosophy and logic. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 17:58:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA01934 for ipng-dist; Tue, 10 Aug 1999 17:55:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01927 for ; Tue, 10 Aug 1999 17:55:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA26721 for ; Tue, 10 Aug 1999 17:55:09 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13614 for ; Tue, 10 Aug 1999 17:55:09 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id UAA06145; Tue, 10 Aug 1999 20:55:08 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000003954; Tue, 10 Aug 1999 20:55:08 -0400 (EDT) From: Jim Bound Message-Id: <199908110055.UAA0000003954@quarry.zk3.dec.com> To: Cyndi Jung cc: Jim Bound , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of "Mon, 09 Aug 1999 16:38:04 PDT." <3.0.2.32.19990809163804.0091fabc@mailhost.ewd.3com.com> Date: Tue, 10 Aug 1999 20:55:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cyndi, >2365 is not a protocol - it is a "best common practise", an agreement >on the division of the class-D address space into scopes. The part >that does work already is organization-local, because IP multicast works >already within an organization - it is the global scope, the inter-domain >part, that is still a mess. Fortunately, organization-local scope >multicast addresses do not require global coordination like the >global scope addresses do - they are sort of a "net10" of the class-D >address space. I think my point was missed and I let it go in my last response to this but decided to put a bit more energy into this specific issue: In rfc2529: >6. Address Mapping -- Multicast > > IPv4 multicast MUST be available. An IPv6 packet with a multicast > destination address DST MUST be transmitted to the IPv4 multicast > address of Organization-Local Scope using the mapping below. These > IPv4 multicast addresses SHOULD be taken from the block > 239.192.0.0/16, a sub-block of the Organization-Local Scope address > block, or, if all of those are not available, from the expansion > blocks defined in [ADMIN]. Note that when they are formed using the > expansion blocks, they use only a /16 sized block. > > +-------+-------+-------+-------+ > | 239 | OLS | DST14 | DST15 | > +-------+-------+-------+-------+ > > DST14, DST15 last two bytes of IPv6 multicast address. > > OLS from the configured Organization-Local > Scope address block. SHOULD be 192, > see [ADMIN] for details. > > No new IANA registration procedures are required for the above. See > appendix A. for a list of all the multicast groups that must be > joined to support Neighbor Discovery. If I send a 6over4 packet to 239.OLS.DST14.DST15 (above) will the multicast router implementations today forward that packet past the IPv4 subnet the message went out on based on the administrative scoping suggested in 6over4 via rfc2365.txt. If not what is the point of putting this mechanism into my IPv6 product today, vs other items on the plate, if it can't be used. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 18:17:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA01967 for ipng-dist; Tue, 10 Aug 1999 18:13:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01960 for ; Tue, 10 Aug 1999 18:13:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA28309 for ; Tue, 10 Aug 1999 18:13:39 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19322 for ; Tue, 10 Aug 1999 18:13:38 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id VAA07113; Tue, 10 Aug 1999 21:13:36 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000005160; Tue, 10 Aug 1999 21:13:35 -0400 (EDT) From: Jim Bound Message-Id: <199908110113.VAA0000005160@quarry.zk3.dec.com> To: Terry Lambert cc: Masataka Ohta , crawdad@fnal.gov, ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of "Tue, 10 Aug 1999 17:31:11 PDT." <37B0C44F.65F3C061@whistle.com> Date: Tue, 10 Aug 1999 21:13:35 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Terry, I agree with you except for the very last paragraph you sent as that has some limitations though I agree and understand. Even that has a test of reasonability in the market place regarding standards. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 18:40:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA02002 for ipng-dist; Tue, 10 Aug 1999 18:37:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01989 for ; Tue, 10 Aug 1999 18:37:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA00358 for ; Tue, 10 Aug 1999 18:37:03 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25764 for ; Tue, 10 Aug 1999 18:37:02 -0700 (PDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id VAA02501; Tue, 10 Aug 1999 21:37:01 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id VAA0000849978; Tue, 10 Aug 1999 21:37:00 -0400 (EDT) From: Jim Bound Message-Id: <199908110137.VAA0000849978@anw.zk3.dec.com> To: Brian E Carpenter cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing In-reply-to: Your message of "Mon, 09 Aug 1999 11:49:08 CDT." <37AF0684.5355455F@hursley.ibm.com> Date: Tue, 10 Aug 1999 21:37:00 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, In the interest of doing something very cool with IPv6 that cannot be ported to as quickly or as efficiently with IPv4 for a moment I will concede that we need src/dst address compares for src addr selection given the following caveats from the recent technical discussion on this subject thread. This is a postualte OK. I still think we need to verify the performance implications and provide an implementation scenario which I have now done offline to support this. At the end I also give you a suggested fix for the two-way connectivity problem for 6to4 if this was not done or is deployed before vendors can add it to IPv6 product efforts in process now for the wave of releases of IPv6 products where we would like to support 6to4. src/dst caveats for disucssion: The src/dst address match algorithm would be a knob that SHOULD be implemented by any node supporting multiple prefixes on an interface, OR is multihomed. The src/dst address match algorithm would be a knob not have to be turned on when a node does not support the two premises above (multiple prefixes or multihomed). If a node exists in a DNS implementation where the server orders the addresses returned for load balancing or some other reasons then the node should realize using the src/dst match algorithm knob will most likely result in the order provided by the DNS server as null and void. If a node has an application that selects the src address (not considering the src/dst address algorithm) then the result to the src/dst address match algorithm behind getipnodebyname or getaddrinfo may be voided when the packet is sent to the stack in the kernel. Thoughts? Fix for 6to4 Two-Way-Connectivity Issue: The fix for 6to4, if the src/dst match was not deployed is to state in 6to4 that all nodes must support in the kernel (use better words here but I mean in the stack where the src addr is selected), "A 6to4 implementation, if src/dst match is not supported, MUST check that a TLA624 prefix src is used to send a packet to a TLA264 dst address.". Also we need a health warning in 6to4 that if an application sends to a 6to4 prefix and selects its own src address it two-way-connectivity may be lost in 6to4. This will apply even if src/dst match is implemented. Comments? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 19:09:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA02035 for ipng-dist; Tue, 10 Aug 1999 19:06:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02028 for ; Tue, 10 Aug 1999 19:06:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA09569 for ; Tue, 10 Aug 1999 19:06:07 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA03202 for ; Tue, 10 Aug 1999 19:06:06 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id SAA01895; Tue, 10 Aug 1999 18:58:37 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id SAA12956; Tue, 10 Aug 1999 18:58:37 -0700 (PDT) Received: from tellurium (usr-modem30.nsd.3com.com [129.213.205.150]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id SAA00381; Tue, 10 Aug 1999 18:58:34 -0700 (PDT) Message-Id: <3.0.2.32.19990810185548.01390788@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Tue, 10 Aug 1999 18:55:48 -0700 To: Jim Bound From: Cyndi Jung Subject: Re: RFC 2529 (6over4) Cc: Richard Draves , "'Brian E Carpenter'" , David Borman , ipng@sunroof.eng.sun.com In-Reply-To: <199908110047.UAA0000022008@quarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Maybe I read what I wanted to read in what Richard wrote - that the IPv4 MTU between pairs of neighbors on a 6over4 subnet would not be a constant value, and in order to ensure that no V6 packet is dropped because the V4 header had the DF bit set, the routers would need to determine the minimum V4 MTU between all pairs (information they might not be able to acquire) or some person would need to manually configure that number into the router so that it could advertise it to all the nodes via the RA. Sounds like a pain either way - do we have some fundamental distrust of V4 fragmentation/reassembly going on here? It is always available, why not use it? Cyndi At 08:47 PM 8/10/99 -0400, Jim Bound wrote: >Cyndi, > >>A very compelling argument for the DF bit to MUST NOT be set. >>Thanks - I feel quite confident about it now. > >I felt Dave and Sowmini's arguments were more compelling that the above >should be SHOULD NOT. Rich provided a good sophist argument which >attempts to reduce the need of the DF bit, but does not address the >issue that it could be used and useful for the future. Hence, all logic >and 23 years of engineering experience and shipping products tells me I >would rather have it be SHOULD NOT in case we have to use it. I think >we need to be a bit liberal here rather than conservative. > >As far as implementations there is only one and I think its just a >research effort? But if its not I would be glad to be wrong. >I know Francis is working on it now, and would really like to hear >Francis's view on this too? > >p.s. Also Sowmini and Dave are engineers working on IPv6 products and in >Dave's case his group has shipped a real IPv6 product. So that counts >more for me too, if this is just to pare down to philosophy and logic. > >/jim > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 19:22:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA02079 for ipng-dist; Tue, 10 Aug 1999 19:16:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02072 for ; Tue, 10 Aug 1999 19:16:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA25782 for ; Tue, 10 Aug 1999 19:16:42 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA05808 for ; Tue, 10 Aug 1999 19:16:42 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id WAA10260; Tue, 10 Aug 1999 22:16:41 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000002471; Tue, 10 Aug 1999 22:16:40 -0400 (EDT) From: Jim Bound Message-Id: <199908110216.WAA0000002471@quarry.zk3.dec.com> To: Cyndi Jung cc: Jim Bound , Richard Draves , "'Brian E Carpenter'" , David Borman , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of "Tue, 10 Aug 1999 18:55:48 PDT." <3.0.2.32.19990810185548.01390788@mailhost.ewd.3com.com> Date: Tue, 10 Aug 1999 22:16:39 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Maybe I read what I wanted to read in what Richard wrote - that the >IPv4 MTU between pairs of neighbors on a 6over4 subnet would not >be a constant value, and in order to ensure that no V6 packet >is dropped because the V4 header had the DF bit set, the routers >would need to determine the minimum V4 MTU between all pairs (information >they might not be able to acquire) or some person would need to manually >configure that number into the router so that it could advertise it to >all the nodes via the RA. The packet should not get dropped but an ICMP Packet Too Big should be generated and 6over4 should deal with it via PMTU discovery. >Sounds like a pain either way - do we have some fundamental distrust of >V4 fragmentation/reassembly going on here? It is always available, why not >use it? Yes of course its bad for ones network health. See Jeff Mogul paper on this subject (I don't have a pointer off the top of my head but if you want to read it I can find it). Also we disallowed it in IPv6 except end-to-end routers don't fragment in IPv6. /jim Cyndi At 08:47 PM 8/10/99 -0400, Jim Bound wrote: >Cyndi, > >>A very compelling argument for the DF bit to MUST NOT be set. >>Thanks - I feel quite confident about it now. > >I felt Dave and Sowmini's arguments were more compelling that the above >should be SHOULD NOT. Rich provided a good sophist argument which >attempts to reduce the need of the DF bit, but does not address the >issue that it could be used and useful for the future. Hence, all logic >and 23 years of engineering experience and shipping products tells me I >would rather have it be SHOULD NOT in case we have to use it. I think >we need to be a bit liberal here rather than conservative. > >As far as implementations there is only one and I think its just a >research effort? But if its not I would be glad to be wrong. >I know Francis is working on it now, and would really like to hear >Francis's view on this too? > >p.s. Also Sowmini and Dave are engineers working on IPv6 products and in >Dave's case his group has shipped a real IPv6 product. So that counts >more for me too, if this is just to pare down to philosophy and logic. > >/jim > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 19:24:03 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA02090 for ipng-dist; Tue, 10 Aug 1999 19:22:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02081 for ; Tue, 10 Aug 1999 19:22:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA04310 for ; Tue, 10 Aug 1999 19:22:24 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA07233 for ; Tue, 10 Aug 1999 19:22:24 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id TAA04455; Tue, 10 Aug 1999 19:16:02 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id TAA15673; Tue, 10 Aug 1999 19:16:01 -0700 (PDT) Received: from tellurium (usr-modem30.nsd.3com.com [129.213.205.150]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id TAA00577; Tue, 10 Aug 1999 19:16:00 -0700 (PDT) Message-Id: <3.0.2.32.19990810191313.007521ac@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Tue, 10 Aug 1999 19:13:13 -0700 To: Jim Bound From: Cyndi Jung Subject: Re: RFC 2529 (6over4) Cc: Jim Bound , Brian E Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: <199908110055.UAA0000003954@quarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >If I send a 6over4 packet to 239.OLS.DST14.DST15 (above) will the >multicast router implementations today forward that packet past the IPv4 >subnet the message went out on based on the administrative scoping >suggested in 6over4 via rfc2365.txt. Yes - they will forward it to all subnets towards all members of that group 239.OLS.DST14.DST15 on the 6over4 subnet. This means, to receive NS frames, the V6 node with V6 address ending in DST14.DST15 must join the V4 group 239.OLS.DST14.DST15, then for all the IP multicast routing protocols I know of (DVMRP, MOSPF, CBT, PIM), any NS packet sent by another system will get delivered to that node. If the admin scoping is not enforced, then these V4 multicast addresses would get forwarded further than you might want, rather than not forwarded. It is the 224.0.0.X class-D addresses that do not get forwarded past the subnet they were transmitted on. Does this help? Cyndi > >If not what is the point of putting this mechanism into my IPv6 product >today, vs other items on the plate, if it can't be used. > I think that without scoping these become global, though I think that the current MBONE rules will at least confine this to your intra-domain. The issue of non-enforcement within your intra-domain means that you can have only one 6over4 subnet, and I think that at the point where you have so many systems on it that you want to break it into multiple 6over4 subnets, you can probably "go native". Cyndi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 19:47:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA02159 for ipng-dist; Tue, 10 Aug 1999 19:44:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02143 for ; Tue, 10 Aug 1999 19:43:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA27855 for ; Tue, 10 Aug 1999 19:43:53 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA08622 for ; Tue, 10 Aug 1999 20:43:53 -0600 (MDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id TAA07856; Tue, 10 Aug 1999 19:37:13 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id TAA19160; Tue, 10 Aug 1999 19:37:13 -0700 (PDT) Received: from tellurium (usr-modem30.nsd.3com.com [129.213.205.150]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id TAA00966; Tue, 10 Aug 1999 19:37:10 -0700 (PDT) Message-Id: <3.0.2.32.19990810193424.0070595c@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Tue, 10 Aug 1999 19:34:24 -0700 To: Jim Bound From: Cyndi Jung Subject: Re: RFC 2529 (6over4) Cc: Jim Bound , Richard Draves , "'Brian E Carpenter'" , David Borman , ipng@sunroof.eng.sun.com In-Reply-To: <199908110216.WAA0000002471@quarry.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:16 PM 8/10/99 -0400, Jim Bound wrote: > >>Maybe I read what I wanted to read in what Richard wrote - that the >>IPv4 MTU between pairs of neighbors on a 6over4 subnet would not >>be a constant value, and in order to ensure that no V6 packet >>is dropped because the V4 header had the DF bit set, the routers >>would need to determine the minimum V4 MTU between all pairs (information >>they might not be able to acquire) or some person would need to manually >>configure that number into the router so that it could advertise it to >>all the nodes via the RA. > >The packet should not get dropped but an ICMP Packet Too Big should be >generated and 6over4 should deal with it via PMTU discovery. It still sounds painful, when the mechanisms are there to handle it in IPv4. > >>Sounds like a pain either way - do we have some fundamental distrust of >>V4 fragmentation/reassembly going on here? It is always available, why not >>use it? > >Yes of course its bad for ones network health. See Jeff Mogul paper on >this subject (I don't have a pointer off the top of my head but if you >want to read it I can find it). Also we disallowed it in IPv6 except >end-to-end routers don't fragment in IPv6. I thought it was eliminated in order to simplify the frame format for streamlined processing, not because it was a Bad Thing. Surely your nodes MUST implement V4 fragmentation/reassembly? Also, I think Jeff Mogul wrote that RFC a very long time ago, when things were really different on the Internet, and people didn't really take the Internet as seriously as they do today, and the implementations were truly toys. It's different now, isn't it? Aren't NFS frames regularly fragmented from 8K down to multiple 1K fragments? Granted, that happens at the originating node, but they are reassembled just fine. It really does work these days. Cyndi > >At 08:47 PM 8/10/99 -0400, Jim Bound wrote: >>Cyndi, >> >>>A very compelling argument for the DF bit to MUST NOT be set. >>>Thanks - I feel quite confident about it now. >> >>I felt Dave and Sowmini's arguments were more compelling that the above >>should be SHOULD NOT. Rich provided a good sophist argument which >>attempts to reduce the need of the DF bit, but does not address the >>issue that it could be used and useful for the future. Hence, all logic >>and 23 years of engineering experience and shipping products tells me I >>would rather have it be SHOULD NOT in case we have to use it. I think >>we need to be a bit liberal here rather than conservative. >> >>As far as implementations there is only one and I think its just a >>research effort? But if its not I would be glad to be wrong. >>I know Francis is working on it now, and would really like to hear >>Francis's view on this too? >> >>p.s. Also Sowmini and Dave are engineers working on IPv6 products and in >>Dave's case his group has shipped a real IPv6 product. So that counts >>more for me too, if this is just to pare down to philosophy and logic. >> >>/jim >> >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- >> >> > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 19:48:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA02182 for ipng-dist; Tue, 10 Aug 1999 19:47:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02175 for ; Tue, 10 Aug 1999 19:47:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA15593 for ; Tue, 10 Aug 1999 19:47:43 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA09479 for ; Tue, 10 Aug 1999 20:47:42 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id WAA06993; Tue, 10 Aug 1999 22:47:42 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000020204; Tue, 10 Aug 1999 22:47:41 -0400 (EDT) From: Jim Bound Message-Id: <199908110247.WAA0000020204@quarry.zk3.dec.com> To: Cyndi Jung cc: Jim Bound , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of "Tue, 10 Aug 1999 19:13:13 PDT." <3.0.2.32.19990810191313.007521ac@mailhost.ewd.3com.com> Date: Tue, 10 Aug 1999 22:47:41 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cyndi, helps me alot. If 239.OLS.DST14.DST15 will get to the IPv6 router via intradomain based on products deployed today that is very good. The inter-domain leaking would be a problem once this got deployed. Probably need a fix for that? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 20:05:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA02212 for ipng-dist; Tue, 10 Aug 1999 20:03:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02205 for ; Tue, 10 Aug 1999 20:02:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA14758 for ; Tue, 10 Aug 1999 20:02:51 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA12872 for ; Tue, 10 Aug 1999 21:02:45 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id XAA12842; Tue, 10 Aug 1999 23:02:44 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000022133; Tue, 10 Aug 1999 23:02:43 -0400 (EDT) From: Jim Bound Message-Id: <199908110302.XAA0000022133@quarry.zk3.dec.com> To: Cyndi Jung cc: Jim Bound , Richard Draves , "'Brian E Carpenter'" , David Borman , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of "Tue, 10 Aug 1999 19:34:24 PDT." <3.0.2.32.19990810193424.0070595c@mailhost.ewd.3com.com> Date: Tue, 10 Aug 1999 23:02:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It seems to me life would be better for routers if they did not have to fragment and I think a benefit to them with IPv6. As far as originating nodes doing the frag thats fine most think I guess and we permit it in Ipv6. Did not mean to get us on this thread. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 20:10:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA02233 for ipng-dist; Tue, 10 Aug 1999 20:09:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02226 for ; Tue, 10 Aug 1999 20:08:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA17664 for ; Tue, 10 Aug 1999 20:08:55 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA14109 for ; Tue, 10 Aug 1999 21:08:54 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id XAA13108; Tue, 10 Aug 1999 23:08:53 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000023246; Tue, 10 Aug 1999 23:08:53 -0400 (EDT) From: Jim Bound Message-Id: <199908110308.XAA0000023246@quarry.zk3.dec.com> To: Richard Draves cc: "'Jim Bound'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing In-reply-to: Your message of "Tue, 10 Aug 1999 09:17:50 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515701@RED-MSG-50> Date: Tue, 10 Aug 1999 23:08:53 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, Per mapping cache from kernel space to user space. Not obvious to me with a little checking. But I will talk with our VM folks. Vacation is playing havoc around here until September though and in the IETF I am noticing. I will be splitting myself soon for a bit. p.s. If I were King we all would be using more of the features from CMUs MACH 4.0 via R. Rachid. This would be almost a no-brainer then in the OS. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 21:30:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA02304 for ipng-dist; Tue, 10 Aug 1999 21:27:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02297 for ; Tue, 10 Aug 1999 21:26:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA21493 for ; Tue, 10 Aug 1999 21:25:40 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA29038 for ; Tue, 10 Aug 1999 22:25:30 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Aug 1999 21:17:03 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Tue, 10 Aug 1999 21:17:07 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515719@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" Cc: "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: RE: IPv6 Src/Dst Address Pairing Date: Tue, 10 Aug 1999 21:16:56 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Per mapping cache from kernel space to user space. Not obvious to me > with a little checking. But I will talk with our VM folks. > Vacation is playing havoc around here until September though > and in the > IETF I am noticing. I will be splitting myself soon for a bit. Jim, when I referred to mapping kernel memory into user space, I was only talking about a fast way for user code to get at the current time. (If you check, you might find that your OS already does this. Many do.) I was NOT suggesting that you create new mappings so that user code could read IPv6 source addresses directly out of the kernel. I would suggest that you use an ioctl or some such for that purpose. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 21:53:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA02339 for ipng-dist; Tue, 10 Aug 1999 21:50:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02331 for ; Tue, 10 Aug 1999 21:50:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA23694 for ; Tue, 10 Aug 1999 21:50:29 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA04570 for ; Tue, 10 Aug 1999 22:50:28 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Aug 1999 21:31:50 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Tue, 10 Aug 1999 21:31:48 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451571B@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" , Cyndi Jung Cc: "'Brian E Carpenter'" , David Borman , ipng@sunroof.eng.sun.com Subject: RE: RFC 2529 (6over4) Date: Tue, 10 Aug 1999 21:31:37 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As far as implementations there is only one and I think its just a > research effort? But if its not I would be glad to be wrong. > I know Francis is working on it now, and would really like to hear > Francis's view on this too? UCLA also has a working implementation for some BSD variant. It would be good to hear from more implementors about this. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 10 21:53:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA02332 for ipng-dist; Tue, 10 Aug 1999 21:50:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02323 for ; Tue, 10 Aug 1999 21:50:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA23679 for ; Tue, 10 Aug 1999 21:50:21 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA04528 for ; Tue, 10 Aug 1999 22:50:15 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 10 Aug 1999 21:29:48 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Tue, 10 Aug 1999 21:29:46 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451571A@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" , Cyndi Jung Cc: "'Brian E Carpenter'" , David Borman , ipng@sunroof.eng.sun.com Subject: RE: RFC 2529 (6over4) Date: Tue, 10 Aug 1999 21:29:41 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually, the more I think about it the more I think that 6over4 should not specify or recommend any setting or clearing of the IPv4 DF bit. Just be silent on the issue. There are two ways in which an implementation might want to set the DF bit: 1. The v4 stack is doing v4 PMTU discovery but it is not affecting the 6over4 link MTU. So here the result is that instead of having v4 fragmentation occur in some router, it happens in the sending node. It is easy to implement this first scenario. In fact if your v4 stack routinely does PMTU discovery this might be the easiest implementation. Note that it's not very useful from the point of view of 6over4, because the 6over4 v6 link will not know about the v4 PMTU. So it doesn't affect the size of the v6 packets that get sent, it just affects where v4 fragmentation happens. 2. The v4 PMTU discovery ends up affecting the 6over4 link MTU. This is tricky to implement because it means the 6over4 link MTU isn't constant - potentially you have a different link MTU for reaching each neighbor. The ND spec doesn't allow for this, but I think it's possible to implement it. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 07:02:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA02646 for ipng-dist; Wed, 11 Aug 1999 06:59:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02639 for ; Wed, 11 Aug 1999 06:59:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA24982 for ; Wed, 11 Aug 1999 06:59:01 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03711 for ; Wed, 11 Aug 1999 07:59:00 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA28109 for ; Wed, 11 Aug 1999 08:58:59 -0500 (CDT) Message-Id: <199908111358.IAA28109@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of Tue, 10 Aug 1999 18:55:48 PDT. <3.0.2.32.19990810185548.01390788@mailhost.ewd.3com.com> Date: Wed, 11 Aug 1999 08:58:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Maybe I read what I wanted to read in what Richard wrote - that the > IPv4 MTU between pairs of neighbors on a 6over4 subnet would not > be a constant value, ... That's what I read, and to me it spelled "case closed". All of the IPv4 network that appears as one link to 6over4 would have to have a uniform MTU for IPv4 PMTUD to be useful. One wiseacre anywhere and bang, you're sending 68 byte packets to everyone. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 07:04:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA02666 for ipng-dist; Wed, 11 Aug 1999 07:03:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02659 for ; Wed, 11 Aug 1999 07:02:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA27468 for ; Wed, 11 Aug 1999 07:02:47 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05064 for ; Wed, 11 Aug 1999 08:02:46 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA274284 for ; Wed, 11 Aug 1999 15:02:42 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA18386 for ; Wed, 11 Aug 1999 15:02:42 +0100 (BST) Message-ID: <37B18201.6D8DC71F@hursley.ibm.com> Date: Wed, 11 Aug 1999 09:00:33 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4)/ MUST NOT DF References: <4D0A23B3F74DD111ACCD00805F31D8101451571A@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > 2. The v4 PMTU discovery ends up affecting the 6over4 link MTU. This is > tricky to implement because it means the 6over4 link MTU isn't constant - > potentially you have a different link MTU for reaching each neighbor. The ND > spec doesn't allow for this, but I think it's possible to implement it. I think you have re-discovered the reason for the MUST NOT. Unless we know how to handle this case, we have a problem, don't we? BTW a little historical research reveals that this MUST NOT appeared in the draft between August and October 1998, but I have no email about it and there is nothing relevant in the Chicago WG minutes. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 07:10:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA02700 for ipng-dist; Wed, 11 Aug 1999 07:09:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02693 for ; Wed, 11 Aug 1999 07:09:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA25977 for ; Wed, 11 Aug 1999 07:09:08 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27164 for ; Wed, 11 Aug 1999 07:09:07 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA18772 for ; Wed, 11 Aug 1999 10:09:06 -0400 (EDT) Received: from whitestar.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000024745; Wed, 11 Aug 1999 10:09:05 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA15404; Wed, 11 Aug 1999 10:09:05 -0400 Message-Id: <37B18401.B1DB9F40@zk3.dec.com> Date: Wed, 11 Aug 1999 10:09:05 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.51 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: IPNG Working Group Subject: Comments on 2292bis (Adv. API) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, Matt, Erik Please find attached some comments on draft-ietf-ipngwg-2292bis-00.txt, Advanced Sockets API for IPv6. This is a compilation of comments received from several members of the Tru64 UNIX IPv6 team: Jim Bound, Gerri Harter, Jack McCann, Ken Powell, Sowmini Varadhan, Eric Wong, Farrell Woods, and Vlad Yasevich. - This document used the wording "described later" and "described shortly." It would ease readability if you include the section numbers into these statements. Section 2.1 [Page 8] - The comment in the following definitions is incorrect: 402 struct ip6_hdrctl { 403 uint32_t ip6_un1_flow; /* 8 bits traffic class, 24 bits flow-ID */ It should be 4 bit version, 8 bit traffic class, 20 bit flow-ID. Section 2.1.2 [Page 9] - The reviewers were questioning the need for the following definition: 490 struct in6_addr ip6r0_addr[1]; /* up to 127 addresses */ This definition made the ip6_rthdr0 structure stick out from all the others. The suggestion is to remove this line and add a comment (just like all the other header structures) that states that the Routing Header 0 is followed by an array of IPv6 addresses. - It would also be helpful if the following text was moved to Section 2. [From page 10...] 520 ...This API assumes that the fields in the 521 protocol headers are left in the network byte order, which is big- 522 endian for the Internet protocols. If not, then either these 523 constants or the fields being tested must be converted at run-time, 524 using something like htons() or htonl(). Section 2.2.1 [page 11] - The following definition is no longer valid: 614 #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */ It now refers to an address that is beyond the scope of source address as defined in Section 3.1 of draft-ietf-ipngwg-icmp-v3-00.txt The draft defines the code value 2 as "beyond scope of source address". Section 2.3 [page 15] 793 int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, 794 const struct in6_addr *); - Please explain the the return type of this macro. Does it return true/false, or does it return 0 for equal, 1 for the first address > second address, -1 for first address < second address. I am guessing it's true/false since that is what all the other macros return, but it is not clear. Section 3 [page 16] - In the last paragraph of the section you talk about special treatment for sockets created with IPPROTO_RAW as the third argument. You then go on to say: 892 ...(Note: This feature was added to 893 IPv4 in 1988 by Van Jacobson to support traceroute, allowing a 894 complete IP header to be passed by the application What is the feature is the spec talking about? This caused some confusion. Section 3.1 [page 17] - What happens if the IPV6_CHECKSUM option is set for ICMPv6 sockets? - Is this option disabled by default only for raw sockets that were not created with IPPROTO_ICMPV6? Answers to these questions could help clarify this section. Section 4 [page 20] - A comment on the definitions of 'on' and 'off' for the setsockopt() calls would be helpful. - Describe the behavior of getsockopt() for IPV6_ options in this section. Do these options support a getsockopt() call and what do they return? Section 5.1 [page 26] - What is the precedence of sin6_scope_id relative to the interface specified by the IPV6_MULTICAST_IF, IPV6_PKTINFO and/or IPV6_NEXTHOP options? Section 6.2 [page 29] - What are the initialization values for the routing header? We noticed that buffer length (bp_len) and the number of segments (segments) are passed to inet6_rth_init() and this caused confusion as to what these arguments are for. Do we set seg_left to segments and if not, are these arguments simply for error checking? Section 7 [page 31] 1691 .... These 1692 requirements and the terminology used with these options are 1693 discussed in Section 4.2 and Appendix B of [RFC-2460]. - Is the assumption here that all options MUST be defined according to section 4.2 and Appendix B of rfc2460? We noticed that if we do not follow the instructions in Appendix B, we were able to design options that broke the API. If the working of this API depends on Appendix B, it should be stated so. 1701 .... The 1700 functions below need to know the alignment of the end of the option - Why does this spec institute this limitation for the API? Why not just pass the alignX and alignY? I am guessing these will be defined in the Option Specification and makes it easier for application programmers to use the API. It would make the API simpler if we were to pass X and Y to the inet6_opt_append(). This would also cause the API not to break if following Appendix B is NOT a MUST. Section 8.2 [page 33] 1825 When using ancillary data a Destination options header is passed 1826 between the application and the kernel as follows: The set preceding 1827 a Routing header are specified with the cmsg_level member is set to 1828 IPPROTO_IPV6 and the cmsg_type member is set to IPV6_RTHDRDSTOPTS. 1829 Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently 1830 ignore when sending packets unless a Routing header is also 1831 specified. - As the spec states here, IPV6_RTHDRDSTOPTS options are ignored unless Routing header is present. Does this mean that if the user has IPV6_RTHDRDSTOPTS options and a Routing header, and then the user removes the Routing header, the IPV6_RTHDRDSTOPTS options go away as well? Should the implementation cache the IPV6_RTHDRDSTOPTS options in case Routing header will appear later? Section 9.1 [page 34] 1875 ... If the extlen value is too small or not a multiple of 8 the 1876 function fails and returns -1. - What do you mean by "too small" in this sentence? Section 9.2 [page 34] - This is the same question as question 2 for Section 7. Providing X and Y in the interface would make the API easier to use. The only time that we've successfully calculated Y based on X and length was when our options followed Appendix B or 2460. Section 9.2 [page 35] 1917 The align parameter must have a value of 1, 2, 4, or 8. The len 1918 value can not exceed the value of align. The last sentece of this paragraph contradicts the previous paragraph as well as the examples in the Appendix. It seems like an unnecessary restriction and it was the opinion of reviewers that it should be removed. Section 9.5 [page 36] - How is the "previous" length updated in this sentence? 1977 .... This 1978 function returns the updated "previous" length taking into account 1979 the option that was returned. - Also, the main body of the spec does not indicate if inet6_opt_next returns pad options or just skips over them. The example code in the appendix shows the application code does recognize and ignore pad options. Suggest a note be added to this section indicating inet6_opt_next does return pad options. Section 10 [page 37] 2040 All Hop-by-Hop options must be specified in a single ancillary data 2041 object. Should multiple be specified the implementation might choose 2042 an arbitrary one or drop the packet. - Does this refer to multiple options or multiple ancillary data objects? Sections 12.2 and 12.3 - What was the reason to put rcmd_af() and rexec_af() in this spec? It was the concensus of the reviewers that these functions are not really needed since they both used to call rresvport() and can be made to call rresvport_af(). As it is currently, rcmd() and rexec() do the hostname lookups. At this point these functions can make the decision to use V6 or V4 based on the addresses returned. We do not really see the need for rcmd_af() and rexec_af(). Section 13. - Why does this section exist in addition to section 18 (TODO and Open Issues)? Should this be merged into one section? Section 22 [page 47] - This section and it's subsections add a lot of new requirements to an implementation's handling of the msghdr and cmsghdr structures. We don't think this should be treated as "informational" given that many of these requirements are necessary to support the main body of the spec. Also, the new requirements are being made to posix standard structures and macros. Something needs to be done to make this section less "informational." Section 22.3.2 [page 51] - It might be good to qualify that cmsg is a pointer to the cmsghdr struct returned by a previous call to CMSG_NEXTHDR() or CMSG_FIRSTHDR(). Section 22.3.4 [page 52] - This sentence is a little confusing, since the macro does not in fact allocate space: 2905 .... This macro can be 2906 used, for example, to allocate space dynamically for the ancillary 2907 data. One possible rewording might be: 2905 .... This macro can be 2906 used, for example, to determine the size of the space needed to 2907 dynamically allocate ancillary data. Section 23.1: The example starts with: void *extptr; int extlen; struct msghdr msg; struct cmsghdr *cmsgptr; int cmsglen; struct sockaddr_in6 I1, I2, I3, D; extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3); cmsglen = CMSG_LEN(extlen); cmsgptr = malloc(cmsglen); cmsgptr->cmsg_len = cmsglen; Should the last three lines shown here be changed to: cmsglen = CMSG_SPACE(extlen); cmsgptr = malloc(cmsglen); cmsgptr->cmsg_len = CMSG_LEN(extlen); -vlad +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 07:39:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA02774 for ipng-dist; Wed, 11 Aug 1999 07:36:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02767 for ; Wed, 11 Aug 1999 07:36:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA01687 for ; Wed, 11 Aug 1999 07:36:24 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA17381 for ; Wed, 11 Aug 1999 08:36:23 -0600 (MDT) Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Aug 11 10:34:08 EDT 1999 Received: from zubin.dnrc.bell-labs.com (zubin [135.180.130.56]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA24511; Wed, 11 Aug 1999 10:34:30 -0400 (EDT) Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.17.249.59]) by zubin.dnrc.bell-labs.com (8.8.8+Sun/8.8.8) with ESMTP id KAA13880; Wed, 11 Aug 1999 10:34:25 -0400 (EDT) Message-ID: <37B18956.96CC48DD@dnrc.bell-labs.com> Date: Wed, 11 Aug 1999 10:31:50 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4)/ MUST NOT DF References: <4D0A23B3F74DD111ACCD00805F31D8101451571A@RED-MSG-50> <37B18201.6D8DC71F@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > Rich, > > > 2. The v4 PMTU discovery ends up affecting the 6over4 link MTU. This is > > tricky to implement because it means the 6over4 link MTU isn't constant - > > potentially you have a different link MTU for reaching each neighbor. The ND > > spec doesn't allow for this, but I think it's possible to implement it. > > I think you have re-discovered the reason for the MUST NOT. Unless > we know how to handle this case, we have a problem, don't we? Seems to me that's the very definition of SHOULD NOT clauses. They're the ones that generally ought not to be done, but if the implementors are sufficiently clueful about the 'tricky' implementation consequences then they can chose to do so. Inserting a MUST NOT just means that clueful implementors who want to go that extra effort will be shouted at for being non-compliant. cheers, gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 08:22:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA02864 for ipng-dist; Wed, 11 Aug 1999 08:18:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02857 for ; Wed, 11 Aug 1999 08:18:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA05217 for ; Wed, 11 Aug 1999 08:18:39 -0700 (PDT) Received: from frantic.bsdi.com ([209.173.194.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04851 for ; Wed, 11 Aug 1999 09:18:33 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id KAA13238; Wed, 11 Aug 1999 10:17:51 -0500 (CDT) Date: Wed, 11 Aug 1999 10:17:51 -0500 (CDT) From: David Borman Message-Id: <199908111517.KAA13238@frantic.bsdi.com> To: richdr@microsoft.eng.sun.com Subject: RE: RFC 2529 (6over4) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few points: 1) PMTU is done on a per-host basis, not on a network basis. So, I don't care if from the IPv6 viewpoint the next host appears to be locally attached, if somehow you get PMTU information for that host, you adjust the MTU for just that host, not for the whole link! The LinkMTU argument is a red-herring. I create a 6over4 packet, set the DF bit in the outer packet and send it. If I get back an ICMPv4 Unreachable: Too Big message, I create an ICMPv6 Too Big message and pass it up, and the IPv6 code should do the right thing. 2) Not all networks are homogeneous. Just because several hosts appear to be directly connected to the same network that you are connected to, does not always mean that you can use the same MTU to talk to all those hosts. HIPPI is an obvious example. Saying that because you might get different PMTU values for different hosts will require you to only use the minimum of those values is bogus. For a simple implementation you might choose to do that, but that is an implementation decision, not a protocol decision. Again, PMTUD is done on a *per host basis*. At best, the LinkMTU gives you a starting point for doing PMTUD. 3) One of the original arguments against setting the DF bit in the outer IPv4 header was that there may be an IPv4 link that has a smaller MTU than the minimum IPv6 MTU. If you do IPv4 PMTUD discovery and find a too-small MTU, you just disable PMTUD for that host. The bottom line is that yes, doing IPv4 PMTUD for 6over4 packets is not a simple thing and there are pitfalls. It is fine for the 6over4 spec to point this out and discourage the setting of the DF bit in the outer IPv4 packet, but it should not totally disallow it! That is why I argue to make it a SHOULD NOT, not a MUST NOT. The IPSec documents took the effort to not only allow the DF bit to be set in the outer IPv4 header when encapsulating, they go into discussion about the issues involved. 6over4 is just another encapsulation technique. If other encapsulation techniques allow for PMTUD, what is so special about 6over4 that it needs to totally disallow it? -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 09:04:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA02946 for ipng-dist; Wed, 11 Aug 1999 09:00:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02939 for ; Wed, 11 Aug 1999 09:00:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA18734 for ; Wed, 11 Aug 1999 09:00:41 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24061 for ; Wed, 11 Aug 1999 10:00:40 -0600 (MDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id MAA12366; Wed, 11 Aug 1999 12:00:39 -0400 (EDT) Received: by anw.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000968600; Wed, 11 Aug 1999 12:00:38 -0400 (EDT) Date: Wed, 11 Aug 1999 12:00:38 -0400 (EDT) From: Jack McCann Message-Id: <199908111600.MAA0000968600@anw.zk3.dec.com> To: iesg@ietf.org Subject: Re: Last Call: IPv6 Router Alert Option to Proposed Standard Cc: awjacks@bbn.com, craig@bbn.com, dkatz@jnx.com, ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC2460 section 4 says: Individual options may have specific alignment requirements, to ensure that multi-octet values within Option Data fields fall on natural boundaries. The alignment requirement of an option is specified using the notation xn+y, meaning the Option Type must appear at an integer multiple of x octets from the start of the header, plus y octets. The IPv6 Router Alert option looks like it should specify an alignment requirement of 2n (i.e. x == 2, y == 0) so that the 2-octet Value field falls on a 2-octet boundary. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 09:17:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA02986 for ipng-dist; Wed, 11 Aug 1999 09:13:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02979 for ; Wed, 11 Aug 1999 09:13:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA20614 for ; Wed, 11 Aug 1999 09:13:35 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00216 for ; Wed, 11 Aug 1999 10:13:29 -0600 (MDT) Received: by odin.digi-data.com id <15237>; Wed, 11 Aug 1999 12:08:45 -0400 Message-Id: <99Aug11.120845gmt-0400.15237@odin.digi-data.com> Date: Wed, 11 Aug 1999 12:16:01 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound , IPng Mailing List Subject: Re: IPv6 Src/Dst Address Pairing References: <199908110137.VAA0000849978@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Jim, > src/dst caveats for disucssion: > The src/dst address match algorithm would be a knob that SHOULD be > implemented by any node supporting multiple prefixes on an interface, OR > is multihomed. Agreed. > > The src/dst address match algorithm would be a knob not have to be > turned on when a node does not support the two premises above > (multiple prefixes or multihomed). Agreed. > > If a node exists in a DNS implementation where the server orders the > addresses returned for load balancing or some other reasons then the > node should realize using the src/dst match algorithm knob will most > likely result in the order provided by the DNS server as null and void. Why should it render the order provided by the DNS Server as null and void? The fact that this node is querying the DNS indicates that it is preparing to initiate a transmission (possibly creating a new connection) to the node that is the subject of the DNS query. That is, these addresses are all candidates to be selected by the originating node as a destination address. In that case, how does choosing one of the addresses as the destination address from the list returned by the DNS Server invalidate the order provided by the DNS server? It is still possible that the originating node would choose to use the candidate address at the top of the list returned by the DNS server. > > If a node has an application that selects the src address (not > considering the src/dst address algorithm) then the result to the > src/dst address match algorithm behind getipnodebyname or getaddrinfo > may be voided when the packet is sent to the stack in the kernel. This is true. > > Thoughts? > Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 09:56:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA03066 for ipng-dist; Wed, 11 Aug 1999 09:53:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03059 for ; Wed, 11 Aug 1999 09:52:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA19373 for ; Wed, 11 Aug 1999 09:52:52 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17705 for ; Wed, 11 Aug 1999 10:52:51 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id SAA21547; Wed, 11 Aug 1999 18:52:47 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id SAA19919; Wed, 11 Aug 1999 18:52:45 +0200 (MET DST) Message-Id: <199908111652.SAA19919@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: Cyndi Jung , Richard Draves , "'Brian E Carpenter'" , David Borman , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of Tue, 10 Aug 1999 20:47:29 EDT. <199908110047.UAA0000022008@quarry.zk3.dec.com> Date: Wed, 11 Aug 1999 18:52:29 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I know Francis is working on it now, and would really like to hear Francis's view on this too? => I believe David has a very good argument then "SHOULD NOT" is enough (but this doesn't change for me, I had bad experiences with IPv4 PMTU then I almost always clear the DF bit and experiment PMTU discovery on tunnels only with IPv6 over IPv6 :-). I don't know if in the case of multicasts something specific should be specified, usually it is a *bad* idea to fragment IPv4 multicasts (no PMTU discovery) but it should work... Regards Francis.Dupont@inria.fr PS: about link-layer addresses, there are *not* useful for IPv6 over IPv4 point-to-point tunnels. When a Cisco sends a link-layer info in RA, it should be checked and dropped! I think 6over4 is the only IPv6 over IPv4 object where link-layer infos are really used. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 11:55:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA03355 for ipng-dist; Wed, 11 Aug 1999 11:19:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03343 for ; Wed, 11 Aug 1999 11:18:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA04746; Wed, 11 Aug 1999 11:15:05 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10981; Wed, 11 Aug 1999 11:15:04 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA24009; Wed, 11 Aug 1999 11:13:42 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA17204; Wed, 11 Aug 1999 11:13:42 -0700 (PDT) Received: from tellurium (usr-modem23.nsd.3com.com [129.213.205.143]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id LAA12814; Wed, 11 Aug 1999 11:13:39 -0700 (PDT) Message-Id: <3.0.2.32.19990811111055.008e83b4@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Wed, 11 Aug 1999 11:10:55 -0700 To: David Borman , richdr@microsoft.eng.sun.com From: Cyndi Jung Subject: RE: RFC 2529 (6over4) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199908111517.KAA13238@frantic.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, I was ready to throw in the towel, since you all are convinced that this is truly unnecessary, so I was digging through the literature to see if in fact the mapping from the ICMPv4 message to the ICMPv6 message was workable when I ran across this in RFC 1191 Path MTU Discovery, the format of the Destination Unreachable, Code "Fragmentation required but DF bit set" - 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Code = 4 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused = 0 | Next-Hop MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Datagram Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ With only 64 bits of the Original Datagram Data, aka the IPv6 datagram, how is the ICMPv6 packet supposed to be delivered to the originating node? Even if the originating node is the one to receive the ICMPv4 message, there is not enough source IPv6 address in the packet for it to tell the message is for him, and certaily there is no destination IPv6 address to determine the node for whom the PMTU is less than the current assumed value of the linkMTU. Has there been an intervening spec that lengthens the data content of the ICMPv4 messages? This is pretty old, yet there is no RFC that has obsoleted it, and it appears that the intent is to make sure the entire packet is small, ensuring that it will reach it's intended recipient. Now what? Can we really use IPv4 PMTU? Cyndi At 10:17 AM 8/11/99 -0500, David Borman wrote: >A few points: > >1) PMTU is done on a per-host basis, not on a network basis. So, > I don't care if from the IPv6 viewpoint the next host appears to > be locally attached, if somehow you get PMTU information for that > host, you adjust the MTU for just that host, not for the whole link! > The LinkMTU argument is a red-herring. > > I create a 6over4 packet, set the DF bit in the outer packet > and send it. If I get back an ICMPv4 Unreachable: Too Big message, > I create an ICMPv6 Too Big message and pass it up, and the IPv6 > code should do the right thing. > >2) Not all networks are homogeneous. Just because several hosts > appear to be directly connected to the same network that you > are connected to, does not always mean that you can use the same > MTU to talk to all those hosts. HIPPI is an obvious example. > > Saying that because you might get different PMTU values for > different hosts will require you to only use the minimum of > those values is bogus. For a simple implementation you might > choose to do that, but that is an implementation decision, not > a protocol decision. Again, PMTUD is done on a *per host basis*. > At best, the LinkMTU gives you a starting point for doing PMTUD. > >3) One of the original arguments against setting the DF bit in the > outer IPv4 header was that there may be an IPv4 link that has > a smaller MTU than the minimum IPv6 MTU. If you do IPv4 PMTUD > discovery and find a too-small MTU, you just disable PMTUD for > that host. > >The bottom line is that yes, doing IPv4 PMTUD for 6over4 packets >is not a simple thing and there are pitfalls. It is fine for the >6over4 spec to point this out and discourage the setting of the DF >bit in the outer IPv4 packet, but it should not totally disallow it! > >That is why I argue to make it a SHOULD NOT, not a MUST NOT. > >The IPSec documents took the effort to not only allow the DF bit to >be set in the outer IPv4 header when encapsulating, they go into >discussion about the issues involved. 6over4 is just another >encapsulation technique. If other encapsulation techniques allow >for PMTUD, what is so special about 6over4 that it needs to totally >disallow it? > > -David Borman, dab@bsdi.com >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 12:21:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA03443 for ipng-dist; Wed, 11 Aug 1999 11:30:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03436 for ; Wed, 11 Aug 1999 11:29:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA19813 for ; Wed, 11 Aug 1999 11:29:36 -0700 (PDT) Received: from frantic.bsdi.com ([209.173.194.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00076 for ; Wed, 11 Aug 1999 12:29:34 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id NAA13867; Wed, 11 Aug 1999 13:28:51 -0500 (CDT) Date: Wed, 11 Aug 1999 13:28:51 -0500 (CDT) From: David Borman Message-Id: <199908111828.NAA13867@frantic.bsdi.com> To: ipng@sunroof.eng.sun.com Subject: RE: RFC 2529 (6over4) Cc: cmj@3Com.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Wed, 11 Aug 1999 11:10:55 -0700 > From: Cyndi Jung > Subject: RE: RFC 2529 (6over4) > Cc: ipng@sunroof.eng.sun.com > ... > With only 64 bits of the Original Datagram Data, aka the IPv6 datagram, > how is the ICMPv6 packet supposed to be delivered to the originating > node? Even if the originating node is the one to receive the ICMPv4 > message, there is not enough source IPv6 address in the packet for it > to tell the message is for him, and certaily there is no destination > IPv6 address to determine the node for whom the PMTU is less than the > current assumed value of the linkMTU. > > Has there been an intervening spec that lengthens the data content of the > ICMPv4 messages? This is pretty old, yet there is no RFC that has > obsoleted it, and it appears that the intent is to make sure the entire > packet is small, ensuring that it will reach it's intended recipient. > > Now what? Can we really use IPv4 PMTU? Yes. If the returned ICMPv4 Unreachable, Fragmentation Needed message does not contain enough information to generate the ICMPv6 Packet Too Big message, you just record the new MTU. When the next 6over4 packet comes along, you can then immediately generate the ICMPv6 Packet Too Big message. Please, everyone, if you haven't yet read section 6.1 "PMTU/DF Processing" and Appendix B, "Analysis/Discussion of PMTU/DF/Fragmentation Issues" in RFC 2401, please do so. Then we can avoid rehashing issues that the IPSec folks have already addressed, and concentrate on whether or not there are issues unique to 6over4 that won't allow those schemes to work. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 12:37:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA03508 for ipng-dist; Wed, 11 Aug 1999 11:49:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03499 for ; Wed, 11 Aug 1999 11:49:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA24287 for ; Wed, 11 Aug 1999 11:49:00 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA08327 for ; Wed, 11 Aug 1999 12:48:59 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 1999 11:45:21 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Wed, 11 Aug 1999 11:45:12 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515728@RED-MSG-50> From: Richard Draves To: "'David Borman'" Cc: ipng@sunroof.eng.sun.com Subject: RE: RFC 2529 (6over4) Date: Wed, 11 Aug 1999 11:45:14 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) PMTU is done on a per-host basis, not on a network basis. So, > I don't care if from the IPv6 viewpoint the next host appears to > be locally attached, if somehow you get PMTU information for that > host, you adjust the MTU for just that host, not for the > whole link! > The LinkMTU argument is a red-herring. Hmm, that could work. It's a little strange since normally I would expect to use the link MTU to reach any neighbor on the link, and could only have a path MTU smaller than the link MTU if the packet is traversing multiple links. You mentioned HIPPI - does it have the property that some link neighbors are not reachable using the link MTU? The ND spec does not anticipate these kinds of links. > I create a 6over4 packet, set the DF bit in the outer packet > and send it. If I get back an ICMPv4 Unreachable: Too Big message, > I create an ICMPv6 Too Big message and pass it up, and the IPv6 > code should do the right thing. Synthesizing an ICMPv6 Packet Too Big message would be awkward - what IPv6 source address would you use for the message? Maybe a v4-mapped address :-) In any case, the conclusion seems to be that one can imagine implementations that set the DF bit in the encapsulating v4 header. I don't see a reason for 6over4 to specify anything wrt DF bit. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 12:39:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA03556 for ipng-dist; Wed, 11 Aug 1999 11:56:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03549 for ; Wed, 11 Aug 1999 11:56:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA25639 for ; Wed, 11 Aug 1999 11:55:58 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06141 for ; Wed, 11 Aug 1999 12:43:14 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id UAA22232; Wed, 11 Aug 1999 20:43:02 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA18246; Wed, 11 Aug 1999 20:43:00 +0200 (MET DST) Message-Id: <199908111843.UAA18246@givry.inria.fr> From: Francis Dupont To: Peter Tattam cc: Robert Elz , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of Fri, 06 Aug 1999 19:45:10 +1000. Date: Wed, 11 Aug 1999 20:42:58 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Francis - I'd very much appreciate a brief message on just how your > proposed tools might go about this task. It doesn't seem to me that > it is going to be trivial, though I can see it might be possible. => I am doing that (I was busy with the eclipse :-). I can see some considerable problems if the client initiates contact with the DNS servers since typically ND & stateless config would probably be done at kernel level. Usually DNS related stuff happens at user level in my experience. Mixing the two might be a bit of a headache, but not impossible. => fortunately I do ND prefix discovery & stateless config at user level. >From a general point of view, I see two ways to approach the problem. a) The host machine pushes the information into the DNS system. => it is the thing I have in my TODO. b) The DNS system pulls the information from the host machines as needed. => I believe in this case an ICMPv6 service will be better (there are many proposals and some implementations of this)... Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 12:43:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA03609 for ipng-dist; Wed, 11 Aug 1999 12:03:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03602 for ; Wed, 11 Aug 1999 12:03:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA27142 for ; Wed, 11 Aug 1999 12:03:17 -0700 (PDT) Received: from frantic.bsdi.com ([209.173.194.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14227 for ; Wed, 11 Aug 1999 13:03:15 -0600 (MDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id OAA13952; Wed, 11 Aug 1999 14:02:38 -0500 (CDT) Date: Wed, 11 Aug 1999 14:02:38 -0500 (CDT) From: David Borman Message-Id: <199908111902.OAA13952@frantic.bsdi.com> To: richdr@microsoft.com Subject: RE: RFC 2529 (6over4) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Richard Draves > Subject: RE: RFC 2529 (6over4) > Date: Wed, 11 Aug 1999 11:45:14 -0700 > ... > You mentioned HIPPI - does it have the property that some link neighbors are > not reachable using the link MTU? The ND spec does not anticipate these > kinds of links. HIPPI doesn't have a link MTU. It can send as large of a packet as you want. It's one of the reasons there is an IPv6 Jumbogram option. > ... > In any case, the conclusion seems to be that one can imagine implementations > that set the DF bit in the encapsulating v4 header. I don't see a reason for > 6over4 to specify anything wrt DF bit. Yes, or at least, not outlaw it. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 12:49:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA03793 for ipng-dist; Wed, 11 Aug 1999 12:24:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03786 for ; Wed, 11 Aug 1999 12:24:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA27154 for ; Wed, 11 Aug 1999 12:24:01 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09816 for ; Wed, 11 Aug 1999 12:24:01 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA21299 for <@external-mail-relay.sgi.com:ipng@sunroof.eng.sun.com>; Wed, 11 Aug 1999 12:23:02 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA62138 for <@relay.engr.sgi.com:ipng@sunroof.eng.sun.com>; Wed, 11 Aug 1999 12:23:59 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA40320 for ipng@sunroof.eng.sun.com; Wed, 11 Aug 1999 12:23:58 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199908111923.MAA40320@bossette.engr.sgi.com> Subject: more 2292-bis comments To: ipng@sunroof.eng.sun.com Date: Wed, 11 Aug 1999 12:23:57 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Prompted by Vladislav's mail, I'm sending some comments that I have also been accumulating regarding 2292-bis as I implement it. Erik, are you still taking care of this document? You seem very involved and busy with other IPv6 hot-topics and my last private email regarding 2292bis remains unanswered. The comments are below... there could well be more as I haven't finished implementing everything yet :-) Cheers, Sam. 1. I assume that the intention is to insert the extension headers created with the inet6_opt_* functions into the cmsg_data part of a control message to be passed as ancillary data. This relationship between the CMSG_* macros and the inet6_opt_* functions wasn't stated explicitly in the document, although it does become apparent after reading the examples in the appendix. Why was the cmsg stuff moved to the appendix? 2. inet6_opt_append(). I think if the extbuf parameter is non-NULL then you would also like the function to update the extension header length field, right? This isn't currently required by the document and I suggest that it should be. 3. I don't see any reason to not allow inet6_opt_append() to add Pad1 and PadN options (section 9.2). 4. I would suggest that padding options _not_ be returned by inet6_opt_next() and that this be stated in section 9.5. 5. Section 9.5 should desecribe how the function behaves once all the options have been read from the buffer; I would suggest that it return a value of zero and that the three call-by-reference return parameters remain undefined. 6. Is there really such an installed base to warrant the rfc-2292 compatability goal? 2292bis states it contains several modifications to simplify the implementation of the API but then suggests that implementation compatibility with 2292 would be a good thing, defeating the goal of these simplifications. I really would prefer a `one or the other' approach, because there is no important functionality in one that isn't in the other regarding the ancillary data/sockopts functionality, it's just two different ways of doing things. 7. There seems to be some confusion as to whether the cmsg_len field of struct cmsghdr includes the header length or not. The definition says it does, as does the ascii diagram, but some of the macro examples, CMSG_NXTHDR for example, imply that it does not. I assume it is the macro examples that are wrong. 8. As Vladislav, I also question the value of section 12 in the API. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 13:16:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA04068 for ipng-dist; Wed, 11 Aug 1999 12:52:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04049 for ; Wed, 11 Aug 1999 12:52:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA22226 for ; Wed, 11 Aug 1999 12:52:17 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA02592 for ; Wed, 11 Aug 1999 13:52:16 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 1999 12:45:17 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Wed, 11 Aug 1999 12:45:16 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451572A@RED-MSG-50> From: Richard Draves To: "'David Borman'" Cc: ipng@sunroof.eng.sun.com Subject: RE: RFC 2529 (6over4) Date: Wed, 11 Aug 1999 12:45:15 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > HIPPI doesn't have a link MTU. It can send as large of a packet as > you want. It's one of the reasons there is an IPv6 Jumbogram option. OK, ND does allow for that. Called a "variable MTU" link. But the expectation is that an administrator will specify a single MTU for the entire link using the MTU option in Router Advertisements. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 13:16:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA04122 for ipng-dist; Wed, 11 Aug 1999 13:01:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04115 for ; Wed, 11 Aug 1999 13:00:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA06121 for ; Wed, 11 Aug 1999 13:00:37 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05903 for ; Wed, 11 Aug 1999 14:00:35 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA22604; Wed, 11 Aug 1999 22:00:32 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA15732; Wed, 11 Aug 1999 22:00:32 +0200 (MET DST) Message-Id: <199908112000.WAA15732@givry.inria.fr> From: Francis Dupont To: Robert Elz cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-reply-to: Your message of Fri, 06 Aug 1999 18:49:00 +1000. <6479.933929340@munnari.OZ.AU> Date: Wed, 11 Aug 1999 22:00:31 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: | => I have in my TODO list the same kind of tools (ie. something which | updates AAAA & PTR RRs from IPv6 addrconf/neighbor discovery). This one is interesting, and is the first real suggestion I have seen that there might be a solution. => it is not a new idea and it should be very close to Jim's tool (it is why I have written "same kind")... The problem is DHCPv6 is not yet available and perhaps will be a bit expensive then the AAAA & PTR RRs update service should be provided with the IPv6 stateless address autoconfig (part of the neighbor discovery). The proposed context is a rather closed environment with security constraints and a medium term mobility (ie nomadism). Of course DHCPv6 is the *solution* but again DHCPv6 is not available. The proposed mechanism is simple: 1 - stateless autoconfig user daemon signals addition/deletion of global prefixes (including old prefixes at boot time) 2 - suitable AAAA and PTR RRs are updated 3 - for security DNS updates are signed with TSIG (using pre-shared keys) Of course for PTR RR updates this may not work with a random server but this works inside an organization, even a large one. Francis.Dupont@inria.fr PS: the first step is to get a working dynamic update for IPv6, both in client and server (Jim has already that). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 13:21:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA04146 for ipng-dist; Wed, 11 Aug 1999 13:15:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04139 for ; Wed, 11 Aug 1999 13:15:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA08646 for ; Wed, 11 Aug 1999 13:15:37 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA29388 for ; Wed, 11 Aug 1999 13:15:33 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id UA08152; Thu, 12 Aug 1999 06:15:15 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: IPv6 and Dynamic DNS In-Reply-To: Your message of "Wed, 11 Aug 1999 22:00:31 +0200." <199908112000.WAA15732@givry.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Aug 1999 06:15:15 +1000 Message-Id: <24614.934402515@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 11 Aug 1999 22:00:31 +0200 From: Francis Dupont Message-ID: <199908112000.WAA15732@givry.inria.fr> | => it is not a new idea and it should be very close to Jim's tool OK, thanks. Clearly Jim understood what you were saying, and I was dreaming ... but thanks for the explanation. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 14:22:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA04347 for ipng-dist; Wed, 11 Aug 1999 14:04:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04340 for ; Wed, 11 Aug 1999 14:04:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA26315 for ; Wed, 11 Aug 1999 14:04:14 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01052 for ; Wed, 11 Aug 1999 15:04:12 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA237142; Wed, 11 Aug 1999 22:04:09 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA32746; Wed, 11 Aug 1999 22:04:08 +0100 (BST) Message-ID: <37B1E4C6.1EF57318@hursley.ibm.com> Date: Wed, 11 Aug 1999 16:01:58 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Jim Bound CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing References: <199908110137.VAA0000849978@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I think we're getting there. If your approach can be fitted into the post-Oslo multihoming proposal, we should be OK. That's not on my personal to do list. I was concerned not to have any special-case handling in hosts for 6to4; otherwise I would probably never have got interested in this topic. But what you suggest is not so different from what the 6to4 draft already says, and we may have to live with that much of a special case I guess. Thanks for listening. Brian Jim Bound wrote: > > Hi Brian, > > In the interest of doing something very cool with IPv6 that cannot be > ported to as quickly or as efficiently with IPv4 for a moment I will > concede that we need src/dst address compares for src addr selection > given the following caveats from the recent technical discussion on this > subject thread. This is a postualte OK. I still think we need to verify > the performance implications and provide an implementation scenario > which I have now done offline to support this. At the end I also give > you a suggested fix for the two-way connectivity problem for 6to4 if > this was not done or is deployed before vendors can add it to IPv6 > product efforts in process now for the wave of releases of IPv6 products > where we would like to support 6to4. > > src/dst caveats for disucssion: > The src/dst address match algorithm would be a knob that SHOULD be > implemented by any node supporting multiple prefixes on an interface, OR > is multihomed. > > The src/dst address match algorithm would be a knob not have to be > turned on when a node does not support the two premises above > (multiple prefixes or multihomed). > > If a node exists in a DNS implementation where the server orders the > addresses returned for load balancing or some other reasons then the > node should realize using the src/dst match algorithm knob will most > likely result in the order provided by the DNS server as null and void. > > If a node has an application that selects the src address (not > considering the src/dst address algorithm) then the result to the > src/dst address match algorithm behind getipnodebyname or getaddrinfo > may be voided when the packet is sent to the stack in the kernel. > > Thoughts? > > Fix for 6to4 Two-Way-Connectivity Issue: > > The fix for 6to4, if the src/dst match was not deployed is to state in > 6to4 that all nodes must support in the kernel (use better words here > but I mean in the stack where the src addr is selected), "A 6to4 > implementation, if src/dst match is not supported, MUST check that a > TLA624 prefix src is used to send a packet to a TLA264 dst address.". > > Also we need a health warning in 6to4 that if an application sends to a > 6to4 prefix and selects its own src address it two-way-connectivity may > be lost in 6to4. This will apply even if src/dst match is implemented. > > Comments? > > /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 14:22:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA04329 for ipng-dist; Wed, 11 Aug 1999 14:02:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04322 for ; Wed, 11 Aug 1999 14:01:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA17602 for ; Wed, 11 Aug 1999 14:01:29 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18460 for ; Wed, 11 Aug 1999 14:01:28 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id OAA20900; Wed, 11 Aug 1999 14:01:09 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id OAA15701; Wed, 11 Aug 1999 14:01:09 -0700 (PDT) Received: from tellurium (usr-modem23.nsd.3com.com [129.213.205.143]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id OAA16621; Wed, 11 Aug 1999 14:01:06 -0700 (PDT) Message-Id: <3.0.2.32.19990811135825.008e0644@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Wed, 11 Aug 1999 13:58:25 -0700 To: David Borman , richdr@microsoft.com From: Cyndi Jung Subject: RE: RFC 2529 (6over4) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199908111902.OAA13952@frantic.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> ... >> In any case, the conclusion seems to be that one can imagine implementations >> that set the DF bit in the encapsulating v4 header. I don't see a reason for >> 6over4 to specify anything wrt DF bit. > >Yes, or at least, not outlaw it. > > -David Borman, dab@bsdi.com Does it need to give guidance on the use of PMTU, both at v4 and v6 levels? Or just be silent. Cyndi BTW, sending the ICMP Destination Unreachable message in V4 is optional - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 15:14:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA04496 for ipng-dist; Wed, 11 Aug 1999 15:04:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04489 for ; Wed, 11 Aug 1999 15:03:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA10035 for ; Wed, 11 Aug 1999 15:03:54 -0700 (PDT) Received: from frantic.bsdi.com ([209.173.194.226]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13393 for ; Wed, 11 Aug 1999 15:03:53 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id RAA14527; Wed, 11 Aug 1999 17:02:05 -0500 (CDT) Date: Wed, 11 Aug 1999 17:02:05 -0500 (CDT) From: David Borman Message-Id: <199908112202.RAA14527@frantic.bsdi.com> To: cmj@3Com.com, richdr@microsoft.com Subject: RE: RFC 2529 (6over4) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Wed, 11 Aug 1999 13:58:25 -0700 > From: Cyndi Jung > Subject: RE: RFC 2529 (6over4) > >> ... > >> In any case, the conclusion seems to be that one can imagine > implementations > >> that set the DF bit in the encapsulating v4 header. I don't see a reason > for > >> 6over4 to specify anything wrt DF bit. > > > >Yes, or at least, not outlaw it. > > > > -David Borman, dab@bsdi.com > > Does it need to give guidance on the use of PMTU, both at v4 and v6 levels? > Or just be silent. I'd say either just be silent about the DF bit, or make it a SHOULD NOT and have a reference to RFC 2401, Section 6.1 and Appendix B. > BTW, sending the ICMP Destination Unreachable message in V4 is optional - Not really. You aren't guaranteed that the ICMP message will get back to you (just as you aren't guaranteed that any IP packet will get through), but RFC 1812, "Requirements for IP Version 4 Routers", says: 5.2.7.1 Destination Unreachable The ICMP Destination Unreachable message is sent by a router in response to a packet which it cannot forward because the destination (or next hop) is unreachable or a service is unavailable. Examples of such cases include a message addressed to a host which is not there and therefore does not respond to ARP requests, and messages addressed to network prefixes for which the router has no valid route. A router MUST be able to generate ICMP Destination Unreachable messages and SHOULD choose a response code that most closely matches the reason the message is being generated. That doesn't sound very optional to me. You can also look at RFC 1435. BTW, the issue of only getting 64 bits of original header in the ICMP message is also addressed in RFC 1812: 4.3.2.3 Original Message Header Historically, every ICMP error message has included the Internet header and at least the first 8 data bytes of the datagram that triggered the error. This is no longer adequate, due to the use of IP-in-IP tunneling and other technologies. Therefore, the ICMP datagram SHOULD contain as much of the original datagram as possible without the length of the ICMP datagram exceeding 576 bytes. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 17:32:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA04859 for ipng-dist; Wed, 11 Aug 1999 17:28:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04852 for ; Wed, 11 Aug 1999 17:28:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA17586 for ; Wed, 11 Aug 1999 17:28:12 -0700 (PDT) Received: from mede.tahi.org (oxalis.nezu.wide.ad.jp [203.178.142.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07976 for ; Wed, 11 Aug 1999 17:28:10 -0700 (PDT) Received: from localhost (localhost.tahi.org [127.0.0.1]) by mede.tahi.org (8.8.8/8.8.8) with ESMTP id JAA03819 for ; Thu, 12 Aug 1999 09:28:09 +0900 (JST) (envelope-from tanaka@mede.tahi.org) To: ipng@sunroof.eng.sun.com Reply-To: contact@tahi.org Subject: TAHI IPv6 Conformance Test Packages Rel 0.3 and reports From: Takashi_Tanaka@yokogawa.co.jp In-Reply-To: Your message of "Tue, 10 Aug 1999 12:49:03 +0900" <19990810124903N.kazu@iijlab.net> References: <19990810124903N.kazu@iijlab.net> X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990812092809E.tanaka@mede.tahi.org> Date: Thu, 12 Aug 1999 09:28:09 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, TAHI Project has opened the IPv6 Conformance Test Packages and test reports about KAME IPv6 network code (http://www.kame.net/) at the following web site: http://www.tahi.org/report/ Changes from the previous release of the IPv6 Conformance Test Packages: The Test Tool (Release-0.3): - support the definition of TCP Header - ported FreeBSD 3.2 The Test Program (Release-0.3): - Neighbor Discovery : Redirect messages for a host - IPv6 Specificatoin : (new) - stateless-addrconf : Many documents were refined The following test report done with the Test Packages were opened: - freebsd228-stable-19990809 --- TAHI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 18:23:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA04942 for ipng-dist; Wed, 11 Aug 1999 18:19:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04935 for ; Wed, 11 Aug 1999 18:19:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA24819 for ; Wed, 11 Aug 1999 18:19:41 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA05608 for ; Wed, 11 Aug 1999 19:19:40 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Aug 1999 18:01:09 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Wed, 11 Aug 1999 18:01:08 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515737@RED-MSG-50> From: Richard Draves To: "'Cyndi Jung'" , David Borman Cc: ipng@sunroof.eng.sun.com Subject: RE: RFC 2529 (6over4) Date: Wed, 11 Aug 1999 18:01:11 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does it need to give guidance on the use of PMTU, both at v4 > and v6 levels? > Or just be silent. It only gets complicated if the v4 PMTU discovery is going to affect the v6 MTU. I think you can say that as a warning to implementors, but I think it's too tricky for you to give much additional guidance. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 22:29:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA05350 for ipng-dist; Wed, 11 Aug 1999 22:20:51 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05343 for ; Wed, 11 Aug 1999 22:20:37 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow.Eng.Sun.COM [129.146.86.77]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA696293; Wed, 11 Aug 1999 22:20:35 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.3+Sun/8.9.3) id WAA107383; Wed, 11 Aug 1999 22:19:41 -0700 (PDT) Date: Wed, 11 Aug 1999 22:19:41 -0700 (PDT) From: Mukesh Kacker Message-Id: <199908120519.WAA107383@lucknow.eng.sun.com> To: sm@bossette.engr.sgi.com Subject: Re: more 2292-bis comments Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I will comment on one of the comments from Sam Manthrope which is related to some changes in RFC2292bis that I contributed to. Sam wrote (among other things). > > 7. There seems to be some confusion as to whether the cmsg_len > field of struct cmsghdr includes the header length or > not. The definition says it does, as does the ascii > diagram, but some of the macro examples, CMSG_NXTHDR for > example, imply that it does not. I assume it is the > macro examples that are wrong. > I do not think CMSG_NXTHDR macro example is broken. In this draft the ALIGN_H and ALIGN_D macros to take care of the separate alignment boundaries are defined and used which could be contributing some confusion. The text says that on many implementations, the two could be identical. Also, the concept that cmsg_len includes the header as well as value is architecture derived from classic BSD Socket implementations (Reno) and I don't think any enhancements could try to "fix" or change that. Some more details follow that will explain the motivation for some of this change for CMSG_* stuff. It is hard to see this stuff now but if people move to 64 (or 128, 256 bit :-)) architectures in future these things begin to matter. :-). Note that the ASCII art for packing of ancillary data into buffers shows padding both after the header and data content. [ Solaris implementation uses different alignment valeis for the two boundaries ]. That had a conflict with the prototypes of the CMSG_LEN and CMSG_SPACE macros. I pointed out that brokenness two years ago in message "IPng 4240" sent on 3 August 1997 in what was then draft-stevens-advanced-api-04.txt but that was not taken care of and that turned into RFC2292. The problem was that with certain alignment choices and the implied definitions of CMSG_LEN and CMSG_SPACE required the "cmsg" pointer but only the "length" part was passed in. - CMSG_SPACE() is fixed by redefining it to be the upper bound on space (instead of exact boundary) needed to store an option which knowing the alignment choices can be computed and is in fact what is needed based on for what the CMSG_SPACE() is used for. In most implmentations it may in fact be the exact space but that is a property of the alignment boundaries chosen. (Passing "cmsg" to it would have been the wrong fix since it is called before filling and walking the control buffer is done.) - CMSG_LEN() still has only length. That implies a (not written in document) restriction that "hdr_alignment_boundary >= data_alignment_boundary". That happens to be true of all current implementations I am aware of. That is a broken restriction however, but here I have bowed to the compatibility monster. Another solution could be similar to what I had proposed two years ago. - define a new macro with a different name, for example, CMSG_FOO(cmsg, length)) which has both "cmsg" and "length" arguments which fixes the architectural problems. - deprecate/obsolete CMSG_LEN(). That would not affect any existing implementation as with their alignment choices, they can ignore the "cmsg" argument. I chose not to propose that as that would be larger change....and I was not sure how much change people would be comfortable with in this update of RFC2292. If people think fixing that aspect of Socket interface architecture is important, consider this a proposal to add the CMSG_FOO macro with prototype as above. (I would not get into choosing names now :-)). -Mukesh Kacker Internet Engineering mukesh.kacker@eng.sun.com Sun Microsystems Inc. +1-650-786-5156 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 11 22:40:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA05373 for ipng-dist; Wed, 11 Aug 1999 22:33:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05366 for ; Wed, 11 Aug 1999 22:32:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA19653; Wed, 11 Aug 1999 22:32:55 -0700 (PDT) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA18281; Wed, 11 Aug 1999 22:32:55 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA03268; Wed, 11 Aug 1999 22:32:53 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA21570; Wed, 11 Aug 1999 22:32:53 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id WAA43354; Wed, 11 Aug 1999 22:32:48 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199908120532.WAA43354@bossette.engr.sgi.com> Subject: Re: more 2292-bis comments To: Mukesh.Kacker@eng.sun.com (Mukesh Kacker) Date: Wed, 11 Aug 1999 22:32:47 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199908120519.WAA107383@lucknow.eng.sun.com> from "Mukesh Kacker" at Aug 11, 99 10:19:41 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have discussed this point off-line with Mukesh and withdraw the comment he references below. The macro isn't broken and the comment was down to my own misunderstanding of the ALIGN_[HD] macros/functions. Cheers, - Sam Mukesh Kacker wrote: > > > > I will comment on one of the comments from Sam Manthrope which is > related to some changes in RFC2292bis that I contributed to. > > Sam wrote (among other things). > > > > 7. There seems to be some confusion as to whether the cmsg_len > > field of struct cmsghdr includes the header length or > > not. The definition says it does, as does the ascii > > diagram, but some of the macro examples, CMSG_NXTHDR for > > example, imply that it does not. I assume it is the > > macro examples that are wrong. > > > > I do not think CMSG_NXTHDR macro example is broken. In this draft > the ALIGN_H and ALIGN_D macros to take care of the separate alignment > boundaries are defined and used which could be contributing some > confusion. The text says that on many implementations, the two could > be identical. > Also, the concept that cmsg_len includes the header as well as value > is architecture derived from classic BSD Socket implementations (Reno) > and I don't think any enhancements could try to "fix" or change that. > > Some more details follow that will explain the motivation for some > of this change for CMSG_* stuff. > It is hard to see this stuff now but if people move to 64 > (or 128, 256 bit :-)) architectures in future these things begin to > matter. :-). > Note that the ASCII art for packing of ancillary data into buffers > shows padding both after the header and data content. [ Solaris implementation > uses different alignment valeis for the two boundaries ]. > That had a conflict with the prototypes of the CMSG_LEN and CMSG_SPACE > macros. I pointed out that brokenness two years ago in message "IPng 4240" > sent on 3 August 1997 in what was then draft-stevens-advanced-api-04.txt but > that was not taken care of and that turned into RFC2292. > The problem was that with certain alignment choices and the implied > definitions of CMSG_LEN and CMSG_SPACE required the "cmsg" pointer but > only the "length" part was passed in. > > - CMSG_SPACE() is fixed by redefining it to be the upper bound on space > (instead of exact boundary) needed to store an option which knowing the > alignment choices can be computed and is in fact what is needed based on > for what the CMSG_SPACE() is used for. In most implmentations it may in > fact be the exact space but that is a property of the alignment boundaries > chosen. (Passing "cmsg" to it would have been the wrong fix since it is > called before filling and walking the control buffer is done.) > > - CMSG_LEN() still has only length. That implies a (not written in document) > restriction that "hdr_alignment_boundary >= data_alignment_boundary". > That happens to be true of all current implementations I am aware of. > That is a broken restriction however, but here I have bowed to the > compatibility monster. Another solution could be similar to what > I had proposed two years ago. > > - define a new macro with a different name, for example, > CMSG_FOO(cmsg, length)) which has both "cmsg" and "length" > arguments which fixes the architectural problems. > - deprecate/obsolete CMSG_LEN(). > > That would not affect any existing implementation as with their alignment > choices, they can ignore the "cmsg" argument. > I chose not to propose that as that would be larger change....and I > was not sure how much change people would be comfortable with in this > update of RFC2292. > If people think fixing that aspect of Socket interface architecture is > important, consider this a proposal to add the CMSG_FOO macro with > prototype as above. (I would not get into choosing names now :-)). > > -Mukesh Kacker > Internet Engineering > mukesh.kacker@eng.sun.com > Sun Microsystems Inc. > +1-650-786-5156 > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 06:41:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA06014 for ipng-dist; Thu, 12 Aug 1999 06:38:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06007 for ; Thu, 12 Aug 1999 06:37:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA12856 for ; Thu, 12 Aug 1999 06:37:50 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17875 for ; Thu, 12 Aug 1999 07:37:49 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA127346; Thu, 12 Aug 1999 14:37:44 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA27850; Thu, 12 Aug 1999 14:37:42 +0100 (BST) Message-ID: <37B2CDA1.D9AF1488@hursley.ibm.com> Date: Thu, 12 Aug 1999 08:35:29 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: "'Cyndi Jung'" Subject: SHOULD NOT set DF [was Re: RFC 2529 (6over4)] References: <4D0A23B3F74DD111ACCD00805F31D81014515737@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The co-authors of 2529 propose that whenever the document is revised, we change to saying that the encapsulator SHOULD NOT set DF, and that for now implementors proceed on that basis. Thanks again to Sowmini for the detailed review that sparked this conversation. We probably want to wait for more interoperability experience before actually revising the RFC. Brian + Cyndi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 07:11:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA06111 for ipng-dist; Thu, 12 Aug 1999 07:07:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06104 for ; Thu, 12 Aug 1999 07:07:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA18932 for ; Thu, 12 Aug 1999 07:07:28 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26370 for ; Thu, 12 Aug 1999 08:07:27 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA16657; Thu, 12 Aug 1999 10:07:26 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000023283; Thu, 12 Aug 1999 10:07:26 -0400 (EDT) From: Jim Bound Message-Id: <199908121407.KAA0000023283@quarry.zk3.dec.com> To: Richard Draves cc: "'Jim Bound'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 Src/Dst Address Pairing In-reply-to: Your message of "Tue, 10 Aug 1999 21:16:56 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515719@RED-MSG-50> Date: Thu, 12 Aug 1999 10:07:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >Jim, when I referred to mapping kernel memory into user space, I was only >talking about a fast way for user code to get at the current time. (If you >check, you might find that your OS already does this. Many do.) I was NOT >suggesting that you create new mappings so that user code could read IPv6 >source addresses directly out of the kernel. I would suggest that you use an >ioctl or some such for that purpose. Hmmm. I knew that. I would suggest I was using ioctls and mapping memory before you went to college. But thanks. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 08:00:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA06182 for ipng-dist; Thu, 12 Aug 1999 07:56:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06175 for ; Thu, 12 Aug 1999 07:56:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA26835 for ; Thu, 12 Aug 1999 07:56:32 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13719 for ; Thu, 12 Aug 1999 08:56:31 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA05823; Thu, 12 Aug 1999 10:56:31 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000029597; Thu, 12 Aug 1999 10:56:30 -0400 (EDT) From: Jim Bound Message-Id: <199908121456.KAA0000029597@quarry.zk3.dec.com> To: gja@dnrc.bell-labs.com cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4)/ MUST NOT DF In-reply-to: Your message of "Wed, 11 Aug 1999 10:31:50 EDT." <37B18956.96CC48DD@dnrc.bell-labs.com> Date: Thu, 12 Aug 1999 10:56:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Seems to me that's the very definition of SHOULD NOT clauses. They're >the ones that generally ought not to be done, but if the implementors >are sufficiently clueful about the 'tricky' implementation consequences >then they can chose to do so. Inserting a MUST NOT just means that >clueful implementors who want to go that extra effort will be shouted >at for being non-compliant. This was the jist of Sowmini's first premise. I agree with that then and with the above. Just make it a SHOULD NOT and lets move on here. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 08:39:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA06281 for ipng-dist; Thu, 12 Aug 1999 08:35:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06274 for ; Thu, 12 Aug 1999 08:35:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA03334 for ; Thu, 12 Aug 1999 08:35:13 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00728 for ; Thu, 12 Aug 1999 08:35:13 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA28798; Thu, 12 Aug 1999 11:35:03 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000007821; Thu, 12 Aug 1999 11:35:02 -0400 (EDT) From: Jim Bound Message-Id: <199908121535.LAA0000007821@quarry.zk3.dec.com> To: robert@digi-data.com cc: Jim Bound , IPng Mailing List Subject: Re: IPv6 Src/Dst Address Pairing In-reply-to: Your message of "Wed, 11 Aug 1999 12:16:01 EDT." <99Aug11.120845gmt-0400.15237@odin.digi-data.com> Date: Thu, 12 Aug 1999 11:35:02 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, >> If a node exists in a DNS implementation where the server orders the >> addresses returned for load balancing or some other reasons then the >> node should realize using the src/dst match algorithm knob will most >> likely result in the order provided by the DNS server as null and void. >Why should it render the order provided by the DNS Server as null and void? >The fact that this node is querying the DNS indicates that it is preparing to >initiate a transmission (possibly creating a new connection) to the node >that is the subject of the DNS query. That is, these addresses are all >candidates to be selected by the originating node as a destination address. >In that case, how does choosing one of the addresses as the destination >address from the list returned by the DNS Server invalidate the order >provided by the DNS server? It is still possible that the originating node >would choose to use the candidate address at the top of the list returned >by the DNS server. In this case I mention (very specific too) the DNS is sending back an ordered list of addresses to you use in hostent with the best load balancing information it has at this time. So for example the query returns: 3ffe:134::1 (best node to use for performance via load) 3ffe:103::4 4ffe::2 5ffe::6 (worst node to use for peformance via load) But the src/dst match reorders the return after matching src addresses in the hostent structure back to getipnodebyanme as follows: 5ffe::6 (worst node to use for peformance via load) 3ffe:103::4 4ffe::2 3ffe:134::1 (best node to use for performance via load) What has happend is this. We now have the optimal src/dst match going to the kernel first as getipnodebyname will use 5ffe::6, but now the worst dst interface to use as far as DNS load balancing was concerned when it responded to the query. Hence, making it null and void for sending it anyway. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 08:55:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA06332 for ipng-dist; Thu, 12 Aug 1999 08:52:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06325 for ; Thu, 12 Aug 1999 08:51:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA18585 for ; Thu, 12 Aug 1999 08:51:57 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07710 for ; Thu, 12 Aug 1999 08:51:57 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA14460; Thu, 12 Aug 1999 11:51:56 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000009741; Thu, 12 Aug 1999 11:51:55 -0400 (EDT) From: Jim Bound Message-Id: <199908121551.LAA0000009741@quarry.zk3.dec.com> To: Richard Draves cc: "'David Borman'" , ipng@sunroof.eng.sun.com Subject: Re: RFC 2529 (6over4) In-reply-to: Your message of "Wed, 11 Aug 1999 12:45:15 PDT." <4D0A23B3F74DD111ACCD00805F31D8101451572A@RED-MSG-50> Date: Thu, 12 Aug 1999 11:51:55 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> HIPPI doesn't have a link MTU. It can send as large of a packet as >> you want. It's one of the reasons there is an IPv6 Jumbogram option. > >OK, ND does allow for that. Called a "variable MTU" link. But the >expectation is that an administrator will specify a single MTU for the >entire link using the MTU option in Router Advertisements. We have to be very careful to outlaw expectations we assume in a standards body. If ND was liberal on this then we need to be liberal in our assumptions as we build tools and enhancments with ND related techonology. Hence, a MUST NOT is not a good idea on this thread. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 10:16:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA06462 for ipng-dist; Thu, 12 Aug 1999 10:11:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06455 for ; Thu, 12 Aug 1999 10:11:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA17044 for ; Thu, 12 Aug 1999 10:11:06 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09328 for ; Thu, 12 Aug 1999 11:10:33 -0600 (MDT) Received: by odin.digi-data.com id <15237>; Thu, 12 Aug 1999 13:05:28 -0400 Message-Id: <99Aug12.130528gmt-0400.15237@odin.digi-data.com> Date: Thu, 12 Aug 1999 13:12:46 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound , IPng Mailing List Subject: Re: IPv6 Src/Dst Address Pairing References: <199908121535.LAA0000007821@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Jim, Jim Bound wrote: > > Hi Robert, > > > In this case I mention (very specific too) the DNS is sending back an > ordered list of addresses to you use in hostent with the best load > balancing information it has at this time. So for example the query > returns: > > 3ffe:134::1 (best node to use for performance via load) > 3ffe:103::4 > 4ffe::2 > 5ffe::6 (worst node to use for peformance via load) > > But the src/dst match reorders the return after matching src addresses > in the hostent structure back to getipnodebyanme as follows: > > 5ffe::6 (worst node to use for peformance via load) > 3ffe:103::4 > 4ffe::2 > 3ffe:134::1 (best node to use for performance via load) > > What has happend is this. We now have the optimal src/dst match going > to the kernel first as getipnodebyname will use 5ffe::6, but now the > worst dst interface to use as far as DNS load balancing was concerned when > it responded to the query. Hence, making it null and void for sending > it anyway. > Now I see what you mean. I was thinking that I can use the Src/Dst address pairing algorithm to choose one of the candidate destination addresses returned by DNS and one of my interface addresses for use in this new transmission. I was not necessarily considering altering the order in which the addresses were presented by the DNS. But then that begs the question. If the DNS in question uses the ordering of the addresses, to facilitate load-balancing or any other such favourable objective, is it not also possible to bias the address selection algorithm to take that ordering into account as well? What I am thinking about here is there is a (conceptual?) matrix M[i,j] of weights such that each M[i,j] represents the degree of "goodness" of the address pair Src[i] and Dst[j]. What we can then do is to multiply each M[i,j] by some biasing factor dependent upon the position of the particular destination address appeared in the list returned by the DNS. Also, this would require that all DNS implementations apply the same meaning to the ordering of the addresses they return. I know that using a bias in the address selection process to take into account the order in which the addresses were returned by the DNS does not completely answer the question of invalidating the order returned by the DNS, but it does not completely ignore it either. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 11:02:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA06573 for ipng-dist; Thu, 12 Aug 1999 10:56:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06566 for ; Thu, 12 Aug 1999 10:56:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA28875 for ; Thu, 12 Aug 1999 10:56:30 -0700 (PDT) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA29209 for ; Thu, 12 Aug 1999 10:56:29 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Aug 1999 10:29:30 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2448.0) id ; Thu, 12 Aug 1999 10:29:28 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451573D@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" , robert@digi-data.com Cc: IPng Mailing List Subject: RE: IPv6 Src/Dst Address Pairing Date: Thu, 12 Aug 1999 10:29:25 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In this case I mention (very specific too) the DNS is sending back an > ordered list of addresses to you use in hostent with the best load > balancing information it has at this time. I think the ordering of the addresses inside getipnodebyname() should be a "stable sort", so if there's a tie between two addresses (looking at the node's own source addresses, there is no reason to prefer one destination address over another destination address), then the two addresses are left in the same order returned by DNS. I think this should produce pretty good results - When the DNS order is trying to load-balance among a cluster of closely connected servers (so they have similar prefixes), then the getipnodebyname() ordering will leave the DNS order alone. When the DNS order is trying to load-balance among servers that are far apart in the Internet (so they have different prefixes), then the getipnodebyname() ordering will favor servers that are closer to the host. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 11:13:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA06612 for ipng-dist; Thu, 12 Aug 1999 11:08:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06604 for ; Thu, 12 Aug 1999 11:08:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA01917 for ; Thu, 12 Aug 1999 11:08:32 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03241 for ; Thu, 12 Aug 1999 12:08:31 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id OAA29492; Thu, 12 Aug 1999 14:08:30 -0400 (EDT) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000032413; Thu, 12 Aug 1999 14:08:29 -0400 (EDT) Date: Thu, 12 Aug 1999 14:08:29 -0400 (EDT) From: Sowmini Varadhan Message-Id: <199908121808.OAA0000032413@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: SHOULD NOT set DF Cc: brian@hursley.ibm.com, cmj@3Com.com, varadhan@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >We probably want to wait for more >interoperability experience before actually revising the >RFC. That's a good proposal- we should also be in a better position to look at any existing multicasting and scalability issues when data from interop experiments are available. Thanks, --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 11:35:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA06693 for ipng-dist; Thu, 12 Aug 1999 11:25:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06686; Thu, 12 Aug 1999 11:24:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA16551; Thu, 12 Aug 1999 11:24:58 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12328; Thu, 12 Aug 1999 11:24:57 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id OAA30936; Thu, 12 Aug 1999 14:24:55 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000011853; Thu, 12 Aug 1999 14:24:55 -0400 (EDT) From: Jim Bound Message-Id: <199908121824.OAA0000011853@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu Subject: FYI: IPv6 Forum Deployment Technical Directorate Date: Thu, 12 Aug 1999 14:24:54 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- Forwarded Message Return-Path: bound@quarry.zk3.dec.com Received: from quarry.zk3.dec.com by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM) id NAA0000023671; Thu, 12 Aug 1999 13:50:14 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000029337; Thu, 12 Aug 1999 13:49:50 -0400 (EDT) From: Jim Bound Message-Id: <199908121749.NAA0000029337@quarry.zk3.dec.com> To: deployment@ipv6.org, members@ipv6forum.com cc: bound@zk3.dec.com, perry@piermont.com, tim@mentat.com, peter@jazz-1.trumpet.com.au, cmj@nsd.3com.com, mccann@zk3.dec.com, bzill@microsoft.com, Francis.Dupont@inria.fr, Marc.Blanchet@viagenie.qc.ca, dmf@unl.edu, thomas.eklund@broadswitch.com, venaas@alfa.itea.ntnu.no, haberman@raleigh.ibm.com, crawdad@fnal.gov, halley@vix.com, deering@cisco.com, hinden@iprg.nokia.com, huitema@bellcore.com, brian@hursley.ibm.com, sob@harvard.edu, mankin@ISI.EDU, RLFink@lbl.gov, Charles.Perkins@eng.sun.com Subject: IPv6 Forum Deployment Technical Directorate Initial Members Date: Thu, 12 Aug 1999 13:49:49 -0400 X-Mts: smtp Folks, Perry and I would like to notify you that we have identified the initial Technical Directorate members and we also felt it important to ask Sr. Technical folks who have been around IPv6 and networks for some time to be part of the Directorate as Advisors. See other caveats below too. The list is as follows: IPv6 Deployment Technical Directorate. Jim Bound & Co-Chair Perry Metzger & Co-Chair Tim Hartrick Peter Tattam Cyndi Jung Jack McCann Brian Zill Francis Dupont Marc Blanchet Dale Finkelson Thomas Eckland Stig Venass Brian Haberman Matt Crawford Bob Halley Advisors: Bob Hinden Steve Deering Brian Carpenter Allison Mankin Christian Huitema Bob Fink Charlie Perkins Scott Bradner We still are awaiting responses from other folks for the Directorate and have run into vacation times we believe. These folks are doing this for free and here are some caveats we will use to guide the Directorate: 1. The Tech Directorate will be a body to do a logic check on all technical materials and deployment strategies by the IPv6 Forum in their fever to get IPv6 deployed, which is presented to the market. It will also do education. 2. The Tech Directorate will make recommendations on deploymemnt and implementation tradeoffs for deployment if those kind of problems arise too, as it releates to IPv6 Forum marketing. 3. The Tech Directorate if it finds errors in IPv6 in their work above will relay that back to the IETF. The Directorate is not to ever become anything like the ATM Forum nor define protocols for IPv6. 4. The Tech Direcorate also is autonoumous to the IPv6 Forum so we have no Kings or Queens either, the Directorate is a complimentary body to the IPv6 Forum. 5. Tech Directorate members will do presentations and be on hand for IPv6 Forum activities when possible but that is not required as a Tech Directorate member. For some cases it may be required that the IPv6 Forum pay for the Travel/Expense for Tech Directorate members when they do not work for large corporate enterprises, if possible. 6. The Tech Directorate will have a mail list soon that folks can use which Marc Blanchet will set up soon. It is perceived the Tech Directorate will have scheduled con-calls to meet and discuss issues about every 6 weeks and as required. Tech Directorate members should be at IETF meetings as that event can be a place to huddle as a team. 7. The only real differentiation in the Advisor role is they are not expected to do "work" consistently as required by other members as most of them are busy in this space in other areas, but to help advise us on the tough deployment technical issues where there are multiple choices. We would like to note that some requests for members were turned down by the person contacted because there is some work load here, this is not expected of the Advisors. 8. Tech Directorate members must be technical and an active participant for the deployment of IPv6 in some manner which can be research, product implememntation, significant IETF IPv6 contributions, network managment and opertions DRI, etc.... 9. Other roles to evolve if necessary or adjuncts to the these caveats. Sincerely, /jim and p.m. ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 12:18:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA06846 for ipng-dist; Thu, 12 Aug 1999 12:13:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06839 for ; Thu, 12 Aug 1999 12:13:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA14785 for ; Thu, 12 Aug 1999 12:13:03 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00866 for ; Thu, 12 Aug 1999 13:13:02 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA17736; Thu, 12 Aug 1999 21:13:00 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA06454; Thu, 12 Aug 1999 21:13:00 +0200 (MET DST) Message-Id: <199908121913.VAA06454@givry.inria.fr> From: Francis Dupont To: Vladislav Yasevich cc: IPNG Working Group Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Wed, 11 Aug 1999 10:09:05 EDT. <37B18401.B1DB9F40@zk3.dec.com> Date: Thu, 12 Aug 1999 21:12:59 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Section 2.1.2 [Page 9] - The reviewers were questioning the need for the following definition: 490 struct in6_addr ip6r0_addr[1]; /* up to 127 addresses */ This definition made the ip6_rthdr0 structure stick out from all the others. The suggestion is to remove this line and add a comment (just like all the other header structures) that states that the Routing Header 0 is followed by an array of IPv6 addresses. => I agree. In fact you can have zero addresses in a routing header (not very useful if you are not tracking bug). I believe one'd like to have ip6r0_addr[0] but some compilers don't like that... Section 2.2.1 [page 11] - The following definition is no longer valid: 614 #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */ It now refers to an address that is beyond the scope of source address as defined in Section 3.1 of draft-ietf-ipngwg-icmp-v3-00.txt The draft defines the code value 2 as "beyond scope of source address". => I propose ICMP6_DST_UNREACH_BEYONDSCOPE Section 5.1 [page 26] - What is the precedence of sin6_scope_id relative to the interface specified by the IPV6_MULTICAST_IF, IPV6_PKTINFO and/or IPV6_NEXTHOP options? => this is an important issue (one already found a code with conflicting IPV6_MULTICAST_IF, IPV6_PKTINFO and sin6_scope_id...) Sections 12.2 and 12.3 - What was the reason to put rcmd_af() and rexec_af() in this spec? => I agree but this is not an important issue. Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 12 12:44:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA06941 for ipng-dist; Thu, 12 Aug 1999 12:39:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06934 for ; Thu, 12 Aug 1999 12:38:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA03998 for ; Thu, 12 Aug 1999 12:38:58 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10129 for ; Thu, 12 Aug 1999 13:38:57 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA28512; Thu, 12 Aug 1999 12:31:45 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA15803; Thu, 12 Aug 1999 12:31:45 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id MAA08511; Thu, 12 Aug 1999 12:31:52 -0700 (PDT) Date: Thu, 12 Aug 1999 12:31:52 -0700 (PDT) From: Tim Hartrick Message-Id: <199908121931.MAA08511@feller.mentat.com> To: vlad@zk3.dec.com, Francis.Dupont@inria.fr Subject: Re: Comments on 2292bis (Adv. API) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, Vladislav, > > In your previous mail you wrote: > > Section 2.1.2 [Page 9] > - The reviewers were questioning the need for the following definition: > 490 struct in6_addr ip6r0_addr[1]; /* up to 127 addresses */ > > This definition made the ip6_rthdr0 structure stick out from all the others. > The suggestion is to remove this line and add a comment (just like all the > other header structures) that states that the Routing Header 0 is followed > by an array of IPv6 addresses. > > => I agree. In fact you can have zero addresses in a routing header > (not very useful if you are not tracking bug). I believe one'd like > to have ip6r0_addr[0] but some compilers don't like that... > Removing this field seems like a win. > Section 2.2.1 [page 11] > - The following definition is no longer valid: > 614 #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */ > > It now refers to an address that is beyond the scope of source address as > defined in Section 3.1 of draft-ietf-ipngwg-icmp-v3-00.txt > The draft defines the code value 2 as "beyond scope of source address". > > => I propose ICMP6_DST_UNREACH_BEYONDSCOPE > Sounds fine to me. > Section 5.1 [page 26] > - What is the precedence of sin6_scope_id relative to the interface > specified by the IPV6_MULTICAST_IF, IPV6_PKTINFO and/or IPV6_NEXTHOP > options? > > => this is an important issue (one already found a code with conflicting > IPV6_MULTICAST_IF, IPV6_PKTINFO and sin6_scope_id...) > I would say that a non-zero sin6_scope_id overrides the IPV6_MULTICAST_IF option and that the interface indices in the IPV6_PKTINFO and IPV6_NEXTHOP options override the sin6_scope_id. The logic being that if the application goes to the trouble to specify a scope identifier in the sockaddr_in6 it probably wants it to override a previous setting of the IPV6_MULTICAST_IF option. Likewise, if the application goes to the effort of building ancillary data items (IPV6_PKTINFO and IPV6_NEXTHOP) it probably intends for the values specified in the ancillary data to be authoritative. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 13 11:38:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA07892 for ipng-dist; Fri, 13 Aug 1999 11:16:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07885 for ; Fri, 13 Aug 1999 11:16:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA06943 for ; Fri, 13 Aug 1999 11:16:31 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01598 for ; Fri, 13 Aug 1999 12:16:28 -0600 (MDT) Received: from [171.68.180.188] (sj-dial-1-244.cisco.com [171.68.179.245]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA02433; Fri, 13 Aug 1999 11:16:20 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515728@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014515728@RED-MSG-50> Date: Fri, 13 Aug 1999 11:16:16 -0700 To: Richard Draves From: Steve Deering Subject: RE: RFC 2529 (6over4) Cc: "'David Borman'" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:45 AM -0700 8/11/99, Richard Draves wrote: > ...It's a little strange since normally I would expect to >use the link MTU to reach any neighbor on the link, and could only have a >path MTU smaller than the link MTU if the packet is traversing multiple >links. Rich, The IPv6 Path MTU Discovery spec (RFC 1981), last paragraph of section 3, says: Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself. In a situation such as when a neighboring router acts as proxy [ND] for some destination, the destination can to appear to be directly connected but is in fact more than one hop away. The 6over4 discussion has pointed out another situation that justifies the above requirement . Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 01:07:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA09913 for ipng-dist; Mon, 16 Aug 1999 01:03:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09906 for ; Mon, 16 Aug 1999 01:03:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA21202 for ; Mon, 16 Aug 1999 01:03:28 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18053 for ; Mon, 16 Aug 1999 02:03:14 -0600 (MDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id QAA24791; Mon, 16 Aug 1999 16:54:28 +0900 (JST) Date: Mon, 16 Aug 1999 17:04:07 +0900 Message-ID: <14263.50679.209399.57571Q@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Cc: vlad@zk3.dec.com, Francis.Dupont@inria.fr Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Thu, 12 Aug 1999 21:12:59 +0200" <199908121913.VAA06454@givry.inria.fr> References: <37B18401.B1DB9F40@zk3.dec.com> <199908121913.VAA06454@givry.inria.fr> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 83 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 12 Aug 1999 21:12:59 +0200, >>>>> Francis Dupont said: > Section 2.2.1 [page 11] > - The following definition is no longer valid: > 614 #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */ > It now refers to an address that is beyond the scope of source address as > defined in Section 3.1 of draft-ietf-ipngwg-icmp-v3-00.txt > The draft defines the code value 2 as "beyond scope of source address". > => I propose ICMP6_DST_UNREACH_BEYONDSCOPE Agreed. In fact, the latest KAME snap uses (and the forthcoming "unified" stack may also use) ICMP6_DST_UNREACH_BEYONDSCOPE. Also, some KAME's userland applications such as tcpdump and ping6 have already been rewritten on the new macro basis. I would also like to propose to updating macro names as much as current specification like. For example, macro names for MLD related messages are not very MLD-like: #define ICMP6_MEMBERSHIP_QUERY 130 #define ICMP6_MEMBERSHIP_REPORT 131 #define ICMP6_MEMBERSHIP_REDUCTION 132 On the other hand, the corresponding messages in the MLD specification are Multicast Listener Query, Multicast Listener Report, and Multicast Listener Done, respectively. Though the meaning does not change, the names defined in the RFC 2292 (and 2292bis) are a bit confusing for application programmers. Just FYI, KAME locally defines the following definitions (please note that we don't insist on these local definitions at all): #define MLD6_LISTENER_QUERY 130 /* multicast listener query */ #define MLD6_LISTENER_REPORT 131 /* multicast listener report */ #define MLD6_LISTENER_DONE 132 /* multicast listener done */ Moreover, there are some new protocols that have been defined since RFC 2292 and are about to be standardized, e.g. Router Renumbering Router Alert Option ICMPv6 name lookups Mobile IPv6 ... I admit that it's hard (even impossible) to catch up all such new protocols, but 2292bis would be a good opportunity. I hope the revised API reflects as much changes as possible. Again, just FYI, KAME locally defines the following definitions for some of the above new protocols: Macros for router renumbering: #define ICMP6_ROUTER_RENUMBERING_COMMAND 0 /* rr command */ #define ICMP6_ROUTER_RENUMBERING_RESULT 1 /* rr result */ #define ICMP6_ROUTER_RENUMBERING_SEQNUM_RESET 255 /* rr seq num reset */ Macros for ICMPv6 name lookups: #define ICMP6_FQDN_QUERY 139 /* FQDN query */ #define ICMP6_FQDN_REPLY 140 /* FQDN reply */ #define ICMP6_NI_QUERY 139 /* node information request */ #define ICMP6_NI_REPLY 140 /* node information reply */ #define ICMP6_NI_SUCESS 0 /* node information successful reply */ #define ICMP6_NI_REFUSED 1 /* node information request is refused */ #define ICMP6_NI_UNKNOWN 2 /* unknown Qtype */ Macros for IPv6 Router Alert HbH option: #define IP6OPT_RTALERT 0x05 /* 00 0 00101 */ #define IP6OPT_RTALERT_MLD 0 /* Datagram contains an MLD message */ #define IP6OPT_RTALERT_RSVP 1 /* Datagram contains an RSVP message */ #define IP6OPT_RTALERT_ACTNET 2 /* contains an Active Networks msg */ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 03:55:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA10037 for ipng-dist; Mon, 16 Aug 1999 03:52:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10030 for ; Mon, 16 Aug 1999 03:52:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA10880 for ; Mon, 16 Aug 1999 03:52:13 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02300 for ; Mon, 16 Aug 1999 03:52:08 -0700 (PDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id TAA25027; Mon, 16 Aug 1999 19:41:29 +0900 (JST) Date: Mon, 16 Aug 1999 19:51:06 +0900 Message-ID: <14263.60698.673536.12718B@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Thu, 12 Aug 1999 12:31:52 -0700 (PDT)" <199908121931.MAA08511@feller.mentat.com> References: <199908121931.MAA08511@feller.mentat.com> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 104 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 12 Aug 1999 12:31:52 -0700 (PDT), >>>>> Tim Hartrick said: >> Section 5.1 [page 26] >> - What is the precedence of sin6_scope_id relative to the interface >> specified by the IPV6_MULTICAST_IF, IPV6_PKTINFO and/or IPV6_NEXTHOP >> options? >> >> => this is an important issue (one already found a code with conflicting >> IPV6_MULTICAST_IF, IPV6_PKTINFO and sin6_scope_id...) >> > I would say that a non-zero sin6_scope_id overrides the IPV6_MULTICAST_IF > option and that the interface indices in the IPV6_PKTINFO and IPV6_NEXTHOP > options override the sin6_scope_id. > The logic being that if the application goes to the trouble to specify a > scope identifier in the sockaddr_in6 it probably wants it to override a > previous setting of the IPV6_MULTICAST_IF option. > Likewise, if the application goes to the effort of building ancillary data > items (IPV6_PKTINFO and IPV6_NEXTHOP) it probably intends for the values > specified in the ancillary data to be authoritative. Basically agreed, but as for sin6_scope_id, I'd rather discuss a more fundamental issue; its semantics. RFC 2553 says about sin6_scope_id just as follows: The sin6_scope_id field is a 32-bit integer that identifies a set of interfaces as appropriate for the scope of the address carried in the sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an interface index. For a site scope sin6_addr, sin6_scope_id would be a site identifier. The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of site identifiers. (section 3.3) The description seems to me not enough specific to ensure portability. For example, the followings are not clear: - if we set a non-zero value to sin6_scope_id and a link-local unicast address to sin6_addr, should the corresponding packet be sent on the interface specified by the value of sin6_scope_id field? - if we receive a packet via recvfrom(or recvmsg, or whatever) and the from(i.e. source) address of the packet is a link-local address, should the sin6_scope_id field be set the index of the receiving interface? Should we allow the kernel to set zero to the field even if the `from' address is link-local? - as RFC says, the specification is ambiguous for site-local addresses. - if we set a non-zero value to sin6_scope_id and a global unicast address to sin6_addr, what should the kernel do? Return an error? Ignore the value? Or send the packet to the interface whose index is the specified value? Which value should the kernel set to sin6_scope_id when receiving from a global address? - all the above questions are also applied for multicast addresses. - suppose that we set a non-zero value to sin6_scope_id, set a link-local address to sin6_addr, and call bind() with the socket address. When we try to send a packet to the socket, should the kernel send the packet to the interface specified by the sin6_scope_id passed to bind()? What if we try to send a packet specifying the destination by a socket address whose sin6_addr is also link-local and whose sin6_scope_id is a different value than the value set by bind()? Even granted that the above points were clear, it would be also complicated to define preference among related ancillary data, setsockopt, and system calls. So, as a starter, let me clarify the methods to specify the source address and to specify the outgoing interface: (possible)methods to specify the source address IPV6_PKTINFO cmsg type IPV6_PKTINFO setsockopt bind system call (possible)methods to specify the outgoing interface IPV6_PKTINFO cmsg type IPV6_PKTINFO setsockopt IPV6_NEXTHOP cmsg type IPV6_NEXTHOP setsockopt IPV6_MULTICAST_IF setsockopt connect system call sendto and sendmsg system calls (bind system call - see above question -) (maybe I miss something) Then we should discuss the preference among them. It's not so trivial for me, so I'd like to stop here and listen to other implementors. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 08:15:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA10196 for ipng-dist; Mon, 16 Aug 1999 08:12:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10188 for ; Mon, 16 Aug 1999 08:12:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA15952 for ; Mon, 16 Aug 1999 08:12:11 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10505 for ; Mon, 16 Aug 1999 09:12:06 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA26126; Mon, 16 Aug 1999 17:05:13 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id RAA28252; Mon, 16 Aug 1999 17:05:13 +0200 (MET DST) Message-Id: <199908161505.RAA28252@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com, vlad@zk3.dec.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Mon, 16 Aug 1999 17:04:07 +0900. <14263.50679.209399.57571Q@condor.isl.rdc.toshiba.co.jp> Date: Mon, 16 Aug 1999 17:05:11 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => I agree for everything with these exceptions: Macros for router renumbering: #define ICMP6_ROUTER_RENUMBERING_COMMAND 0 /* rr command */ #define ICMP6_ROUTER_RENUMBERING_RESULT 1 /* rr result */ #define ICMP6_ROUTER_RENUMBERING_SEQNUM_RESET 255 /* rr seq num reset */ => I prefer shorter ICMP6_RT_RENUM_COMMAND, ... ie I replace _ROUTER_RENUMBERING_ by _RT_RENUM_ for router renumbering "sub-definitions". (I don't like names with more than 32 characters even I expect the compilers I use can manage real long names :-) Macros for ICMPv6 name lookups: => I think we should wait for the new I-D (but the style is fine for me)? Macros for IPv6 Router Alert HbH option: => I use a different style: #define OPT6_ROUTER_ALERT 5 /*** Router Alert */ struct opt6_ra { /* Router-Alert */ u_int8_t ra_ext; /* extension type (*** 5) */ u_int8_t ra_len; /* length (2) */ u_int16_t ra_code; /* code */ }; #define OPT6_RA_GROUP 0 /* ICMPv6 Group Membership */ (will be replaced by OPT6_RA_MLD at the next cleanup) #define OPT6_RA_RSVP 1 /* RSVP */ #define OPT6_RA_ACTNET 2 /* Active Networks */ I'd REALLY like to have a standard way to defined properly aligned/packed option structures (opt6_ra & co definitions are in fact for documentation only). RFC 2460 "xn+y" notation is not yet used everywhere which is a *shame* and a source of problems for complex options like binding update! Of course I am (ie. my emacs is) ready to change definitions as soon as there is a rough consensus... Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 09:07:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA10242 for ipng-dist; Mon, 16 Aug 1999 09:03:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10235 for ; Mon, 16 Aug 1999 09:03:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA16360 for ; Mon, 16 Aug 1999 09:03:03 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04211 for ; Mon, 16 Aug 1999 09:03:02 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA11856; Mon, 16 Aug 1999 09:03:35 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA26038; Mon, 16 Aug 1999 09:03:35 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA09652; Mon, 16 Aug 1999 09:03:40 -0700 (PDT) Date: Mon, 16 Aug 1999 09:03:40 -0700 (PDT) From: Tim Hartrick Message-Id: <199908161603.JAA09652@feller.mentat.com> To: ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: Comments on 2292bis (Adv. API) Cc: vlad@zk3.dec.com, Francis.Dupont@inria.fr X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > #define MLD6_LISTENER_QUERY 130 /* multicast listener query */ > #define MLD6_LISTENER_REPORT 131 /* multicast listener report */ > #define MLD6_LISTENER_DONE 132 /* multicast listener done */ > In order to keep the namespace gods quite I would say that we should stick to ICMP6 prefix for all the ICMPv6 types and codes. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 09:18:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA10278 for ipng-dist; Mon, 16 Aug 1999 09:14:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10271 for ; Mon, 16 Aug 1999 09:14:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA18622 for ; Mon, 16 Aug 1999 09:14:24 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08649 for ; Mon, 16 Aug 1999 09:14:23 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1040:0:ff:fe00:0]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA25619; Tue, 17 Aug 1999 01:06:06 +0900 (JST) Date: Tue, 17 Aug 1999 01:15:44 +0900 Message-ID: <14264.14640.392592.74466C@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com, vlad@zk3.dec.com, Francis.Dupont@inria.fr Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Mon, 16 Aug 1999 09:03:40 -0700 (PDT)" <199908161603.JAA09652@feller.mentat.com> References: <199908161603.JAA09652@feller.mentat.com> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 16 Aug 1999 09:03:40 -0700 (PDT), >>>>> Tim Hartrick said: >> #define MLD6_LISTENER_QUERY 130 /* multicast listener query */ >> #define MLD6_LISTENER_REPORT 131 /* multicast listener report */ >> #define MLD6_LISTENER_DONE 132 /* multicast listener done */ > In order to keep the namespace gods quite I would say that we should > stick to ICMP6 prefix for all the ICMPv6 types and codes. Seems reasonable. I won't oppose to changing our definitions to, for, example, ICMP6_MLD_LISTENER_QUERY, or whatever. The only point that I want is to adopt MLD-like macro names. ##However, we've already had exception to the ICMP6_XXX rule; ND_xxx ##macros:-) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 09:33:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA10332 for ipng-dist; Mon, 16 Aug 1999 09:28:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10323 for ; Mon, 16 Aug 1999 09:28:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA10344 for ; Mon, 16 Aug 1999 09:28:02 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12707 for ; Mon, 16 Aug 1999 10:28:02 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA11907; Mon, 16 Aug 1999 09:20:28 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA26459; Mon, 16 Aug 1999 09:20:28 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA09665; Mon, 16 Aug 1999 09:20:33 -0700 (PDT) Date: Mon, 16 Aug 1999 09:20:33 -0700 (PDT) From: Tim Hartrick Message-Id: <199908161620.JAA09665@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp Subject: Re: Comments on 2292bis (Adv. API) Cc: vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > - if we set a non-zero value to sin6_scope_id and a link-local unicast > address to sin6_addr, should the corresponding packet be sent on the > interface specified by the value of sin6_scope_id field? > Yes. > - if we receive a packet via recvfrom(or recvmsg, or whatever) and > the from(i.e. source) address of the packet is a link-local address, > should the sin6_scope_id field be set the index of the receiving > interface? Should we allow the kernel to set zero to the field even > if the `from' address is link-local? > It should always be interface index of the receiving interface. > - as RFC says, the specification is ambiguous for site-local > addresses. > > - if we set a non-zero value to sin6_scope_id and a global unicast > address to sin6_addr, what should the kernel do? Return an error? > Ignore the value? Or send the packet to the interface whose index is > the specified value? I intend to ignore it since it is not meaningful global scope addresses, multicast or unicast. > Which value should the kernel set to sin6_scope_id when receiving > from a global address? > Zero. > - all the above questions are also applied for multicast addresses. > > - suppose that we set a non-zero value to sin6_scope_id, set a > link-local address to sin6_addr, and call bind() with the socket > address. When we try to send a packet to the socket, should the > kernel send the packet to the interface specified by the > sin6_scope_id passed to bind()? Not unless the packet would otherwise have gone out that interface. The source address selection in this case could be tricky. I would say that if the datagram is going to exit from the interface specified in the bind then use the bound address as the source, otherwise use a source address from the sending interface. > What if we try to send a packet specifying the destination > by a socket address whose sin6_addr is also link-local and whose > sin6_scope_id is a different value than the value set by bind()? > Then I would do the above. That is, send the datagram out the interface specified in the address of the sendto call and use the source address associated with the sending interface. > Even granted that the above points were clear, it would be also > complicated to define preference among related ancillary data, > setsockopt, and system calls. > > So, as a starter, let me clarify the methods to specify the source > address and to specify the outgoing interface: > > (possible)methods to specify the source address > IPV6_PKTINFO cmsg type > IPV6_PKTINFO setsockopt I may have misread the specification but I didn't think you could use the IPV6_PKTINFO option in a setsockopt. > bind system call > > (possible)methods to specify the outgoing interface > IPV6_PKTINFO cmsg type > IPV6_PKTINFO setsockopt > IPV6_NEXTHOP cmsg type > IPV6_NEXTHOP setsockopt I thought that this was ancillary data only as well. > IPV6_MULTICAST_IF setsockopt > connect system call > sendto and sendmsg system calls > (bind system call - see above question -) > (maybe I miss something) > > Then we should discuss the preference among them. It's not so trivial > for me, so I'd like to stop here and listen to other implementors. > You are correct that it is quite complicated. Many of these methods were developed a while ago when we hadn't considered all the ramifications of scoped addresses. We probably still haven't considered all the ramifications. Once I get the specification in front of me I will try and provide some opinions on the above. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 09:33:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA10311 for ipng-dist; Mon, 16 Aug 1999 09:26:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10304 for ; Mon, 16 Aug 1999 09:26:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09954 for ; Mon, 16 Aug 1999 09:26:01 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13111 for ; Mon, 16 Aug 1999 09:26:00 -0700 (PDT) Received: from arrowsmith.wrs.com (arrowsmith.wrs.com [147.11.38.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA20341 for ; Mon, 16 Aug 1999 09:25:59 -0700 (PDT) Received: from arrowsmith (localhost [127.0.0.1]) by arrowsmith.wrs.com (8.9.1/8.9.0) with ESMTP id JAA17840 for ; Mon, 16 Aug 1999 09:25:59 -0700 (PDT) Message-Id: <199908161625.JAA17840@arrowsmith.wrs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: ipng@sunroof.eng.sun.com Subject: Unified stack? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Aug 1999 09:25:59 -0700 From: George Neville-Neil Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Folks, I've been noticing the discussions about the unified stack which I figure is the work to put Wide, INRIA et al together in one place. I looked at the IPng web page and can't find a link to this work. Is there one yet? If so where? Thanks, George -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 09:33:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA10320 for ipng-dist; Mon, 16 Aug 1999 09:27:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10313 for ; Mon, 16 Aug 1999 09:27:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA20832 for ; Mon, 16 Aug 1999 09:27:14 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13768 for ; Mon, 16 Aug 1999 09:27:13 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id SAA27212; Mon, 16 Aug 1999 18:27:07 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id SAA27400; Mon, 16 Aug 1999 18:27:06 +0200 (MET DST) Message-Id: <199908161627.SAA27400@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: tim@mentat.com, vlad@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Mon, 16 Aug 1999 19:51:06 +0900. <14263.60698.673536.12718B@condor.isl.rdc.toshiba.co.jp> Date: Mon, 16 Aug 1999 18:27:04 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Basically agreed, but as for sin6_scope_id, I'd rather discuss a more fundamental issue; its semantics. => I interprete the specs as : - for link-local addresses and multicast addresses the sin6_scope_id is the index of the: * incoming interface on reception * outgoing interface on emission - for site-local addresses the sin6_scope_id should be a site number (something new, zero can be a real site number, ...) ??? - for other sin6_scope_id has no meaning (ignore on emission, zero on reception) As the sin6_scope_id is a local parameter it should be in host order. The description seems to me not enough specific to ensure portability. For example, the followings are not clear: - if we set a non-zero value to sin6_scope_id and a link-local unicast address to sin6_addr, should the corresponding packet be sent on the interface specified by the value of sin6_scope_id field? => yes - if we receive a packet via recvfrom (or recvmsg, or whatever) and the from (i.e. source) address of the packet is a link-local address, should the sin6_scope_id field be set the index of the receiving interface? => yes Should we allow the kernel to set zero to the field even if the `from' address is link-local? => no - as RFC says, the specification is ambiguous for site-local addresses. => we are going to know what is a site... (:-) It is on my plan to implement real multi-sited node one day (I believe I know a solution for the kernel/API stuff but routing daemon is still a problem, perhaps OSPFv6 (which is multi-process, ie one can run an OSPFv6 process per site on the same router) can help?) - if we set a non-zero value to sin6_scope_id and a global unicast address to sin6_addr, what should the kernel do? Return an error? Ignore the value? Or send the packet to the interface whose index is the specified value? => ignore the value which can be no more than a hint (ie if you have multiple routes for the destination you should select the one via the specified interface if there is one). If you can't say if it is an interface index or a site identifier (are spaces separate?) you are again in trouble (I have no multiple routes but this point should not be a reason to never get that!) Which value should the kernel set to sin6_scope_id when receiving from a global address? => zero (should not be the interface index because why not the site identifier... the user doesn't need it and will ignore it). - all the above questions are also applied for multicast addresses. => multicast addresses are exactly like link-local addresses even they have their own scope because a multicast destination without the outgoing interface is incomplete. - suppose that we set a non-zero value to sin6_scope_id, set a link-local address to sin6_addr, and call bind() with the socket address. When we try to send a packet to the socket, should the kernel send the packet to the interface specified by the sin6_scope_id passed to bind()? => sin6_scope_id in bind() should be for reception (ie. the socket will not received packet from another interface). What if we try to send a packet specifying the destination by a socket address whose sin6_addr is also link-local and whose sin6_scope_id is a different value than the value set by bind()? => argh! This is a real point and another case of precedence (here between bind and connect/send/... sin6_scope_id). I've just tried on my implementation: I consider sin6_scope_id has a small precedence then connect() sin6_scope_id is overruled by the bind() sin6_scope_id: packets (neighbor solicitations in fact) are sent on the previous interface... Even granted that the above points were clear, it would be also complicated to define preference among related ancillary data, setsockopt, and system calls. => you have just added a new item in the precedence table (in fact a new line without a value :-). Thanks Francis.Dupont@inria.fr PS: *tentative* precedence table (according to what I believe to have coded): source address: this can't be bound again when this is already bound. outgoing interface: IPV6_MULTICAST_IF < connect/send* < bind < full IPV6_PKTINFO (IPV6_NEXTHOP is not yet implemented; I've written "full IPV6_PKTINFO" because the address can be unspecified and/or the index zero. There are two reasons for the highest precedence for IPV6_PKTINFO: - it is the first proposed way to solve the multi-homed/interface issue - it is the only way to specify the outgoing interface address in a send* system call (bind() needs a fresh socket each time) An interface address is stronger than an interface index then IPV6_MULTICAST_IF has the lowest precedence. It is a rationate for connect/send* < bind even I've got this in my code by a side effect :-)) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 10:18:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA10476 for ipng-dist; Mon, 16 Aug 1999 10:13:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10469 for ; Mon, 16 Aug 1999 10:13:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA00762 for ; Mon, 16 Aug 1999 10:13:22 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02742 for ; Mon, 16 Aug 1999 10:13:21 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id TAA27644; Mon, 16 Aug 1999 19:06:26 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id TAA25604; Mon, 16 Aug 1999 19:06:25 +0200 (MET DST) Message-Id: <199908161706.TAA25604@givry.inria.fr> From: Francis Dupont To: Tim Hartrick cc: ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp, vlad@zk3.dec.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Mon, 16 Aug 1999 09:03:40 PDT. <199908161603.JAA09652@feller.mentat.com> Date: Mon, 16 Aug 1999 19:06:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > #define MLD6_LISTENER_QUERY 130 /* multicast listener query */ In order to keep the namespace gods quite I would say that we should stick to ICMP6 prefix for all the ICMPv6 types and codes. => I believe Jinmei's idea is to have both ICMP6_MEMBERSHIP_QUERY and MLD6_LISTENER_QUERY, isn't it? Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 16 19:28:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA11052 for ipng-dist; Mon, 16 Aug 1999 19:22:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11045 for ; Mon, 16 Aug 1999 19:21:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA07879 for ; Mon, 16 Aug 1999 19:21:49 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27662 for ; Mon, 16 Aug 1999 19:21:47 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id LAA26520; Tue, 17 Aug 1999 11:13:29 +0900 (JST) Date: Tue, 17 Aug 1999 11:23:09 +0900 Message-ID: <14264.51085.674015.3063M@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: tim@mentat.com, ipng@sunroof.eng.sun.com, vlad@zk3.dec.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Mon, 16 Aug 1999 19:06:23 +0200" <199908161706.TAA25604@givry.inria.fr> References: <199908161603.JAA09652@feller.mentat.com> <199908161706.TAA25604@givry.inria.fr> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 16 Aug 1999 19:06:23 +0200, >>>>> Francis Dupont said: > In your previous mail you wrote: >> #define MLD6_LISTENER_QUERY 130 /* multicast listener query */ > In order to keep the namespace gods quite I would say that we should > stick to ICMP6 prefix for all the ICMPv6 types and codes. > => I believe Jinmei's idea is to have both ICMP6_MEMBERSHIP_QUERY and > MLD6_LISTENER_QUERY, isn't it? That's right. It's my understanding that one of concerns of 2292bis is to insure lower compatibility(i.e. compatibility with old 2292). Since these two (old and new) macros can coexist, we should do so. Thanks for clarification, Francis. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 17 15:33:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA11968 for ipng-dist; Tue, 17 Aug 1999 15:27:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11961 for ; Tue, 17 Aug 1999 15:26:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA09000 for ; Tue, 17 Aug 1999 15:25:50 -0700 (PDT) Received: from isrv3.pa.vix.com (isrv3.pa.vix.com [204.152.184.182]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21663 for ; Tue, 17 Aug 1999 15:25:49 -0700 (PDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.pa.vix.com (8.9.1/8.9.1) via ESMTP id PAA24406 for ; Tue, 17 Aug 1999 15:25:49 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: from bb.rc.vix.com (localhost [127.0.0.1]) by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id PAA09117 for ; Tue, 17 Aug 1999 15:25:49 -0700 (PDT) env-from (Bob_Halley@iengines.net) Message-Id: <199908172225.PAA09117@bb.rc.vix.com> To: ipng@sunroof.eng.sun.com Subject: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses Date: Tue, 17 Aug 1999 15:25:49 -0700 From: Bob Halley Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk BIND is one of the applications that would like to use the IPV6_PKTINFO option. It would be great if BIND could simply create a single IPv6 UDP socket with a wildcard address and use it for both IPv4 and IPv6 requests, but in draft-ietf-ipngwg-2292bis-00.txt, section 11, it says [...] Some implementations, however, may provide access to the packet information (source/destination address, send/receive interface, and hop limit) on an IPv6 socket that is using IPv4-mapped IPv6 addresses. So, I cannot rely on using IPV6_PKTINFO for IPv4-mapped IPv6 addresses. Using a single socket both both v4 and v6 is tempting because: Only one fd is used. Interface scanning is not required. This has a security benefit, since after we bind() to port 53, we can drop privileges and still handle subsequent interface additions. Having IPv6 packet info for IPv4-mapped addresses is also desirable because we get interface information. The current method of binding a socket to each interface address ensures that responses we send will have a source address which is the same as the destination address the client used, but we do not know from which interface the packet was actually received, nor which interface the system will use when we send our response. I propose that either: Support of IPV6_PKTINFO for IPv4-mapped IPv6 addresses be made mandatory or Applications be given an easy way of determining (at compile time or run time) whether a given implementation supports IPV6_PKTINFO for IPv4-mapped IPv6 addresses I prefer the former, but realize that it may be too much of a burden to make mandatory. If support is not going to be mandatory, we need a definite way of knowing whether support is available. Also, in section 11 the draft says: In general, attempting to specify an IPv6-only option, such as the Hop-by-Hop options, Destination options, or Routing header on an IPv6 socket that is using IPv4-mapped IPv6 addresses, will probably result in an error. One interpretation of the text above would be that an implementation may silently ignore the option. I propose "will result in an error" instead of "will probably result in an error". /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 17 17:15:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA12099 for ipng-dist; Tue, 17 Aug 1999 17:11:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12092 for ; Tue, 17 Aug 1999 17:11:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA18777 for ; Tue, 17 Aug 1999 17:11:37 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03564 for ; Tue, 17 Aug 1999 17:11:35 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA11747 for ; Wed, 18 Aug 1999 09:11:33 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: gnn's message of Mon, 16 Aug 1999 09:25:59 MST. <199908161625.JAA17840@arrowsmith.wrs.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Unified stack? From: itojun@iijlab.net Date: Wed, 18 Aug 1999 09:11:33 +0900 Message-ID: <11745.934935093@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've been noticing the discussions about the unified stack >which I figure is the work to put Wide, INRIA et al together in one >place. I looked at the IPng web page and can't find a link to >this work. Is there one yet? If so where? Oops I forgot to cc: to mailing list. There is no unified-ipv6 webpage so far. Basically, after design and manpower struggles as reported at couple of IETFs, we (= NRL/INRIA/KAME) decided to use KAME as base IPv6 distribution for unified-ipv6 distribution. KAME will be adding some knobs based on comments from other guys. So, KAME STABLE kits after end of summer will have an alias name on it: "unified-ipv6". (it's still summer I believe, in Japan it is very summer:-P) So, it would be good to check www.kame.net for unified-ipv6. KAME team is now reorganizing repository for better code share, for easier openbsd/bsdi4 support (which are kind of tricky since NRL code is already there) and other things. 64bit CPU portability issue is mostly clarified thanks to NetBSD guys. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 17 17:53:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA12194 for ipng-dist; Tue, 17 Aug 1999 17:49:37 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12187 for ; Tue, 17 Aug 1999 17:49:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id RAA22851 for ipng@sunroof.eng.sun.com; Tue, 17 Aug 1999 17:47:44 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12014 for ; Tue, 17 Aug 1999 16:05:44 -0700 (PDT) Received: from gargleblaster (gargleblaster.Eng.Sun.COM [129.146.86.249]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA624784 for ; Tue, 17 Aug 1999 16:05:44 -0700 (PDT) Message-Id: <199908172305.QAA624784@jurassic.eng.sun.com> Date: Tue, 17 Aug 1999 16:05:42 -0700 (PDT) From: Don Coolidge Reply-To: Don Coolidge Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iHzcCjRW2biMuTIa+zwn+A== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Also, in section 11 the draft says: > > In general, attempting to specify an IPv6-only option, such as the > Hop-by-Hop options, Destination options, or Routing header on an IPv6 > socket that is using IPv4-mapped IPv6 addresses, will probably result > in an error. > >One interpretation of the text above would be that an implementation >may silently ignore the option. I propose "will result in an error" >instead of "will probably result in an error". The text may read the way it does because there are v6 options like hoplimit and the Routing header that could potentially be meaningfully mapped (sometimes with a bit of work) to corresponding v4 options (ttl and source routing in these cases). My understanding is that there is still discussion in the WG as to whether or not this sort of thing should be permitted/forbidden/implementation-specific. To change the indicated text to "will result in an error" is to close off that discussion by forbidding such potentially useful mappings. I'm not implying that I feel one way or another about such cross-gender mappings; I'm just saying that the indicated text shouldn't be considered for change until after the WG has dealt with the entire question of using options, either v4 or selected v6 ones, on sockets using mapped addresses. -- Don Coolidge -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 17 18:12:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA12236 for ipng-dist; Tue, 17 Aug 1999 18:08:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12229 for ; Tue, 17 Aug 1999 18:07:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA03602 for ; Tue, 17 Aug 1999 18:07:50 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA23308 for ; Tue, 17 Aug 1999 18:07:49 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA17648; Tue, 17 Aug 1999 18:08:23 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA01435; Tue, 17 Aug 1999 18:08:23 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id SAA11033; Tue, 17 Aug 1999 18:08:30 -0700 (PDT) Date: Tue, 17 Aug 1999 18:08:30 -0700 (PDT) From: Tim Hartrick Message-Id: <199908180108.SAA11033@feller.mentat.com> To: ipng@sunroof.eng.sun.com, Bob_Halley@iengines.net Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > > I propose that either: > > Support of IPV6_PKTINFO for IPv4-mapped IPv6 addresses be made > mandatory > > or > > Applications be given an easy way of determining (at compile time or > run time) whether a given implementation supports IPV6_PKTINFO for > IPv4-mapped IPv6 addresses > > I prefer the former, but realize that it may be too much of a burden to > make mandatory. If support is not going to be mandatory, we need a > definite way of knowing whether support is available. > >From a implementation complexity point of view I would prefer a third alternative which is that we simply don't support IPV6_PKTINFO option for mapped addresses. No may about it. I agree that the may is bad so we probably shouldn't fence sit. It is either supported or it is not. I would think that your second alternative above would be no good at all since you still have to test and maintain the old code for handling multiple file descriptors and interface scanning. Maybe you need to do that any- way so it is not big deal. It would be nice if you could simply depend on the existence of IP_RECVDSTADDR and something like what we call IP_RECVIFADDR. Oh well..... > Also, in section 11 the draft says: > > In general, attempting to specify an IPv6-only option, such as the > Hop-by-Hop options, Destination options, or Routing header on an IPv6 > socket that is using IPv4-mapped IPv6 addresses, will probably result > in an error. > > One interpretation of the text above would be that an implementation > may silently ignore the option. I propose "will result in an error" > instead of "will probably result in an error". > I am with you. We fail any option which does not match the network layer of the socket. That is you can't set IP_TTL on an AF_INET6 socket and you can't set IPV6_HOPLIMIT on an AF_INET socket. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 17 18:40:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA12315 for ipng-dist; Tue, 17 Aug 1999 18:36:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12308 for ; Tue, 17 Aug 1999 18:36:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA10039; Tue, 17 Aug 1999 18:36:05 -0700 (PDT) Received: from isrv3.pa.vix.com (isrv3.pa.vix.com [204.152.184.182]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA16219; Tue, 17 Aug 1999 19:36:01 -0600 (MDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.pa.vix.com (8.9.1/8.9.1) via ESMTP id SAA05001; Tue, 17 Aug 1999 18:36:01 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: from bb.rc.vix.com (localhost [127.0.0.1]) by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id SAA13344; Tue, 17 Aug 1999 18:36:01 -0700 (PDT) env-from (Bob_Halley@iengines.net) Message-Id: <199908180136.SAA13344@bb.rc.vix.com> To: Don Coolidge cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses In-Reply-To: Message from Don Coolidge of "Tue, 17 Aug 1999 16:05:42 PDT." <199908172305.QAA624784@jurassic.eng.sun.com> Date: Tue, 17 Aug 1999 18:36:00 -0700 From: Bob Halley Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Don Coolidge wrote: > The text may read the way it does because there are v6 options like > hoplimit and the Routing header that could potentially be meaningfully > mapped (sometimes with a bit of work) to corresponding v4 options (ttl > and source routing in these cases). My understanding is that there is > still discussion in the WG as to whether or not this sort of thing > should be permitted/forbidden/implementation-specific. To change > the indicated text to "will result in an error" is to close off > that discussion by forbidding such potentially useful mappings. My intent is not to forbid specific meaningful mappings, but to deal with the general case where you are trying to do an operation that has no meaningful translation back into IPv4. In such cases, I would like to forbid silent failure. /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 18 07:51:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA12895 for ipng-dist; Wed, 18 Aug 1999 07:48:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12888 for ; Wed, 18 Aug 1999 07:48:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA23759 for ; Wed, 18 Aug 1999 07:47:58 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09017 for ; Wed, 18 Aug 1999 07:47:57 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id QAA11529; Wed, 18 Aug 1999 16:47:55 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id QAA26771; Wed, 18 Aug 1999 16:47:53 +0200 (MET DST) Message-Id: <199908181447.QAA26771@givry.inria.fr> From: Francis Dupont To: Bob Halley cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses In-reply-to: Your message of Tue, 17 Aug 1999 15:25:49 PDT. <199908172225.PAA09117@bb.rc.vix.com> Date: Wed, 18 Aug 1999 16:47:53 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: BIND is one of the applications that would like to use the IPV6_PKTINFO option. => I agree! Interface scanning is *not* the best way to get the source info. I propose that either: Support of IPV6_PKTINFO for IPv4-mapped IPv6 addresses be made mandatory => we have it (because we'd like to use it for BIND) then I support this proposal. Applications be given an easy way of determining (at compile time or run time) whether a given implementation supports IPV6_PKTINFO for IPv4-mapped IPv6 addresses => propose a name for the define (better than IPV6_INRIA_VERSION :-) One interpretation of the text above would be that an implementation may silently ignore the option. I propose "will result in an error" instead of "will probably result in an error". => I agree (we return ENOPROTOOPT aka "Protocol not available" in such cases). Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 18 20:53:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA13981 for ipng-dist; Wed, 18 Aug 1999 20:50:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13974 for ; Wed, 18 Aug 1999 20:50:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA02038 for ; Wed, 18 Aug 1999 20:50:36 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA15565 for ; Wed, 18 Aug 1999 21:50:34 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA08741; Thu, 19 Aug 1999 12:50:08 +0900 (JST) To: dhaskin@baynetworks.com, sonishi@baynetworks.com cc: ipng@sunroof.eng.sun.com Subject: RFC2465 (IPv6 MIB) question X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Thu, 19 Aug 1999 12:50:08 +0900 Message-ID: <8739.935034608@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a quesiton about RFC2465, on how to map outgoing packets to interfaces. The spec says, as attached, to count discarded packets or ULP- originated packets in per-interface structure. In some cases, it is impossible to map outgoing packet to an interface. For example, if you have no route for the IPv6 destination, you never know which interface the packet will go out. How am I supposed to handle such situations? Do you just handle these as if they were toward some dummy interface? (loopback maybe) itojun --- ipv6IfStatsOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IPv6 datagrams which local IPv6 user-protocols (including ICMP) supplied to IPv6 in requests for transmission. Note that this counter does not include any datagrams counted in ipv6IfStatsOutForwDatagrams." ::= { ipv6IfStatsEntry 11 } ipv6IfStatsOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of output IPv6 datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipv6IfStatsOutForwDatagrams if any such packets met this (discretionary) discard criterion." ::= { ipv6IfStatsEntry 12 } -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 01:57:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA14217 for ipng-dist; Thu, 19 Aug 1999 01:54:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14210 for ; Thu, 19 Aug 1999 01:54:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA01727 for ; Thu, 19 Aug 1999 01:54:03 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03413 for ; Thu, 19 Aug 1999 01:53:20 -0700 (PDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id RAA03086; Thu, 19 Aug 1999 17:44:22 +0900 (JST) Date: Thu, 19 Aug 1999 17:53:59 +0900 Message-ID: <14267.50727.497010.50149A@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Mon, 16 Aug 1999 09:20:33 -0700 (PDT)" <199908161620.JAA09665@feller.mentat.com> References: <199908161620.JAA09665@feller.mentat.com> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 155 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, thanks for the quick response. I should've shown the current KAME's behavior about my questions. I'll show the behavior in this response. >>>>> On Mon, 16 Aug 1999 09:20:33 -0700 (PDT), >>>>> Tim Hartrick said: >> - if we set a non-zero value to sin6_scope_id and a link-local unicast >> address to sin6_addr, should the corresponding packet be sent on the >> interface specified by the value of sin6_scope_id field? >> > Yes. Yes for KAME. >> - if we receive a packet via recvfrom(or recvmsg, or whatever) and >> the from(i.e. source) address of the packet is a link-local address, >> should the sin6_scope_id field be set the index of the receiving >> interface? Should we allow the kernel to set zero to the field even >> if the `from' address is link-local? >> > It should always be interface index of the receiving interface. Ditto for KAME. >> - as RFC says, the specification is ambiguous for site-local >> addresses. Currently, KAME scarecely supports site-local (unicast) addresses. They are treated as global. >> - if we set a non-zero value to sin6_scope_id and a global unicast >> address to sin6_addr, what should the kernel do? Return an error? >> Ignore the value? Or send the packet to the interface whose index is >> the specified value? > I intend to ignore it since it is not meaningful global scope addresses, > multicast or unicast. Ditto for KAME. >> Which value should the kernel set to sin6_scope_id when receiving >> from a global address? >> > Zero. Ditto for KAME. >> - all the above questions are also applied for multicast addresses. When sending, KAME always regards a non-zero sin6_scope_id as the identifier of the outgoing interface in order to choose the source address. However, the sin6_scope_id isn't used when sending the packet...KAME always needs IPV6_MULTICAST_IF or IPV6_PKTINFO, which may be wrong and corrected. Also, it might be wrong to regards sin6_scope_id as the outgoing interface id even for a non link-local multicast address, since we can't handle other scope(e.g. site-local). For receiving, KAME sets the identifier of the receiving interface to sin6_scope_id field only for a link-local scope multicast address. I admit that this asynchronousness is unnatural... >> - suppose that we set a non-zero value to sin6_scope_id, set a >> link-local address to sin6_addr, and call bind() with the socket >> address. When we try to send a packet to the socket, should the >> kernel send the packet to the interface specified by the >> sin6_scope_id passed to bind()? > Not unless the packet would otherwise have gone out that interface. I'm sorry, but I can't understand this. Could you tell me the behavior more concretely? > The source address selection in this case could be tricky. I would say > that if the datagram is going to exit from the interface specified in the > bind then use the bound address as the source, otherwise use a source address > from the sending interface. >> What if we try to send a packet specifying the destination >> by a socket address whose sin6_addr is also link-local and whose >> sin6_scope_id is a different value than the value set by bind()? >> > Then I would do the above. That is, send the datagram out the interface > specified in the address of the sendto call and use the source address > associated with the sending interface. Hmm...but is it right for a TCP socket? Do we have to use the bound address as source for a TCP socket? By the way, KAME's source address selection in this case is strange... - for a UDP socket, use an address on the sending interface, which is different than the bound address. - for a TCP socket, use the bound address. - for a IPv6 raw socket...bind system call is failed. Yes, it's a bug. >> Even granted that the above points were clear, it would be also >> complicated to define preference among related ancillary data, >> setsockopt, and system calls. >> >> So, as a starter, let me clarify the methods to specify the source >> address and to specify the outgoing interface: >> >> (possible)methods to specify the source address >> IPV6_PKTINFO cmsg type >> IPV6_PKTINFO setsockopt > I may have misread the specification but I didn't think you could use the > IPV6_PKTINFO option in a setsockopt. Section 4 of 2292bis says as follows: This is done by defining socket option types which can be used both with setsockopt and with ancillary data. Ancillary data is discussed in Appendix A. The following optional information can be exchanged between the application and the kernel: 1. The send/receive interface and source/destination address, (snip) The three socket option parameters and the three cmsghdr fields that describe the options/ancillary data objects are summarized as: opt level/ optname/ optval/ cmsg_level cmsg_type cmsg_data[] ------------ ------------ ------------------------ IPPROTO_IPV6 IPV6_PKTINFO in6_pktinfo structure It seems to me that the text allows us to call setsockopt(IPV6_PKTINFO). >> Then we should discuss the preference among them. It's not so trivial >> for me, so I'd like to stop here and listen to other implementors. > You are correct that it is quite complicated. Many of these methods were > developed a while ago when we hadn't considered all the ramifications of > scoped addresses. We probably still haven't considered all the ramifications. Yes, it would be tough to define proper preference...maybe we have too many methods. > Once I get the specification in front of me I will try and provide some > opinions on the above. Thanks. We KAME team will also work on this and will post here the result. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 03:23:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA14359 for ipng-dist; Thu, 19 Aug 1999 03:20:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14352 for ; Thu, 19 Aug 1999 03:20:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA05238 for ; Thu, 19 Aug 1999 03:20:35 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA21052 for ; Thu, 19 Aug 1999 04:20:33 -0600 (MDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id TAA03287; Thu, 19 Aug 1999 19:12:15 +0900 (JST) Date: Thu, 19 Aug 1999 19:21:51 +0900 Message-ID: <14267.55999.999153.12006I@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Mon, 16 Aug 1999 18:27:04 +0200" <199908161627.SAA27400@givry.inria.fr> References: <14263.60698.673536.12718B@condor.isl.rdc.toshiba.co.jp> <199908161627.SAA27400@givry.inria.fr> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 60 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the delayed response... >>>>> On Mon, 16 Aug 1999 18:27:04 +0200, >>>>> Francis Dupont said: > - all the above questions are also applied for multicast addresses. > => multicast addresses are exactly like link-local addresses even > they have their own scope because a multicast destination without > the outgoing interface is incomplete. As I said in the previous response to Tim, this behavior resembles KAME're behavior, and I agree that a multicast destination without the outgoing interface is incomplete. However, does the behavior prevent to support other scope than link-local? If we regard sin6_scope_id as the outgoing i/f for any multicast destinations, how do we specify, for example, the site identifier for a site-local scope multicast address? > - suppose that we set a non-zero value to sin6_scope_id, set a > link-local address to sin6_addr, and call bind() with the socket > address. When we try to send a packet to the socket, should the > kernel send the packet to the interface specified by the > sin6_scope_id passed to bind()? > => sin6_scope_id in bind() should be for reception (ie. the socket > will not received packet from another interface). But the bound address uses as packets' source address sent via the socket, doesn't it? Do you allow the packet to be sent on a different interface than the interface to which the source address belongs? > What if we try to send a packet specifying the destination > by a socket address whose sin6_addr is also link-local and whose > sin6_scope_id is a different value than the value set by bind()? > => argh! This is a real point and another case of precedence > (here between bind and connect/send/... sin6_scope_id). > I've just tried on my implementation: I consider sin6_scope_id has > a small precedence then connect() sin6_scope_id is overruled by > the bind() sin6_scope_id: packets (neighbor solicitations in fact) > are sent on the previous interface... The precedence seems fine for a TCP socket, but it would break the link border... > PS: *tentative* precedence table (according to what I believe to have coded): > source address: this can't be bound again when this is already bound. > outgoing interface: > IPV6_MULTICAST_IF < connect/send* < bind < full IPV6_PKTINFO Thanks for the tentative idea. It would be a good start point for discussion. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 03:43:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA14394 for ipng-dist; Thu, 19 Aug 1999 03:40:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14387 for ; Thu, 19 Aug 1999 03:40:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA21901 for ; Thu, 19 Aug 1999 03:40:32 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24609 for ; Thu, 19 Aug 1999 04:40:31 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA15430; Thu, 19 Aug 1999 19:40:03 +0900 (JST) To: Bob Halley cc: ipng@sunroof.eng.sun.com In-reply-to: Bob_Halley's message of Tue, 17 Aug 1999 15:25:49 MST. <199908172225.PAA09117@bb.rc.vix.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses From: itojun@iijlab.net Date: Thu, 19 Aug 1999 19:40:03 +0900 Message-ID: <15428.935059203@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >BIND is one of the applications that would like to use the >IPV6_PKTINFO option. >It would be great if BIND could simply create a single IPv6 UDP socket >with a wildcard address and use it for both IPv4 and IPv6 requests, >but in draft-ietf-ipngwg-2292bis-00.txt, section 11, it says > [...] Some implementations, however, may provide access to > the packet information (source/destination address, send/receive > interface, and hop limit) on an IPv6 socket that is using IPv4-mapped > IPv6 addresses. >So, I cannot rely on using IPV6_PKTINFO for IPv4-mapped IPv6 addresses. I would say that this is too much to ask. If you need complex operation like IPV6_PKTINFO, expect that to work on IPv6 connection toward AF_INET6 socket, no others. There are too many complexities introduced by IPv4 mapped address, and I hate to see any additional complexities to be added. For example, with regard to IPv4 mapped address, the current document falis to define the kernel behavior, like: - what should happen when IPv6 wildcard bind(2) is performed on port X, then IPv4 specific bind(2) is performed onto port X Actually current document defined nothing about port number space treatment (whether IPv6 TCP port number space and IPv4 TCP port number space is unified, or separated). There are too many interactions between two AFs introduced by IPv4 mapped address. I do not think it to be healthy. I understand IPv4 mapped address (::ffff:10.1.1.1) as a way to ease porting of simple AF_INET applications (which listens to only single socket) into AF_INET6 application, while continue support for IPv4 connection on top of AF_INET6 socket. The way IPv4 mapped address is defined is not future-proven. When the next version of internet protocol - say IPv9 - is introduced you will need to port your aplication again. IMHO the way for new code to go is to - avoid in_addr, in6_addr and other protocol specific data structure - avoid gethostbyname2(), getipnodebyname() and other functions that return protocol specific data struture - use sockaddr_storage, sockaddr * and get{addr}info() throughout the code I always suggest userland programmers to handle AF_INET and AF_INET6 as totally separated address families. things go much simpler if you do so (you will have no problem with these bind(2) ordeirng issues, port number space issues, and such). I have tutorial material on this aspect so feel free to take a look at. I'm happy to give talks on this on any occasions, so just contact me. http://playground.iijlab.net/newsletter/19990630/ itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 06:13:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA14457 for ipng-dist; Thu, 19 Aug 1999 06:09:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14450 for ; Thu, 19 Aug 1999 06:09:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA11858 for ; Thu, 19 Aug 1999 06:09:43 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22002 for ; Thu, 19 Aug 1999 07:09:42 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id PAA03938; Thu, 19 Aug 1999 15:09:41 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id PAA01887; Thu, 19 Aug 1999 15:09:40 +0200 (MET DST) Message-Id: <199908191309.PAA01887@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Thu, 19 Aug 1999 19:21:51 +0900. <14267.55999.999153.12006I@condor.isl.rdc.toshiba.co.jp> Date: Thu, 19 Aug 1999 15:09:39 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: However, does the behavior (the important thing for a multicast address is the outgoing interface) prevent to support other scope than link-local? If we regard sin6_scope_id as the outgoing i/f for any multicast destinations, how do we specify, for example, the site identifier for a site-local scope multicast address? => I have considered *-local scopes and multicast scopes are different notions and to use the same identifier for site-local unicast and multicast (ie. fuse them) is only simpler... But in general a site identifier does not point to one interface then the site identifier is not enough even for a site-local multicast address. IPV6_MULTICAST_IF argument is an interface index and not a scope id. But the bound address uses as packets' source address sent via the socket, doesn't it? => yes Do you allow the packet to be sent on a different interface than the interface to which the source address belongs? => the IPV6_PKTINFO will try to overwrite both the interface and the source address then will fail: this is not allowed but is not a real problem because bind() and IPV6_PKTINFO are alternatives. Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 09:00:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA14597 for ipng-dist; Thu, 19 Aug 1999 08:56:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14590 for ; Thu, 19 Aug 1999 08:56:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA17596 for ; Thu, 19 Aug 1999 08:56:32 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21209 for ; Thu, 19 Aug 1999 09:56:31 -0600 (MDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA29744 for ; Thu, 19 Aug 1999 11:55:47 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA27058 for ; Thu, 19 Aug 1999 11:55:49 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id LAA19570 for ; Thu, 19 Aug 1999 11:56:18 -0400 (EDT) Message-Id: <199908191556.LAA19570@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: Re: Last Call: Multicast Listener Discovery (MLD) for IPv6 to Proposed Standard Date: Thu, 19 Aug 1999 11:56:17 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This document is now being balloted by the IESG. In reviewing the document, I noted one issue that might be worth thinking about, as this is a decision that cannot easily be changed later. In MLD, all packets must originate from a link-local address, and the Hop Limit field is set to 1 prior to sending a packet. If we assume that routers will check and not improperly forward packets that have link-local source addresses, an intruder could only interfere with the MLD protocol running on the same link to which it attaches. > 9. Security Considerations > > We consider the ramifications of a forged message of each type. Note > that the requirement that nodes verify that the IPv6 Source Address of > all received MLD messages is a link-local address defends them from act- > ing on forged MLD messages originated off-link, so we discuss only the > effects of on-link forgery. When ND was developed, requiring that packets originate from a link-local source address was deemed insufficient to prevent off-link attacks. It was asserted that routers might ignore the check and forward such packets anyway as a performance enhancement. Thus, ND has the Hop Limit == 255 check, where on receipt a packet is not accepted if its Hop Limit is < 255. This ensures that no packet traversing a router will be accepted for processing. Question: Should MLD also make use of the 255 hack, or is the current approach sufficient? The tradeoff issue I see is the following: 1) As currently defined, it may be possible for a remote node to send a Report message indicating that there is a listener for a particular group on a link. This could be used to fool a router on a remote link to believe it should begin forwarding a high-bandwidth audio/video stream to that link, overwhelming (say) a low-bandwidth access link between a site and the internet. Note: this can only happen if routers improperly forward messages originating from link-local source addresses. 2) On the other hand, using the Hop Limit == 255 hack would cause Report messages (which are sent to the specific multicast group they are reporting on) to possibly be forwarded beyond the local link (again, only if routers skipped the source address check), resulting in traffic going further than it needs to. The current draft prevents the problem in 2), because all packets have a TTL of 1. Question: Is problem 1) a significant enough concern that it should be addressed via the 255 hack? Are there other attacks from off-link sources that we need to worry about? (note: the security considerations section does a good job of outlining vulnerabilities. I've appended it FYRP.) Thomas 9. Security Considerations We consider the ramifications of a forged message of each type. Note that the requirement that nodes verify that the IPv6 Source Address of all received MLD messages is a link-local address defends them from act- ing on forged MLD messages originated off-link, so we discuss only the effects of on-link forgery. Query message: A forged Query message from a machine with a lower IP address than the current Querier will cause Querier duties to be assigned to the forger. If the forger then sends no more Query messages, other routers' Other Querier Present timer will time out and one will resume the role of Querier. During this time, if the forger ignores Done messages, traffic might flow to addresses with no lis- teners for up to [Multicast Listener Interval]. A forged Query message sent to an address with listeners will cause one or more nodes that are listeners to that address to send a Report. This causes a small amount of extra traffic on the link, but causes no protocol problems. Report message: A forged Report message may cause routers to think there are lis- teners for an address present on a link when there are not. How- ever, since listening to a multicast address is generally an unprivileged operation, a local user may trivially gain the same result without forging any messages. Done message: A forged Done message will cause the Querier to send out Multicast- Address-Specific Queries for the address in question. This causes extra processing on each router and on each of the address's lis- teners, and extra packets on the link, but cannot cause loss of desired traffic. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 09:45:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA14670 for ipng-dist; Thu, 19 Aug 1999 09:42:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14663 for ; Thu, 19 Aug 1999 09:42:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA11436 for ; Thu, 19 Aug 1999 09:42:10 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07319 for ; Thu, 19 Aug 1999 09:42:09 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA18160; Thu, 19 Aug 1999 12:38:59 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA26766; Thu, 19 Aug 1999 12:39:01 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id MAA20112; Thu, 19 Aug 1999 12:39:28 -0400 (EDT) Message-Id: <199908191639.MAA20112@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Jack McCann cc: iesg@ietf.org, awjacks@bbn.com, craig@bbn.com, dkatz@jnx.com, ipng@sunroof.eng.sun.com Subject: Re: Last Call: IPv6 Router Alert Option to Proposed Standard In-reply-to: Your message of "Wed, 11 Aug 1999 12:00:38 EDT." <199908111600.MAA0000968600@anw.zk3.dec.com> Date: Thu, 19 Aug 1999 12:39:28 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jack, > The IPv6 Router Alert option looks like it should specify an alignment > requirement of 2n (i.e. x == 2, y == 0) so that the 2-octet Value > field falls on a 2-octet boundary. This sounds right to me. Do the authors agree? Doing a little cross checking: RFC 2473 seems to have neglected to state the alignment requirement, though one would assume there wouldn't be one for a 1-octet data value. :-) draft-ietf-mobileip-ipv6-08.txt also would appear to need similar text. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 11:03:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA14941 for ipng-dist; Thu, 19 Aug 1999 10:59:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14934 for ; Thu, 19 Aug 1999 10:58:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA16871 for ; Thu, 19 Aug 1999 10:58:57 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11409 for ; Thu, 19 Aug 1999 10:58:57 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id KAA20945; Thu, 19 Aug 1999 10:51:11 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199908191639.MAA20112@cichlid.raleigh.ibm.com> References: <199908191639.MAA20112@cichlid.raleigh.ibm.com> Date: Thu, 19 Aug 1999 10:51:09 -0700 To: Thomas Narten From: Steve Deering Subject: Re: Last Call: IPv6 Router Alert Option to Proposed Standard Cc: Jack McCann , iesg@ietf.org, awjacks@bbn.com, craig@bbn.com, dkatz@jnx.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:39 PM -0400 8/19/99, Thomas Narten wrote: >Jack, > > > The IPv6 Router Alert option looks like it should specify an alignment > > requirement of 2n (i.e. x == 2, y == 0) so that the 2-octet Value > > field falls on a 2-octet boundary. > >This sounds right to me. Do the authors agree? I'm not an author, but I agree. Any document that defines an IPv6 option containing a multi-octet field should specify an alignment requirement for that option so as to cause the multi-octet field to be aligned on its natural boundary, using the notation "alignment requirement: xn+y" as described in section 4.2 of RFC 2460. Appendix B of RFC 2460 provides some examples of how the alignment requirement is determined and used. The definition of an option that does not contain any multi-octet fields should include the notation: "alignment requirement: none", as in the definitions of the Pad1 and PadN options in RFC 2460. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 11:04:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA14956 for ipng-dist; Thu, 19 Aug 1999 11:02:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14949 for ; Thu, 19 Aug 1999 11:02:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA14521 for ; Thu, 19 Aug 1999 11:02:31 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17078 for ; Thu, 19 Aug 1999 12:02:30 -0600 (MDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA05351; Thu, 19 Aug 1999 11:02:27 -0700 (PDT) Message-Id: <3.0.5.32.19990819110112.03581c70@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 19 Aug 1999 11:01:12 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Updated IPv6 Address Assignments on IANA Web page Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 address assignments on the IANA web page has been updated. They can be found at: http://www.iana.org/numbers.html The files are consistent with the current IPv6 addressing RFCs and include the current TLA and Sub-TLA assignments, and IPv6 multicast addresses. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 14:05:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA15395 for ipng-dist; Thu, 19 Aug 1999 14:01:59 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15388 for ; Thu, 19 Aug 1999 14:01:47 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA968562; Thu, 19 Aug 1999 14:01:44 -0700 (PDT) Date: Thu, 19 Aug 1999 13:59:32 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 and Dynamic DNS To: "Peter Ford (Exchange)" Cc: Robert Elz , Francis Dupont , ipng@sunroof.eng.sun.com, namedroppers@internic.net In-Reply-To: "Your message with ID" <078292D50C98D2118D090008C7E9C6A6017942C1@STAY.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Ford wrote on 6 Aug: > It sure would be nice if you could force some sort of "hard" addrconf so > that servers on the network would know who is "on a wire", this would allow > routers to do host based routing, build more accurate topology databases (a > BIG request from customers), etc. The only mechanism we have today is to set the flag in the router advertisement which says "Use DHCP". Of course, it wouldn't be hard to extend ND/addrconf which e.g. an option of the semantics: "send an unsolicited neighbor advertisement every N seconds to the all-routers multicast address". This of course doesn't prevent malicious nodes from being silent, but it would provide what you need. Of course, I don't know how useful this would be. Also, I don't see how it would help with dynamic DNS trust issues. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 14:48:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA15548 for ipng-dist; Thu, 19 Aug 1999 14:45:11 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15541 for ; Thu, 19 Aug 1999 14:44:59 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA974791; Thu, 19 Aug 1999 14:44:57 -0700 (PDT) Date: Thu, 19 Aug 1999 14:42:46 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2529 (6over4) To: Sowmini Varadhan Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199908031928.PAA0000011024@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >It was not clear why the spec rules (lines below) that the >DF bit MUST NOT be set. Perhaps this injunction classifies as a "SHOULD NOT"? > 121 ... However, the IPv4 "do not > 122 fragment" bit MUST NOT be set in the encapsulating IPv4 header. > Since IPv4 path MTU discovery does not work for multicast packets when sending an IPv4 multicast packet MUST NOT is correct. When sendinfg IPv4 unicast packets I guess you can do IPv4 path MTU discovery per IPv4 destination on the virtual 6over4 interface. I don't know if this is worth the complexity - but RFC 1933 specifies how to do this on configured tunnels and the logic would be the same. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 14:54:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA15580 for ipng-dist; Thu, 19 Aug 1999 14:53:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15573 for ; Thu, 19 Aug 1999 14:53:07 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA975974; Thu, 19 Aug 1999 14:53:05 -0700 (PDT) Date: Thu, 19 Aug 1999 14:50:53 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2529 (6over4) To: Brian E Carpenter Cc: Francis Dupont , Sowmini Varadhan , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <37A87F28.5D788BEA@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This point came up in 6to4 as well and it seems to vary quite > a bit between implementations. Personally I think referring to > virtual or pseudo interface makes the concepts much clearer, > but we probably need a phrase indicating that it is not > an implementation requirement. But we need to make sure we agree what that means. For instance, the specification on source address selection is likely to say "select among the addresses assigned to the interface ...". I assume we want this to apply to the 6over4 or 6to4 interface, whether or not it is implemented as a BSD ifnet structure. Thus for clarity I suggest using the term "interface" as defined in RFC 2460 which includes attachments to a tunnel over IPv4. But the document(s) should say that an implementation can provide the specified behavior in any way it disires. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 15:06:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA15611 for ipng-dist; Thu, 19 Aug 1999 15:02:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15603 for ; Thu, 19 Aug 1999 15:02:27 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA977271; Thu, 19 Aug 1999 15:02:25 -0700 (PDT) Date: Thu, 19 Aug 1999 15:00:14 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 Src/Dst Address Pairing To: Jim Bound Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199908051610.MAA0000984442@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I don't think the performance overhead of sorting the list returned by getipnodebyname is significant. In fact, we've sorted the list of IPv4 addresses returned by gethostbyname for many years in Solaris (so that addresses on a directly attached subnet appears first in the list). At least in IPv4 in most cases there is only one address thus there is no sorting needed. And if you run a local caching resolver (or something similar - we have something called nscd which caches for DNS, NIS, etc) the caching process can ask the kernel for its list of IP addresses once and do the work in user space. But it would be good to do some performance studies - something we never did for our gethostbyname code. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 15:16:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA15658 for ipng-dist; Thu, 19 Aug 1999 15:12:44 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15647 for ; Thu, 19 Aug 1999 15:12:07 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA978824; Thu, 19 Aug 1999 15:12:02 -0700 (PDT) Date: Thu, 19 Aug 1999 15:09:51 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: RFC 2529 (6over4) To: Richard Draves Cc: "'Brian E Carpenter'" , David Borman , cmj@3com.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D810145156FD@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It's a little tricky to have an implementation that would allow a different > link MTU for different neighbors on the link. For example, what MTU would > the sender use for a multicast destination? Just allow fragmentation for > multicast destinations? So I guess I can imagine a 6over4 implementation > that would use v4 PMTU discovery, but it's a stretch. While we haven't built 6over4 yet (shame on us :-) we have the infrastructure in place for having the IPv6 pmtu be affected by the IPv4 pmtu when tunneling over IPv4. This is used to make configured and automatic tunnels work as specified in RFC 1933. But when we do 6over4 IPv4 multicast packets need to pick one fixed MTU value and the DF big can not be set on them (since multicast packets with DF set are silently dropped - no ICMPv4 errors are allowed in response to multicast packets - something that ICMPv6 changed). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 15:20:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA15702 for ipng-dist; Thu, 19 Aug 1999 15:18:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15695 for ; Thu, 19 Aug 1999 15:18:06 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA979689; Thu, 19 Aug 1999 15:18:00 -0700 (PDT) Date: Thu, 19 Aug 1999 15:15:48 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: SHOULD NOT set DF [was Re: RFC 2529 (6over4)] To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com, "'Cyndi Jung'" In-Reply-To: "Your message with ID" <37B2CDA1.D9AF1488@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The co-authors of 2529 propose that whenever the document > is revised, we change to saying that the encapsulator > SHOULD NOT set DF, and that for now implementors proceed > on that basis. as long as you add "MUST NOT set DF when the IPv4 packet is a multicast packet." I think I raised the multicast issue at a meeting which generated the MUST NOT. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 15:32:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA15738 for ipng-dist; Thu, 19 Aug 1999 15:28:36 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15731 for ; Thu, 19 Aug 1999 15:28:25 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA981019; Thu, 19 Aug 1999 15:28:23 -0700 (PDT) Date: Thu, 19 Aug 1999 15:26:11 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC2465 (IPv6 MIB) question To: itojun@iijlab.net Cc: dhaskin@baynetworks.com, sonishi@baynetworks.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <8739.935034608@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hello, I have a quesiton about RFC2465, on how to map outgoing > packets to interfaces. > > The spec says, as attached, to count discarded packets or ULP- > originated packets in per-interface structure. In some cases, it is > impossible to map outgoing packet to an interface. For example, if > you have no route for the IPv6 destination, you never know which > interface the packet will go out. > How am I supposed to handle such situations? Do you just handle > these as if they were toward some dummy interface? (loopback maybe) If you are forwarding the packet you can add it for the incomming interface. If you are originating the packet things are harder ... We add such packets to global counters, which work fine for netstat. netstat -s will add everything else (all interface stats) to the global counters and only print those. Thus this will include the stats that can't be associated with an interface. netstat -sa will in addition print the per-interface counters, which do not include the unassociated counters. Of course, this doesn't say anything about what you get when responding to an SNMP query. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 23:05:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA16314 for ipng-dist; Thu, 19 Aug 1999 23:02:59 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16307 for ; Thu, 19 Aug 1999 23:02:46 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA123331; Thu, 19 Aug 1999 23:02:44 -0700 (PDT) Date: Thu, 19 Aug 1999 23:00:31 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses To: Bob Halley Cc: Don Coolidge , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199908180136.SAA13344@bb.rc.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My intent is not to forbid specific meaningful mappings, but to deal > with the general case where you are trying to do an operation that has > no meaningful translation back into IPv4. In such cases, I would like > to forbid silent failure. For setsockopt we can definitely forbid silently failures. But when using ancillary data with sendmsg certain implementations (that use asynch message passing to get to the TCP/IP stack - also known as streams) can not return errors from the TCP/IP code to sendmsg. I can at least clarify that the "may" only applies to sendmsg and not to setsockopt. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 23:09:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA16342 for ipng-dist; Thu, 19 Aug 1999 23:08:35 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16335 for ; Thu, 19 Aug 1999 23:08:23 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA123698; Thu, 19 Aug 1999 23:08:23 -0700 (PDT) Date: Thu, 19 Aug 1999 23:06:10 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses To: Bob Halley Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199908172225.PAA09117@bb.rc.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I propose that either: > > Support of IPV6_PKTINFO for IPv4-mapped IPv6 addresses be made > mandatory > > or > > Applications be given an easy way of determining (at compile time or > run time) whether a given implementation supports IPV6_PKTINFO for > IPv4-mapped IPv6 addresses Do you care about the ifindex or just the ability to get the destination address (in recvmsg) and being able to set the source address per packet in sendmsg? The reason I ask is because in our implementation it would be relatively easy to add the ipi6_addr part of IPV6_PKTINFO for IPv4-mapped addresses but more difficult to handle the ipi6_ifindex. Basically this would do the same as using IP_RECVDSTADDR for receive and some yet to be defined ancillary data option (IP_SRCADDR???) for send. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 19 23:11:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA16360 for ipng-dist; Thu, 19 Aug 1999 23:10:11 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16347 for ; Thu, 19 Aug 1999 23:09:57 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA123730 for ; Thu, 19 Aug 1999 23:09:56 -0700 (PDT) Date: Thu, 19 Aug 1999 23:07:43 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >----------------Begin Forwarded Message----------------< Date: Thu, 19 Aug 1999 22:58:15 -0700 (PDT) From: "Erik Nordmark" Subject: Re: Comments on 2292bis (Adv. API) To: "Vladislav Yasevich" Cc: "IPNG Working Group" , rstevens@kohala.com, matt@3am-software.com, erik.nordmark@eng.sun.com Thank you all for the very careful review - it will make the document much better. > - This document used the wording "described later" and "described shortly." > It would ease readability if you include the section numbers into these > statements. Will do. > Section 2.1 [Page 8] > - The comment in the following definitions is incorrect: > 402 struct ip6_hdrctl { > 403 uint32_t ip6_un1_flow; /* 8 bits traffic class, 24 bits flow-ID */ > It should be 4 bit version, 8 bit traffic class, 20 bit flow-ID. I know - but 80 columns was limiting things. I'll try with "TC" instead of "traffic class" and see if it fits. > Section 2.1.2 [Page 9] > - The reviewers were questioning the need for the following definition: > 490 struct in6_addr ip6r0_addr[1]; /* up to 127 addresses */ > > This definition made the ip6_rthdr0 structure stick out from all the others. > The suggestion is to remove this line and add a comment (just like all the > other header structures) that states that the Routing Header 0 is followed > by an array of IPv6 addresses. I agree there isn't perfect consistency. But I do find it useful when writing code since I can access rthdr->ip6r0_addr[i] instead of something like ((struct in6_addr *)&rthdr[1])[i] if I remove the field. > - It would also be helpful if the following text was moved to Section 2. > [From page 10...] > 520 ...This API assumes that the fields in the > 521 protocol headers are left in the network byte order, which is big- > 522 endian for the Internet protocols. If not, then either these > 523 constants or the fields being tested must be converted at run-time, > 524 using something like htons() or htonl(). OK. > > Section 2.2.1 [page 11] > - The following definition is no longer valid: > 614 #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */ > > It now refers to an address that is beyond the scope of source address as > defined in Section 3.1 of draft-ietf-ipngwg-icmp-v3-00.txt > The draft defines the code value 2 as "beyond scope of source address". OK. > > Section 2.3 [page 15] > 793 int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, > 794 const struct in6_addr *); > > - Please explain the the return type of this macro. Does it return > true/false, or does it return 0 for equal, 1 for the first address > second > address, -1 for first address < second address. I am guessing it's > true/false since that is what all the other macros return, but it is not > clear. zero/non-zero (i.e. true/false) is the intent. I'll clarify. > > Section 3 [page 16] > - In the last paragraph of the section you talk about special treatment for > sockets created with IPPROTO_RAW as the third argument. You then go on > to say: > 892 ...(Note: This feature was added to > 893 IPv4 in 1988 by Van Jacobson to support traceroute, allowing a > 894 complete IP header to be passed by the application > > What is the feature is the spec talking about? This caused some confusion. I'll clarify. It is "to have it mean that the application will send down complete packets including the IPv4 header." > > Section 3.1 [page 17] > - What happens if the IPV6_CHECKSUM option is set for ICMPv6 sockets? I'll add "An attempt to set IPV6_CHECKSUM for an ICMPv6 socket will fail." > - Is this option disabled by default only for raw sockets that were not > created with IPPROTO_ICMPV6? Spec already says "By default, this socket option is disabled." The option has no meaning for ICMPv6 sockets since they always do their checksum. > Section 4 [page 20] > - A comment on the definitions of 'on' and 'off' for the setsockopt() calls > would be helpful. What would you like clarified? Is is just int on = 1; > - Describe the behavior of getsockopt() for IPV6_ options in this section. > Do these options support a getsockopt() call and what do they return? My intent was to leave that unspecified in order to allow implementations that support both 2292 and 2292bis using the same value for e.g. IP_RECVRTHDR and IP_RTHDR. Such an implementation might want to return the value used to enable receipt i.e. the integer. Implementations that only support 2292bis would presumably return what was set with setsockopt i.e. the sticky option content. If no implementors will provide 2292 compatibilty using the above scheme then we can nail down the behavior in the spec. > > Section 5.1 [page 26] > - What is the precedence of sin6_scope_id relative to the interface > specified by the IPV6_MULTICAST_IF, IPV6_PKTINFO and/or IPV6_NEXTHOP options? Good question! What should it be? (IPv6_NEXTHOP doesn't interact with the others - it is the only way to specify the nexthop address.) What we currently implement in Solaris is that the "easiest to change" gets precedence. Thus if sin6_scope_id is set and the destination is link-local it is used to determine the interface. If not, if IPV6_PKTINFO is set in acillary data and the ipi6_ifindex is non-zero it applies. Finally IPV6_MULTICAST_IF applies for multicast packets. Do we want to specify such details? If so, does the above order make sense? > Section 6.2 [page 29] > - What are the initialization values for the routing header? > We noticed that buffer length (bp_len) and the number of segments (segments) > are passed to inet6_rth_init() and this caused confusion as to what these > arguments are for. Do we set seg_left to segments and if not, are these > arguments simply for error checking? The example pictures in Appendix B (page 55) shows how things work. segments is used to set ip6r0_len - inet6_rth_add() increments ip6r0_segleft (and checks that it doesn't exceed ip6r0_len/2). bp_len is just used for error checking. I'll clarify this. > Section 7 [page 31] > 1691 .... These > 1692 requirements and the terminology used with these options are > 1693 discussed in Section 4.2 and Appendix B of [RFC-2460]. > > - Is the assumption here that all options MUST be defined according to > section 4.2 and Appendix B of rfc2460? We noticed that if we do not > follow the instructions in Appendix B, we were able to design options > that broke the API. If the working of this API depends on Appendix B, > it should be stated so. I don't understand what "broke the API" means. If you define an option that doesn't follow the asignment rules in 2460 then you might not be able to access fields in the option used aligned access. If you use the inet6_opt_get_val() and inet6_opt_set_val(), and the implementation of those functions take advantage of aligned access, then you might see the sending and receiving applications dump core. Perhaps we should add a note to point out that robust receivers should verify alignment before calling inet6_opt_get_val(). Or have inet6_opt_get_val() check alignment and fail by returning -1? > 1701 .... The > 1700 functions below need to know the alignment of the end of the > option - Why does this spec institute this limitation for the API? Why not > just pass the alignX and alignY? I am guessing these will be defined in the > Option Specification and makes it easier for application programmers to use > the API. > It would make the API simpler if we were to pass X and Y to the > inet6_opt_append(). This would also cause the API not to break if > following Appendix B is NOT a MUST. Because in order to reserve space and lay out the option you would need three things: the size of the option alignX alignY You can reduce this by removing alignX (or is it Y?) if you assume that the largest field is last in the option (as specified in 2460 appendix B). So what does "break the API" mean? > > Section 8.2 [page 33] > 1825 When using ancillary data a Destination options header is passed > 1826 between the application and the kernel as follows: The set > preceding > 1827 a Routing header are specified with the cmsg_level member is set to > 1828 IPPROTO_IPV6 and the cmsg_type member is set to IPV6_RTHDRDSTOPTS. > 1829 Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently > 1830 ignore when sending packets unless a Routing header is also > 1831 specified. > > - As the spec states here, IPV6_RTHDRDSTOPTS options are ignored unless > Routing header is present. Does this mean that if the user has > IPV6_RTHDRDSTOPTS options and a Routing header, and then the user removes > the Routing header, the IPV6_RTHDRDSTOPTS options go away as well? Should > the implementation cache the IPV6_RTHDRDSTOPTS options in case Routing > header will appear later? Are you asking about sticky options or ancillary data? For sticky options the simplest thing to me seems to be to record the option value first (so that it can be returned in a getsockopt) and then build a header template. The header template will be a function of all the sticky options. This means that IPV6_RTHDRDSTOPTS and IPV6_RTHDR can be setsockopt independently, but that the transmitted header will only contain a destination header before the routing header when both of them are set. But other implementors might see things differently. Also, is this something we should nail down in the spec? > > Section 9.1 [page 34] > 1875 ... If the extlen value is too small or not a multiple of 8 the > 1876 function fails and returns -1. > > - What do you mean by "too small" in this sentence? I guess zero is the only too small value that is a multiple of 8. Thus it is really" If the extlen value is not a positive multiple of 8 the function fails and returns -1. > Section 9.2 [page 34] > - This is the same question as question 2 for Section 7. Providing X and Y > in the interface would make the API easier to use. > The only time that we've successfully calculated Y based on X and length was > when our options followed Appendix B or 2460. You would need X, Y, and length since you can't calculate the length based on X and Y. 2 parameters are simpler than 3, so I hope we can live with the 2460 Appendix B model. > > Section 9.2 [page 35] > 1917 The align parameter must have a value of 1, 2, 4, or 8. The len > 1918 value can not exceed the value of align. > > The last sentece of this paragraph contradicts the previous paragraph as well > as the examples in the Appendix. It seems like an unnecessary restriction > and it was the opinion of reviewers that it should be removed. In fact it is completely bogus. What I meant to say was the inverse: The align value can not exceed the value of len. I'll address the rest of the comments in a second email message. Erik >----------------End Forwarded Message----------------< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 20 11:54:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA17085 for ipng-dist; Fri, 20 Aug 1999 11:41:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17077 for ; Fri, 20 Aug 1999 11:41:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA04969 for ; Fri, 20 Aug 1999 11:41:27 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09795 for ; Fri, 20 Aug 1999 11:41:23 -0700 (PDT) Received: from localhost ([3ffe:501:100f:1040:0:ff:fe00:0]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id DAA06881; Sat, 21 Aug 1999 03:33:00 +0900 (JST) Date: Sat, 21 Aug 1999 03:42:35 +0900 Message-ID: <14269.41371.28379.75679V@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Thu, 19 Aug 1999 15:09:39 +0200" <199908191309.PAA01887@givry.inria.fr> References: <14267.55999.999153.12006I@condor.isl.rdc.toshiba.co.jp> <199908191309.PAA01887@givry.inria.fr> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 61 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 19 Aug 1999 15:09:39 +0200, >>>>> Francis Dupont said: > However, does the behavior (the important thing for a multicast address > is the outgoing interface) prevent to support other scope than link-local? > If we regard sin6_scope_id as the outgoing i/f for any multicast > destinations, how do we specify, for example, the site identifier for > a site-local scope multicast address? > => I have considered *-local scopes and multicast scopes are different > notions and to use the same identifier for site-local unicast and multicast > (ie. fuse them) is only simpler... But in general a site identifier does > not point to one interface then the site identifier is not enough even > for a site-local multicast address. Hmm...maybe you're right. I'll reconsider the semantics of sin6_scope_id for (any scope) multicast addresses. > IPV6_MULTICAST_IF argument is an > interface index and not a scope id. Exactly. So I didn't mean IPV6_MULTICAST_IF, whose semantics is clear. The problem is sin6_scope_id filed. > But the bound address uses as packets' source address sent via the > socket, doesn't it? > => yes OK, then... > Do you allow the packet to be sent on a different interface > than the interface to which the source address belongs? > => the IPV6_PKTINFO will try to overwrite both the interface and the > source address then will fail: this is not allowed but is not a real > problem because bind() and IPV6_PKTINFO are alternatives. I don't think so. First, a problematic situation could happen even without IPV6_PKTINFO. For example, consider the following sample code. struct sockaddr_in6 sa1, sa2; sa1.sin6_scope_id = 1; sa1.sin6_addr = fe80::1; sa2.sin6_scope_id = 2; sa2.sin6_addr = fe80::2; bind(sa1); sendto(sa2); then, what should happen? In the above example, we don't use IPV6_PKTINFO at all! Secondly, I belive that bind() and IPV6_PKTINFO can coexist. What if you call bind() then call sendmsg with IPV6_PKTINFO and if the interface specified by sin6_scope_id of bind() contradicts the interface specified by IPV6_PKTINFO? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 20 11:54:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA17078 for ipng-dist; Fri, 20 Aug 1999 11:41:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17069 for ; Fri, 20 Aug 1999 11:41:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA25905; Fri, 20 Aug 1999 11:41:06 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21080; Fri, 20 Aug 1999 12:41:04 -0600 (MDT) Received: from localhost ([3ffe:501:100f:1040:0:ff:fe00:0]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id DAA06885; Sat, 21 Aug 1999 03:33:05 +0900 (JST) Date: Sat, 21 Aug 1999 03:42:39 +0900 Message-ID: <14269.41375.855147.51939W@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Thu, 19 Aug 1999 23:07:43 -0700 (PDT)" References: User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 19 Aug 1999 23:07:43 -0700 (PDT), >>>>> Erik Nordmark said: >> - What is the precedence of sin6_scope_id relative to the interface >> specified by the IPV6_MULTICAST_IF, IPV6_PKTINFO and/or IPV6_NEXTHOP options? > Good question! What should it be? (IPv6_NEXTHOP doesn't interact with > the others - it is the only way to specify the nexthop address.) > What we currently implement in Solaris is that the "easiest to change" > gets precedence. > Thus if sin6_scope_id is set and the destination is link-local it is > used to determine the interface. > If not, if IPV6_PKTINFO is set in acillary data and the ipi6_ifindex is > non-zero it applies. > Finally IPV6_MULTICAST_IF applies for multicast packets. As I said in some previous mails, I believe the problem is not so simple. First, the semantics of sin6_scope_id field is quite ambiguous. Besides, the semantics for unicast addresses might differ the semantics for multicast addresses(see Francis' mails). Also, we have many methods to specify the outgoing interface other than sin6_sope_id, IPV6_PKTINFO and IPV6_MULTICAST_IF. > Do we want to specify such details? If so, does the above order make sense? We want. The current status is quite confusing for application programmers. In fact, some routing engineers in Japan need more clarification on how to specifiy the outgoing interface. But I'm afraid that your order is too simple to clarify the problem. Maybe we need more work and should reach a consensus on proper precedence. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 20 12:15:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA17151 for ipng-dist; Fri, 20 Aug 1999 12:09:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17144 for ; Fri, 20 Aug 1999 12:09:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA10537; Fri, 20 Aug 1999 12:09:15 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20644; Fri, 20 Aug 1999 12:09:15 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA29466; Fri, 20 Aug 1999 12:09:52 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA26919; Fri, 20 Aug 1999 12:09:52 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id MAA12003; Fri, 20 Aug 1999 12:09:51 -0700 (PDT) Date: Fri, 20 Aug 1999 12:09:51 -0700 (PDT) From: Tim Hartrick Message-Id: <199908201909.MAA12003@feller.mentat.com> To: ipng@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > > > Section 8.2 [page 33] > > 1825 When using ancillary data a Destination options header is passed > > 1826 between the application and the kernel as follows: The set > > preceding > > 1827 a Routing header are specified with the cmsg_level member is set to > > 1828 IPPROTO_IPV6 and the cmsg_type member is set to IPV6_RTHDRDSTOPTS. > > 1829 Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently > > 1830 ignore when sending packets unless a Routing header is also > > 1831 specified. > > > > - As the spec states here, IPV6_RTHDRDSTOPTS options are ignored unless > > Routing header is present. Does this mean that if the user has > > IPV6_RTHDRDSTOPTS options and a Routing header, and then the user removes > > the Routing header, the IPV6_RTHDRDSTOPTS options go away as well? Should > > the implementation cache the IPV6_RTHDRDSTOPTS options in case Routing > > header will appear later? > > Are you asking about sticky options or ancillary data? > For sticky options the simplest thing to me seems to be to > record the option value first (so that it can be returned in a getsockopt) > and then build a header template. The header template will be a function > of all the sticky options. This means that IPV6_RTHDRDSTOPTS and IPV6_RTHDR > can be setsockopt independently, but that the transmitted header will > only contain a destination header before the routing header when both of > them are set. > > But other implementors might see things differently. > Also, is this something we should nail down in the spec? > I probably wouldn't bother with removing the destination option header if the routing header is removed. In fact this might actually have some utility in that someone, if they were of a mind, could use this as a way to insert multiple destination options headers into a datagram. In general I had assumed that IPV6_RTHDRDSTOPTS and IPV6DSTOPTS simply allowed one specify the relative ordering of two destination options headers. If there was a routing header fine but it wasn't necessarily a requirement. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 20 12:57:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA17265 for ipng-dist; Fri, 20 Aug 1999 12:53:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17258 for ; Fri, 20 Aug 1999 12:52:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA15881 for ; Fri, 20 Aug 1999 12:52:56 -0700 (PDT) Received: from isrv3.pa.vix.com (isrv3.pa.vix.com [204.152.184.182]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05603 for ; Fri, 20 Aug 1999 12:52:56 -0700 (PDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.pa.vix.com (8.9.1/8.9.1) via ESMTP id MAA17427; Fri, 20 Aug 1999 12:52:55 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: from bb.rc.vix.com (localhost [127.0.0.1]) by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id MAA15739; Fri, 20 Aug 1999 12:52:55 -0700 (PDT) env-from (Bob_Halley@iengines.net) Message-Id: <199908201952.MAA15739@bb.rc.vix.com> To: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: draft-ietf-ipngwg-dns-lookups-04.txt Date: Fri, 20 Aug 1999 12:52:55 -0700 From: Bob Halley Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft is vague about just what "type A6 additional section processing" is. If you look at it like type A additional section processing, then you would see if you had an A6 RRset for the target name, and if so you would add it to the additional data section. You would not follow the A6 chains. However, section 5 of the draft talks about adding "any relevant A6 records available locally". The relevant A6 records are more than just the A6 records for the target name; they are any A6 record in the A6 chains for the target name. The requestor would like to get as much information about the A6 chains as possible, to reduce the number of times it has to query the server. I propose that the draft define "type A6 additional data section processing" to mean "add all locally known data about the A6 chains for the target name that will fit in the response". (I'm sure someone can come up with better phrasing that that.) Also, in section 4.1.2, it says A query with QTYPE=A6 causes type A and type AAAA additional section processing for the QNAME, and type A6 and type NS additional section processing for the DNS names, if any, in the RDATA field of the A6 records in the answer section. Type NS additional section processing is required. The intent is to give a hint as to where more information about the A6 target name might be found, saving the requestor from having to figure that out. This kind of processing is not done for any other RR type that has a target name (e.g. MX). The issues I see: The responding server is doing type A6 additional section processing for the answer section A6 target names. If it actually has these A6 records, then adding the NS records isn't very helpful, since the requestor probably won't need to use them. The NS records are the responder's best information about where to go next, but the requestor may have better-matching NS records in its cache. There is more work to generate a reply. The NS records are not needed by simple resolvers (i.e. those that always forward to a set of nameservers willing to do recursion). I propose eliminating type NS additional section processing from the draft. Comments? /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 20 13:26:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA17317 for ipng-dist; Fri, 20 Aug 1999 13:21:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17310 for ; Fri, 20 Aug 1999 13:21:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA13426; Fri, 20 Aug 1999 13:21:06 -0700 (PDT) Received: from isrv3.pa.vix.com (isrv3.pa.vix.com [204.152.184.182]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28182; Fri, 20 Aug 1999 14:21:06 -0600 (MDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.pa.vix.com (8.9.1/8.9.1) via ESMTP id NAA19024; Fri, 20 Aug 1999 13:21:06 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: from bb.rc.vix.com (localhost [127.0.0.1]) by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id NAA16349; Fri, 20 Aug 1999 13:21:05 -0700 (PDT) env-from (Bob_Halley@iengines.net) Message-Id: <199908202021.NAA16349@bb.rc.vix.com> To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis IPV6_PKTINFO and IPv4-mapped IPv6 Addresses In-Reply-To: Message from Erik Nordmark of "Thu, 19 Aug 1999 23:06:10 PDT." Date: Fri, 20 Aug 1999 13:21:05 -0700 From: Bob Halley Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > Do you care about the ifindex or just the ability to get the destination > address (in recvmsg) and being able to set the source address per packet > in sendmsg? Getting the destination address (and setting the source address in replies) is interesting because it allows me to use one UDP socket instead of having to have one for each interface address. Being able to use ifindex is also interesting, although less so. I could use it to select how the server would behave, for example treating requests that came from an interface on an internal network differently from those which came from an external interface. > The reason I ask is because in our implementation it would be relatively > easy to add the ipi6_addr part of IPV6_PKTINFO for IPv4-mapped addresses > but more difficult to handle the ipi6_ifindex. I can certainly understand that. Still, I'd rather see no IPV6_PKTINFO for mapped addresses than different levels of implementation which varied by vendor. >From my application developer's point of view, the attractiveness of IPv4-mapped IPv6 addresses is living in the V6 world, and using the V6 APIs to get additional functionality. If mapped addresses are not "first class" objects, but are subject to many restrictions and caveats (other than those where there is no meaningful V4 equivalent), it's going to be easier if I just keep V4 and V6 separate. /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 20 15:33:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA17435 for ipng-dist; Fri, 20 Aug 1999 15:29:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17425 for ; Fri, 20 Aug 1999 15:29:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA11410 for ; Fri, 20 Aug 1999 15:28:58 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA13384 for ; Fri, 20 Aug 1999 16:28:58 -0600 (MDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Aug 1999 15:27:28 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.14) id ; Fri, 20 Aug 1999 15:27:28 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145157E5@RED-MSG-50> From: Richard Draves To: "'JINMEI Tatuya / ????'" , Francis.Dupont@inria.fr Cc: ipng@sunroof.eng.sun.com Subject: RE: Comments on 2292bis (Adv. API) Date: Fri, 20 Aug 1999 15:27:17 -0700 X-Mailer: Internet Mail Service (5.5.2650.14) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > struct sockaddr_in6 sa1, sa2; > sa1.sin6_scope_id = 1; > sa1.sin6_addr = fe80::1; > sa2.sin6_scope_id = 2; > sa2.sin6_addr = fe80::2; > bind(sa1); > sendto(sa2); I would expect (or at least allow) an error. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 22 23:11:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA19240 for ipng-dist; Sun, 22 Aug 1999 23:07:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19233 for ; Sun, 22 Aug 1999 23:07:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA05853 for ; Sun, 22 Aug 1999 23:07:24 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA29173 for ; Sun, 22 Aug 1999 23:07:23 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA27332; Mon, 23 Aug 1999 15:07:03 +0900 (JST) To: relevant-places: ; X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: commercial IPv6 service launched in Japan From: itojun@iijlab.net Date: Mon, 23 Aug 1999 15:07:03 +0900 Message-ID: <27330.935388423@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry for this marketing-like email, but I believe this is a very good news for IPv6. IIJ (one of biggest ISPs in Japan) today announced commercial IPv6 trial service. It is is modeled as addendum service for its IPv4 leased line services. It uses RFC1933 tunnel as its medium, only because there are less equipments available for IPv6 native leased line services. Note that this is not an ad-hoc experiment from iijlab (research laboratory division of IIJ - I'm one of member at iijlab), but very official service from IIJ. I believe this is one of very first commercial ISP activity for IPv6 services. http://www.iij.ad.jp/pressrelease/1999/ipv6-service-e.html itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 22 23:11:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA19249 for ipng-dist; Sun, 22 Aug 1999 23:09:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19242 for ; Sun, 22 Aug 1999 23:09:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA00737 for ; Sun, 22 Aug 1999 23:09:33 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05804 for ; Mon, 23 Aug 1999 00:09:26 -0600 (MDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id OAA12615; Mon, 23 Aug 1999 14:59:53 +0900 (JST) Date: Mon, 23 Aug 1999 15:09:28 +0900 Message-ID: <14272.58776.753073.60797N@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com Subject: RE: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Fri, 20 Aug 1999 15:27:17 -0700" <4D0A23B3F74DD111ACCD00805F31D810145157E5@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D810145157E5@RED-MSG-50> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 20 Aug 1999 15:27:17 -0700, >>>>> Richard Draves said: >> struct sockaddr_in6 sa1, sa2; >> sa1.sin6_scope_id = 1; >> sa1.sin6_addr = fe80::1; >> sa2.sin6_scope_id = 2; >> sa2.sin6_addr = fe80::2; >> bind(sa1); >> sendto(sa2); > I would expect (or at least allow) an error. Yes, I think an error would be reasonable. But the behavior that Francis' said in his mail seems to just allow the node to send a packet with the source address fe80::1(scope 1) to the interface whose scope id is 2. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 23 00:39:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA19356 for ipng-dist; Mon, 23 Aug 1999 00:35:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19349 for ; Mon, 23 Aug 1999 00:35:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA23953 for ; Mon, 23 Aug 1999 00:35:31 -0700 (PDT) Received: from lorraine.loria.fr (lorraine.loria.fr [152.81.1.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA19454 for ; Mon, 23 Aug 1999 01:35:29 -0600 (MDT) Received: from loria.fr (antibes.loria.fr [152.81.12.73]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with ESMTP id JAA20367; Mon, 23 Aug 1999 09:35:28 +0200 (MET DST) Message-ID: <37C0F9C0.457E20DA@loria.fr> Date: Mon, 23 Aug 1999 09:35:28 +0200 From: Isabelle Chrisment X-Mailer: Mozilla 4.03 [fr] (WinNT; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Call For Participation in Mobile-IPv6 Connectathon Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk CALL FOR PARTICIPATION MOBILE IPv6 CONNECTATHON September 15- 17, 1999, LORIA, Nancy, France The G6 group is organizing a mobile-IPv6 connectathon in France, in Nancy, on September 15, 16 & 17 1999. Nancy is located in the east of France. If you have mobile-IPv6 code and would like to participate to this event complete the enclosed registration form before END OF AUGUST. Further information is available at http://www.loria.fr/~ichris/mobipv6 REGISTRATION FORM FOR MOBILE-IPv6 CONNECTATHON'99 Workshop Date : Septembre 15 - September 17 1999 The reception of participants will begin September 15, from 10.00 am to 10.30 am. The workshop will be ended September 17, at midday. Conference Location INRIA-LORIA/ Nancy 615 rue du Jardin Botanique BP 101 54602 Villers-Lès-Nancy url : http://www.loria.fr Registration form to be completed and forwarded to re@loria.fr _______________________________________________________________________________ Name (first, middle, last) _______________________________________________________________________________ Affiliation (for badge) _______________________________________________________________________________ Title/Job Function _______________________________________________________________________________ Address _______________________________________________________________________________ City Prov/State Zip Code _______________________________________________________________________________ Country _______________________________________________________________________________ Telephone _______________________________________________________________________________ Fax _______________________________________________________________________________ E-mail Participation in the Dinner : (9/16/1999) Yes __ No __ Date/Time of arrival : Date/Time of departure : -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 23 01:40:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA19438 for ipng-dist; Mon, 23 Aug 1999 01:37:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19431 for ; Mon, 23 Aug 1999 01:37:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA27385 for ; Mon, 23 Aug 1999 01:37:44 -0700 (PDT) Received: from lorraine.loria.fr (lorraine.loria.fr [152.81.1.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28838 for ; Mon, 23 Aug 1999 02:37:43 -0600 (MDT) Received: from loria.fr (antibes.loria.fr [152.81.12.73]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with ESMTP id KAA23781 for ; Mon, 23 Aug 1999 10:37:42 +0200 (MET DST) Message-ID: <37C10855.AA914F05@loria.fr> Date: Mon, 23 Aug 1999 10:37:41 +0200 From: Isabelle Chrisment X-Mailer: Mozilla 4.03 [fr] (WinNT; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Call For Participation in Mobile-IPv6 Connectathon Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk CALL FOR PARTICIPATION MOBILE IPv6 CONNECTATHON September 15- 17, 1999, LORIA, Nancy, France The G6 group is organizing a mobile-IPv6 connectathon in France, in Nancy, on September 15, 16 & 17 1999. Nancy is located in the east of France. If you have mobile-IPv6 code and would like to participate to this event complete the enclosed registration form before END OF AUGUST. Further information is available at http://www.loria.fr/~ichris/mobipv6 REGISTRATION FORM FOR MOBILE-IPv6 CONNECTATHON'99 Workshop Date : Septembre 15 - September 17 1999 The reception of participants will begin September 15, from 10.00 am to 10.30 am. The workshop will be ended September 17, at midday. Conference Location INRIA-LORIA/ Nancy 615 rue du Jardin Botanique BP 101 54602 Villers-Lès-Nancy url : http://www.loria.fr Registration form to be completed and forwarded to re@loria.fr ____________________________________________________________________________ ___ Name (first, middle, last) ____________________________________________________________________________ ___ Affiliation (for badge) ____________________________________________________________________________ ___ Title/Job Function ____________________________________________________________________________ ___ Address ____________________________________________________________________________ ___ City Prov/State Zip Code ____________________________________________________________________________ ___ Country ____________________________________________________________________________ ___ Telephone ____________________________________________________________________________ ___ Fax ____________________________________________________________________________ ___ E-mail Participation in the Dinner : (9/16/1999) Yes __ No __ Date/Time of arrival : Date/Time of departure : -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 23 09:38:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA20594 for ipng-dist; Mon, 23 Aug 1999 09:35:20 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20587 for ; Mon, 23 Aug 1999 09:35:15 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA27073 for ipng@sunroof.eng.sun.com; Mon, 23 Aug 1999 09:33:25 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20447 for ; Mon, 23 Aug 1999 09:25:24 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA367412; Mon, 23 Aug 1999 09:25:16 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.9.3+Sun/8.9.3) id JAA19919; Mon, 23 Aug 1999 09:24:39 -0700 (PDT) Date: Mon, 23 Aug 1999 09:24:39 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <199908231624.JAA19919@locked.eng.sun.com> To: richdr@microsoft.com Subject: Source address selection Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In section 4.2 of draft-draves-ipngwg-simple-srcaddr-01.txt. it states that >It is RECOMMENDED that the candidate source addresses be the set of >unicast addresses assigned to the interface that will be used to >send to the destination. (The "outgoing" interface.) For a given destination, there could be multiple routes e.g multiple default routes, by which the destination can be reached. Each route may be reachable through a different interface. If we choose the route and hence the interface without looking at the scope of the destination, we may send out a packet to global scope with the link local source address i.e the interface chosen may not have global scoped addreeses. So, when there are multiple routes to the same destination, should the route selection look at the scope of the destination so that a proper *source address* would be selected ? -mohan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 23 12:46:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA21116 for ipng-dist; Mon, 23 Aug 1999 12:41:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21109 for ; Mon, 23 Aug 1999 12:41:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA09031; Mon, 23 Aug 1999 12:41:28 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21354; Mon, 23 Aug 1999 13:41:27 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id PAA32008; Mon, 23 Aug 1999 15:41:26 -0400 (EDT) Received: from whitestar.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000016004; Mon, 23 Aug 1999 15:41:26 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA01909; Mon, 23 Aug 1999 15:41:25 -0400 Message-Id: <37C1A3E5.91C3DB81@zk3.dec.com> Date: Mon, 23 Aug 1999 15:41:25 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.51 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: Erik Nordmark Cc: IPNG Working Group Subject: Re: Comments on 2292bis (Adv. API) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > > Section 2.1.2 [Page 9] > > - The reviewers were questioning the need for the following definition: > > 490 struct in6_addr ip6r0_addr[1]; /* up to 127 addresses */ > > > > This definition made the ip6_rthdr0 structure stick out from all the others. > > The suggestion is to remove this line and add a comment (just like all the > > other header structures) that states that the Routing Header 0 is followed > > by an array of IPv6 addresses. > > I agree there isn't perfect consistency. > But I do find it useful when writing code since I can access > rthdr->ip6r0_addr[i] > instead of something like > ((struct in6_addr *)&rthdr[1])[i] > if I remove the field. As Francis Dupont pointed out in an earlier message, you can have zero addresses in a routing header (not very usefull) and the current definition can cause confusion with this scenario. For the case above the implementation can define a pointer to the addresses in the routing header and use that pointer to reference all the addresses. It will get rid of the cast you showed. > > > > Section 3.1 [page 17] > > - What happens if the IPV6_CHECKSUM option is set for ICMPv6 sockets? > > I'll add "An attempt to set IPV6_CHECKSUM for an ICMPv6 socket will fail." > > > - Is this option disabled by default only for raw sockets that were not > > created with IPPROTO_ICMPV6? > > Spec already says "By default, this socket option is disabled." > The option has no meaning for ICMPv6 sockets since they always do their > checksum. > Could you state that in the spec? > > > - Describe the behavior of getsockopt() for IPV6_ options in this section. > > Do these options support a getsockopt() call and what do they return? > > My intent was to leave that unspecified in order to allow implementations that > support both 2292 and 2292bis using the same value for e.g. > IP_RECVRTHDR and IP_RTHDR. > Such an implementation might want to return the value used to enable receipt > i.e. the integer. > Implementations that only support 2292bis would presumably return what was > set with setsockopt i.e. the sticky option content. > > If no implementors will provide 2292 compatibilty using the above scheme > then we can nail down the behavior in the spec. > After a closer look at the option processing, I found that there is an ambiguity between 2292 and 2292bis. In particular, the ambiguity exists with IPV6_HOPLIMIT option. With the 2292, this was an 'on/off' options. With 2292bis sticky options, this now takes the actually hop limit itself. If the implementaion decides to support both specs, how is it to pick which option to set (both values are int)? In general here, I agree with Sam Manthorpe's comment that we should not try to be compatible with 2292. This would get rid of the ambiguities and would allow specification of getsockopt(). > > > > Section 5.1 [page 26] > > - What is the precedence of sin6_scope_id relative to the interface > > specified by the IPV6_MULTICAST_IF, IPV6_PKTINFO and/or IPV6_NEXTHOP options? > > Good question! What should it be? (IPv6_NEXTHOP doesn't interact with > the others - it is the only way to specify the nexthop address.) > What we currently implement in Solaris is that the "easiest to change" > gets precedence. > Thus if sin6_scope_id is set and the destination is link-local it is > used to determine the interface. > If not, if IPV6_PKTINFO is set in acillary data and the ipi6_ifindex is > non-zero it applies. > Finally IPV6_MULTICAST_IF applies for multicast packets. > > Do we want to specify such details? If so, does the above order make sense? > There has been a lot of discussion of this particular issue on the list and I belive that we should clarify the details. As it stands now, there is a lot of confustion for application programers. > > Section 7 [page 31] > > 1691 .... These > > 1692 requirements and the terminology used with these options are > > 1693 discussed in Section 4.2 and Appendix B of [RFC-2460]. > > > > - Is the assumption here that all options MUST be defined according to > > section 4.2 and Appendix B of rfc2460? We noticed that if we do not > > follow the instructions in Appendix B, we were able to design options > > that broke the API. If the working of this API depends on Appendix B, > > it should be stated so. > > I don't understand what "broke the API" means. > If you define an option that doesn't follow the asignment rules in 2460 > then you might not be able to access fields in the option used aligned > access. > If you use the inet6_opt_get_val() and inet6_opt_set_val(), and > the implementation of those functions take advantage of aligned access, > then you might see the sending and receiving applications dump core. > Perhaps we should add a note to point out that robust receivers should > verify alignment before calling inet6_opt_get_val(). > Or have inet6_opt_get_val() check alignment and fail by returning -1? > > > 1701 .... The > > 1700 functions below need to know the alignment of the end of the > > option - Why does this spec institute this limitation for the API? Why not > > just pass the alignX and alignY? I am guessing these will be defined in the > > Option Specification and makes it easier for application programmers to use > > the API. > > It would make the API simpler if we were to pass X and Y to the > > inet6_opt_append(). This would also cause the API not to break if > > following Appendix B is NOT a MUST. > > Because in order to reserve space and lay out the option you would need > three things: > the size of the option > alignX > alignY > > You can reduce this by removing alignX (or is it Y?) if you assume that > the largest field is last in the option (as specified in 2460 appendix B). > > So what does "break the API" mean? > The problem that we saw with this specification is that it heavily depends on Appendix B of 2460. In particular that the fields have to be ordered by size. If someone does not follow this specification then the API as it stands right now will not be able to calculate allignment function correctly. For example, considere these 2 options: OPT1:(doesn't follow Appendix B) OPT2: Length = 12 Length = 12 Data1 = 8 bytes Data1 = 4 bytes Data2 = 4 bytes Data2 = 4 bytes Data3 = 4 bytes The alignment of the end of both of these options is 4 since the last data field is only 4 bytes. If that is the case, then when setting up OPT1, the Data1 field may not be aligned on a natural boundry and may break the applications and cause alignment faults. If we were to fix OPT1 to follow Appendix B, everything works fine. There reason we are advocating for 'alignX' and 'alignY' as arguments to the API is that they will already be defined in the Option Specification and easily used ('length' will be the 3 argument). If the Option Specification does not follow Appendix B (it doesn't have to), then this API will still align the data correctly and conserve as much space as possible (one of the goals stated in 2460). > > > > Section 8.2 [page 33] > > 1825 When using ancillary data a Destination options header is passed > > 1826 between the application and the kernel as follows: The set > > preceding > > 1827 a Routing header are specified with the cmsg_level member is set to > > 1828 IPPROTO_IPV6 and the cmsg_type member is set to IPV6_RTHDRDSTOPTS. > > 1829 Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently > > 1830 ignore when sending packets unless a Routing header is also > > 1831 specified. > > > > - As the spec states here, IPV6_RTHDRDSTOPTS options are ignored unless > > Routing header is present. Does this mean that if the user has > > IPV6_RTHDRDSTOPTS options and a Routing header, and then the user removes > > the Routing header, the IPV6_RTHDRDSTOPTS options go away as well? Should > > the implementation cache the IPV6_RTHDRDSTOPTS options in case Routing > > header will appear later? > > Are you asking about sticky options or ancillary data? > For sticky options the simplest thing to me seems to be to > record the option value first (so that it can be returned in a getsockopt) > and then build a header template. The header template will be a function > of all the sticky options. This means that IPV6_RTHDRDSTOPTS and IPV6_RTHDR > can be setsockopt independently, but that the transmitted header will > only contain a destination header before the routing header when both of > them are set. > > But other implementors might see things differently. > Also, is this something we should nail down in the spec? > Yes, I was refering to sticky otions. It looks like you are advocating caching the options. In you implementation if the user were to set both IPV6_RTHDRDSTOPTS and IPV6_RTHDR options, and then unset IPV6_RTHDR, you would still have the IPV6_RTHDRDSTOPTS option set, but will ignore it. Is my understanding correct? It might be nice to have it nailed down in the spec. What do the others think? > > > > Section 9.1 [page 34] > > 1875 ... If the extlen value is too small or not a multiple of 8 the > > 1876 function fails and returns -1. > > > > - What do you mean by "too small" in this sentence? > > I guess zero is the only too small value that is a multiple of 8. > Thus it is really" > If the extlen value is not a positive multiple of 8 the > function fails and returns -1. > Will this be in the new spec? > > I'll address the rest of the comments in a second email message. > > Erik Thanks -vlad +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 23 20:56:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA21985 for ipng-dist; Mon, 23 Aug 1999 20:53:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21978 for ; Mon, 23 Aug 1999 20:53:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA19232; Mon, 23 Aug 1999 20:53:27 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA16540; Mon, 23 Aug 1999 20:53:21 -0700 (PDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id MAA14990; Tue, 24 Aug 1999 12:43:05 +0900 (JST) Date: Tue, 24 Aug 1999 12:52:36 +0900 Message-ID: <14274.5892.693682.9106S@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: vlad@zk3.dec.com Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-Reply-To: In your message of "Mon, 23 Aug 1999 15:41:25 -0400" <37C1A3E5.91C3DB81@zk3.dec.com> References: <37C1A3E5.91C3DB81@zk3.dec.com> User-Agent: Wanderlust/2.1.3 (Sukiyaki) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 42 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 23 Aug 1999 15:41:25 -0400, >>>>> Vladislav Yasevich said: >> > Section 8.2 [page 33] (snip) >> > - As the spec states here, IPV6_RTHDRDSTOPTS options are ignored unless >> > Routing header is present. Does this mean that if the user has >> > IPV6_RTHDRDSTOPTS options and a Routing header, and then the user removes >> > the Routing header, the IPV6_RTHDRDSTOPTS options go away as well? Should >> > the implementation cache the IPV6_RTHDRDSTOPTS options in case Routing >> > header will appear later? >> >> Are you asking about sticky options or ancillary data? >> For sticky options the simplest thing to me seems to be to >> record the option value first (so that it can be returned in a getsockopt) >> and then build a header template. The header template will be a function >> of all the sticky options. This means that IPV6_RTHDRDSTOPTS and IPV6_RTHDR >> can be setsockopt independently, but that the transmitted header will >> only contain a destination header before the routing header when both of >> them are set. >> >> But other implementors might see things differently. >> Also, is this something we should nail down in the spec? > Yes, I was refering to sticky otions. It looks like you are advocating caching > the options. In you implementation if the user were to set both > IPV6_RTHDRDSTOPTS and IPV6_RTHDR options, and then unset IPV6_RTHDR, you would > still have the IPV6_RTHDRDSTOPTS option set, but will ignore it. Is my > understanding correct? > It might be nice to have it nailed down in the spec. What do the others think? I agree with you that it sould be nailed down. The current specification is surely ambiguous and this ambiguity will confuse application programmers. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 04:40:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA22382 for ipng-dist; Tue, 24 Aug 1999 04:37:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22375 for ; Tue, 24 Aug 1999 04:37:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA28241 for ; Tue, 24 Aug 1999 04:37:29 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA03789 for ; Tue, 24 Aug 1999 05:37:28 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id NAA16428; Tue, 24 Aug 1999 13:37:26 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id NAA09294; Tue, 24 Aug 1999 13:37:25 +0200 (MET DST) Message-Id: <199908241137.NAA09294@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Sat, 21 Aug 1999 03:42:35 +0900. <14269.41371.28379.75679V@condor.isl.rdc.toshiba.co.jp> Date: Tue, 24 Aug 1999 13:37:24 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Do you allow the packet to be sent on a different interface > than the interface to which the source address belongs? > => the IPV6_PKTINFO will try to overwrite both the interface and the > source address then will fail: this is not allowed but is not a real > problem because bind() and IPV6_PKTINFO are alternatives. => I should have been more precise: IPV6_PKTINFO with a not-unspecified address. I don't think so. First, a problematic situation could happen even without IPV6_PKTINFO. For example, consider the following sample code. struct sockaddr_in6 sa1, sa2; sa1.sin6_scope_id = 1; sa1.sin6_addr = fe80::1; sa2.sin6_scope_id = 2; sa2.sin6_addr = fe80::2; bind(sa1); sendto(sa2); then, what should happen? In the above example, we don't use IPV6_PKTINFO at all! => I've already recognized I have not taken into account the bind() then send() case... Of course the document should give some guide-lines! Secondly, I believe that bind() and IPV6_PKTINFO can coexist. What if you call bind() then call sendmsg with IPV6_PKTINFO and if the interface specified by sin6_scope_id of bind() contradicts the interface specified by IPV6_PKTINFO? => I still believe it is and will be very seldom that both bind() and IPV6_PKTINFO with an address will be used in a program but I think this is not a good reason to forget to specify the precedence between all the different ways to give the source address or/and the outgoing interface. Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 04:52:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA22416 for ipng-dist; Tue, 24 Aug 1999 04:48:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22409 for ; Tue, 24 Aug 1999 04:48:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA28694 for ; Tue, 24 Aug 1999 04:48:43 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA09075 for ; Tue, 24 Aug 1999 04:48:42 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id NAA16688; Tue, 24 Aug 1999 13:48:41 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id NAA29712; Tue, 24 Aug 1999 13:48:39 +0200 (MET DST) Message-Id: <199908241148.NAA29712@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Comments on 2292bis (Adv. API) In-reply-to: Your message of Mon, 23 Aug 1999 15:09:28 +0900. <14272.58776.753073.60797N@condor.isl.rdc.toshiba.co.jp> Date: Tue, 24 Aug 1999 13:48:38 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> On Fri, 20 Aug 1999 15:27:17 -0700, >>>>> Richard Draves said: >> struct sockaddr_in6 sa1, sa2; >> sa1.sin6_scope_id = 1; >> sa1.sin6_addr = fe80::1; >> sa2.sin6_scope_id = 2; >> sa2.sin6_addr = fe80::2; >> bind(sa1); >> sendto(sa2); > I would expect (or at least allow) an error. Yes, I think an error would be reasonable. But the behavior that Francis' said in his mail seems to just allow the node to send a packet with the source address fe80::1(scope 1) to the interface whose scope id is 2. => precedence and conflict resolution are two different things: if all kinds of conflict give an error then precedence is no more needed... I believe we need both: in some case (for instance IPV6_PKTINFO) some precedence should be applied, in other cases (like the bind() then send() one) an error is the best answer. Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 09:40:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA22736 for ipng-dist; Tue, 24 Aug 1999 09:36:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22729 for ; Tue, 24 Aug 1999 09:35:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA10365 for ; Tue, 24 Aug 1999 09:35:58 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA10629 for ; Tue, 24 Aug 1999 10:35:55 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 24 Aug 1999 09:33:11 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Tue, 24 Aug 1999 09:33:11 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451581F@RED-MSG-50> From: Richard Draves To: "'Mohan Parthasarathy'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Source address selection Date: Tue, 24 Aug 1999 09:33:07 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >It is RECOMMENDED that the candidate source addresses be the set of > >unicast addresses assigned to the interface that will be used to > >send to the destination. (The "outgoing" interface.) > > For a given destination, there could be multiple routes > e.g multiple default routes, by which the destination can > be reached. Each route may be reachable through a different > interface. If we choose the route and hence the interface > without looking at the scope of the destination, we may send > out a packet to global scope with the link local source > address i.e the interface chosen may not have global scoped > addreeses. > > So, when there are multiple routes to the same destination, > should the route selection look at the scope of the destination > so that a proper *source address* would be selected ? If I understand correctly, you are asking if source address selection concerns should influence the routing decision. For example, if there are two default routes, should one default route be preferred over another because it will lead to a better choice of source address. I think such behavior should be allowed but not required. Would it be helpful to have some discussion of this point in the draft? Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 11:27:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA22956 for ipng-dist; Tue, 24 Aug 1999 11:23:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22949 for ; Tue, 24 Aug 1999 11:23:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA13950 for ; Tue, 24 Aug 1999 11:23:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03780 for ; Tue, 24 Aug 1999 11:23:01 -0700 (PDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA02718; Tue, 24 Aug 1999 11:23:01 -0700 (PDT) Message-Id: <3.0.5.32.19990824112142.0356f4e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Aug 1999 11:21:42 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Interim Meeting Announcement Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are pleased to announce that the IPng working group will hold an interim meeting in Tokyo from September 30 through October 1. The meeting is hosted by the WIDE group. The meeting will focus on IPv6 Multihoming. We think multihoming is an important topic for the w.g. and that an interim meeting is a good way to move the work forward. Other topics may be added if there is both time and interest. Please send proposed agenda items to and . We are aware that some people in the working group may not be able to travel to Tokyo to attend the meeting. We did some research and concluded that enough people will be able to attend to make the meeting productive. Logistical information can be found at: http://www.wide.ad.jp/events/199909.ipng-interim/ There is enough information there now to make flight reservations. Hotel information will be added soon. We plan to have the meeting end around Noon on Friday (October 1) to allow people time for travel to the airport to make late afternoon flights. An email address to RSVP will be provided later. We wish to thank the WIDE group for their generous offer to host the meeting. Bob Hinden / Steve Deering IPng w.g. Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 11:31:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA22977 for ipng-dist; Tue, 24 Aug 1999 11:29:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22970 for ; Tue, 24 Aug 1999 11:29:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA21742 for ; Tue, 24 Aug 1999 11:29:28 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06586 for ; Tue, 24 Aug 1999 11:29:28 -0700 (PDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id LAA03356; Tue, 24 Aug 1999 11:29:28 -0700 (PDT) Message-Id: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Aug 1999 11:28:09 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Interim Meeting Announcement [w/ Correction] Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [The correct dates are September 29 through October 1] We are pleased to announce that the IPng working group will hold an interim meeting in Tokyo from September 29 through October 1. The meeting is hosted by the WIDE group. The meeting will focus on IPv6 Multihoming. We think multihoming is an important topic for the w.g. and that an interim meeting is a good way to move the work forward. Other topics may be added if there is both time and interest. Please send proposed agenda items to and . We are aware that some people in the working group may not be able to travel to Tokyo to attend the meeting. We did some research and concluded that enough people will be able to attend to make the meeting productive. Logistical information can be found at: http://www.wide.ad.jp/events/199909.ipng-interim/ There is enough information there now to make flight reservations. Hotel information will be added soon. We plan to have the meeting end around Noon on Friday (October 1) to allow people time for travel to the airport to make late afternoon flights. An email address to RSVP will be provided later. We wish to thank the WIDE group for their generous offer to host the meeting. Bob Hinden / Steve Deering IPng w.g. Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 13:54:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA23173 for ipng-dist; Tue, 24 Aug 1999 13:50:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23166 for ; Tue, 24 Aug 1999 13:50:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA23160 for ; Tue, 24 Aug 1999 13:50:25 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01980 for ; Tue, 24 Aug 1999 14:50:24 -0600 (MDT) Received: from classic (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.8.8) with ESMTP id QAA13929 for ; Tue, 24 Aug 1999 16:41:13 -0400 (EDT) Prefer-Language: fr, en Message-Id: <4.2.0.58.19990824164145.03b60100@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 24 Aug 1999 16:43:23 -0400 To: ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: Re: IPng Interim Meeting Announcement [w/ Correction] In-Reply-To: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Any plan to multicast this over the mbone for the people that will not be able to attend? Regards, Marc. At 11:28 99-08-24 -0700, Bob Hinden wrote: >[The correct dates are September 29 through October 1] > >We are pleased to announce that the IPng working group will hold an interim >meeting in Tokyo from September 29 through October 1. The meeting is >hosted by the WIDE group. > >The meeting will focus on IPv6 Multihoming. We think multihoming is an >important topic for the w.g. and that an interim meeting is a good way to >move the work forward. Other topics may be added if there is both time and >interest. Please send proposed agenda items to and >. > >We are aware that some people in the working group may not be able to >travel to Tokyo to attend the meeting. We did some research and concluded >that enough people will be able to attend to make the meeting productive. > >Logistical information can be found at: > > http://www.wide.ad.jp/events/199909.ipng-interim/ > >There is enough information there now to make flight reservations. Hotel >information will be added soon. We plan to have the meeting end around >Noon on Friday (October 1) to allow people time for travel to the airport >to make late afternoon flights. > >An email address to RSVP will be provided later. > >We wish to thank the WIDE group for their generous offer to host the meeting. > >Bob Hinden / Steve Deering >IPng w.g. Chairs > > > > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 16:02:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA23335 for ipng-dist; Tue, 24 Aug 1999 15:58:14 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23328 for ; Tue, 24 Aug 1999 15:58:10 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id PAA28653 for ipng@sunroof.eng.sun.com; Tue, 24 Aug 1999 15:56:19 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23276 for ; Tue, 24 Aug 1999 15:08:12 -0700 (PDT) Received: from locked.eng.sun.com (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA566401; Tue, 24 Aug 1999 15:08:11 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.9.3+Sun/8.9.3) id PAA20567; Tue, 24 Aug 1999 15:07:27 -0700 (PDT) Date: Tue, 24 Aug 1999 15:07:27 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <199908242207.PAA20567@locked.eng.sun.com> To: richdr@microsoft.com Subject: RE: Source address selection Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If I understand correctly, you are asking if source address selection > concerns should influence the routing decision. For example, if there are > two default routes, should one default route be preferred over another > because it will lead to a better choice of source address. > Correct. > I think such behavior should be allowed but not required. > > Would it be helpful to have some discussion of this point in the draft? > As this draft specifically talks about source address selection, the above could be one of the scenarios where one needs to select the route properly so that a proper source address is chosen. Is there a practical case where this could happen i.e having 2 default routes but the right scoped addresses are not available on both the interfaces ? -mohan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 18:28:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA23513 for ipng-dist; Tue, 24 Aug 1999 18:24:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23506 for ; Tue, 24 Aug 1999 18:24:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA28928 for ; Tue, 24 Aug 1999 18:24:12 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA07087 for ; Tue, 24 Aug 1999 19:24:11 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA20054 for ; Wed, 25 Aug 1999 10:24:10 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA19558 for ; Wed, 25 Aug 1999 10:24:10 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA09072 for ; Wed, 25 Aug 1999 10:24:09 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Re: IPng Interim Meeting Announcement [w/ Correction] From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> References: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> X-Mailer: Mew version 1.94b53 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990825102325V.kazu@iijlab.net> Date: Wed, 25 Aug 1999 10:23:25 +0900 X-Dispatcher: imput version 990823(IM125) Lines: 13 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Bob Hinden Subject: IPng Interim Meeting Announcement [w/ Correction] > There is enough information there now to make flight reservations. Hotel > information will be added soon. We plan to have the meeting end around > Noon on Friday (October 1) to allow people time for travel to the airport > to make late afternoon flights. I'm going to talk with a travel agency today to make hotel reservation easier for you. Please wait for a while. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 18:35:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA23531 for ipng-dist; Tue, 24 Aug 1999 18:30:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23524 for ; Tue, 24 Aug 1999 18:30:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA11160 for ; Tue, 24 Aug 1999 18:30:06 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08616 for ; Tue, 24 Aug 1999 19:30:04 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA20156 for ; Wed, 25 Aug 1999 10:30:03 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA20194 for ; Wed, 25 Aug 1999 10:30:03 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA09544 for ; Wed, 25 Aug 1999 10:30:03 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Re: IPng Interim Meeting Announcement [w/ Correction] From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <4.2.0.58.19990824164145.03b60100@mail.viagenie.qc.ca> References: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> <4.2.0.58.19990824164145.03b60100@mail.viagenie.qc.ca> X-Mailer: Mew version 1.94b53 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990825102919W.kazu@iijlab.net> Date: Wed, 25 Aug 1999 10:29:19 +0900 X-Dispatcher: imput version 990823(IM125) Lines: 10 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Marc Blanchet Subject: Re: IPng Interim Meeting Announcement [w/ Correction] > Any plan to multicast this over the mbone for the people that will not be > able to attend? If we can arrange a fat leased line, we will multicast the meeting over *IPv6*. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 19:10:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA23567 for ipng-dist; Tue, 24 Aug 1999 19:06:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23560 for ; Tue, 24 Aug 1999 19:06:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA28328 for ; Tue, 24 Aug 1999 19:06:00 -0700 (PDT) Received: from minilla.access.co.jp ([157.78.176.26]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA19064 for ; Tue, 24 Aug 1999 19:05:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by minilla.access.co.jp (8.9.3/3.7W) with ESMTP id LAA00937; Wed, 25 Aug 1999 11:05:54 +0900 To: ipng@sunroof.eng.sun.com Cc: hinden@iprg.nokia.com, koji@dti.ad.jp Subject: Re: IPng Interim Meeting Announcement [w/ Correction] From: kay (=?iso-2022-jp?B?GyRCJU4lMCVBJTElJBsoQg==?=) In-Reply-To: <19990825095745B.kay@v6.access.co.jp> References: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> <19990825095745B.kay@v6.access.co.jp> X-Mailer: Mew version 1.94b50 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-Id: <19990825110554O.kay@v6.access.co.jp> Date: Wed, 25 Aug 1999 11:05:54 +0900 X-Dispatcher: imput version 990816(IM121) Lines: 58 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've sent this mail only to Bob, so I resend it to ML. Please answer this question, someone. Thanks in advance Kay kay ($B%N%0%A%1%$(B) wrote | Hi Bob, | | I'm very glad to hearing this announce about multi homing(Our site is now | multi-homing now) and held in Tokyo (Yes, I'm living in Tokyo :p) | | One question, | Do I have to register to attend this meeting? | | I can't find out any link to register form in the web. | | | http://www.wide.ad.jp/events/199909.ipng-interim/ | | Thanks in advance | Best regards | Kay | | Bob Hinden wrote | | | [The correct dates are September 29 through October 1] | | | | We are pleased to announce that the IPng working group will hold an interim | | meeting in Tokyo from September 29 through October 1. The meeting is | | hosted by the WIDE group. | | | | The meeting will focus on IPv6 Multihoming. We think multihoming is an | | important topic for the w.g. and that an interim meeting is a good way to | | move the work forward. Other topics may be added if there is both time and | | interest. Please send proposed agenda items to and | | . | | | | We are aware that some people in the working group may not be able to | | travel to Tokyo to attend the meeting. We did some research and concluded | | that enough people will be able to attend to make the meeting productive. | | | | Logistical information can be found at: | | | | http://www.wide.ad.jp/events/199909.ipng-interim/ | | | | There is enough information there now to make flight reservations. Hotel | | information will be added soon. We plan to have the meeting end around | | Noon on Friday (October 1) to allow people time for travel to the airport | | to make late afternoon flights. | | | | An email address to RSVP will be provided later. | | | | We wish to thank the WIDE group for their generous offer to host the meeting. | | | | Bob Hinden / Steve Deering | | IPng w.g. Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 19:17:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA23586 for ipng-dist; Tue, 24 Aug 1999 19:15:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23579 for ; Tue, 24 Aug 1999 19:14:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA06186 for ; Tue, 24 Aug 1999 19:14:54 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19790 for ; Tue, 24 Aug 1999 20:14:53 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA07606; Wed, 25 Aug 1999 11:14:44 +0900 (JST) To: kay (=?ISO-2022-JP?B?GyRCJU4lMCVBJTElJBsoQg==?=) cc: ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, koji@dti.ad.jp In-reply-to: kay's message of Wed, 25 Aug 1999 11:05:54 JST. <19990825110554O.kay@v6.access.co.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPng Interim Meeting Announcement [w/ Correction] From: itojun@iijlab.net Date: Wed, 25 Aug 1999 11:14:44 +0900 Message-ID: <7604.935547284@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >| I'm very glad to hearing this announce about multi homing(Our site is now >| multi-homing now) and held in Tokyo (Yes, I'm living in Tokyo :p) >| >| One question, >| Do I have to register to attend this meeting? >| I can't find out any link to register form in the web. - registeration - accomodation are yet to be announced. we made available the webpage so that foreign people can make flight plan earlier. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 24 19:50:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA23731 for ipng-dist; Tue, 24 Aug 1999 19:47:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23724 for ; Tue, 24 Aug 1999 19:47:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA10959 for ; Tue, 24 Aug 1999 19:47:02 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26759 for ; Tue, 24 Aug 1999 20:47:01 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id MAA19597; Wed, 25 Aug 1999 12:45:31 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 25 Aug 1999 12:45:31 +1000 (EST) From: Peter Tattam Reply-To: Peter Tattam To: itojun@iijlab.net cc: kay , ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, koji@dti.ad.jp Subject: Re: IPng Interim Meeting Announcement [w/ Correction] In-Reply-To: <7604.935547284@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A pity it is rather close to the other Ipv6 forum time as I can't afford to make two trips close together. Let us hope the multicast works ok. Peter On Wed, 25 Aug 1999 itojun@iijlab.net wrote: > > >| I'm very glad to hearing this announce about multi homing(Our site is now > >| multi-homing now) and held in Tokyo (Yes, I'm living in Tokyo :p) > >| > >| One question, > >| Do I have to register to attend this meeting? > >| I can't find out any link to register form in the web. > > - registeration > - accomodation > are yet to be announced. we made available the webpage so that > foreign people can make flight plan earlier. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 01:49:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA23905 for ipng-dist; Wed, 25 Aug 1999 01:44:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23898 for ; Wed, 25 Aug 1999 01:44:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA16126 for ; Wed, 25 Aug 1999 01:44:17 -0700 (PDT) Received: from mediator.uni-c.dk (mediator.uni-c.dk [130.228.12.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08739 for ; Wed, 25 Aug 1999 02:44:16 -0600 (MDT) Received: (from nba@localhost) by mediator.uni-c.dk (8.9.3/8.9.3) id KAA11425 for ipng@sunroof.eng.sun.com; Wed, 25 Aug 1999 10:44:15 +0200 (MET DST) Date: Wed, 25 Aug 1999 10:44:15 +0200 From: Niels Baggesen To: ipng@sunroof.eng.sun.com Subject: Re: IPng Interim Meeting Announcement [w/ Correction] Message-ID: <19990825104415.C949@mediator.uni-c.dk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> <4.2.0.58.19990824164145.03b60100@mail.viagenie.qc.ca> <19990825102919W.kazu@iijlab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990825102919W.kazu@iijlab.net>; from Kazu Yamamoto on Wed, Aug 25, 1999 at 10:29:19AM +0900 Organization: UNI-C Multimedia Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Aug 25, 1999 at 10:29:19 +0900, Kazu Yamamoto wrote: > From: Marc Blanchet > Subject: Re: IPng Interim Meeting Announcement [w/ Correction] > > > Any plan to multicast this over the mbone for the people that will not be > > able to attend? > > If we can arrange a fat leased line, we will multicast the meeting > over *IPv6*. Do we have any multicast connectivity at all for IPv6? /Niels -- Niels Baggesen, UNI-C, Olof Palmes Alle 38, DK-8200 Aarhus N, Denmark Email: Niels.Baggesen@uni-c.dk Tel: +45 89 37 66 69 Fax: +45 89 37 66 77 --- Never underestimate the bandwidth of a CD flying through the lab --- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 02:00:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA23938 for ipng-dist; Wed, 25 Aug 1999 01:57:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23931 for ; Wed, 25 Aug 1999 01:57:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA25153 for ; Wed, 25 Aug 1999 01:57:00 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10785 for ; Wed, 25 Aug 1999 02:56:59 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id RAA29147 for ; Wed, 25 Aug 1999 17:56:58 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id RAA18760 for ; Wed, 25 Aug 1999 17:56:57 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id RAA29389 for ; Wed, 25 Aug 1999 17:56:56 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: Re: IPng Interim Meeting Announcement [w/ Correction] From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <19990825104415.C949@mediator.uni-c.dk> References: <4.2.0.58.19990824164145.03b60100@mail.viagenie.qc.ca> <19990825102919W.kazu@iijlab.net> <19990825104415.C949@mediator.uni-c.dk> X-Mailer: Mew version 1.94b53 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990825175612H.kazu@iijlab.net> Date: Wed, 25 Aug 1999 17:56:12 +0900 X-Dispatcher: imput version 990823(IM125) Lines: 10 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Do we have any multicast connectivity at all for IPv6? Multicast is required by IPv6 by spec. At least in the 6bone-jp, multicast over IPv6 is available. (On last Saturday, a NetBSD user meeting was multicasted to the 6bone-jp.) It is a good chance to implement/deploy IPv6 multicast to your portion of 6bone if not ready. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 04:02:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA24027 for ipng-dist; Wed, 25 Aug 1999 03:59:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24020 for ; Wed, 25 Aug 1999 03:58:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA24214 for ; Wed, 25 Aug 1999 03:58:55 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA01882 for ; Wed, 25 Aug 1999 04:58:55 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16996; Wed, 25 Aug 1999 06:58:54 -0400 (EDT) Message-Id: <199908251058.GAA16996@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-mld-mib-01.txt Date: Wed, 25 Aug 1999 06:58:53 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol Author(s) : B. Haberman, R. Worzella Filename : draft-ietf-ipngwg-mld-mib-01.txt Pages : 15 Date : 24-Aug-99 This document defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module which defines managed objects for implementations of the Multicast Listener Discovery Protocol [MLD]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-mld-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990824075619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990824075619.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 20:33:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA25247 for ipng-dist; Wed, 25 Aug 1999 20:29:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25240 for ; Wed, 25 Aug 1999 20:29:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA12929 for ; Wed, 25 Aug 1999 20:29:13 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19462 for ; Wed, 25 Aug 1999 20:29:12 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA11822; Thu, 26 Aug 1999 12:29:11 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA03558; Thu, 26 Aug 1999 12:29:10 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA02114; Thu, 26 Aug 1999 12:29:09 +0900 (JST) To: ipng@sunroof.eng.sun.com Cc: jun@wide.ad.jp Subject: Re: IPng Interim Meeting Announcement [w/ Correction] From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <19990825102325V.kazu@iijlab.net> References: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> <19990825102325V.kazu@iijlab.net> X-Mailer: Mew version 1.94b54 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990826122826A.kazu@iijlab.net> Date: Thu, 26 Aug 1999 12:28:26 +0900 X-Dispatcher: imput version 990823(IM125) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Kazu Yamamoto Subject: Re: IPng Interim Meeting Announcement [w/ Correction] > I'm going to talk with a travel agency today to make hotel reservation > easier for you. Please wait for a while. A travel agency in Japan, JCOM, will help you on registration to the meeting and reservation of hotel room. JCOM said to me that they have already blocked 50 rooms of the nearest hotel, Mita Miyako hotel. The meeting date is 9/29 - 10/1. The meeting room is available from 9:00 to 17:00 for all days. However, we are planning to start the meeting at 10:30 on the first day because of some preparations. Also, we will have a reception party in 9/29 evening at Mita Miyako hotel. So, my image of the schedule is as follows; 9/28 [Coming to Japan] 9/29 10:30 - 17:00 meeting, 18:00-20:00 reception 9/30 09:00 - 17:00 meeting 10/1 09:00 - 17:00 meeting 10/2 [Back to your country] NOTE: YOU SHOULD UNDERSTAND THAT WESTERN PEOPLE LOSE ONE DAY CROSSING THE PACIFIC OCEAN TO JAPAN. Is my understanding correct? Since JCOM books 50 rooms, check in 9/29 check out 10/2, I have to ask JCOM to change the check in date to 9/28 I want the co-chairs to review this plan. A registration web page will be available in the early next week. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 22:14:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA25527 for ipng-dist; Wed, 25 Aug 1999 22:02:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25520 for ; Wed, 25 Aug 1999 22:01:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA18809 for ; Wed, 25 Aug 1999 22:01:48 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06670 for ; Wed, 25 Aug 1999 23:01:47 -0600 (MDT) Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA29785; Wed, 25 Aug 1999 22:01:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990826122826A.kazu@iijlab.net> References: <3.0.5.32.19990824112809.0343c220@mailhost.iprg.nokia.com> <19990825102325V.kazu@iijlab.net> <19990826122826A.kazu@iijlab.net> Date: Wed, 25 Aug 1999 22:01:13 -0700 To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) From: Steve Deering Subject: Re: IPng Interim Meeting Announcement [w/ Correction] Cc: ipng@sunroof.eng.sun.com, jun@wide.ad.jp Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:28 PM +0900 8/26/99, Kazu Yamamoto wrote: >A travel agency in Japan, JCOM, will help you on registration to the >meeting and reservation of hotel room. JCOM said to me that they have >already blocked 50 rooms of the nearest hotel, Mita Miyako hotel. Kazu, Sounds great. Do you happen to know how much the per-night hotel charge will be? >Also, we will have a reception party in 9/29 evening at Mita Miyako >hotel. So, my image of the schedule is as follows; > >9/28 [Coming to Japan] >9/29 10:30 - 17:00 meeting, 18:00-20:00 reception >9/30 09:00 - 17:00 meeting >10/1 09:00 - 17:00 meeting >10/2 [Back to your country] That looks good. We have announced that the working group business will finish by noon on Friday, 10/1, for those who wish to fly home that same afternoon. Therefore, if it is significantly cheaper to not occupy the meeting room after 12:00 on Friday, you may take advantage of that saving. If not, we could use the meeting room on Friday afternoon for non-working-group purposes, such as interoperability testing, software demos, discussion of deployment and operational issues, etc. >Is my understanding correct? Since JCOM books 50 rooms, check in 9/29 >check out 10/2, I have to ask JCOM to change the check in date to 9/28 I suspect that most non-local attendees will check in on 9/28 and check out on 10/1 or 10/2. Some may wish to arrive a day or two earlier, or depart a day later, in order to include some sightseeing days, oops, I mean jet-lag adjustment days, so it would be good if the hotel arrangements could be somewhat flexible, but that is not essential. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 22:30:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA25561 for ipng-dist; Wed, 25 Aug 1999 22:26:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25554 for ; Wed, 25 Aug 1999 22:25:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA11229 for ; Wed, 25 Aug 1999 22:25:51 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA10982 for ; Wed, 25 Aug 1999 23:25:50 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA16671; Thu, 26 Aug 1999 14:25:49 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA21068; Thu, 26 Aug 1999 14:25:49 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA14418; Thu, 26 Aug 1999 14:25:49 +0900 (JST) To: ipng@sunroof.eng.sun.com, jun@wide.ad.jp Subject: Re: IPng Interim Meeting Announcement [w/ Correction] From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <19990825102325V.kazu@iijlab.net> <19990826122826A.kazu@iijlab.net> X-Mailer: Mew version 1.94b54 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990826142507Z.kazu@iijlab.net> Date: Thu, 26 Aug 1999 14:25:07 +0900 X-Dispatcher: imput version 990823(IM125) Lines: 47 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Steve Deering Subject: Re: IPng Interim Meeting Announcement [w/ Correction] > Do you happen to know how much the per-night hotel > charge will be? I should double-check. However I believe it is 8,500 JPY per night (without any foods and excluding tax). This is very cheap in the Tokyo area because access from the JR Shinagawa station is inconvenient. (But very convenient to the venue.) #When I lived outside Tokyo, my favorite hotel near the Shinagawa #station charged 13,000 JPY. I will go to see this hotel very soon. I expect that rooms are small. I imagine that some guys can't stand. ^^; So, JCOM will provide information of other rich hotels around the JR Shinagawa hotel. People should understand that space in the Tokyo area is the most expensive resource. Rooms are essentially small. Even if two people share one two-bed room, each person is charged. > That looks good. We have announced that the working group business > will finish by noon on Friday, 10/1, for those who wish to fly home > that same afternoon. Ah. I should have read Bob's message carefully! > Therefore, if it is significantly cheaper to not > occupy the meeting room after 12:00 on Friday, you may take advantage > of that saving. If not, we could use the meeting room on Friday > afternoon for non-working-group purposes, such as interoperability > testing, software demos, discussion of deployment and operational > issues, etc. Don't worry about room charge. We keep the room upto 17:00 on Friday. > I suspect that most non-local attendees will check in on 9/28 and check > out on 10/1 or 10/2. Some may wish to arrive a day or two earlier, > or depart a day later, in order to include some sightseeing days, oops, > I mean jet-lag adjustment days, so it would be good if the hotel > arrangements could be somewhat flexible, but that is not essential. Don't worry. It will be flexible. (I omitted to explain details to make the story simple.) --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 22:42:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA25584 for ipng-dist; Wed, 25 Aug 1999 22:33:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25573 for ; Wed, 25 Aug 1999 22:33:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA20369 for ; Wed, 25 Aug 1999 22:33:34 -0700 (PDT) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.140.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16262 for ; Wed, 25 Aug 1999 22:33:33 -0700 (PDT) Received: from junthinkpad600 (98A85ACE.ipt.aol.com [152.168.90.206]) by shonan.sfc.wide.ad.jp (8.9.3+3.2W/3.7Wpl2-shonan) with SMTP id OAA04447; Thu, 26 Aug 1999 14:33:26 +0900 (JST) (envelope-from jun@wide.ad.jp) From: "Jun Murai" To: =?iso-8859-1?B?S2F6dSBZYW1hbW90byAoWlIte35hLkYp?= , Subject: RE: IPng Interim Meeting Announcement [w/ Correction] Date: Thu, 26 Aug 1999 14:33:19 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <19990826142507Z.kazu@iijlab.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kazu, when rich people stays in shinagawa, then only transportation from Shinagawa to the conference place would be a taxi, right? could you check with JCOM about the BUS availability and how it works? jun@santiago in winter.. certainly working for IPv6 address allocations! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 23:59:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA25635 for ipng-dist; Wed, 25 Aug 1999 23:52:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25628 for ; Wed, 25 Aug 1999 23:51:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA24085 for ; Wed, 25 Aug 1999 23:51:56 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA26748 for ; Thu, 26 Aug 1999 00:51:54 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA19139; Thu, 26 Aug 1999 15:51:53 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA03127; Thu, 26 Aug 1999 15:51:52 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA22977; Thu, 26 Aug 1999 15:51:52 +0900 (JST) To: jun@wide.ad.jp, ipng@sunroof.eng.sun.com Subject: RE: IPng Interim Meeting Announcement [w/ Correction] From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <19990826142507Z.kazu@iijlab.net> X-Mailer: Mew version 1.94b54 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990826155109K.kazu@iijlab.net> Date: Thu, 26 Aug 1999 15:51:09 +0900 X-Dispatcher: imput version 990826(IM126) Lines: 14 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Jun Murai" Subject: RE: IPng Interim Meeting Announcement [w/ Correction] > could you check with JCOM about the BUS availability and how it works? Jun, your secretary interprets "the BUS" as public one. And she asked JCOM to put information on the web page now coming. Folks, personally I don't recommend buses even if available. I for one hesitate to take bus in any area of Japan because the convention is varied(e.g timing of payment, 10,000 JPY note can be used or not). Also no English announcement is available I bet. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 25 23:59:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA25645 for ipng-dist; Wed, 25 Aug 1999 23:57:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25638 for ; Wed, 25 Aug 1999 23:56:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA26098 for ; Wed, 25 Aug 1999 23:56:37 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA27735 for ; Thu, 26 Aug 1999 00:56:36 -0600 (MDT) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id PAA20379 for ; Thu, 26 Aug 1999 15:48:54 +0900 (JST) Date: Thu, 26 Aug 1999 15:58:25 +0900 Message-ID: <14276.58769.44610.9106S@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPng Interim Meeting Announcement [w/ Correction] In-Reply-To: In your message of "Wed, 25 Aug 1999 17:56:12 +0900" <19990825175612H.kazu@iijlab.net> References: <4.2.0.58.19990824164145.03b60100@mail.viagenie.qc.ca> <19990825102919W.kazu@iijlab.net> <19990825104415.C949@mediator.uni-c.dk> <19990825175612H.kazu@iijlab.net> User-Agent: Wanderlust/2.1.4 (Tears In Heaven) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 25 Aug 1999 17:56:12 +0900, >>>>> Kazu Yamamoto said: >> Do we have any multicast connectivity at all for IPv6? > Multicast is required by IPv6 by spec. At least in the 6bone-jp, > multicast over IPv6 is available. (On last Saturday, a NetBSD user > meeting was multicasted to the 6bone-jp.) > It is a good chance to implement/deploy IPv6 multicast to your portion > of 6bone if not ready. To those who are interested in an IPv6 multicast session of the interim meeting: We're deploying IPv6 PIM-SM with a single Rendezvous Point in the WIDE 6bone (i.e. part of 6bone-jp). If someone would like to receive IPv6 multicast stream of the interim meeting, please let us know. We're willing to our PIM domain to your site. If there is a router that doesn't support IPv6 PIM between you and us, we'll be able to establish a direct IPv6 link using IPv6/IPv4 tunnel and run PIM over the link. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 02:25:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA25766 for ipng-dist; Thu, 26 Aug 1999 02:22:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25759 for ; Thu, 26 Aug 1999 02:22:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA04170 for ; Thu, 26 Aug 1999 02:22:09 -0700 (PDT) Received: from un (ydcspingw.ydc.co.jp [202.33.211.252]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA05471 for ; Thu, 26 Aug 1999 02:22:08 -0700 (PDT) Received: from italy (Italy.cct.ydc.co.jp [10.21.0.135]) by un (8.9.1+3.1W/3.7W) with SMTP id SAA07624 for ; Thu, 26 Aug 1999 18:23:53 +0900 (JST) Message-Id: <4.1-J.19990826175524.040fee90@un.cct.ydc.co.jp> X-Sender: miyata@bahamas.cct.ydc.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1-J Date: Thu, 26 Aug 1999 18:24:40 +0900 To: ipng@sunroof.eng.sun.com From: Hiroshi Miyata Subject: IPv6 Interoperability test event. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, there, Tahi Project has plan to hold a interoperability test event before/while the IETF IPng Interim Meeting in JAPAN. Schedule from September 26 through October 1. Sunday, September 26 12:00 Noon Registration desk opens. 12:00 Noon to 17:00 Set up Equipment 16:00 -17:00 Opening & Briefing 17:00 -19:00 Reception (Get Together and Evening Refreshments) Monday, September 27 8:45 Registration desk opens. 9:00 -18:00 Interoperability Test (Lunch will be served.) Tuesday, September 28 8:45 Registration desk opens. 9:00 -18:00 Interoperability Test (Lunch will be served.) Wednesday, September 29 8:45 Registration desk opens. 9:00 -17:00 Extra day* Thursday, September 30 8:45 Registration desk opens. 9:00 -17:00 Extra day* Friday, October 1 8:45 Registration desk opens. 9:00 -17:00 Extra day* *Extra day is the days for the persons who want continue the test, and who could not attend the test on 27,28. We welcome a extra persons who has interest in our event. Location: Sasagawa Memorial Hall (map) 3-12-12, Mita, Minato-ku, Tokyo 108 JAPAN Same building as IETF IPng Interim meeting. Accomodations: We recommend MITA MIYAKO HOTEL. http://www.mitamiyako.co.jp/English/index.html Agenda 1)Conformance Test. We perform our conformance test to your implementations as your requirement. You can select the functions to be performed. 2)Interoperablity with our enviroment. We verify interoperability in accordance with the scenarios by building the model network and attaching the target equipment to the model network. The scenarios are focused on routing. 3)Free environment. The environments (Hubs, routers, Ethernet cables, power supply, etc.) which you can freely use for interoperability test with another implementation will be provided. You can find more detail information at the URL below. http://www.tahi.org/ Please visit and check it. Thanks, ................................................ Hiroshi Miyata : Yokogawa Digital Computer Corp. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 04:06:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA25893 for ipng-dist; Thu, 26 Aug 1999 04:03:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25886 for ; Thu, 26 Aug 1999 04:02:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA09941 for ; Thu, 26 Aug 1999 04:02:51 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA15926 for ; Thu, 26 Aug 1999 05:02:49 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09308; Thu, 26 Aug 1999 07:02:47 -0400 (EDT) Message-Id: <199908261102.HAA09308@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6router-alert-06.txt Date: Thu, 26 Aug 1999 07:02:47 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Router Alert Option Author(s) : C. Partridge, A. Jackson Filename : draft-ietf-ipngwg-ipv6router-alert-06.txt Pages : 5 Date : 25-Aug-99 This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6router-alert-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6router-alert-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990825115715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6router-alert-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990825115715.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 04:41:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA25941 for ipng-dist; Thu, 26 Aug 1999 04:37:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25934 for ; Thu, 26 Aug 1999 04:37:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA28418 for ; Thu, 26 Aug 1999 04:37:31 -0700 (PDT) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.140.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA00460 for ; Thu, 26 Aug 1999 04:37:25 -0700 (PDT) Received: from junthinkpad600 (h164.p096.iij4u.or.jp [210.130.96.164]) by shonan.sfc.wide.ad.jp (8.9.3+3.2W/3.7Wpl2-shonan) with SMTP id UAA15010; Thu, 26 Aug 1999 20:37:17 +0900 (JST) (envelope-from jun@wide.ad.jp) From: "Jun Murai" To: =?iso-8859-1?B?S2F6dSBZYW1hbW90byAoWlIte35hLkYp?= , Subject: RE: IPng Interim Meeting Announcement [w/ Correction] Date: Thu, 26 Aug 1999 20:37:16 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <19990826155109K.kazu@iijlab.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk well, my intention was the public transportation. not all the taxi drivers communicate in english anyway. if we can provide a little bit of guidance, 10minitus public bus ride along the straight street can always work. a little bit of adventure at first, but should be all right. lets try to get enough information anyway about the public transportation when we offer shinagawa hotels. so that each of the attendees would make decision. jun > -----Original Message----- > From: Kazu Yamamoto (ŽR–{˜a•F) [mailto:kazu@iijlab.net] > Sent: Thursday, August 26, 1999 3:51 PM > To: jun@wide.ad.jp; ipng@sunroof.eng.sun.com > Subject: RE: IPng Interim Meeting Announcement [w/ Correction] > > > From: "Jun Murai" > Subject: RE: IPng Interim Meeting Announcement [w/ Correction] > > > could you check with JCOM about the BUS availability and how it works? > > Jun, your secretary interprets "the BUS" as public one. And she asked > JCOM to put information on the web page now coming. > > Folks, personally I don't recommend buses even if available. I for one > hesitate to take bus in any area of Japan because the convention is > varied(e.g timing of payment, 10,000 JPY note can be used or > not). Also no English announcement is available I bet. > > --Kazu > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 11:01:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA26336 for ipng-dist; Thu, 26 Aug 1999 10:57:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26329 for ; Thu, 26 Aug 1999 10:57:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA22560 for ; Thu, 26 Aug 1999 10:57:09 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA14053 for ; Thu, 26 Aug 1999 10:57:09 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 1999 10:56:53 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Thu, 26 Aug 1999 10:56:52 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451586F@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: hop limit API question Date: Thu, 26 Aug 1999 10:35:31 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What are the semantics of setting a zero hop limit with the IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS socket options? Does it mean that packets can not leave the sending node, but can be received through loopback? (If the destination address is assigned to the outgoing interface and for multicast, if IPV6_MULTICAST_LOOP allows loopback.) Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 11:45:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA26401 for ipng-dist; Thu, 26 Aug 1999 11:40:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26394 for ; Thu, 26 Aug 1999 11:40:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA10487 for ; Thu, 26 Aug 1999 11:40:21 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA03743 for ; Thu, 26 Aug 1999 11:40:20 -0700 (PDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Aug 1999 11:36:43 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Thu, 26 Aug 1999 11:36:43 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101451587B@RED-MSG-50> From: Richard Draves To: "'Mohan Parthasarathy'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Source address selection Date: Thu, 26 Aug 1999 11:34:39 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As this draft specifically talks about source address selection, > the above could be one of the scenarios where one needs to > select the route properly so that a proper source address is > chosen. Is there a practical case where this could happen i.e > having 2 default routes but the right scoped addresses are > not available on both the interfaces ? I think it's an unlikely scenario, almost certainly indicating misconfiguration. I would rather not require (or even recommend) that source address selection considerations influence the routing decision. I like to keep the two modules separate in my implementation and I imagine that most implementors would feel similarly. But for those that want to do it, it should be allowed. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 13:19:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA26611 for ipng-dist; Thu, 26 Aug 1999 13:12:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26604 for ; Thu, 26 Aug 1999 13:12:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA27487 for ; Thu, 26 Aug 1999 13:11:46 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06110 for ; Thu, 26 Aug 1999 14:11:45 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA03677; Thu, 26 Aug 1999 22:11:43 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA05136; Thu, 26 Aug 1999 22:11:42 +0200 (MET DST) Message-Id: <199908262011.WAA05136@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'IPng List'" Subject: Re: hop limit API question In-reply-to: Your message of Thu, 26 Aug 1999 10:35:31 PDT. <4D0A23B3F74DD111ACCD00805F31D8101451586F@RED-MSG-50> Date: Thu, 26 Aug 1999 22:11:42 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: What are the semantics of setting a zero hop limit with the IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS socket options? Does it mean that packets can not leave the sending node, but can be received through loopback? (If the destination address is assigned to the outgoing interface and for multicast, if IPV6_MULTICAST_LOOP allows loopback.) => there are two cases : - unicast (IPV6_UNICAST_HOPS) : packets have a zero hop limit (then they can't be forwarded because 0 is less than or equal to 1, cf RFC 2460 4.4 about routing header processing). I don't think zero TTL/hop limit *unicast* packets are forbiden on the wire. - multicast (IPV6_MULTICAST_HOPS) : this case should be the same but in general we have kept the IPv4 behavior then they are not sent on the wire but if IPV6_MULTICAST_LOOP was set and a receiver was declared (with IPV6_JOIN_GROUP aka IPV6_ADD_MEMBERSHIP) then the packet is looped and not dropped. The usual BSD piece of code is : } /* * Multicasts with a time-to-live of zero may be looped- * back, above, but must not be transmitted on a network. * Also, multicasts addressed to the loopback interface * are not sent -- the above call to ip6_mloopback() will * loop back a copy if this host actually belongs to the * destination group on the loopback interface. */ if (ip->ip6_hlim == 0 || (ifp->if_flags & IFF_LOOPBACK) != 0) { m_freem(m0); ... I think this behavior is not bad then should be kept ? Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 14:36:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA26764 for ipng-dist; Thu, 26 Aug 1999 14:32:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26757 for ; Thu, 26 Aug 1999 14:32:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA01328 for ; Thu, 26 Aug 1999 14:32:17 -0700 (PDT) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17215 for ; Thu, 26 Aug 1999 14:32:17 -0700 (PDT) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id QAA26509; Thu, 26 Aug 1999 16:32:02 -0500 (CDT) Received: from dal-tx4-43.ix.netcom.com(207.94.121.107) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma026406; Thu Aug 26 16:31:24 1999 Message-ID: <37C5430D.D7E0E7D9@ix.netcom.com> Date: Thu, 26 Aug 1999 14:37:20 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: iana , ICANN Subject: AN interesting article. FYI... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, One might want to tke a look at this... http://www.planetit.com/techcenters/docs/advanced_ip_services/opinion/PIT19990816S0013 Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 15:26:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA26829 for ipng-dist; Thu, 26 Aug 1999 15:22:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26822 for ; Thu, 26 Aug 1999 15:22:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA04191 for ; Thu, 26 Aug 1999 15:22:27 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07825 for ; Thu, 26 Aug 1999 15:22:26 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id PAA19982; Thu, 26 Aug 1999 15:22:25 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id PAA00400; Thu, 26 Aug 1999 15:22:24 -0700 (PDT) Received: from tdc97-cyndi.tdc.3com.com (tdc69pc.tdc.3com.com [139.87.12.225]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id PAA13186; Thu, 26 Aug 1999 15:22:24 -0700 (PDT) Message-Id: <3.0.32.19990826151504.00e1862c@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 26 Aug 1999 15:15:04 -0700 To: Jeff Williams , ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: Re: AN interesting article. FYI... Cc: iana , ICANN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Class A domain name? I think for the rest, you can substitute DECNET for IPv4 and IP for IPv6 and 1988 for 1999 ... it reads the same. Some things never change. Cyndi At 02:37 PM 8/26/99 +0100, Jeff Williams wrote: >All, > > One might want to tke a look at this... > >http://www.planetit.com/techcenters/docs/advanced_ip_services/opinion/PIT19 990816S0013 > >Regards, >-- > >Jeffrey A. Williams >Spokesman INEGroup (Over 95k members strong!) >CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. >Information Network Eng. Group. INEG. INC. >E-Mail jwkckid1@ix.netcom.com >Contact Number: 972-447-1894 >Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 16:50:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA27047 for ipng-dist; Thu, 26 Aug 1999 16:45:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27040 for ; Thu, 26 Aug 1999 16:45:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA11211 for ; Thu, 26 Aug 1999 16:45:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01985 for ; Thu, 26 Aug 1999 17:45:08 -0600 (MDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA22089; Thu, 26 Aug 1999 16:45:03 -0700 (PDT) Message-Id: <3.0.5.32.19990826164338.036a8400@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 26 Aug 1999 16:43:38 -0700 To: Cyndi Jung From: Bob Hinden Subject: Re: AN interesting article. FYI... Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.32.19990826151504.00e1862c@pop.nsd.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Cyndi, >Class A domain name? > >I think for the rest, you can substitute DECNET for IPv4 >and IP for IPv6 and 1988 for 1999 ... it reads the same. The paragraph really speaks for itself: "The other argument for IPv6 is that it would let us solve the forthcoming domain-name-address shortage. Yes, we're running out of domain-name addresses, but perhaps we can address that by reducing the number of Internet addresses you get with each domain name. Throwing blocks of 10,000 addresses in with each Class A name should be a Class A felony; why not just blocks of 1,000 addresses, each of which can handle up to 10,000 virtual addresses in subnets? Let's make the current holders of Class A domain names cough up some of their addresses." A little confused.... Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 17:18:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA27104 for ipng-dist; Thu, 26 Aug 1999 17:13:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27097 for ; Thu, 26 Aug 1999 17:13:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA25535 for ; Thu, 26 Aug 1999 17:13:19 -0700 (PDT) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA20038 for ; Thu, 26 Aug 1999 17:13:18 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id UAA06251 for ipng@sunroof.eng.sun.com; Thu, 26 Aug 1999 20:13:17 -0400 (EDT) Date: Thu, 26 Aug 1999 20:13:17 -0400 (EDT) From: Scott Bradner Message-Id: <199908270013.UAA06251@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the author's bio line Richard Adhikari is a leading journalist on advanced-IP issues for several major publications, including The Wall Street Journal, and is a regular contributor to Planet IT. does not speak well for the wsj Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 17:18:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA27094 for ipng-dist; Thu, 26 Aug 1999 17:11:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27087 for ; Thu, 26 Aug 1999 17:11:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA25160 for ; Thu, 26 Aug 1999 17:11:06 -0700 (PDT) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA19163 for ; Thu, 26 Aug 1999 17:11:05 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id UAA06240 for ipng@sunroof.eng.sun.com; Thu, 26 Aug 1999 20:11:04 -0400 (EDT) Date: Thu, 26 Aug 1999 20:11:04 -0400 (EDT) From: Scott Bradner Message-Id: <199908270011.UAA06240@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "The other argument for IPv6 is that it would let us solve the forthcoming domain-name-address shortage. Yes, we're running out of domain-name addresses, but perhaps we can address that by reducing the number of Internet addresses you get with each domain name. Throwing blocks of 10,000 addresses in with each Class A name should be a Class A felony; why not just blocks of 1,000 addresses, each of which can handle up to 10,000 virtual addresses in subnets? Let's make the current holders of Class A domain names cough up some of their addresses." seems to have combined telephone number assignment rules with IP addressing terms - rather low clue density Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 17:37:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA27160 for ipng-dist; Thu, 26 Aug 1999 17:33:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27153 for ; Thu, 26 Aug 1999 17:33:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA21505 for ; Thu, 26 Aug 1999 17:33:17 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19106 for ; Thu, 26 Aug 1999 18:33:17 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA24549 for ; Thu, 26 Aug 1999 17:32:57 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA29652 for ; Thu, 26 Aug 1999 17:32:57 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id RAA00699 for ipng@sunroof.eng.sun.com; Thu, 26 Aug 1999 17:33:01 -0700 (PDT) Date: Thu, 26 Aug 1999 17:33:01 -0700 (PDT) From: Tim Hartrick Message-Id: <199908270033.RAA00699@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > the author's bio line > > Richard Adhikari is a leading journalist on advanced-IP issues for several > major publications, including The Wall Street Journal, and is a regular > contributor to Planet IT. > > does not speak well for the wsj > It is rather pitiful to see that becoming a "leading journalist" these days requires neither mastery of the English language nor fundamental understanding of the subject matter. A truly amazing combination of ham- handed writing and ignorance. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 20:02:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA27277 for ipng-dist; Thu, 26 Aug 1999 19:58:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27270 for ; Thu, 26 Aug 1999 19:58:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA21116 for ; Thu, 26 Aug 1999 19:58:25 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23897 for ; Thu, 26 Aug 1999 20:58:25 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA04934 for ; Fri, 27 Aug 1999 11:58:24 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA08145 for ; Fri, 27 Aug 1999 11:58:23 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA12698 for ; Fri, 27 Aug 1999 11:58:23 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: THAI conformance/inter-operability test event From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94b55 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990827115742O.kazu@iijlab.net> Date: Fri, 27 Aug 1999 11:57:42 +0900 X-Dispatcher: imput version 990826(IM126) Lines: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI. The TAHI project (http://www.tahi.org) will hold an IPv6 conformance/inter-operability test event before the ipng interim meeting at the same venue. JCOM keeps some hotel rooms for participants of this event. So, if you want to attend it, you can ask JCOM to book hotel rooms. As I said before, the registration/reservation page will be available in the next week. Before you book flight tickets, please give one more look at: http://www.wide.ad.jp/events/199909.ipng-interim/ --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 26 20:59:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA27373 for ipng-dist; Thu, 26 Aug 1999 20:55:56 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27366 for ; Thu, 26 Aug 1999 20:55:44 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA892529; Thu, 26 Aug 1999 20:55:40 -0700 (PDT) Date: Thu, 26 Aug 1999 20:53:24 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: hop limit API question To: Richard Draves Cc: "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8101451586F@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What are the semantics of setting a zero hop limit with the > IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS socket options? We've implemented the multicast behavior to match the IPv4 behavior just like Francis (loop back to any local members on the sending interface if IPV6_MULTICAST_LOOP is set). For unicast we make no checks thus packets would be transmitted with a zero hoplimit. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 06:56:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA27981 for ipng-dist; Fri, 27 Aug 1999 06:53:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27974 for ; Fri, 27 Aug 1999 06:53:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA27935 for ; Fri, 27 Aug 1999 06:53:31 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28923 for ; Fri, 27 Aug 1999 06:53:31 -0700 (PDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id JAA14658; Fri, 27 Aug 1999 09:53:26 -0400 (EDT) Received: from zk3.dec.com by anw.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id JAA0000529454; Fri, 27 Aug 1999 09:53:26 -0400 (EDT) Message-ID: <37C69855.B27D4E77@zk3.dec.com> Date: Fri, 27 Aug 1999 09:53:25 -0400 From: "Joseph J. Vlcek" Reply-To: Joseph.VLcek@Compaq.com X-Mailer: Mozilla 4.51 [en] (X11; I; OSF1 T5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: ipng@sunroof.eng.sun.com, iana , ICANN Subject: Re: AN interesting article. FYI... References: <37C5430D.D7E0E7D9@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Interesting article... I suppose the author would rather be driving a car that: o gets 6 MPG o has no bumpers o has no seat belts o has no airbags o has no A/C (Actually A/C is a safety feature... it helps to prevent you from falling asleep on long hot drives, and it actually saves gas) o has the back seat strapped to the truck bed like granny on the old TV show The Beverly Hill Billies o has a chain drive o has nice sharp hard metal under the dash board o does not have collapsible steering columns o gives off high toxic emissions ... The list goes on... the point being there was always someone in the public that did not want to spend the extra money for new safety features on cars, but the car companies invested the money on it anyway, did have to raise the price of a car but are we better off today. You can bet we are! Bottom line: "Improvements do come at a cost." Jeff Williams wrote: > > All, > > One might want to tke a look at this... > > http://www.planetit.com/techcenters/docs/advanced_ip_services/opinion/PIT19990816S0013 > > Regards, > -- > > Jeffrey A. Williams > Spokesman INEGroup (Over 95k members strong!) > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 972-447-1894 > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Joseph VLcek | Joseph.VLcek@Compaq.com | DTN 264.0823 | 603.884.0823 Happiness is not in the destination; it's in the manner of traveling. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 07:04:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA28005 for ipng-dist; Fri, 27 Aug 1999 07:03:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27998 for ; Fri, 27 Aug 1999 07:03:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28804 for ; Fri, 27 Aug 1999 07:03:01 -0700 (PDT) Received: from ausmail2.austin.ibm.com (ausmail2.austin.ibm.com [192.35.232.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02495 for ; Fri, 27 Aug 1999 07:03:00 -0700 (PDT) Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id IAA29832 for ; Fri, 27 Aug 1999 08:59:21 -0500 Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [9.53.150.76]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id JAA32334; Fri, 27 Aug 1999 09:02:59 -0500 Received: (from marquard@localhost) by mojave.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id JAA34152; Fri, 27 Aug 1999 09:02:59 -0500 To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199908270033.RAA00699@feller.mentat.com> From: Dave Marquardt Date: 27 Aug 1999 09:02:58 -0500 In-Reply-To: Tim Hartrick's message of "Thu, 26 Aug 1999 17:33:01 -0700 (PDT)" Message-ID: Lines: 19 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "20 Minutes to Nikko" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Hartrick writes: > > the author's bio line > > > > Richard Adhikari is a leading journalist on advanced-IP issues for several > > major publications, including The Wall Street Journal, and is a regular > > contributor to Planet IT. > > > > does not speak well for the wsj > > > > It is rather pitiful to see that becoming a "leading journalist" these > days requires neither mastery of the English language nor fundamental > understanding of the subject matter. A truly amazing combination of ham- > handed writing and ignorance. Well, it was an opinion piece, but one ought to back up one's opinion with facts. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 07:22:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA28041 for ipng-dist; Fri, 27 Aug 1999 07:19:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28034 for ; Fri, 27 Aug 1999 07:19:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA00035 for ; Fri, 27 Aug 1999 07:19:06 -0700 (PDT) Received: from central.hub.nih.gov (central.hub.nih.gov [128.231.90.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05544 for ; Fri, 27 Aug 1999 08:19:06 -0600 (MDT) Received: by central.hub.nih.gov with Internet Mail Service (5.5.2650.10) id ; Fri, 27 Aug 1999 10:18:59 -0400 Message-ID: <29057D45C11BD211B68600805FEAA1EE04A31EBD@nihexchange3.nih.gov> From: "Januszewski, Joseph (CIT)" To: "'Joseph.VLcek@Compaq.com'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: AN interesting article. Date: Fri, 27 Aug 1999 10:18:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I also found it ironic that on page 3 of the PlanetIT article is a Related Link called "Stupid Networking"... "a leading journalist on advanced-IP issues", indeed! _________________________________________________________________ U.S. Department of Health and Human Services National Institutes of Health Joseph J. Januszewski, III, EiT Computer Specialist, Certified Network Analyst Center for Information Technology Bethesda, Maryland SMTP: jjanusze@exchange.nih.gov Voice: (301) 435-5518 _________________________________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 07:42:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA28070 for ipng-dist; Fri, 27 Aug 1999 07:37:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28063 for ; Fri, 27 Aug 1999 07:35:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA01592 for ; Fri, 27 Aug 1999 07:35:31 -0700 (PDT) Received: from deadprotocol.org (liahona.lightrealm.com [209.95.111.218]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11711 for ; Fri, 27 Aug 1999 08:35:29 -0600 (MDT) Received: from deadprotocol.org (dialupJ144.omah.uswest.net [216.161.76.144]) by deadprotocol.org (8.8.7/8.8.5) with ESMTP id HAA15199 for ; Fri, 27 Aug 1999 07:34:38 -0700 (PDT) Message-ID: <37C6A131.C7C8D390@deadprotocol.org> Date: Fri, 27 Aug 1999 09:31:13 -0500 From: Greg X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199908270033.RAA00699@feller.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Indeed, I cannot see how one with such shortsightedness could become an authority in the matter. Lucky Idiot comes to mind... Clearly journalistic standards are not what they once were as it seems the media just can't resist giving idiots a podium to scream from. That's my two cents on Mr. Richard Adhikari. As far as planet IT... > > > > the author's bio line > > > > Richard Adhikari is a leading journalist on advanced-IP issues for several > > major publications, including The Wall Street Journal, and is a regular > > contributor to Planet IT. > > > > does not speak well for the wsj > > > > It is rather pitiful to see that becoming a "leading journalist" these > days requires neither mastery of the English language nor fundamental > understanding of the subject matter. A truly amazing combination of ham- > handed writing and ignorance. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 08:43:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA28166 for ipng-dist; Fri, 27 Aug 1999 08:40:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28159 for ; Fri, 27 Aug 1999 08:40:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA09197 for ; Fri, 27 Aug 1999 08:39:55 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12183 for ; Fri, 27 Aug 1999 08:39:55 -0700 (PDT) Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-blue.research.att.com (Postfix) with ESMTP id B2FC84CE26; Fri, 27 Aug 1999 11:39:54 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id LAA12784; Fri, 27 Aug 1999 11:39:51 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id BFACB41F16; Fri, 27 Aug 1999 11:39:51 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id ACA53400B4; Fri, 27 Aug 1999 11:39:46 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Scott Bradner Cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Aug 1999 11:39:46 -0400 Message-Id: <19990827153951.BFACB41F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199908270013.UAA06251@newdev.harvard.edu>, Scott Bradner writes: > > the author's bio line > > Richard Adhikari is a leading journalist on advanced-IP issues for several > major publications, including The Wall Street Journal, and is a regular > contributor to Planet IT. > > does not speak well for the wsj Or perhaps for Mr. Adhikari -- the online WSJ search function turns up no IP-related articles by him since at least 1990. (As a control, I fed the names of other WSJ reporters into the same search page -- those attempts resulted in many hits.) I also ran the same search on all major U.S. newspapers and business publications -- still no hits. But I did find some hits in Computerworld, Information Week, and the like. It's possible that the WSJ has picked up some stories he wrote for other publications; other control searches did not turn up authors of, for example, AP wire stories that the Journal carried. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 08:44:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA28175 for ipng-dist; Fri, 27 Aug 1999 08:43:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28168 for ; Fri, 27 Aug 1999 08:43:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA27908 for ; Fri, 27 Aug 1999 08:43:01 -0700 (PDT) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13475 for ; Fri, 27 Aug 1999 08:43:00 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id LAA08128; Fri, 27 Aug 1999 11:42:58 -0400 (EDT) Date: Fri, 27 Aug 1999 11:42:58 -0400 (EDT) From: Scott Bradner Message-Id: <199908271542.LAA08128@newdev.harvard.edu> To: smb@research.att.com Subject: Re: AN interesting article. FYI... contd Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk research is good - I did a search and came up with the same but that was after I sent the note Scott ------- From smb@research.att.com Fri Aug 27 11:40:07 1999 From: "Steven M. Bellovin" To: Scott Bradner Cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd Date: Fri, 27 Aug 1999 11:39:46 -0400 Sender: smb@research.att.com In message <199908270013.UAA06251@newdev.harvard.edu>, Scott Bradner writes: > > the author's bio line > > Richard Adhikari is a leading journalist on advanced-IP issues for several > major publications, including The Wall Street Journal, and is a regular > contributor to Planet IT. > > does not speak well for the wsj Or perhaps for Mr. Adhikari -- the online WSJ search function turns up no IP-related articles by him since at least 1990. (As a control, I fed the names of other WSJ reporters into the same search page -- those attempts resulted in many hits.) I also ran the same search on all major U.S. newspapers and business publications -- still no hits. But I did find some hits in Computerworld, Information Week, and the like. It's possible that the WSJ has picked up some stories he wrote for other publications; other control searches did not turn up authors of, for example, AP wire stories that the Journal carried. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 09:08:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA28258 for ipng-dist; Fri, 27 Aug 1999 09:05:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28251 for ; Fri, 27 Aug 1999 09:05:20 -0700 (PDT) From: akephart@austin.ibm.com Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02294 for ; Fri, 27 Aug 1999 09:05:19 -0700 (PDT) Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21415 for ; Fri, 27 Aug 1999 10:05:18 -0600 (MDT) Received: from netmail2.austin.ibm.com (netmail2.austin.ibm.com [9.53.250.97]) by ausmail.austin.ibm.com (8.9.1/8.8.5) with ESMTP id LAA110552 for ; Fri, 27 Aug 1999 11:06:20 -0500 Received: from aguila.austin.ibm.com (aguila.austin.ibm.com [9.53.150.192]) by netmail2.austin.ibm.com (8.8.5/8.8.5) with ESMTP id LAA55616; Fri, 27 Aug 1999 11:05:17 -0500 Received: (from akephart@localhost) by aguila.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id LAA32984; Fri, 27 Aug 1999 11:05:16 -0500 Message-Id: <199908271605.LAA32984@aguila.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Dave Marquardt cc: ipng@sunroof.eng.sun.com Reply-To: akephart@austin.ibm.com Subject: Re: AN interesting article. FYI... contd In-reply-to: (Your message of 27 Aug 99 09:02:58 -0500.) Date: Fri, 27 Aug 1999 11:05:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Marquardt writes: > Tim Hartrick writes: > > > the author's bio line > > > > > > Richard Adhikari is a leading journalist on advanced-IP issues for several > > > major publications, including The Wall Street Journal, and is a regular > > > contributor to Planet IT. > > > > > > does not speak well for the wsj > > > > > > > It is rather pitiful to see that becoming a "leading journalist" these > > days requires neither mastery of the English language nor fundamental > > understanding of the subject matter. A truly amazing combination of ham- > > handed writing and ignorance. > > Well, it was an opinion piece, but one ought to back up one's opinion > with facts. > > -Dave Well-informed or not (apparently not in this case), it is articles like this that help in shaping consumer desire or apprehension for new products and technologies. The article may not be useful for technical implementation information (or accurate facts of any sort), but it does tell us a lot about what some common opposition to IPv6 will use as arguments. As such, we should be aware of these arguments, and make sure we can get out the right message. We can dismiss it out of hand, or we can use it to help shape our own advocacy efforts... Imagine that some CIO has read this article and then asks you, "So, why should I buy into this whole IPv6 thing? What about these infrasctructure costs? What about the compatibility issues?" How would you respond (other than just pointing out that the author hadn't a clue)? -andrew -- +---------------------------------------------------------------------------+ | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +---------------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 09:39:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA28317 for ipng-dist; Fri, 27 Aug 1999 09:35:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28310 for ; Fri, 27 Aug 1999 09:35:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA18722 for ; Fri, 27 Aug 1999 09:35:02 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07608 for ; Fri, 27 Aug 1999 09:35:02 -0700 (PDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id LAA02759; Fri, 27 Aug 1999 11:34:04 -0500 (CDT) Received: from dal-tx47-58.ix.netcom.com(198.211.44.250) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma002624; Fri Aug 27 11:33:32 1999 Message-ID: <37C64EB5.29773769@ix.netcom.com> Date: Fri, 27 Aug 1999 09:39:20 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Scott Bradner CC: smb@research.att.com, ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd - Off topic References: <199908271542.LAA08128@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott and all, Let me ask you all something. Why the keen interest in debunking this article and it's author? Sure, he didn't use proper terminology, but other than that I found him to be fairly accurate... Scott Bradner wrote: > research is good - I did a search and came up with the same but that was > after I sent the note > > Scott > > ------- > > >From smb@research.att.com Fri Aug 27 11:40:07 1999 > From: "Steven M. Bellovin" > To: Scott Bradner > Cc: ipng@sunroof.eng.sun.com > Subject: Re: AN interesting article. FYI... contd > Date: Fri, 27 Aug 1999 11:39:46 -0400 > Sender: smb@research.att.com > > In message <199908270013.UAA06251@newdev.harvard.edu>, Scott Bradner writes: > > > > the author's bio line > > > > Richard Adhikari is a leading journalist on advanced-IP issues for several > > major publications, including The Wall Street Journal, and is a regular > > contributor to Planet IT. > > > > does not speak well for the wsj > > Or perhaps for Mr. Adhikari -- the online WSJ search function turns up no > IP-related articles by him since at least 1990. (As a control, I fed the > names of other WSJ reporters into the same search page -- those attempts > resulted in many hits.) I also ran the same search on all major U.S. > newspapers and business publications -- still no hits. But I did find some > hits in Computerworld, Information Week, and the like. It's possible that > the WSJ has picked up some stories he wrote for other publications; other > control searches did not turn up authors of, for example, AP wire stories > that the Journal carried. > > --Steve Bellovin > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 09:46:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA28351 for ipng-dist; Fri, 27 Aug 1999 09:44:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28344 for ; Fri, 27 Aug 1999 09:44:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA10213 for ; Fri, 27 Aug 1999 09:44:14 -0700 (PDT) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11752 for ; Fri, 27 Aug 1999 09:44:12 -0700 (PDT) Received: from gateway (loshin.ne.mediaone.net [24.128.200.158]) by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id MAA25698 for ; Fri, 27 Aug 1999 12:44:00 -0400 (EDT) Message-Id: <4.1.19990827122039.00b988e0@pop.ne.mediaone.net> X-Sender: rapo@mail130.pair.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 27 Aug 1999 12:43:44 -0400 To: ipng@sunroof.eng.sun.com From: Pete Loshin Subject: Re: AN interesting article. FYI... contd In-Reply-To: <199908271605.LAA32984@aguila.austin.ibm.com> References: <(Your message of 27 Aug 99 09:02:58 -0500.) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:05 AM 8/27/99 -0500, akephart@austin.ibm.com wrote: >...The article may not >be useful for technical implementation information (or accurate facts >of any sort), but it does tell us a lot about what some common >opposition to IPv6 will use as arguments. As such, we should be >aware of these arguments, and make sure we can get out the right message. >We can dismiss it out of hand, or we can use it to help shape our own >advocacy efforts... So, IPv6 is a gratuitous upgrade, a plot on the part of competing vendors, colluding with each other to scam customers? If that kind of argument held water with executives, do you think Microsoft would be on its way to becoming a trillion-dollar company? (Before you flame me, Microsoft is certainly not the only offender with what some people might consider to be gratuitous upgrades, just the most successful.) How many new versions of Ethernet have we seen since IPv4 was rolled out? I'd say that upgrading the link layer is far more intrusive than upgrading the network layer, yet it's been done. > Imagine that some CIO has read this article and then asks you, >"So, why should I buy into this whole IPv6 thing? What about these >infrasctructure costs? What about the compatibility issues?" How would you >respond (other than just pointing out that the author hadn't a clue)? I'd give the CIO a copy of my book, _IPv6 Clearly Explained_ (Morgan Kaufmann, 1999). Then, I'd start throwing buzzwords around, like "competitive advantage" and "value proposition" while I explain IPv6's technical merits and the kinds of things you can do with that you just can't do with IPv4. BTW, re: CMP (now part of Miller Freeman), the article about deploying IPv6 that so many of the participants of this list helped me write this spring for Data Communications (which will publish its last hard copy edition on October 21) has not yet been published--and might not make it into print, though I'm told it is supposed to make it into the last issue. -pl -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 10:19:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA28447 for ipng-dist; Fri, 27 Aug 1999 10:14:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28439 for ; Fri, 27 Aug 1999 10:14:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA17848 for ; Fri, 27 Aug 1999 10:14:04 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA23787 for ; Fri, 27 Aug 1999 11:14:03 -0600 (MDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Fri Aug 27 13:12:40 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.17.249.223]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA08055; Fri, 27 Aug 1999 13:12:37 -0400 (EDT) Message-ID: <37C6C6ED.A12AAE36@dnrc.bell-labs.com> Date: Fri, 27 Aug 1999 13:12:13 -0400 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd - Off topic References: <199908271542.LAA08128@newdev.harvard.edu> <37C64EB5.29773769@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams wrote: > > Scott and all, > > Let me ask you all something. Why the keen interest in debunking > this article and it's author? Sure, he didn't use proper terminology, > but other than that I found him to be fairly accurate... Improper terminology? Misleading falsehoods. Falsehoods tend to be offensive when used to buttress an attack. They waste time and money when the purveyor of said falsehoods has reached your decision makers, and you need to back track and reconstruct the truth. Sufficient? gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 10:45:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA28575 for ipng-dist; Fri, 27 Aug 1999 10:39:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28568 for ; Fri, 27 Aug 1999 10:39:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA28008 for ; Fri, 27 Aug 1999 10:39:11 -0700 (PDT) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03227 for ; Fri, 27 Aug 1999 11:34:56 -0600 (MDT) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id MAA12325; Fri, 27 Aug 1999 12:34:30 -0500 (CDT) Received: from dal-tx50-53.ix.netcom.com(198.211.45.245) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma012294; Fri Aug 27 12:34:25 1999 Message-ID: <37C65CFB.A7E3BADB@ix.netcom.com> Date: Fri, 27 Aug 1999 10:40:13 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Grenville Armitage CC: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd - Off topic References: <199908271542.LAA08128@newdev.harvard.edu> <37C64EB5.29773769@ix.netcom.com> <37C6C6ED.A12AAE36@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenville and all, Why do *I* need to backtrack? I did not write the article. I only posted it for informational purposes... Why the hostility? And respectfully, I disagree with you regarding the article is a basic falsehood. Grenville Armitage wrote: > Jeff Williams wrote: > > > > Scott and all, > > > > Let me ask you all something. Why the keen interest in debunking > > this article and it's author? Sure, he didn't use proper terminology, > > but other than that I found him to be fairly accurate... > > Improper terminology? Misleading falsehoods. > > Falsehoods tend to be offensive when used to buttress an attack. > They waste time and money when the purveyor of said falsehoods has > reached your decision makers, and you need to back track and reconstruct > the truth. > > Sufficient? > > gja Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 10:51:55 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA28607 for ipng-dist; Fri, 27 Aug 1999 10:48:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28598 for ; Fri, 27 Aug 1999 10:48:13 -0700 (PDT) From: ford.re.1@pg.com Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA26328 for ; Fri, 27 Aug 1999 10:48:12 -0700 (PDT) Received: from bbhm.na.pg.com (bbhm.na.pg.com [192.44.184.159]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11711 for ; Fri, 27 Aug 1999 10:48:11 -0700 (PDT) X-ExtMailInfo: ford.re.1@notes.bdc-notes031.na.pg.com bhh5.na.pg.com [192.44.184.129] Received: from bhh5.na.pg.com (root@bhh5.na.pg.com [192.44.184.129]) by bbhm.na.pg.com (8.8.8/8.8.8) with ESMTP id NAA11584 for ; Fri, 27 Aug 1999 13:43:49 -0400 (EDT) Received: from bdc-notes041.na.pg.com (bdc-notes041.na.pg.com [155.125.116.41]) by bhh5.na.pg.com (8.8.8/8.8.8) with SMTP id NAA25759 for ; Fri, 27 Aug 1999 13:47:32 -0400 (EDT) Received: by bdc-notes041.na.pg.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 852567DA.005C4746 ; Fri, 27 Aug 1999 12:47:55 -0400 X-Lotus-FromDomain: PGI To: pete@loshin.com cc: ipng@sunroof.eng.sun.com Message-ID: <852567DA.005C4366.00@bdc-notes041.na.pg.com> Date: Fri, 27 Aug 1999 13:47:40 -0400 Subject: Re: AN interesting article. FYI... contd Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I read the article in question. It was very light on facts (I don't know what IPv6 and domain name shortages have in common), but some of the implementation points are real. I am the fellow who will be going to my CIO to ask for money to implement IPv6 one day. And to be very honest, it will be a hard sell. We will need to replace/upgrade almost all of our equipment (mainframe datacenters, 10's of 1,000's of pc's, hundreds of routers, thousands of eithernet switches, I don't know how many Novell, NT and Unix servers). Everything has addresses buried in them (I know, we should not do that but we have a lot of people in IT, so it happens and I cannot assume). We have custom code we wrote and custom code vendors have written for us, some of whom are no longer in business (again, not right but it's life). We will have to throw-out applications as part of this. I think that the job will take 5-10 years to complete, with the help of 100's of people around the world. We are talking a huge investment. To be honest, right now the only justification for this is to stay current and maybe someone will come along and implement something based on it that we need. We have enough addresses for our internal needs. I know, that sounds like the "I won't go to IP because Decnet is good enough" 1988 arguement, but we went to IP because it gave us the ability to connect everything to everything, which is exteremely powerful. I need that kind of argement to propose this size of upgrade. Gartner and Forrester's are recommending that their clients re-evaluate IPv6 in 2003, and I tend to agree with them. It's just not a hot topic on anyones plate at the moment. I'm not going to hand a line to my CIO, I have to feel it is of value to recommend it. Show me the killer app, or the fact that the public internet is going IPv6 big time, or that bluetooth is coming fast with IPv6. I am very encouraged to see future IO talking about IPv6, that may be what brings it into the glass house if it becomes the predominate standard. I applaud the work that the IETF and ngtrans group are doing to ease transition from IPv4 to IPv6. Roy Ford From: Pete Loshin on 08/27/99 12:43 PM To: ipng@sunroof.eng.sun.com cc: (bcc: Roy Ford-RE-1/PGI) Subject: Re: AN interesting article. FYI... contd At 11:05 AM 8/27/99 -0500, akephart@austin.ibm.com wrote: >...The article may not >be useful for technical implementation information (or accurate facts >of any sort), but it does tell us a lot about what some common >opposition to IPv6 will use as arguments. As such, we should be >aware of these arguments, and make sure we can get out the right message. >We can dismiss it out of hand, or we can use it to help shape our own >advocacy efforts... So, IPv6 is a gratuitous upgrade, a plot on the part of competing vendors, colluding with each other to scam customers? If that kind of argument held water with executives, do you think Microsoft would be on its way to becoming a trillion-dollar company? (Before you flame me, Microsoft is certainly not the only offender with what some people might consider to be gratuitous upgrades, just the most successful.) How many new versions of Ethernet have we seen since IPv4 was rolled out? I'd say that upgrading the link layer is far more intrusive than upgrading the network layer, yet it's been done. > Imagine that some CIO has read this article and then asks you, >"So, why should I buy into this whole IPv6 thing? What about these >infrasctructure costs? What about the compatibility issues?" How would you >respond (other than just pointing out that the author hadn't a clue)? I'd give the CIO a copy of my book, _IPv6 Clearly Explained_ (Morgan Kaufmann, 1999). Then, I'd start throwing buzzwords around, like "competitive advantage" and "value proposition" while I explain IPv6's technical merits and the kinds of things you can do with that you just can't do with IPv4. BTW, re: CMP (now part of Miller Freeman), the article about deploying IPv6 that so many of the participants of this list helped me write this spring for Data Communications (which will publish its last hard copy edition on October 21) has not yet been published--and might not make it into print, though I'm told it is supposed to make it into the last issue. -pl -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 10:56:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA28622 for ipng-dist; Fri, 27 Aug 1999 10:51:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28615 for ; Fri, 27 Aug 1999 10:51:09 -0700 (PDT) From: akephart@austin.ibm.com Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA27072 for ; Fri, 27 Aug 1999 10:51:00 -0700 (PDT) Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10640 for ; Fri, 27 Aug 1999 11:51:00 -0600 (MDT) Received: from netmail2.austin.ibm.com (netmail2.austin.ibm.com [9.53.250.97]) by ausmail.austin.ibm.com (8.9.1/8.8.5) with ESMTP id MAA09646 for ; Fri, 27 Aug 1999 12:52:01 -0500 Received: from aguila.austin.ibm.com (aguila.austin.ibm.com [9.53.150.192]) by netmail2.austin.ibm.com (8.8.5/8.8.5) with ESMTP id MAA26598; Fri, 27 Aug 1999 12:50:58 -0500 Received: (from akephart@localhost) by aguila.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) id MAA27076; Fri, 27 Aug 1999 12:50:58 -0500 Message-Id: <199908271750.MAA27076@aguila.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Pete Loshin cc: ipng@sunroof.eng.sun.com Reply-To: akephart@austin.ibm.com Subject: Re: AN interesting article. FYI... contd In-reply-to: (Your message of Fri, 27 Aug 99 12:43:44 -0400.)<4.1.19990827122039.00b988e0@pop.ne.mediaone.net> Date: Fri, 27 Aug 1999 12:50:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pete Loshin writes: > At 11:05 AM 8/27/99 -0500, akephart@austin.ibm.com wrote: > > >...The article may not > >be useful for technical implementation information (or accurate facts > >of any sort), but it does tell us a lot about what some common > >opposition to IPv6 will use as arguments. As such, we should be > >aware of these arguments, and make sure we can get out the right message. > >We can dismiss it out of hand, or we can use it to help shape our own > >advocacy efforts... > > So, IPv6 is a gratuitous upgrade, a plot on the part of competing vendors, > colluding with each other to scam customers? No, but that's what the article implies, and -- unless he knows better -- the reader will understand to be the case... > > If that kind of argument held water with executives, do you think Microsoft > would be on its way to becoming a trillion-dollar company? (Before you > flame me, Microsoft is certainly not the only offender with what some > people might consider to be gratuitous upgrades, just the most successful.) A perfect example, since they encounter (deservedly or not, depending on your perspective) this kind of "gratuitous upgrade" attack regularly. They consistently win because they are very good at redirecting the discussion away from what it costs, and focus it on what is gained (or perceived to be gained). They learn what the opposing arguments are (valid or not) and then directly combat them or direct attention away from them. It isn't because the execs aren't swayed by these kinds of bogus arguments, but because they (Microsoft) know how to fight them. > > How many new versions of Ethernet have we seen since IPv4 was rolled out? > I'd say that upgrading the link layer is far more intrusive than upgrading > the network layer, yet it's been done. > > > Imagine that some CIO has read this article and then asks you, > >"So, why should I buy into this whole IPv6 thing? What about these > >infrasctructure costs? What about the compatibility issues?" How would you > >respond (other than just pointing out that the author hadn't a clue)? > > I'd give the CIO a copy of my book, _IPv6 Clearly Explained_ (Morgan > Kaufmann, 1999). Then, I'd start throwing buzzwords around, like > "competitive advantage" and "value proposition" while I explain IPv6's > technical merits and the kinds of things you can do with that you just > can't do with IPv4. An excellent response, and exactly the kind of thing I was trying to elicit. If that CIO is swayed by buzzwords, we should respond with buzzwords. If that CIO is swayed by technical merits, we should respond with technical merits. We have more than enough of each to go around, and both are useful in the appropriate situations. > > BTW, re: CMP (now part of Miller Freeman), the article about deploying IPv6 > that so many of the participants of this list helped me write this spring > for Data Communications (which will publish its last hard copy edition on > October 21) has not yet been published--and might not make it into print, > though I'm told it is supposed to make it into the last issue. I do hope it makes it...I'll look forward to reading it. Positive press is crucial to general acceptance. > > -pl -andrew -- +---------------------------------------------------------------------------+ | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +---------------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 11:17:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA28706 for ipng-dist; Fri, 27 Aug 1999 11:09:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28699 for ; Fri, 27 Aug 1999 11:09:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA13132 for ; Fri, 27 Aug 1999 11:09:43 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19325 for ; Fri, 27 Aug 1999 12:09:42 -0600 (MDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 27 Aug 1999 11:09:25 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A56902919F40@SIT.platinum.corp.microsoft.com> From: "Mike Zintel (Exchange)" To: "'akephart@austin.ibm.com'" , Pete Loshin Cc: ipng@sunroof.eng.sun.com Subject: RE: AN interesting article. FYI... contd Date: Fri, 27 Aug 1999 11:09:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's helpful to contrast an ideal IPv6 world with today's world of DHCP'd, IPCP'd, NAT'd, tunneled and proxied TCP/IP. Part of the problem selling IPv6 is the success of the address shortage work-arounds. Call attention to the usability and administration costs of these solutions. One serious problem still largely unsolved in today's world is the absence of a unique identifier that can be used initiate a connection from the core network to a (PPP or DHCP) transiently connected end node. This is part is a result of PPP/DHCP enabled address pooling. Mike. -----Original Message----- From: akephart@austin.ibm.com [mailto:akephart@austin.ibm.com] Sent: Friday, August 27, 1999 10:51 AM To: Pete Loshin Cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd Pete Loshin writes: > At 11:05 AM 8/27/99 -0500, akephart@austin.ibm.com wrote: > > >...The article may not > >be useful for technical implementation information (or accurate facts > >of any sort), but it does tell us a lot about what some common > >opposition to IPv6 will use as arguments. As such, we should be > >aware of these arguments, and make sure we can get out the right message. > >We can dismiss it out of hand, or we can use it to help shape our own > >advocacy efforts... > > So, IPv6 is a gratuitous upgrade, a plot on the part of competing vendors, > colluding with each other to scam customers? No, but that's what the article implies, and -- unless he knows better -- the reader will understand to be the case... > > If that kind of argument held water with executives, do you think Microsoft > would be on its way to becoming a trillion-dollar company? (Before you > flame me, Microsoft is certainly not the only offender with what some > people might consider to be gratuitous upgrades, just the most successful.) A perfect example, since they encounter (deservedly or not, depending on your perspective) this kind of "gratuitous upgrade" attack regularly. They consistently win because they are very good at redirecting the discussion away from what it costs, and focus it on what is gained (or perceived to be gained). They learn what the opposing arguments are (valid or not) and then directly combat them or direct attention away from them. It isn't because the execs aren't swayed by these kinds of bogus arguments, but because they (Microsoft) know how to fight them. > > How many new versions of Ethernet have we seen since IPv4 was rolled out? > I'd say that upgrading the link layer is far more intrusive than upgrading > the network layer, yet it's been done. > > > Imagine that some CIO has read this article and then asks you, > >"So, why should I buy into this whole IPv6 thing? What about these > >infrasctructure costs? What about the compatibility issues?" How would you > >respond (other than just pointing out that the author hadn't a clue)? > > I'd give the CIO a copy of my book, _IPv6 Clearly Explained_ (Morgan > Kaufmann, 1999). Then, I'd start throwing buzzwords around, like > "competitive advantage" and "value proposition" while I explain IPv6's > technical merits and the kinds of things you can do with that you just > can't do with IPv4. An excellent response, and exactly the kind of thing I was trying to elicit. If that CIO is swayed by buzzwords, we should respond with buzzwords. If that CIO is swayed by technical merits, we should respond with technical merits. We have more than enough of each to go around, and both are useful in the appropriate situations. > > BTW, re: CMP (now part of Miller Freeman), the article about deploying IPv6 > that so many of the participants of this list helped me write this spring > for Data Communications (which will publish its last hard copy edition on > October 21) has not yet been published--and might not make it into print, > though I'm told it is supposed to make it into the last issue. I do hope it makes it...I'll look forward to reading it. Positive press is crucial to general acceptance. > > -pl -andrew -- +--------------------------------------------------------------------------- + | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +--------------------------------------------------------------------------- + -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 11:17:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA28715 for ipng-dist; Fri, 27 Aug 1999 11:10:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28708 for ; Fri, 27 Aug 1999 11:10:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA02070 for ; Fri, 27 Aug 1999 11:10:21 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22205 for ; Fri, 27 Aug 1999 11:10:21 -0700 (PDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id NAA20384; Fri, 27 Aug 1999 13:09:42 -0500 (CDT) Received: from dal-tx50-53.ix.netcom.com(198.211.45.245) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma020138; Fri Aug 27 13:08:26 1999 Message-ID: <37C664EF.C76E4353@ix.netcom.com> Date: Fri, 27 Aug 1999 11:14:10 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: akephart@austin.ibm.com CC: Dave Marquardt , ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199908271605.LAA32984@aguila.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew and all, Thank you andrew for clarifying this. It is part of the reason I posted the article to begin with. Sheeeesh, some folks are touchy! akephart@austin.ibm.com wrote: > Dave Marquardt writes: > > Tim Hartrick writes: > > > > the author's bio line > > > > > > > > Richard Adhikari is a leading journalist on advanced-IP issues for several > > > > major publications, including The Wall Street Journal, and is a regular > > > > contributor to Planet IT. > > > > > > > > does not speak well for the wsj > > > > > > > > > > It is rather pitiful to see that becoming a "leading journalist" these > > > days requires neither mastery of the English language nor fundamental > > > understanding of the subject matter. A truly amazing combination of ham- > > > handed writing and ignorance. > > > > Well, it was an opinion piece, but one ought to back up one's opinion > > with facts. > > > > -Dave > > Well-informed or not (apparently not in this case), it is > articles like this that help in shaping consumer desire or > apprehension for new products and technologies. The article may not > be useful for technical implementation information (or accurate facts > of any sort), but it does tell us a lot about what some common > opposition to IPv6 will use as arguments. As such, we should be > aware of these arguments, and make sure we can get out the right message. > We can dismiss it out of hand, or we can use it to help shape our own > advocacy efforts... > > Imagine that some CIO has read this article and then asks you, > "So, why should I buy into this whole IPv6 thing? What about these > infrasctructure costs? What about the compatibility issues?" How would you > respond (other than just pointing out that the author hadn't a clue)? > > -andrew > > -- > +---------------------------------------------------------------------------+ > | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | > | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | > +---------------------------------------------------------------------------+ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 11:21:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA28777 for ipng-dist; Fri, 27 Aug 1999 11:18:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28756 for ; Fri, 27 Aug 1999 11:18:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA14975 for ; Fri, 27 Aug 1999 11:18:02 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA22989 for ; Fri, 27 Aug 1999 12:18:01 -0600 (MDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Aug 27 14:16:58 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.17.250.148]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA11153; Fri, 27 Aug 1999 14:16:55 -0400 (EDT) Message-ID: <37C6D5FE.ADCD2157@dnrc.bell-labs.com> Date: Fri, 27 Aug 1999 14:16:30 -0400 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd - Off topic References: <199908271542.LAA08128@newdev.harvard.edu> <37C64EB5.29773769@ix.netcom.com> <37C6C6ED.A12AAE36@dnrc.bell-labs.com> <37C65CFB.A7E3BADB@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk no need to be defensive, the word "you" in my email doesn't refer to _you_ specifically. gja Jeff Williams wrote: > > Grenville and all, > > Why do *I* need to backtrack? I did not write the article. I only > posted it for informational purposes... Why the hostility? And > respectfully, I disagree with you regarding the article is a basic > falsehood. > > Grenville Armitage wrote: > > > Jeff Williams wrote: > > > > > > Scott and all, > > > > > > Let me ask you all something. Why the keen interest in debunking > > > this article and it's author? Sure, he didn't use proper terminology, > > > but other than that I found him to be fairly accurate... > > > > Improper terminology? Misleading falsehoods. > > > > Falsehoods tend to be offensive when used to buttress an attack. > > They waste time and money when the purveyor of said falsehoods has > > reached your decision makers, and you need to back track and reconstruct > > the truth. > > > > Sufficient? > > > > gja > > Regards, > > -- > Jeffrey A. Williams > Spokesman INEGroup (Over 95k members strong!) > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 972-447-1894 > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -- ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 11:28:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA28844 for ipng-dist; Fri, 27 Aug 1999 11:24:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28837 for ; Fri, 27 Aug 1999 11:24:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08670 for ; Fri, 27 Aug 1999 11:24:02 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA25492 for ; Fri, 27 Aug 1999 12:24:01 -0600 (MDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Aug 27 14:22:59 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.17.250.148]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA11424; Fri, 27 Aug 1999 14:22:56 -0400 (EDT) Message-ID: <37C6D765.559EFF43@dnrc.bell-labs.com> Date: Fri, 27 Aug 1999 14:22:29 -0400 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Williams CC: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd - Off topic References: <199908271542.LAA08128@newdev.harvard.edu> <37C64EB5.29773769@ix.netcom.com> <37C6C6ED.A12AAE36@dnrc.bell-labs.com> <37C65CFB.A7E3BADB@ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff Williams wrote: [..] > And > respectfully, I disagree with you regarding the article is a basic > falsehood. While we're discussing accuracy, you can disagree with that straw man if you like, but dont attribute it to me. I note that there's often little difference between misusing terminology and creating misleading falsehoods. You admit the author didn't use proper terminology. Clearly I shouldn't have used such shorthanded notion in my initial reply to you. gja > > Grenville Armitage wrote: > > > Jeff Williams wrote: > > > > > > Scott and all, > > > > > > Let me ask you all something. Why the keen interest in debunking > > > this article and it's author? Sure, he didn't use proper terminology, > > > but other than that I found him to be fairly accurate... > > > > Improper terminology? Misleading falsehoods. > > > > Falsehoods tend to be offensive when used to buttress an attack. > > They waste time and money when the purveyor of said falsehoods has > > reached your decision makers, and you need to back track and reconstruct > > the truth. > > > > Sufficient? > > > > gja > > Regards, > > -- > Jeffrey A. Williams > Spokesman INEGroup (Over 95k members strong!) > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > Information Network Eng. Group. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Contact Number: 972-447-1894 > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -- ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs Research, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 11:29:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA28835 for ipng-dist; Fri, 27 Aug 1999 11:23:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28828 for ; Fri, 27 Aug 1999 11:23:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA12969 for ; Fri, 27 Aug 1999 11:23:46 -0700 (PDT) Received: from majordomo2.umd.edu (majordomo2.umd.edu [128.8.10.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25346 for ; Fri, 27 Aug 1999 12:23:43 -0600 (MDT) Received: from rac6.wam.umd.edu (trini@rac6.wam.umd.edu [128.8.10.146]) by majordomo2.umd.edu (8.9.3/8.9.3) with ESMTP id OAA22453; Fri, 27 Aug 1999 14:23:39 -0400 (EDT) Date: Fri, 27 Aug 1999 14:23:39 -0400 (EDT) From: TriniInXisle To: ford.re.1@pg.com cc: pete@loshin.com, ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd In-Reply-To: <852567DA.005C4366.00@bdc-notes041.na.pg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How to i remove myself from this list. On Fri, 27 Aug 1999 ford.re.1@pg.com wrote: > I read the article in question. It was very light on facts (I don't know what > IPv6 and domain name shortages have in common), but some of the implementation > points are real. > > I am the fellow who will be going to my CIO to ask for money to implement IPv6 > one day. And to be very honest, it will be a hard sell. > > We will need to replace/upgrade almost all of our equipment (mainframe > datacenters, 10's of 1,000's of pc's, hundreds of routers, thousands of > eithernet switches, I don't know how many Novell, NT and Unix servers). > Everything has addresses buried in them (I know, we should not do that but we > have a lot of people in IT, so it happens and I cannot assume). We have custom > code we wrote and custom code vendors have written for us, some of whom are no > longer in business (again, not right but it's life). We will have to throw-out > applications as part of this. I think that the job will take 5-10 years to > complete, with the help of 100's of people around the world. We are talking a > huge investment. > > To be honest, right now the only justification for this is to stay current and > maybe someone will come along and implement something based on it that we need. > We have enough addresses for our internal needs. I know, that sounds like the > "I won't go to IP because Decnet is good enough" 1988 arguement, but we went to > IP because it gave us the ability to connect everything to everything, which is > exteremely powerful. I need that kind of argement to propose this size of > upgrade. Gartner and Forrester's are recommending that their clients > re-evaluate IPv6 in 2003, and I tend to agree with them. It's just not a hot > topic on anyones plate at the moment. > > I'm not going to hand a line to my CIO, I have to feel it is of value to > recommend it. Show me the killer app, or the fact that the public internet is > going IPv6 big time, or that bluetooth is coming fast with IPv6. I am very > encouraged to see future IO talking about IPv6, that may be what brings it into > the glass house if it becomes the predominate standard. I applaud the work that > the IETF and ngtrans group are doing to ease transition from IPv4 to IPv6. > > Roy Ford > > > > From: Pete Loshin on 08/27/99 12:43 PM > > To: ipng@sunroof.eng.sun.com > cc: (bcc: Roy Ford-RE-1/PGI) > Subject: Re: AN interesting article. FYI... contd > > > > > At 11:05 AM 8/27/99 -0500, akephart@austin.ibm.com wrote: > > >...The article may not > >be useful for technical implementation information (or accurate facts > >of any sort), but it does tell us a lot about what some common > >opposition to IPv6 will use as arguments. As such, we should be > >aware of these arguments, and make sure we can get out the right message. > >We can dismiss it out of hand, or we can use it to help shape our own > >advocacy efforts... > > So, IPv6 is a gratuitous upgrade, a plot on the part of competing vendors, > colluding with each other to scam customers? > > If that kind of argument held water with executives, do you think Microsoft > would be on its way to becoming a trillion-dollar company? (Before you > flame me, Microsoft is certainly not the only offender with what some > people might consider to be gratuitous upgrades, just the most successful.) > > How many new versions of Ethernet have we seen since IPv4 was rolled out? > I'd say that upgrading the link layer is far more intrusive than upgrading > the network layer, yet it's been done. > > > Imagine that some CIO has read this article and then asks you, > >"So, why should I buy into this whole IPv6 thing? What about these > >infrasctructure costs? What about the compatibility issues?" How would you > >respond (other than just pointing out that the author hadn't a clue)? > > I'd give the CIO a copy of my book, _IPv6 Clearly Explained_ (Morgan > Kaufmann, 1999). Then, I'd start throwing buzzwords around, like > "competitive advantage" and "value proposition" while I explain IPv6's > technical merits and the kinds of things you can do with that you just > can't do with IPv4. > > BTW, re: CMP (now part of Miller Freeman), the article about deploying IPv6 > that so many of the participants of this list helped me write this spring > for Data Communications (which will publish its last hard copy edition on > October 21) has not yet been published--and might not make it into print, > though I'm told it is supposed to make it into the last issue. > > -pl > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-==-=-=-=-=-==-=-=-=-=-=-=-= Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list without my permission. Violation of my privacy with advertising or SPAM/SPOOFING will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. Thank You. WEB SITES CREATED by UNDERGRAD Inc. Trini Discussion WEBSITES...CHECK IT OUT!!! http://www.x-pointcgi.com/cgi-bin/users/8248/wwwboard/wwwboard.html http://TriniLyme.listbot.com/ International Education Services. http://www.educomlimited.com Other Sites of Notable Mention http://www.angelfire.com/tx2/nikkipikki/ http://www.cs.umd.edu/projects/maruti -=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-= -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 11:56:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA28889 for ipng-dist; Fri, 27 Aug 1999 11:32:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28882 for ; Fri, 27 Aug 1999 11:31:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA18440 for ; Fri, 27 Aug 1999 11:31:44 -0700 (PDT) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28773 for ; Fri, 27 Aug 1999 12:31:39 -0600 (MDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id NAA18536; Fri, 27 Aug 1999 13:29:46 -0500 (CDT) Received: from dal-tx50-53.ix.netcom.com(198.211.45.245) by dfw-ix5.ix.netcom.com via smap (V1.3) id rma018502; Fri Aug 27 13:29:29 1999 Message-ID: <37C669DD.27FA493B@ix.netcom.com> Date: Fri, 27 Aug 1999 11:35:13 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: akephart@austin.ibm.com CC: Pete Loshin , ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199908271750.MAA27076@aguila.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew and all, akephart@austin.ibm.com wrote: > Pete Loshin writes: > > > At 11:05 AM 8/27/99 -0500, akephart@austin.ibm.com wrote: > > > > >...The article may not > > >be useful for technical implementation information (or accurate facts > > >of any sort), but it does tell us a lot about what some common > > >opposition to IPv6 will use as arguments. As such, we should be > > >aware of these arguments, and make sure we can get out the right message. > > >We can dismiss it out of hand, or we can use it to help shape our own > > >advocacy efforts... > > > > So, IPv6 is a gratuitous upgrade, a plot on the part of competing vendors, > > colluding with each other to scam customers? > > No, but that's what the article implies, and -- unless he knows > better -- the reader will understand to be the case... I am not sure I completely agree. Yes it is true that the author is bias to a degree, I must admit. But to characterize other competing vendors as "Scam Artists" is over the top IMHO, and this sort of rhetoric should be discouraged... No offense to you Pete. >;) > > > > > > If that kind of argument held water with executives, do you think Microsoft > > would be on its way to becoming a trillion-dollar company? (Before you > > flame me, Microsoft is certainly not the only offender with what some > > people might consider to be gratuitous upgrades, just the most successful.) > > A perfect example, since they encounter (deservedly or not, > depending on your perspective) this kind of "gratuitous upgrade" > attack regularly. They consistently win because they are very good > at redirecting the discussion away from what it costs, and focus > it on what is gained (or perceived to be gained). They learn what the > opposing arguments are (valid or not) and then directly combat them > or direct attention away from them. It isn't because the execs aren't > swayed by these kinds of bogus arguments, but because they (Microsoft) > know how to fight them. Well I just don't trust MS that well. Too many bad experiences I suppose. And when it comes to networking and DNS, MS is a pee wee... > > > > > > How many new versions of Ethernet have we seen since IPv4 was rolled out? > > I'd say that upgrading the link layer is far more intrusive than upgrading > > the network layer, yet it's been done. > > > > > Imagine that some CIO has read this article and then asks you, > > >"So, why should I buy into this whole IPv6 thing? What about these > > >infrasctructure costs? What about the compatibility issues?" How would you > > >respond (other than just pointing out that the author hadn't a clue)? > > > > I'd give the CIO a copy of my book, _IPv6 Clearly Explained_ (Morgan > > Kaufmann, 1999). Then, I'd start throwing buzzwords around, like > > "competitive advantage" and "value proposition" while I explain IPv6's > > technical merits and the kinds of things you can do with that you just > > can't do with IPv4. > > An excellent response, and exactly the kind of thing I was > trying to elicit. If that CIO is swayed by buzzwords, we should respond > with buzzwords. If that CIO is swayed by technical merits, we > should respond with technical merits. We have more than enough of > each to go around, and both are useful in the appropriate situations. Good point, if you can indeed carry the day, so to speak. One must understand that IPv6 is not a panacea by any stretch of the imagination... > > > > > > BTW, re: CMP (now part of Miller Freeman), the article about deploying IPv6 > > that so many of the participants of this list helped me write this spring > > for Data Communications (which will publish its last hard copy edition on > > October 21) has not yet been published--and might not make it into print, > > though I'm told it is supposed to make it into the last issue. > > I do hope it makes it...I'll look forward to reading it. > Positive press is crucial to general acceptance. I do too! And Pete, if not let me know privately I may be able to help with several publishers... > > > > > > -pl > > -andrew > -- > +---------------------------------------------------------------------------+ > | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | > | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | > +---------------------------------------------------------------------------+ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 11:57:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA28907 for ipng-dist; Fri, 27 Aug 1999 11:34:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28900 for ; Fri, 27 Aug 1999 11:34:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA19228 for ; Fri, 27 Aug 1999 11:34:22 -0700 (PDT) Received: from dfw-ix5.ix.netcom.com (dfw-ix5.ix.netcom.com [206.214.98.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03032 for ; Fri, 27 Aug 1999 11:34:21 -0700 (PDT) Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id NAA19215; Fri, 27 Aug 1999 13:34:12 -0500 (CDT) Received: from dal-tx50-53.ix.netcom.com(198.211.45.245) by dfw-ix5.ix.netcom.com via smap (V1.3) id rma019181; Fri Aug 27 13:33:40 1999 Message-ID: <37C66ADC.A64169A2@ix.netcom.com> Date: Fri, 27 Aug 1999 11:39:27 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Grenville Armitage CC: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd - Off topic References: <199908271542.LAA08128@newdev.harvard.edu> <37C64EB5.29773769@ix.netcom.com> <37C6C6ED.A12AAE36@dnrc.bell-labs.com> <37C65CFB.A7E3BADB@ix.netcom.com> <37C6D5FE.ADCD2157@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Grenwille and all, Ok. Just seemed that way in you previous post is all... >;) As I am a fairly large stock holder in Lucent, I was beginning to wonder.... Grenville Armitage wrote: > no need to be defensive, the word "you" in my email doesn't > refer to _you_ specifically. > > gja > > Jeff Williams wrote: > > > > Grenville and all, > > > > Why do *I* need to backtrack? I did not write the article. I only > > posted it for informational purposes... Why the hostility? And > > respectfully, I disagree with you regarding the article is a basic > > falsehood. > > > > Grenville Armitage wrote: > > > > > Jeff Williams wrote: > > > > > > > > Scott and all, > > > > > > > > Let me ask you all something. Why the keen interest in debunking > > > > this article and it's author? Sure, he didn't use proper terminology, > > > > but other than that I found him to be fairly accurate... > > > > > > Improper terminology? Misleading falsehoods. > > > > > > Falsehoods tend to be offensive when used to buttress an attack. > > > They waste time and money when the purveyor of said falsehoods has > > > reached your decision makers, and you need to back track and reconstruct > > > the truth. > > > > > > Sufficient? > > > > > > gja > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman INEGroup (Over 95k members strong!) > > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. > > Information Network Eng. Group. INEG. INC. > > E-Mail jwkckid1@ix.netcom.com > > Contact Number: 972-447-1894 > > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 > > -- > ________________________________________________________________________ > Grenville Armitage http://mh005.infi.net/~gja > Bell Labs Research, Lucent Technologies Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 12:39:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA29008 for ipng-dist; Fri, 27 Aug 1999 12:28:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29001 for ; Fri, 27 Aug 1999 12:27:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA19241 for ; Fri, 27 Aug 1999 12:27:58 -0700 (PDT) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25580 for ; Fri, 27 Aug 1999 12:27:57 -0700 (PDT) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id OAA01360; Fri, 27 Aug 1999 14:27:03 -0500 (CDT) Received: from dal-tx50-53.ix.netcom.com(198.211.45.245) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma022408; Fri Aug 27 13:20:03 1999 Message-ID: <37C667AC.A2FC7FF8@ix.netcom.com> Date: Fri, 27 Aug 1999 11:25:51 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: ford.re.1@pg.com CC: pete@loshin.com, ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <852567DA.005C4366.00@bdc-notes041.na.pg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Roy and all, I have to agree with you here. Many are not going to do the upgrade when the can do most of what IPv6 provides on IPV4 networks now. The justification just isn't there form a $$ standpoint at the very least. But I also believe that they should also not look at it from that standpoint alone either. I would also say, that we are upgrading to IPv6 but also providing IPv8 capability as well, but it will be s slow transition over about two years. However for us, we will do our own tunneling for IPv4. I am not satisfied with the IETF's technique. I believe ours is superior. I also find the currently IPv6 does not work and play well with ATM, that is a big concern to us and many others I am sure. Hence we have, again we will be using the IPv4toIPv8 as IPv8 provides much better for ATM's, and IPv8 will still carry any IPv6 traffic with no major problems.. ford.re.1@pg.com wrote: > I read the article in question. It was very light on facts (I don't know what > IPv6 and domain name shortages have in common), but some of the implementation > points are real. > > I am the fellow who will be going to my CIO to ask for money to implement IPv6 > one day. And to be very honest, it will be a hard sell. > > We will need to replace/upgrade almost all of our equipment (mainframe > datacenters, 10's of 1,000's of pc's, hundreds of routers, thousands of > eithernet switches, I don't know how many Novell, NT and Unix servers). > Everything has addresses buried in them (I know, we should not do that but we > have a lot of people in IT, so it happens and I cannot assume). We have custom > code we wrote and custom code vendors have written for us, some of whom are no > longer in business (again, not right but it's life). We will have to throw-out > applications as part of this. I think that the job will take 5-10 years to > complete, with the help of 100's of people around the world. We are talking a > huge investment. > > To be honest, right now the only justification for this is to stay current and > maybe someone will come along and implement something based on it that we need. > We have enough addresses for our internal needs. I know, that sounds like the > "I won't go to IP because Decnet is good enough" 1988 arguement, but we went to > IP because it gave us the ability to connect everything to everything, which is > exteremely powerful. I need that kind of argement to propose this size of > upgrade. Gartner and Forrester's are recommending that their clients > re-evaluate IPv6 in 2003, and I tend to agree with them. It's just not a hot > topic on anyones plate at the moment. > > I'm not going to hand a line to my CIO, I have to feel it is of value to > recommend it. Show me the killer app, or the fact that the public internet is > going IPv6 big time, or that bluetooth is coming fast with IPv6. I am very > encouraged to see future IO talking about IPv6, that may be what brings it into > the glass house if it becomes the predominate standard. I applaud the work that > the IETF and ngtrans group are doing to ease transition from IPv4 to IPv6. > > Roy Ford > > From: Pete Loshin on 08/27/99 12:43 PM > > To: ipng@sunroof.eng.sun.com > cc: (bcc: Roy Ford-RE-1/PGI) > Subject: Re: AN interesting article. FYI... contd > > At 11:05 AM 8/27/99 -0500, akephart@austin.ibm.com wrote: > > >...The article may not > >be useful for technical implementation information (or accurate facts > >of any sort), but it does tell us a lot about what some common > >opposition to IPv6 will use as arguments. As such, we should be > >aware of these arguments, and make sure we can get out the right message. > >We can dismiss it out of hand, or we can use it to help shape our own > >advocacy efforts... > > So, IPv6 is a gratuitous upgrade, a plot on the part of competing vendors, > colluding with each other to scam customers? > > If that kind of argument held water with executives, do you think Microsoft > would be on its way to becoming a trillion-dollar company? (Before you > flame me, Microsoft is certainly not the only offender with what some > people might consider to be gratuitous upgrades, just the most successful.) > > How many new versions of Ethernet have we seen since IPv4 was rolled out? > I'd say that upgrading the link layer is far more intrusive than upgrading > the network layer, yet it's been done. > > > Imagine that some CIO has read this article and then asks you, > >"So, why should I buy into this whole IPv6 thing? What about these > >infrasctructure costs? What about the compatibility issues?" How would you > >respond (other than just pointing out that the author hadn't a clue)? > > I'd give the CIO a copy of my book, _IPv6 Clearly Explained_ (Morgan > Kaufmann, 1999). Then, I'd start throwing buzzwords around, like > "competitive advantage" and "value proposition" while I explain IPv6's > technical merits and the kinds of things you can do with that you just > can't do with IPv4. > > BTW, re: CMP (now part of Miller Freeman), the article about deploying IPv6 > that so many of the participants of this list helped me write this spring > for Data Communications (which will publish its last hard copy edition on > October 21) has not yet been published--and might not make it into print, > though I'm told it is supposed to make it into the last issue. > > -pl > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 13:21:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA29091 for ipng-dist; Fri, 27 Aug 1999 13:13:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29084 for ; Fri, 27 Aug 1999 13:13:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA03080 for ; Fri, 27 Aug 1999 13:13:41 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10612 for ; Fri, 27 Aug 1999 14:13:40 -0600 (MDT) Received: from endor.eas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id QAA15633; Fri, 27 Aug 1999 16:13:34 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.eas.harvard.edu (8.8.8/8.8.8) id QAA27379; Fri, 27 Aug 1999 16:13:34 -0400 (EDT) Date: Fri, 27 Aug 1999 16:13:34 -0400 (EDT) Message-Id: <199908272013.QAA27379@endor.eas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: RE: AN interesting article. FYI... contd Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I must play devil's advocate here. "Mike Zintel (Exchange)" wrote: |It's helpful to contrast an ideal IPv6 world with today's world of DHCP'd, |IPCP'd, NAT'd, tunneled and proxied TCP/IP. In today's world, at least some end users (i.e., those who got in before so many addresses became "reserved") have stable, portable IP address space. Under IPv6, no end user will have stable or portable IP address space. This may seem like a good equalizer to the have-nots, but it isn't a feature for the haves. In today's world, at least some end users can still take advantage of what was once seen as a very important characteristic of the tcp/ip protocol: as long as you control the end points, it can be made arbitrarily tenacious independent of the reliability of the intermediate routers (assuming you don't have a total, permanent failure of course). Under IPv6, any active tcp/ip connection is always at the mercy of renumbering. Saying that nobody expects tcp/ip connections to be reliable outside of the intranet (as I have seen expressed here from time to time) ignores all those users who expect just that. Assuming that the problem will be easily solved by adapting tcp/ip to survive renumbering is, I think, minimizing a very tricky technical task. (And of course, it does nothing for application-level address knowledge.) Any complete solution that renders tcp, udp, and everything above largely independent of short-term address persistence (perhaps by creating a new class of cookie that effectively becomes the "first-class citizen" of identify) will make IPv6 addresses very different animals from IPv4 addresses. It may even make IPv6 addresses (at least in the sense that they are administratively allocatable entities) superfluous. This last is actually technically interesting, but it would obviate the need for all the address allocation policy that we know and love, and things don't seem to be moving it that direction. And besides, there has to be some pseudo-stable address space if only to provide a measure for billing... In today's world, a NAT user has complete control of the stability of its internal addresses and can hide its internal structure more-or-less completely. Under IPv6, the stability of the internal addresses (which are then, granted, at least globally routable) is dependent on every provider above the user. Moreover, the internal structure is completely exposed. This is great for the ISP who wants to bill per-host, but of little benefit to the end user. Naturally, there will be IPv6 NAT boxes (in several translation flavors) and I'll bet they will be used in V6<->V6 mode just to get the structure-hiding and firewall features. But there's not much point comparing NAT to NAT in this context... |Part of the problem selling IPv6 is the success of the address shortage |work-arounds. We are observing evolution in action. Apply the pressure of an address shortage (even if artificial) and the market will adapt, but perhaps not in the way some would like. It would be neat if you could make addresses valuable (dollar-wise) and then create a lot of wealth by expanding the address space, but the market doesn't always work that way. :) |Call attention to the usability and administration costs of |these solutions. The problem here is at least three-fold. First, a lot of these work-arounds work very well and their administrative costs even over the life of a company may not approach the cost of switching to IPv6 (and IPv6 solutions are not without their--hard to characterize--administrative costs). Second, some of these work-arounds offer features above and beyond expanding apparent address-space. These features will still be required with a switch to IPv6 but all the code will be new and untested. More overhead tipping the balance away from IPv6. Finally, IPv6 simply does not offer anything resembling an expanded IPv4 address space. IPv6 addresses are qualitatively very different from IPv4 addresses. IPv6 addresses are closer to DHCP'd or even NAT'd addresses than they are to stable IPv4 addresses, and IPv6 features tend to be of more benefit to ISPs than to end users. Until all the collateral work has been done to make an IPv6 address a functional drop-in replacement for an IPv4 address in whatever applications are of interest to a particular organization, there may be little incentive for that organization to switch. Even when this is done, IPv6 will have to bring more than parity to the table. |One serious problem still largely unsolved in today's world is the absence |of a unique identifier that can be used initiate a connection from the core |network to a (PPP or DHCP) transiently connected end node. This is part is a |result of PPP/DHCP enabled address pooling. This problem is currently addressed with dynamic DNS. IPv6 will presumably rely on the same mechanisms, perhaps more so since IPv6 addresses are less stable... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 13:34:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA29147 for ipng-dist; Fri, 27 Aug 1999 13:29:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29140 for ; Fri, 27 Aug 1999 13:29:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA06047 for ; Fri, 27 Aug 1999 13:29:08 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA16884 for ; Fri, 27 Aug 1999 14:29:08 -0600 (MDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 1999 13:12:59 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.14) id ; Fri, 27 Aug 1999 13:12:41 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515895@RED-MSG-50> From: Richard Draves To: "'ford.re.1@pg.com'" , pete@loshin.com Cc: ipng@sunroof.eng.sun.com Subject: RE: AN interesting article. FYI... contd Date: Fri, 27 Aug 1999 13:12:55 -0700 X-Mailer: Internet Mail Service (5.5.2650.14) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We will need to replace/upgrade almost all of our equipment (mainframe > datacenters, 10's of 1,000's of pc's, hundreds of routers, > thousands of > eithernet switches, I don't know how many Novell, NT and Unix > servers). > Everything has addresses buried in them (I know, we should > not do that but we > have a lot of people in IT, so it happens and I cannot > assume). We have custom > code we wrote and custom code vendors have written for us, > some of whom are no > longer in business (again, not right but it's life). We will > have to throw-out > applications as part of this. I think that the job will take > 5-10 years to > complete, with the help of 100's of people around the world. > We are talking a > huge investment. I am optimistic that we can & are developing transition techniques that will allow the transition to IPv6 to be much more incremental. Legacy applications should continue to function. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 13:40:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA29169 for ipng-dist; Fri, 27 Aug 1999 13:37:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29162 for ; Fri, 27 Aug 1999 13:37:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA07906 for ; Fri, 27 Aug 1999 13:37:46 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23675 for ; Fri, 27 Aug 1999 13:37:46 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 27 Aug 1999 13:37:30 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A56902919F43@SIT.platinum.corp.microsoft.com> From: "Mike Zintel (Exchange)" To: ipng@sunroof.eng.sun.com Subject: RE: AN interesting article. FYI... contd Date: Fri, 27 Aug 1999 13:37:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk |One serious problem still largely unsolved in today's world is the absence |of a unique identifier that can be used initiate a connection from the core |network to a (PPP or DHCP) transiently connected end node. This is part is a |result of PPP/DHCP enabled address pooling. This problem is currently addressed with dynamic DNS. IPv6 will presumably rely on the same mechanisms, perhaps more so since IPv6 addresses are less stable... I don't understand how DDNS alone will solve this in the absence of some sticky address for every end node. If client initiated DDNS updates must occur, say, everytime PPP or DHCP gives me a new address, how can we build a network where my moher can call me when I'm not connected? Mike. -----Original Message----- From: Dan Lanciani [mailto:ddl@deas.harvard.edu] Sent: Friday, August 27, 1999 1:14 PM To: ipng@sunroof.eng.sun.com Subject: RE: AN interesting article. FYI... contd I must play devil's advocate here. "Mike Zintel (Exchange)" wrote: |It's helpful to contrast an ideal IPv6 world with today's world of DHCP'd, |IPCP'd, NAT'd, tunneled and proxied TCP/IP. In today's world, at least some end users (i.e., those who got in before so many addresses became "reserved") have stable, portable IP address space. Under IPv6, no end user will have stable or portable IP address space. This may seem like a good equalizer to the have-nots, but it isn't a feature for the haves. In today's world, at least some end users can still take advantage of what was once seen as a very important characteristic of the tcp/ip protocol: as long as you control the end points, it can be made arbitrarily tenacious independent of the reliability of the intermediate routers (assuming you don't have a total, permanent failure of course). Under IPv6, any active tcp/ip connection is always at the mercy of renumbering. Saying that nobody expects tcp/ip connections to be reliable outside of the intranet (as I have seen expressed here from time to time) ignores all those users who expect just that. Assuming that the problem will be easily solved by adapting tcp/ip to survive renumbering is, I think, minimizing a very tricky technical task. (And of course, it does nothing for application-level address knowledge.) Any complete solution that renders tcp, udp, and everything above largely independent of short-term address persistence (perhaps by creating a new class of cookie that effectively becomes the "first-class citizen" of identify) will make IPv6 addresses very different animals from IPv4 addresses. It may even make IPv6 addresses (at least in the sense that they are administratively allocatable entities) superfluous. This last is actually technically interesting, but it would obviate the need for all the address allocation policy that we know and love, and things don't seem to be moving it that direction. And besides, there has to be some pseudo-stable address space if only to provide a measure for billing... In today's world, a NAT user has complete control of the stability of its internal addresses and can hide its internal structure more-or-less completely. Under IPv6, the stability of the internal addresses (which are then, granted, at least globally routable) is dependent on every provider above the user. Moreover, the internal structure is completely exposed. This is great for the ISP who wants to bill per-host, but of little benefit to the end user. Naturally, there will be IPv6 NAT boxes (in several translation flavors) and I'll bet they will be used in V6<->V6 mode just to get the structure-hiding and firewall features. But there's not much point comparing NAT to NAT in this context... |Part of the problem selling IPv6 is the success of the address shortage |work-arounds. We are observing evolution in action. Apply the pressure of an address shortage (even if artificial) and the market will adapt, but perhaps not in the way some would like. It would be neat if you could make addresses valuable (dollar-wise) and then create a lot of wealth by expanding the address space, but the market doesn't always work that way. :) |Call attention to the usability and administration costs of |these solutions. The problem here is at least three-fold. First, a lot of these work-arounds work very well and their administrative costs even over the life of a company may not approach the cost of switching to IPv6 (and IPv6 solutions are not without their--hard to characterize--administrative costs). Second, some of these work-arounds offer features above and beyond expanding apparent address-space. These features will still be required with a switch to IPv6 but all the code will be new and untested. More overhead tipping the balance away from IPv6. Finally, IPv6 simply does not offer anything resembling an expanded IPv4 address space. IPv6 addresses are qualitatively very different from IPv4 addresses. IPv6 addresses are closer to DHCP'd or even NAT'd addresses than they are to stable IPv4 addresses, and IPv6 features tend to be of more benefit to ISPs than to end users. Until all the collateral work has been done to make an IPv6 address a functional drop-in replacement for an IPv4 address in whatever applications are of interest to a particular organization, there may be little incentive for that organization to switch. Even when this is done, IPv6 will have to bring more than parity to the table. |One serious problem still largely unsolved in today's world is the absence |of a unique identifier that can be used initiate a connection from the core |network to a (PPP or DHCP) transiently connected end node. This is part is a |result of PPP/DHCP enabled address pooling. This problem is currently addressed with dynamic DNS. IPv6 will presumably rely on the same mechanisms, perhaps more so since IPv6 addresses are less stable... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 14:54:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA29357 for ipng-dist; Fri, 27 Aug 1999 14:49:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29350 for ; Fri, 27 Aug 1999 14:49:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA25827 for ; Fri, 27 Aug 1999 14:49:13 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA18097 for ; Fri, 27 Aug 1999 15:49:12 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Aug 1999 14:27:05 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Fri, 27 Aug 1999 14:27:04 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145158A7@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: "'IPng List'" Subject: RE: hop limit API question Date: Fri, 27 Aug 1999 14:27:19 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We've implemented the multicast behavior to match the IPv4 behavior > just like Francis (loop back to any local members on the > sending interface > if IPV6_MULTICAST_LOOP is set). > > For unicast we make no checks thus packets would be transmitted with > a zero hoplimit. Hmm, at least for v4, the host requirements RFC 1122 section 3.2.1.7 says that hosts MUST NOT send a datagram with a TTL of zero. But it seems reasonable to allow loopback of packets (both unicast and multicast) with a zero hop limit. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 27 20:50:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA29562 for ipng-dist; Fri, 27 Aug 1999 20:38:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29553 for ; Fri, 27 Aug 1999 20:38:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA29670 for ; Fri, 27 Aug 1999 20:37:05 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA09334 for ; Fri, 27 Aug 1999 21:37:03 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id NAA15777; Sat, 28 Aug 1999 13:35:40 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Sat, 28 Aug 1999 13:35:40 +1000 (EST) From: Peter Tattam To: Dan Lanciani cc: IPNG Mailing List , Latif LADID Subject: RE: AN interesting article. FYI... contd In-Reply-To: <199908272013.QAA27379@endor.eas.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan and others have touched on an important issue, and that is Ipv6 is likely to get (and has already been) grilled heavily by the press. My own personal experiences with the press reflect similar attitudes to the one by the reporter in question. We need to keep an open mind about these aspects and should be focusing on mechanisms in IPv6 that give good incentives for organizations to upgrade to IPv6. The promotion of transition mechanisms should be taking a fairly high priority, as should ease of use of the new protocol. Instead I perceive opinions that maybe shun or discredit transition solutions, and policies of aggregation and renumbering that push us into uncharted territory. To the average outsider from the IPv6 scene, these would be enough of a disincentive for them to transition their infrastructure to Ipv6 despite their current problems with Ipv4 address lifetime extensions. Many of the people who have the final say on decisions on whether to switch to Ipv6 will unfortunately listen to the cries of the opponents, and will have a hard time fathoming the perceived benefits and difficulties IPv6 transition will bring them. With that in mind, our (TSI's) focus is on demonstrating how easy it is to enable a client and a network to IPv6 and let them see the benefits for themselves. Mind you, this is not as easy as it sounds, and there are still engineering hurdles that I have been frustrated at finding solutions to. Also, it may boil down to what we perceive as the eventual goal of IPv6. If it remains, as I believe has been, as merely an engineering solution to solve a specific set of problems, it will not make much headway. If it instead becomes "a way of life", then we may have more of a chance. This would mean that the IPv6 team will then need to focus on a more holistic approach to doing networking, with a common set of key goals. Those goals will have to answer many more powerful issues than the existing IPv6 solutions address. I and others would tend to think that there isn't quite enough benefit from moving to IPv6 that would tip the scale for the CEO's and CIO's of this world. There need to be some bolder and more decisive goals for the world to take note and start agreeing with us. I feel that a goal of being able to contruct a network out of raw components and simply connect them together with the absolute minimum of configuration would be a worthy one for the "IPv6 way of life" to embrace. This would have to be applied in a totally holistic approach from the appliances and workstations to intermediate routers and potentially right into the main core. We already have systems in hardware that you simply plug this bit into that bit and it just works. Face it people, configuration and maintenance of networks is probably one of the biggest hits and a growing one for every IT related company in the world. If we could demonstrate that Holy Grail through the "IPv6 way of life" many many more prominent decisions makers would take serious notice of IPv6. The internet has grown too large for people to tinker any more, and it needs to move to a higher plane of self management. In a world where computing is moving rapidly to the appliance model, "the Ipv6 way of life" may be the only way that reality could be achieved. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 28 02:48:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA29815 for ipng-dist; Sat, 28 Aug 1999 02:39:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29808 for ; Sat, 28 Aug 1999 02:39:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA15527; Sat, 28 Aug 1999 02:37:45 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA13150; Sat, 28 Aug 1999 02:37:44 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA24680; Sat, 28 Aug 1999 11:37:42 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA30391; Sat, 28 Aug 1999 11:37:41 +0200 (MET DST) Message-Id: <199908280937.LAA30391@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'Erik Nordmark'" , "'IPng List'" Subject: Re: hop limit API question In-reply-to: Your message of Fri, 27 Aug 1999 14:27:19 PDT. <4D0A23B3F74DD111ACCD00805F31D810145158A7@RED-MSG-50> Date: Sat, 28 Aug 1999 11:37:40 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > We've implemented the multicast behavior to match the IPv4 behavior > just like Francis (loop back to any local members on the > sending interface > if IPV6_MULTICAST_LOOP is set). > > For unicast we make no checks thus packets would be transmitted with > a zero hoplimit. Hmm, at least for v4, the host requirements RFC 1122 section 3.2.1.7 says that hosts MUST NOT send a datagram with a TTL of zero. => I've tried to explain this point : - RFC 1122 section 3.2.1.7 refers to RFC 791 where this point is not. - in my TCP/IP Illustrated vol2 p1100 in the BSD compliance list there is: * MUST NOT send packet with TTL of 0. Partially: The IP layer (ip_output) in Net/3 does not check this requirement and relies on the transport layers not to construct an IP header with a TTL of 0. UDP, TCP, ICMP, and IGMP all select a nonzero TTL default value. The default value can be overridden by the IP_TTL option. But it seems reasonable to allow loopback of packets (both unicast and multicast) with a zero hop limit. => I agree. Do you believe there MUST be an explicit test for not-loopback packets with 0 hop limit ? I think it doesn't matter (ie. the MUST should be replaced by a SHOULD, the only case where packets with 0 hop limit can be a problem is for brain-damaged routers with 0-1=255 !). Regards Francis.Dupont@inria.fr PS: my intention is not to open a new MUST vs SHOULD war but I'd like to know if I have to add the two line test in my ip6_output() function... PPS: after more reflection, I think the IPV6_*CAST_HOPS setsockopt spec is the good place to fix this problem : replace for IPV6_UNICAST_HOPS: x < -1: return an error of EINVAL x == -1: use kernel default 0 <= x <= 255: use x x >= 256: return an error of EINVAL by x < -1: return an error of EINVAL x == -1: use kernel default x == 0: EINVAL error or kernel default ??? 0 < x <= 255: use x x >= 256: return an error of EINVAL because if the (unique!) destination of a packet is local then the hop limit doesn't matter. keep the IPV6_MULTICAST_HOPS with a mention to the limitation for 0 hop limit (ie. Richard Draves' text). It is very important to keep IPv4 multicast application programming style for IPv6 because there is only a little documentation about how to build multicast applications (Steve Deering's note in ipmulti distrib is the best known (least unknow :-)) and of course there (still) are about IPv4. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 28 12:56:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA00193 for ipng-dist; Sat, 28 Aug 1999 12:47:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00186 for ; Sat, 28 Aug 1999 12:46:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA07250 for ; Sat, 28 Aug 1999 12:45:58 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10823 for ; Sat, 28 Aug 1999 13:45:57 -0600 (MDT) Received: from gigue.eas.harvard.edu (gigue.eas.harvard.edu [140.247.51.194]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id PAA01155 for ; Sat, 28 Aug 1999 15:45:52 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by gigue.eas.harvard.edu (8.9.1/8.9.1) id PAA00747 for ipng@sunroof.eng.sun.com; Sat, 28 Aug 1999 15:45:50 -0400 (EDT) Date: Sat, 28 Aug 1999 15:45:50 -0400 (EDT) Message-Id: <199908281945.PAA00747@gigue.eas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: RE: AN interesting article. FYI... contd Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Mike Zintel (Exchange)" wrote: |I don't understand how DDNS alone will solve this in the absence of some |sticky address for every end node. | |If client initiated DDNS updates must occur, say, everytime PPP or DHCP |gives me a new address, how can we build a network where my moher can call |me when I'm not connected? Ah, I assumed you were referring to the case of a transient connection while that connection was up. Clearly for the true dynamic outcall case you want an address identifier that is as stable as possible, but that applies equally to IPv4 and IPv6. Of course, for IPv4 that identifier could in fact be your IP address (at least it could when end-user allocations of portable address space were still allowed). Whether this was a good thing or a bad thing seems to be a philosophical debate. :) Who knows what the first-class identifier will turn out to be under IPv6? It's certainly handy in many applications to have a stable identifier that you can ``own'' and that won't change out from under you. To be useful that identifier may need to be at a lower level than a domain name but at a higher level than a dynamic address. Evolution will probably provide... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 29 07:51:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA00592 for ipng-dist; Sun, 29 Aug 1999 07:42:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00585 for ; Sun, 29 Aug 1999 07:42:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA25796 for ; Sun, 29 Aug 1999 07:42:44 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22250 for ; Sun, 29 Aug 1999 08:42:39 -0600 (MDT) Received: by odin.digi-data.com id <15233>; Sun, 29 Aug 1999 10:39:29 -0400 Message-Id: <99Aug29.103929gmt-0400.15233@odin.digi-data.com> Date: Sun, 29 Aug 1999 10:45:05 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dan Lanciani , IPng Mailing List Subject: Re: AN interesting article. FYI... contd References: <199908281945.PAA00747@gigue.eas.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Dan, > Who knows what the > first-class identifier will turn out to be under IPv6? It's certainly handy > in many applications to have a stable identifier that you can ``own'' and > that won't change out from under you. To be useful that identifier may > need to be at a lower level than a domain name but at a higher level than > a dynamic address. Evolution will probably provide... > Have we come full circle to the question of Session Stability as we had been discussing in another thread a few weeks ago? Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 29 12:37:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA00777 for ipng-dist; Sun, 29 Aug 1999 12:26:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00770 for ; Sun, 29 Aug 1999 12:25:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA21622 for ; Sun, 29 Aug 1999 12:25:58 -0700 (PDT) Received: from minuet.das.harvard.edu (mail.eas.harvard.edu [140.247.50.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22489 for ; Sun, 29 Aug 1999 12:25:57 -0700 (PDT) Received: from gigue.eas.harvard.edu (gigue.eas.harvard.edu [140.247.51.194]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id PAA05103 for ; Sun, 29 Aug 1999 15:25:56 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by gigue.eas.harvard.edu (8.9.1/8.9.1) id PAA03164 for IPng@sunroof.eng.sun.com; Sun, 29 Aug 1999 15:25:53 -0400 (EDT) Date: Sun, 29 Aug 1999 15:25:53 -0400 (EDT) Message-Id: <199908291925.PAA03164@gigue.eas.harvard.edu> To: IPng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Honore wrote: |Dear Dan, | |> Who knows what the |> first-class identifier will turn out to be under IPv6? It's certainly handy |> in many applications to have a stable identifier that you can ``own'' and |> that won't change out from under you. To be useful that identifier may |> need to be at a lower level than a domain name but at a higher level than |> a dynamic address. Evolution will probably provide... |> | |Have we come full circle to the question of Session Stability as we had been |discussing in another thread a few weeks ago? I think we've gone round that circle *many* times already over the years. That the issue remains unresolved this late in the game is unfortunate. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 29 13:18:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA00807 for ipng-dist; Sun, 29 Aug 1999 13:05:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00800 for ; Sun, 29 Aug 1999 13:05:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA22839 for ; Sun, 29 Aug 1999 13:05:08 -0700 (PDT) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26349 for ; Sun, 29 Aug 1999 13:05:08 -0700 (PDT) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id PAA29858; Sun, 29 Aug 1999 15:04:30 -0500 (CDT) Received: from dal-tx61-62.ix.netcom.com(207.221.95.62) by dfw-ix2.ix.netcom.com via smap (V1.3) id rma029847; Sun Aug 29 15:04:05 1999 Message-ID: <37C92306.3361C90@ix.netcom.com> Date: Sun, 29 Aug 1999 13:09:44 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Dan Lanciani CC: IPng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd References: <199908291925.PAA03164@gigue.eas.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan and all, Indeed you are right here Dan. This is a inadequacy of IPv6 that should have been addressed years ago actually, and is still not. Fortunately this is not the case with IPv8... Which in the long haul will be preferred to IPv6, for this an other reasons... Dan Lanciani wrote: > Robert Honore wrote: > > |Dear Dan, > | > |> Who knows what the > |> first-class identifier will turn out to be under IPv6? It's certainly handy > |> in many applications to have a stable identifier that you can ``own'' and > |> that won't change out from under you. To be useful that identifier may > |> need to be at a lower level than a domain name but at a higher level than > |> a dynamic address. Evolution will probably provide... > |> > | > |Have we come full circle to the question of Session Stability as we had been > |discussing in another thread a few weeks ago? > > I think we've gone round that circle *many* times already over the years. That > the issue remains unresolved this late in the game is unfortunate. > > Dan Lanciani > ddl@harvard.edu > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 29 23:23:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA01265 for ipng-dist; Sun, 29 Aug 1999 23:14:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01258 for ; Sun, 29 Aug 1999 23:14:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA17004 for ; Sun, 29 Aug 1999 23:13:59 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA21385 for ; Sun, 29 Aug 1999 23:13:58 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA27291; Mon, 30 Aug 1999 15:13:43 +0900 (JST) To: Francis Dupont cc: IPng@sunroof.eng.sun.com, v6@wide.ad.jp In-reply-to: Francis.Dupont's message of Sat, 28 Aug 1999 11:42:59 +0200. <199908280942.LAA21819@givry.inria.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AirSurfer at Tokyo interim meeting From: itojun@iijlab.net Date: Mon, 30 Aug 1999 15:13:43 +0900 Message-ID: <27289.935993623@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It was unicasted to me but I believe other people may find it useful: >Which kind of AirSurfers will be available at the interim meeting ? >(there are old Xircoms, new Xircoms (plus?), BayStacks 650 (IEEE FH) >and BayStacks 660 (IEEE DS)) >I'd like to know if the FreeBSD PAO "cnw" driver will work. I suppose we will be able to put base stations for: - old Xircom/Netwave AirSurfer (NOT plus) - BayStack 650 (IEEE FH) In case there's any problem with wireless, please do not forget to bring normal (wired) 10Base-T/100Base-T interface card, and 10Base-T cable to your notebook PC. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 30 05:21:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA01867 for ipng-dist; Mon, 30 Aug 1999 05:10:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01860 for ; Mon, 30 Aug 1999 05:10:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA01347 for ; Mon, 30 Aug 1999 05:10:06 -0700 (PDT) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.67.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA22404 for ; Mon, 30 Aug 1999 05:10:05 -0700 (PDT) Received: from hygro.adsl.duke.edu (localhost [127.0.0.1]) by hygro.adsl.duke.edu (8.8.7/8.8.7) with ESMTP id IAA06511; Mon, 30 Aug 1999 08:10:32 -0400 Message-Id: <199908301210.IAA06511@hygro.adsl.duke.edu> To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: AN interesting article. FYI... contd In-Reply-To: Message from Dan Lanciani of "Sat, 28 Aug 1999 15:45:50 EDT." <199908281945.PAA00747@gigue.eas.harvard.edu> Date: Mon, 30 Aug 1999 08:10:31 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ah, I assumed you were referring to the case of a transient > connection while that connection was up. Clearly for the true > dynamic outcall case you want an address identifier that is as > stable as possible, but that applies equally to IPv4 and IPv6. Of > course, for IPv4 that identifier could in fact be your IP address > (at least it could when end-user allocations of portable address > space were still allowed). Whether this was a good thing or a bad > thing seems to be a philosophical debate. :) Philosophical desires aside, the reality today is that the IPv4 addresses are no longer the stable identifiers that folks find covenient. Wishing it otherwise won't make it so. > Who knows what the first-class identifier will turn out to be under > IPv6? It's certainly handy in many applications to have a stable > identifier that you can ``own'' and that won't change out from under > you. To be useful that identifier may need to be at a lower level > than a domain name but at a higher level than a dynamic address. > Evolution will probably provide... The hard problem with stable identifiers is that for identifiers to be useful, one needs to be able to map them into a network address that IP can use to actually deliver a packet to the destination corresponding to that identifier. An identifier by itself, with no idea how to deliver a packet to the node corresponding to an identifier is close to useless. If one stores the identifier, presumably one will want to use it again in the future. But then it needs to be mappable into a network layer address so packets can be delivered to it. And if addresses change over time, than the mapping changes over time as well. In the old days of IPv4, having the address carry both the identifier and locator in the same enitity (i.e., the address) made the mapping problem trivial. How to do the mapping in a world where network address can change is a very hard problem, if one wants a solution that scales to the size of the Internet. DNS names come to mind because there we have a scalable distributed database that maps identifiers (DNS names) to arbitrary information (e.g., the current address corresponding to the identifier). But how to keep the DNS up-to-date in a world where addresses change frequently is a non-trivial problem. This becomes particularly apparent when one understands that the DNS is glued together by hard-wired addresses (pointers to DNS servers for a zone). You can't change network addresses without fixing up the DNS pointers simultanenously (if you want the mapping function to always work). While this could in theory be done, there are some non-trivial details to work out before this can be made practical, and to my knowledge, no one has sat down and tried to work through a detailed design (though it would certainly be useful if someone did!). Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 00:23:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA27162 for ipng-dist; Tue, 31 Aug 1999 00:18:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27155 for ; Tue, 31 Aug 1999 00:18:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA03129 for ; Tue, 31 Aug 1999 00:18:24 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA06181 for ; Tue, 31 Aug 1999 00:18:24 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id QAA10146 for ; Tue, 31 Aug 1999 16:18:23 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA12251 for ; Tue, 31 Aug 1999 16:18:22 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA25231 for ; Tue, 31 Aug 1999 16:18:22 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: web delayed From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94pre1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990831161749D.kazu@iijlab.net> Date: Tue, 31 Aug 1999 16:17:49 +0900 X-Dispatcher: imput version 990826(IM126) Lines: 7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, We need more time to fix the registration web page. Please wait for a while. You don't have to hurry up anyway because hotel rooms have already been booked. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 02:22:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA27347 for ipng-dist; Tue, 31 Aug 1999 02:13:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27340 for ; Tue, 31 Aug 1999 02:13:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA25965 for ; Tue, 31 Aug 1999 02:12:17 -0700 (PDT) Received: from lorraine.loria.fr (lorraine.loria.fr [152.81.1.17]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28394 for ; Tue, 31 Aug 1999 02:12:15 -0700 (PDT) Received: from loria.fr (antibes.loria.fr [152.81.12.73]) by lorraine.loria.fr (8.9.3/8.9.3/8.9.3/JCG-DG) with ESMTP id LAA26598 for ; Tue, 31 Aug 1999 11:12:14 +0200 (MET DST) Message-ID: <37CB9C6D.2D5CA90A@loria.fr> Date: Tue, 31 Aug 1999 11:12:13 +0200 From: Isabelle Chrisment X-Mailer: Mozilla 4.03 [fr] (WinNT; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Last Call For Participation in Mobile-IPv6 Connectathon] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > LAST CALL FOR PARTICIPATION > > MOBILE IPv6 CONNECTATHON > > September 15- 17, 1999, > LORIA, Nancy, France > > > The G6 group is organizing a mobile-IPv6 connectathon in France, in > Nancy, > on September 15, 16 & 17 1999. Nancy is located in the east of France. > > If you have mobile-IPv6 code and would like to participate to this > event complete the enclosed registration form before the 4th of > SEPTEMBER 1999 (last deadline) . > > Further information is available at > http://www.loria.fr/~ichris/mobipv6 > > > REGISTRATION FORM FOR MOBILE-IPv6 CONNECTATHON'99 > > > Workshop Date : Septembre 15 - September 17 1999 > The reception of participants will begin September 15, from 10.00 am > to > 10.30 am. > The workshop will be ended September 17, at midday. > > Conference Location INRIA-LORIA/ Nancy > 615 rue du Jardin Botanique > BP 101 > 54602 Villers-Lès-Nancy > url : http://www.loria.fr > > Registration form to be completed and forwarded to re@loria.fr > > ______________________________________________________________ > ________________ > Name (first, middle, last) > > __________________________ > ____________________________________________________ > Affiliation (for badge) > > _______________________ > _______________________________________________________ > Title/Job Function > > __________________ > ____________________________________________________________ > Address > > _______ > _______________________________________________________________________ > > City Prov/State > Zip Code > > ________ > ______________________________________________________________________ > > Country > > _______ > _______________________________________________________________________ > > Telephone > > _________ > _____________________________________________________________________ > Fax > > ___ > ___________________________________________________________________________ > > E-mail > > Participation in the Dinner : > (9/16/1999) Yes __ > No __ > > Date/Time of arrival : > > Date/Time of departure : -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 15:48:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA27934 for ipng-dist; Tue, 31 Aug 1999 15:45:06 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27906 for ; Tue, 31 Aug 1999 15:44:27 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA489931; Tue, 31 Aug 1999 15:44:24 -0700 (PDT) Date: Tue, 31 Aug 1999 13:59:44 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: Tim Hartrick Cc: vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199908121931.MAA08511@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would say that a non-zero sin6_scope_id overrides the IPV6_MULTICAST_IF > option and that the interface indices in the IPV6_PKTINFO and IPV6_NEXTHOP > options override the sin6_scope_id. For IPV6_NEXTHOP are you talking about an ifindex in a sockaddr_dl? If so, will this override IPV6_PKTINFO or the other way around? For IPV6_PKTINFO there might be a difference whether it is a sticky option or in ancillary data. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 15:48:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA27933 for ipng-dist; Tue, 31 Aug 1999 15:44:46 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27894 for ; Tue, 31 Aug 1999 15:44:21 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA489907; Tue, 31 Aug 1999 15:44:19 -0700 (PDT) Date: Tue, 31 Aug 1999 13:45:03 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: more 2292-bis comments To: Sam Manthorpe Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199908111923.MAA40320@bossette.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. I assume that the intention is to insert the extension > headers created with the inet6_opt_* functions into the > cmsg_data part of a control message to be passed as > ancillary data. Yes, cmsg_data *or* in a setsockopt for sticky options. > This relationship between the CMSG_* > macros and the inet6_opt_* functions wasn't stated > explicitly in the document, although it does become > apparent after reading the examples in the appendix. > Why was the cmsg stuff moved to the appendix? I'll try to make this more explicit. > 2. inet6_opt_append(). I think if the extbuf parameter > is non-NULL then you would also like the function to > update the extension header length field, right? This > isn't currently required by the document and I suggest > that it should be. The intent is that inet6_opt_init set the length (so that the other functions can check for overrunning the the buffer). I could embelish the example with pictures, or I could toss an example implementation of inet6_opt_*() in an appendix. > 3. I don't see any reason to not allow inet6_opt_append() > to add Pad1 and PadN options (section 9.2). Agreed. > 4. I would suggest that padding options _not_ be returned > by inet6_opt_next() and that this be stated in section 9.5. I think that would make sense. > 5. Section 9.5 should desecribe how the function behaves > once all the options have been read from the buffer; I would > suggest that it return a value of zero and that the three > call-by-reference return parameters remain undefined. Yes, we need to specify something. > 6. Is there really such an installed base to warrant the > rfc-2292 compatability goal? 2292bis states it contains > several modifications to simplify the implementation > of the API but then suggests that implementation > compatibility with 2292 would be a good thing, defeating > the goal of these simplifications. I really would prefer > a `one or the other' approach, because there is no important > functionality in one that isn't in the other regarding > the ancillary data/sockopts functionality, it's just > two different ways of doing things. I'm open to input. Does anybody want 2292 compatibility? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 15:48:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA27935 for ipng-dist; Tue, 31 Aug 1999 15:45:08 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27902 for ; Tue, 31 Aug 1999 15:44:24 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA489916; Tue, 31 Aug 1999 15:44:21 -0700 (PDT) Date: Tue, 31 Aug 1999 13:47:59 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: Francis Dupont Cc: Vladislav Yasevich , IPNG Working Group In-Reply-To: "Your message with ID" <199908121913.VAA06454@givry.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Section 2.2.1 [page 11] > - The following definition is no longer valid: > 614 #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */ > > It now refers to an address that is beyond the scope of source address as > defined in Section 3.1 of draft-ietf-ipngwg-icmp-v3-00.txt > The draft defines the code value 2 as "beyond scope of source address". > > => I propose ICMP6_DST_UNREACH_BEYONDSCOPE Done. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 15:48:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA27937 for ipng-dist; Tue, 31 Aug 1999 15:45:19 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27914 for ; Tue, 31 Aug 1999 15:44:31 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA489960; Tue, 31 Aug 1999 15:44:28 -0700 (PDT) Date: Tue, 31 Aug 1999 14:22:59 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: tim@mentat.com, vlad@zk3.dec.com, Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <14263.60698.673536.12718B@condor.isl.rdc.toshiba.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are my personal opinions. Once I've gotten to the end of this thread of email I'll try to figure out where the consensus is heading. > RFC 2553 says about sin6_scope_id just as follows: > > [...] > > The description seems to me not enough specific to ensure > portability. For example, the followings are not clear: > > - if we set a non-zero value to sin6_scope_id and a link-local unicast > address to sin6_addr, should the corresponding packet be sent on the > interface specified by the value of sin6_scope_id field? Yes. > - if we receive a packet via recvfrom(or recvmsg, or whatever) and > the from(i.e. source) address of the packet is a link-local address, > should the sin6_scope_id field be set the index of the receiving > interface? Should we allow the kernel to set zero to the field even > if the `from' address is link-local? No. We want the application which does recvfrom + sendto to work with link-local addresses on a multihomed system. Thus if the source is link-local then recvfrom MUST return the ifindex as sin6_scope_id. > - as RFC says, the specification is ambiguous for site-local > addresses. I think it is as well-specified given the state of any notion of "site identifiers". Doing anything more requires at least something like the if_nametoindex type functionality for site indentifiers, as well as some (node local) name space for site identifiers. > - if we set a non-zero value to sin6_scope_id and a global unicast > address to sin6_addr, what should the kernel do? Return an error? > Ignore the value? Or send the packet to the interface whose index is > the specified value? Ignore or error sounds reasonable. > Which value should the kernel set to sin6_scope_id when receiving > from a global address? Zero. > - all the above questions are also applied for multicast addresses. For link scope same as link-local. For site scope same as site-local. Don't know what to to do with the reserved values between those two. > - suppose that we set a non-zero value to sin6_scope_id, set a > link-local address to sin6_addr, and call bind() with the socket > address. When we try to send a packet to the socket, should the > kernel send the packet to the interface specified by the > sin6_scope_id passed to bind()? Good question. bind() conceptually specifies the local part of the address and not where things are sent. Thus it would make more sense to ask if you bind to link-local X with ifindex 2 will that reject packets sent to link-local address X which arrive on some other interface? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 15:48:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA27936 for ipng-dist; Tue, 31 Aug 1999 15:45:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27912 for ; Tue, 31 Aug 1999 15:44:30 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA489946; Tue, 31 Aug 1999 15:44:26 -0700 (PDT) Date: Tue, 31 Aug 1999 14:05:08 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com, vlad@zk3.dec.com, Francis.Dupont@inria.fr In-Reply-To: "Your message with ID" <14263.50679.209399.57571Q@condor.isl.rdc.toshiba.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Though the meaning does not change, the names defined in the RFC 2292 > (and 2292bis) are a bit confusing for application programmers. > Just FYI, KAME locally defines the following definitions (please note > that we don't insist on these local definitions at all): > > #define MLD6_LISTENER_QUERY 130 /* multicast listener query */ > #define MLD6_LISTENER_REPORT 131 /* multicast listener report */ > #define MLD6_LISTENER_DONE 132 /* multicast listener done */ To be consitent with ND_ (and since the protocol is really MLD and not MLDv6) it would make sense to use the MLD_ prefix instead of MLD6_. > Moreover, there are some new protocols that have been defined since > RFC 2292 and are about to be standardized, e.g. > > Router Renumbering > Router Alert Option > ICMPv6 name lookups Is name lookups moving forward? Is it close to a WG last call? (I haven't heard much about it.) > Mobile IPv6 > ... > > I admit that it's hard (even impossible) to catch up all such new > protocols, but 2292bis would be a good opportunity. I hope the revised > API reflects as much changes as possible. I agree that this would make sense. Have you guys defined data structures for the above packet/option formats in addition to the constants you list below? If I get the info I can add it to 2292bis. Erik > Again, just FYI, KAME locally defines the following definitions for > some of the above new protocols: > > Macros for router renumbering: > #define ICMP6_ROUTER_RENUMBERING_COMMAND 0 /* rr command */ > #define ICMP6_ROUTER_RENUMBERING_RESULT 1 /* rr result */ > #define ICMP6_ROUTER_RENUMBERING_SEQNUM_RESET 255 /* rr seq num reset */ > > Macros for ICMPv6 name lookups: > #define ICMP6_FQDN_QUERY 139 /* FQDN query */ > #define ICMP6_FQDN_REPLY 140 /* FQDN reply */ > #define ICMP6_NI_QUERY 139 /* node information request */ > #define ICMP6_NI_REPLY 140 /* node information reply */ > > #define ICMP6_NI_SUCESS 0 /* node information successful reply */ > #define ICMP6_NI_REFUSED 1 /* node information request is refused */ > #define ICMP6_NI_UNKNOWN 2 /* unknown Qtype */ > > Macros for IPv6 Router Alert HbH option: > #define IP6OPT_RTALERT 0x05 /* 00 0 00101 */ > #define IP6OPT_RTALERT_MLD 0 /* Datagram contains an MLD message */ > #define IP6OPT_RTALERT_RSVP 1 /* Datagram contains an RSVP message */ > #define IP6OPT_RTALERT_ACTNET 2 /* contains an Active Networks msg */ > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 16:13:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA28038 for ipng-dist; Tue, 31 Aug 1999 16:10:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28031 for ; Tue, 31 Aug 1999 16:10:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA08753 for ; Tue, 31 Aug 1999 16:10:08 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA06686 for ; Tue, 31 Aug 1999 17:10:06 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 31 Aug 1999 16:09:49 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Tue, 31 Aug 1999 16:09:48 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145158CB@RED-MSG-50> From: Richard Draves To: ipng@sunroof.eng.sun.com Subject: node-local mc & the API Date: Tue, 31 Aug 1999 16:09:37 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does the API require/allow any special restrictions on node-local multicast addresses. For example, can an implementation require that node-local multicast addresses only be assigned to a loopback interface? How do node-local multicast addresses interact with the IPV6_MULTICAST_LOOP option? If the option is set to disallow loopback, I assume that means transmissions will get dropped in the bit bucket? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 31 17:49:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA28173 for ipng-dist; Tue, 31 Aug 1999 17:46:29 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28166 for ; Tue, 31 Aug 1999 17:46:19 -0700 (PDT) Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA509730; Tue, 31 Aug 1999 17:46:16 -0700 (PDT) Date: Tue, 31 Aug 1999 17:46:16 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on 2292bis (Adv. API) (2) (Fwd) To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com, rstevens@kohala.com, matt@3am-software.com, erik.nordmark@eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Resent with correct address] >----------------Begin Forwarded Message----------------< Date: Tue, 31 Aug 1999 10:18:58 -0700 (PDT) From: "Erik Nordmark" Subject: Re: Comments on 2292bis (Adv. API) (2) To: "Vladislav Yasevich" Cc: "IPNG Working Group" , rstevens@kohala.com, matt@3am-software.com, erik.nordmark@eng.sun.com > Section 9.5 [page 36] > - How is the "previous" length updated in this sentence? > 1977 .... This > 1978 function returns the updated "previous" length taking into account > 1979 the option that was returned. It updates it so that it can be passed to the next call to inet6_opt_next. I'll add some text to that effect. (Or were you asking how to implement this?) > - Also, the main body of the spec does not indicate if inet6_opt_next returns > pad options or just skips over them. The example code in the appendix shows > the application code does recognize and ignore pad options. Suggest a note > be added to this section indicating inet6_opt_next does return pad options. I agree we should clarify this. But do we want it to return them or skip them? > > Section 10 [page 37] > 2040 All Hop-by-Hop options must be specified in a single ancillary data > 2041 object. Should multiple be specified the implementation might > choose > 2042 an arbitrary one or drop the packet. > > - Does this refer to multiple options or multiple ancillary data objects? The latter. > > Sections 12.2 and 12.3 > - What was the reason to put rcmd_af() and rexec_af() in this spec? > It was the concensus of the reviewers that these functions are not really > needed since they both used to call rresvport() and can be made to call > rresvport_af(). As it is currently, rcmd() and rexec() do the hostname > lookups. At this point these functions can make the decision to use V6 or > V4 based on the addresses returned. We do not really see the need for > rcmd_af() and rexec_af(). I tried finding the old discussion but failed to do so. The issue is that transparently changing rcmd and rresvport to open AF_INET6 sockets (based on what getipnodebyname returns) might break some existing applications. For example, an application which calls rcmd and then calls getpeername. Thus I think we need APIs so that only applications which state that they can handle sockaddr_in6 addresses will get an AF_INET6 socket returned by rcmd/rexec/rresvport. > > Section 13. > - Why does this section exist in addition to section 18 (TODO and Open > Issues)? Should this be merged into one section? Because it existed in 2292 :-) Once we are done there will hopefully be no such section - just a section with changes from rfc 2292. > Section 22 [page 47] > - This section and it's subsections add a lot of new requirements to > an implementation's handling of the msghdr and cmsghdr structures. What aspects of msghdr and cmsghdr are new? 99% of it is in posix/xnet already. The only new things are CMSG_SPACE and CMSG_LEN. Anything else? > We don't think this should be treated as "informational" given that > many of these requirements are necessary to support the main body of > the spec. Also, the new requirements are being made to posix standard > structures and macros. Something needs to be done to make this section > less "informational." We could lift out the new stuff and leave the repetitive information in the appendix. > > Section 22.3.2 [page 51] > - It might be good to qualify that cmsg is a pointer to the cmsghdr struct > returned by a previous call to CMSG_NEXTHDR() or CMSG_FIRSTHDR(). Could do that - but I don't want to make this spec a tutorial on ancillary data since there are already books covering that subject. > Section 22.3.4 [page 52] > - This sentence is a little confusing, since the macro does not in > fact allocate space: > 2905 .... This macro can be > 2906 used, for example, to allocate space dynamically for the ancillary > 2907 data. I'll fix it. > Section 23.1: The example starts with: > > void *extptr; > int extlen; > struct msghdr msg; > struct cmsghdr *cmsgptr; > int cmsglen; > struct sockaddr_in6 I1, I2, I3, D; > > extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3); > cmsglen = CMSG_LEN(extlen); > cmsgptr = malloc(cmsglen); > cmsgptr->cmsg_len = cmsglen; > > Should the last three lines shown here be changed to: > > cmsglen = CMSG_SPACE(extlen); > cmsgptr = malloc(cmsglen); > cmsgptr->cmsg_len = CMSG_LEN(extlen); I have a general TODO on this. The fact is that both CMSG_LEN and CMSG_SPACE work when there is only one ancillary data item. But I think it makes sense for constency to adopt your proposal. (Turned out you found the one and only example - I thought there was more brokenness.) Erik >----------------End Forwarded Message----------------< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------