From owner-ipng@sunroof.eng.sun.com Tue Apr 6 03:01:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA24435 for ipng-dist; Tue, 6 Apr 1999 02:58: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 CAA24428 for ; Tue, 6 Apr 1999 02:58:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id CAA15720 for ; Tue, 6 Apr 1999 02:58:32 -0700 (PDT) Received: from dur.tbit.dk (dur.tbit.dk [194.182.135.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA07682 for ; Tue, 6 Apr 1999 02:58:31 -0700 (PDT) Received: from pcn.tbit.dk (pcn.tbit.dk [194.182.135.33]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id LAA03061 for ; Tue, 6 Apr 1999 11:58:27 +0200 (MET DST) Date: Tue, 6 Apr 1999 11:58:27 +0200 (MET DST) From: "Peder Chr. Norgaard" To: ipng@sunroof.eng.sun.com Subject: (IPng 7395) A few questions regarding draft-ietf-ipngwg-mld-mib-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am glad to see the draft MIB for Multicast Listener Discovery and have had a quick look at the possibility of implementing it. Two quick questions come to mind: 1) To identify interfaces you have chosen to use an Integer32, with no explicit reference to other MIBs. Now, with IPv6 we have two different and independent numberings of interfaces, namely the classical IP-independent InterfaceIndex from IF-MIB (currently RFC 2233), and the new IPv6 specific Ipv6IfIndex from IPV6-TC (currently RFC 2465). Which of the two are you thinking of? The document need to be clarified on this point. My preference would be the latter; that will allow the MIB to describe MLD over anything that can be handled with the IPV6-MIB. Using the former could give problems for MLD over things like IPv4 tunnels unless one have implemented a specific tunnel MIB with an associated IF-MIB InterfaceIndex. 2) Why are you using the word and OID tree position "experimental"? Is this MIB not something that belongs on the normal Standards Track? best regards --peder chr. Peder Chr. Nørgaard System Developer, M. Sc. Telebit Communications A/S tel: +45 86 28 81 77 - 49 Fabrikvej 11 fax: +45 86 28 81 86 DK-8260 Viby J Denmark e-mail: pcn@tbit.dk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 8 13:35:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA27198 for ipng-dist; Thu, 8 Apr 1999 13:32: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 NAA27191 for ; Thu, 8 Apr 1999 13:32:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id NAA10475 for ; Thu, 8 Apr 1999 13:32:23 -0700 (PDT) Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA24488 for ; Thu, 8 Apr 1999 13:32:22 -0700 (PDT) Received: by mailgate.rdg.opengroup.org; id AA30205; Thu, 8 Apr 1999 20:33:57 GMT Received: from cjh.rdg.opengroup.org [192.153.166.111] by mailgate.rdg.opengroup.org via smtpd V1.32 (99/03/30 12:28:06) for ; Thu Apr 08 21:33 BST 1999 Message-Id: <3.0.3.32.19990408212045.007d2cc0@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 08 Apr 1999 21:20:45 +0100 To: xnet@opengroup.org, ipng@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 7397) Incorporation of Basic API to IPv6 in XNS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - At its recent meeting, the XNET working group drew up the following timetable for its work on incorporating the Basic API to IPV6 described in RFC 2553 into the Open Group Networking Services Specification, XNS. It is intended that this will in turn become part of a new UNIX standard, which will be endorsed by the IEEE and ISO as well as by The Open Group (This joint TOG/IEEE/ISO activity is called the Austin Group, see http://www.opengroup.org/austin/ ). Issues and proposals for resolution listed by April 30 Formal Change Requests (CRs) submitted by May 14 Voting on CRs: May 17 - May 28 Issue Resolution: May 31 - June 4 Teleconference if needed: June 3 Review draft available by June 18 Interim XNET meeting during Oslo IETF July 16 (or other date that week to be agreed) Formal CRs submitted against new draft by July 30 Voting on CRs: August 2 - August 6 Issue Resolution: August 9 - August 13 Open Group Company Review: September 1 - September 30 Issue resolution at XNET meeting: October 19 - October 21 Sanity Check: November 1 - November 5 Formal Open Group approval for publication during November in time for the Austin Group meeting on December 6 The current working draft of XNS is on the web in html and pdf forms at http://www.opengroup.org/orc/DOCS/XNS/ It includes all of the Basic API except for the getaddrinfo(), freeaddrinfo(), getnameinfo() and gai_strerror() functions. These functions are in an addendum which is at http://www.opengroup.org/orc/DOCS/XNS_GAI/ (they are expected to be merged into the next draft of XNS but the addendum has been produced to enable comments to be made on them in the mean time). You can request changes to these drafts on-line, using the HTML versions (if your browser is sufficiently modern) or by e-mail to xnet@opengroup.org. All interested parties are invited to join in this work. The mailgroup on which comments will be discussed is xnet@opengroup.org. If anyone on the ipng list who is not currently a member of this mailgroup would like to be added to it, please would they let me know. If any substantive changes to the Basic API are decided on in the course of this work then the whole ipng list will be asked to review them (they will probably be incorporated in an update to RFC 2553 which will be posted as an Internet Draft in the normal way). Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 11 11:23:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA29111 for ipng-dist; Sun, 11 Apr 1999 11:20:59 -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 LAA29104 for ; Sun, 11 Apr 1999 11:20:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id LAA05108 for ; Sun, 11 Apr 1999 11:20:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA24565 for ; Sun, 11 Apr 1999 11:20:47 -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 OAA04363; Sun, 11 Apr 1999 14:20:41 -0400 (EDT) Message-Id: <199904111820.OAA04363@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: (IPng 7403) I-D ACTION:draft-ietf-ipngwg-scoped-routing-01.txt Date: Sun, 11 Apr 1999 14:20:40 -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 : Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Author(s) : B. Haberman Filename : draft-ietf-ipngwg-scoped-routing-01.txt Pages : 7 Date : 07-Apr-99 This document outlines a mechanism for generating routing tables that include scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward scoped unicast and multicast addresses regardless of the routing protocol. It should be noted that these rules will apply to all scoped addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoped-routing-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-scoped-routing-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-scoped-routing-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: <19990407142253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoped-routing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoped-routing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990407142253.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 Mon Apr 12 02:41:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA29397 for ipng-dist; Mon, 12 Apr 1999 02:39:23 -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 CAA29390 for ; Mon, 12 Apr 1999 02:39:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id CAA28262 for ; Mon, 12 Apr 1999 02:39:12 -0700 (PDT) Received: from kame200.kame.net (kame200.kame.net [203.178.141.200]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA16750 for ; Mon, 12 Apr 1999 02:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by kame200.kame.net (8.9.2/8.9.2) with ESMTP id SAA03743 for ; Mon, 12 Apr 1999 18:40:52 +0900 (JST) (envelope-from kazu@kame.net) To: ipng@sunroof.eng.sun.com Subject: (IPng 7405) KAME stable release 19990412 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94b21 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: <19990412184052H.kazu@kame.net> Date: Mon, 12 Apr 1999 18:40:52 +0900 X-Dispatcher: imput version 990405(IM114) Lines: 67 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.1(New!), NetBSD 1.3.3, 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. --Kazu, KAME Project --from here The following is the RELNOTE file. RELNOTES of KAME kit KAME Project $Date: 1999/04/12 02:39:05 $ Here is a summary of differences between KAME stable 19990131 and 19990412. <> - Fixed mbuf leaks and other mbuf-related twists. <> - Fixed mbuf leaks and other mbuf-related twists. - Rate limit for icmp6 redirect. - Reject overlapping fragment on reception. - More spec-conformant source address selection for NA output. - MINCLSIZE is decreased to force drivers to give cluster mbuf. - (FreeBSD 3.1) cisco HDLC support for sppp device. - (BSDI) merged `goto ours' hack using the routing table from KAME for FreeBSD. - ND6 reachable time is now recomputed in at least two hours even if no router advertisement is received. - Changed to use ND based MTU instead of the link's physical MTU when detecting whether the packet should be fragmented. <> - setsockopt(IPV6_{UNI,MULTI}CAST_HOPS) now behaves as described in spec. - Fixed libinet6 in order to support a lot of interfaces(e.g. over 100 gifs can be configured). <> - Avoid corrupted packet on tcp retransmission. - Fixed a bug in IPsec header size computation for MTU consideration. - esp_output() now takes care of both IPv4 and IPv6 (used to be separate). - Fix memory leakage in IPsec tunnel decapsulation. - (NetBSD) tcp4/6 takes care about IPsec header size in MSS computation. <> - traceroute6 supports source route (-g). - -c specifies alternate configuration file path for rtadvd. - Bug fixes and enhancements of bgpd. - Additions of several manpages. <> - ports/pkgsrc: upgraded base version for many items in the collection. - ports/pkgsrc additions: wbd, squid, ethereal - 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 Mon Apr 12 09:10:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA29643 for ipng-dist; Mon, 12 Apr 1999 09:07: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 JAA29636 for ; Mon, 12 Apr 1999 09:07:47 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id JAA06911 for ; Mon, 12 Apr 1999 09:07:45 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA03173 for ; Mon, 12 Apr 1999 09:07:41 -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 LAA27693 for ; Mon, 12 Apr 1999 11:07:38 -0500 (CDT) Message-Id: <199904121607.LAA27693@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 7406) Re: I-D ACTION:draft-ietf-ipngwg-scoped-routing-01.txt In-reply-to: Your message of Sun, 11 Apr 1999 14:20:40 EDT. <199904111820.OAA04363@ietf.org> Date: Mon, 12 Apr 1999 11:07:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a good first cut at a document that should definitely exist. I think it needs elaboration or correction in a couple of directions. Section 2: > - Site boundaries cut through nodes How about splitting this into three: Links belong to at most one site. Interfaces belong to the site of the attached link, if any. Nodes are part of all sites which their interfaces belong to, and no other sites. > - A single interface can only be in one site An interface can be in at most one site. In my mind, it would often be useful for links between two sites to belong to neither. Maybe a footnote is needed for subinterfaces (VCs and the like). Section 3 > In a single site router, a routing protocol > can advertise and route all addresses and prefixes on all interfaces. Except the link-local prefix, of course. Section 4.2 > the router must perform the following : Conceptually, yes. But the effect can be achieved other ways. > code = 5 (Scope Mismatch). I'm not convinced we *need* a new code. Code 3 is for "any other reason [than administrative prohibition or no route]." If the sending node has some sort of try-again smarts, it can easily notice that the src & dst scopes are different. Section 5 Here's a question: Were the various multicast scopes meant to be strictly hierarchical? They can't be if nodes are multi-sited, unless you demand that a node-local multicast only reach (conceptual) sockets bound to interfaces in the same site -- and I think that would be a bad demand to make. scop=2 (link-local) couldn't cross a site boundary, by the proposed definition of site boundaries, but scop=1 could, and in principle so could scop=3 and 4. I think we can live with 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 Apr 14 01:07:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA00855 for ipng-dist; Wed, 14 Apr 1999 01:04: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 BAA00848 for ; Wed, 14 Apr 1999 01:04:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id BAA05682 for ; Wed, 14 Apr 1999 01:04:17 -0700 (PDT) Received: from carex.nov.tahi.org (oxalis.nezu.wide.ad.jp [203.178.142.208]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA25217 for ; Wed, 14 Apr 1999 01:04:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carex.nov.tahi.org (8.8.8/8.8.8) with ESMTP id RAA28609 for ; Wed, 14 Apr 1999 17:04:07 +0900 (JST) (envelope-from nov@nov.tahi.org) To: ipng@sunroof.eng.sun.com Subject: (IPng 7407) Re: KAME stable release 19990412 From: Nobuo Okabe Reply-To: Nobuo_Okabe@yokogawa.co.jp In-Reply-To: Your message of "Mon, 12 Apr 1999 18:40:52 +0900" <19990412184052H.kazu@kame.net> References: <19990412184052H.kazu@kame.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: <19990414170407I.nov@nov.tahi.org> Date: Wed, 14 Apr 1999 17:04:07 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, I'm pleased to announce TAHI Project that is joint effort to provide verification technology for IPv6. We are working with KAME project and WIDE project. We have opened conformance test report about KAME-19990412-stable at our web site: http://www.tahi.org/report/ kazu> As usual, KAME Project has released "stable" packages of IPv6/IPsec kazu> network code for FreeBSD 2.2.8/3.1(New!), NetBSD 1.3.3, and BSD/OS kazu> 3.1. kazu> kazu> These packages are free of charge but absolutely no warranty. They are kazu> avaiable from the following web site: kazu> kazu> http://www.kame.net/ kazu> kazu> NOTE: IF YOU GAIN ACCESS TO THIS WEB PAGE OVER IPv6, THE TURTLE WILL kazu> DANCE. kazu> kazu> --Kazu, KAME Project Thanks, Nobuo Okabe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 16 13:16:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA03001 for ipng-dist; Fri, 16 Apr 1999 12:55:05 -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 MAA02993 for ; Fri, 16 Apr 1999 12:54:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id MAA00384 for ; Fri, 16 Apr 1999 12:54:43 -0700 (PDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA16108 for ; Fri, 16 Apr 1999 12:54:44 -0700 (PDT) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Fri, 16 Apr 1999 19:23:26 GMT Message-ID: <027d01be883f$addcd2c0$634cf526@east.isi.edu> From: "Aaron Griggs" To: Cc: Subject: (IPng 7412) IPSec interop question Date: Fri, 16 Apr 1999 15:31:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am implementing IPSec in IPv6. We are ready to do some interoperability testing of our IPSec and ran across this issue. The AH document (RFC 2402) states the following: 3.3 Outbound Packet Processing ... For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. ... The SHOULD means one vendor may not interoperate with another. Why isn't this SHOULD a MUST? That would mean that any combination would work, right? I know this doesn't affect the required combos since AH is after ESP (IP_AH_ESP_DATA). "After" means it occurs closer to the IP header. However for IP_ESP_AH_DATA, why SHOULD I ignore the ESP header? You have to predict everything anyway for AH. And the ESP header is quite simple (as is AH) compared to the other IPv6 extension headers. And why say, "For simplicity of processing?" It is not necessarily simpler to ignore them if you want to authenticate the entire packet without having to worry that other security extension headers may exist after the AH header (at least on the send side). The issue here should be interoperating not simplicity. On the receive side, you can't throw away the extension headers because you many need them to do the AH authentication. Which means you may want to save the IPSec extension headers if you are not ignoring them. So since this is a SHOULD I want to try and get a consensus of what implementations do, be they IPv4 or IPv6. Are there any implementations that do not ignore IPSec headers that come after an AH header? Do most implementations just do the required IPSec combos and not worry about this? Thanks, Aaron -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 19 23:38:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA04959 for ipng-dist; Mon, 19 Apr 1999 23:36:15 -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 XAA04952 for ; Mon, 19 Apr 1999 23:36:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id XAA19448 for ; Mon, 19 Apr 1999 23:36:04 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA25397 for ; Mon, 19 Apr 1999 23:36:03 -0700 (PDT) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id PAA08536 for ; Tue, 20 Apr 1999 15:36:00 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 7419) "two hour rule" update on rfc2462 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: Jun-ichiro itojun Hagino Date: Tue, 20 Apr 1999 15:36:00 +0900 Message-ID: <8532.924590160@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to know the status for the attached email. Is it officially considered as update to RFC2462 (for future inclusion), or just went away? I think this is more safe (and simple) than what RFC2462 says... itojun ------- Forwarded Message Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with SMTP id BAA22629 for ; Mon, 9 Nov 1998 01:07:51 +0900 (JST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA08527; Sun, 8 Nov 1998 08:02:41 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id IAA13734; Sun, 8 Nov 1998 08:02:39 -0800 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA19712 for ipng-dist; Sun, 8 Nov 1998 07:58:09 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA19705 for ; Sun, 8 Nov 1998 07:58:01 -0800 (PST) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA16763 for ; Sun, 8 Nov 1998 07:58:00 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA00684 for ; Sun, 8 Nov 1998 07:58:00 -0800 (PST) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0a) with SMTP id KAA20176 for ; Sun, 8 Nov 1998 10:57:59 -0500 (EST) Received: from localhost by quarry.zk3.dec.com; (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA32473; Sun, 8 Nov 1998 10:57:59 -0500 Message-Id: <199811081557.AA32473@quarry.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng 6712) DEAD CODE in Addrconf DOS Algortim Prevention Date: Sun, 08 Nov 1998 10:57:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk X-Filter: mailagent [version 3.0 PL56] for itojun@itojun.org Folks, We need to fix this and I propose a fix below. I don't know if folks have put this in their addrconf code but I just got around to it and found a problem. Here is the algorithm for DOS at present in addrconf 5.5.3. draft-ietf-ipngwg-addrconf-v2-02.txt 1) If the received Lifetime is greater than 2 hours or greater | than StoredLifetime, update the stored Lifetime of the | corresponding address. | 2) If the StoredLifetime is less than or equal to 2 hours and the | received Lifetime is less than or equal to StoredLifetime, | ignore the prefix, unless the Router Advertisement from which | this Prefix Information option was obtained has been | authenticated (e.g., via IPSec [RFC1826]). If the Router | Advertisment was authenticated, the StoredLifetime should be | set to the Lifetime in the received option. | 3) Otherwise, reset the stored Lifetime in the corresponding | address to two hours. | Here is the scenario: Lets say Valid Lifetime from last Rtr Advertisement was 3600 (seconds) StoredLifetime = 1700 (Note seconds and less than two hours) This really represents the time remaining on the Valid Lifetime since the last Router Advertisement was received. I address that this algorithm needs a wordsmith fix too below. Rtr Adv: Valid Life = 1750 Part 1) above will permit updating the valid liftime because the second OR conditon will execute. ergo 1750 > 1700. Because the first OR condition will fail. ergo 1750 > 2HOURS, which will be FALSE. In this case Valid Lifetime will become 1750, Part 2) and Part 3) will not execute. But lets take another Rtr Adv with same Stored Life as above: Valid Lifetime = 1680 Part 1) will fail for both OR conditions and execute the second test Part 2): StoredLife <= 2HOURS && Recvd Valid Life <= Storedlife 1700 7200 1680 1700 In this case we just ignore the prefx per Part 2) unless IPsec = TRUE. In the algorithm Part 2) the second test can never be not true because if it was it would always be caught in Part 1), thus, making Part 3) DEAD CODE and not needed in the algorithm. If Stored Life was 1701....++++ Part 1) would update the Valid Lifetime and in Part 2) if Stored Life was -----........1700 the prefix would be ingored. The second part of the AND condition in Part 2) is the same test as the second OR condition in Part 1) in essence. Part 1) second OR condition: Rcvd Valid Lifetime > Stored Lifetime 1680 1700 NOW GO TO Part 2) as this FAILS: Part 2) second AND condition: Rcvd Valid Lifetime <= Stored Lifetime 1680 1700 This is true and PASSES so ignore the prefix. There is no case where Part 3) can happen and is dead code for that final else condition if you wrote the code with an if-else construct. In addition Part 2) is really not needed in the algorithm, and the prefix can be ignored in Part 1). The algorithm should be changed as follows: 1) If the received Valid Lifetime is greater than 2 hours or greater than Stored Lifetime, update the Valid Lifetime of the corresponding address, else ignore the prefix, unless the Router Advertisement from which this Prefix Information option was obtained has been authenticated (e.g., via IPSec [RFC1826]). If the Router Advertisment was authenticated, the Valid Lifetime should be set to the Valid Lifetime in the received option. Also note there is an error in the wording of the algorithm at present if the Rtr Adv was authenticated. And in Part 3) at present. We cannot set the Stored Lifetime as that is really the remaining time (ticks) for the Valid Lifetime, what has to be set is the Valid Lifetime and what implementations will have to do is take a new timestamp when a new Valid Life time is accepted. Likewise in Part 1) you cannot update the StoredLifetime but the Valid Lifetime. But this also permits implementations that are running a continuous decrement of the Valid Lifetime in a Realtime implementation (Embedded System, or Toaster using IPv6) to treat the Stored Lifetime and Valid Lifetime in this spec as synonomous semantically. This is much simpler, removes dead code, and does not change the result of the algorithm, intended by the ipng working group. We also should define StoredLifetime as follows: StoredLifetime - The StoredLifetime is the time remaining for the Valid Lifetime since it was received by a Router Advertisement. The result of this algorithm remains that a Router cannot send a Valid Lifetime that is less than the remaining lifetime for the Valid Lifetime of the Host processing ND Addrconf Router Advertisements. Which is what the present algorithm does but makes the wording so folks don't write all this dead and uneeded code from the spec. It also makes the spec clearer, hence, implementation easier and less costly. I consider this an editorial fix to addrconf and wordsmithing to make it more clear. /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 - -------------------------------------------------------------------- ------- 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 Tue Apr 20 06:45:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA05144 for ipng-dist; Tue, 20 Apr 1999 06:40:38 -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 GAA05137 for ; Tue, 20 Apr 1999 06:40:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id GAA04762 for ; Tue, 20 Apr 1999 06:40:26 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA03762 for ; Tue, 20 Apr 1999 06:40:25 -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 WAA19154 for ; Tue, 20 Apr 1999 22:40:19 +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 WAA19520 for ; Tue, 20 Apr 1999 22:40:19 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id WAA08678 for ; Tue, 20 Apr 1999 22:40:18 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 7420) Questions on A6 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94b23 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: <19990420224109U.kazu@iijlab.net> Date: Tue, 20 Apr 1999 22:41:09 +0900 X-Dispatcher: imput version 990405(IM114) Lines: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have some questions on the draft-ietf-ipngwg-dns-lookups-03.txt draft. (1) Suppose that DNS queries/answers are carried over IPv6. (ie. DNS servers and resolvers speak IPv6 only.) How can I write an A6 record for a name server of a given zone(say x.example) and a glue recode in its upper zone with A6 records? The followings are taken from Section 6.1. I would like to know how can I fill records marked with "*". ---example zone EXAMPLE. SOA (...) X.EXAMPLE. NS NSSRV.X.EXAMPLE. NSSRV.X.EXAMPLE. A6 XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (*) --- ---x.example.zone X.EXAMPLE. SOA (...) NS NSSRV NSSRV A6 XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (*) N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. --- (2) Section 6.3 says: Answer: \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. Is this correct? I guess "IP6" is missing and the followings are correct. \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. \[x123456789ABCDEF0/64].SUBNET-1.IP6.X.EXAMPLE. PTR N.X.EXAMPLE. ^^^ --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 Apr 20 18:21:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA06129 for ipng-dist; Tue, 20 Apr 1999 18:13: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 SAA06122 for ; Tue, 20 Apr 1999 18:13:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id SAA01122 for ; Tue, 20 Apr 1999 18:09:34 -0700 (PDT) Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by earth.sun.com (8.9.1/8.9.1) with SMTP id SAA08660 for ; Tue, 20 Apr 1999 18:09:34 -0700 (PDT) Received: from alderhill.wins.lbl.gov (alderhill) [128.3.9.220] by mail1.es.net with smtp (Exim 1.81 #2) id 10ZlW9-0003cZ-00; Tue, 20 Apr 1999 18:09:33 -0700 Message-Id: <4.1.19990420172735.00982790@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 20 Apr 1999 17:59:31 -0700 To: IPng List From: Bob Fink Subject: (IPng 7422) new RIR IPv6 Assignment and Allocation Policy draft (16Apr99) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is the new RIR IPv6 Assignment and Allocation Policy draft for your comments by May 3: Please send your comments just to the list you receive this message on (i.e., a simple reply). Hopefully this will minimize multiple copies being sent. I'll make sure to gather comments from the various lists for any composite reponse to the RIRs. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 21 06:41:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA06520 for ipng-dist; Wed, 21 Apr 1999 06:38: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 GAA06513 for ; Wed, 21 Apr 1999 06:38:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id GAA09448 for ; Wed, 21 Apr 1999 06:38:28 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA19198 for ; Wed, 21 Apr 1999 06:38: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 JAA05778; Wed, 21 Apr 1999 09:38:23 -0400 (EDT) Message-Id: <199904211338.JAA05778@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: (IPng 7425) I-D ACTION:draft-ietf-ipngwg-hbh-ext-csi-00.txt Date: Wed, 21 Apr 1999 09:38:22 -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 : Connection/Link Status Investigation (CSI) for IPv6 IPv6 Hop-by-Hop option and ICMPv6 messages Extension Author(s) : H. Kitamura Filename : draft-ietf-ipngwg-hbh-ext-csi-00.txt Pages : 24 Date : 20-Apr-99 This document proposes a new mechanism whereby status information is collected for nodes along both the outgoing and incoming paths. This mechanism is called 'Connection/Link Status Investigation (CSI).' In order to realize the CSI mechanism, one new IPv6 Hop-by-Hop option and three new ICMPv6 messages are proposed as extensions. The CSI mechanism is as simple as the 'ping' mechanism and is also efficient, because ideally the status information of the nodes is collected with a pair of 'request/reply' ICMPv6 messages. By using the CSI mechanism, more efficient and reliable 'traceroute' type functions can be realized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-00.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-hbh-ext-csi-00.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-hbh-ext-csi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19990420145308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-hbh-ext-csi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990420145308.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 Apr 21 09:03:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA06643 for ipng-dist; Wed, 21 Apr 1999 09:01: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 JAA06636 for ; Wed, 21 Apr 1999 09:01:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id JAA01761; Wed, 21 Apr 1999 09:01:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA22608; Wed, 21 Apr 1999 09:01:00 -0700 (PDT) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id IAA25625; Wed, 21 Apr 1999 08:59:32 -0700 (PDT) Message-Id: <3.0.5.32.19990421085854.00b9e790@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Apr 1999 08:58:54 -0700 To: narten@raleigh.ibm.com, nordmark@eng.sun.com From: Bob Hinden Subject: (IPng 7426) Request to Advance "IPv6 Jumbograms" Cc: scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IPv6 Jumbograms Author(s) : D. Borman, S. Deering, R. Hinden Filename : draft-ietf-ipngwg-jumbograms-00.txt Pages : 8 Date : 01-Mar-99 A working group last call for this document was completed on April 7, 1999. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 21 09:05:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA06661 for ipng-dist; Wed, 21 Apr 1999 09:04: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 JAA06654 for ; Wed, 21 Apr 1999 09:04:27 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id JAA08408; Wed, 21 Apr 1999 09:04:24 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA24872; Wed, 21 Apr 1999 09:04:23 -0700 (PDT) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA25819; Wed, 21 Apr 1999 09:03:41 -0700 (PDT) Message-Id: <3.0.5.32.19990421090302.03785b50@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Apr 1999 09:03:02 -0700 To: narten@raleigh.ibm.com, nordmark@eng.sun.com From: Bob Hinden Subject: (IPng 7427) Request to Advance "Router Renumbering for IPv6" Cc: scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-08.txt Pages : 30 Date : 01-Mar-99 A working group last call for this document was completed on April 7, 1999. This version of the document reflects comments received during an earlier IETF last call and IESG review. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 21 09:07:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA06679 for ipng-dist; Wed, 21 Apr 1999 09:05:59 -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 JAA06665 for ; Wed, 21 Apr 1999 09:05:47 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id JAA03985; Wed, 21 Apr 1999 09:05:45 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA25825; Wed, 21 Apr 1999 09:05:45 -0700 (PDT) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id JAA25936; Wed, 21 Apr 1999 09:05:04 -0700 (PDT) Message-Id: <3.0.5.32.19990421090422.00b90100@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Apr 1999 09:04:22 -0700 To: narten@raleigh.ibm.com, nordmark@eng.sun.com From: Bob Hinden Subject: (IPng 7428) Request to Advance "Multicast Listener Discovery (MLD) for IPv6" Cc: scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : Multicast Listener Discovery (MLD) for IPv6 Author(s) : S. Deering, B. Fenner, B. Haberman Filename : draft-ietf-ipngwg-mld-01.txt Pages : 20 Date : 01-Mar-99 A working group last call for this document was completed on April 7, 1999. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 21 10:24:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA06812 for ipng-dist; Wed, 21 Apr 1999 10:15: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 KAA06805 for ; Wed, 21 Apr 1999 10:15:29 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id KAA16519 for ; Wed, 21 Apr 1999 10:15:28 -0700 (PDT) Received: from P1 (p1.isdn.net.il [192.115.104.11]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA14789 for ; Wed, 21 Apr 1999 10:15:27 -0700 (PDT) Received: from mail pickup service by isdn.net.il with Microsoft SMTPSVC; Wed, 21 Apr 1999 20:14:03 +0300 Received: from ietf.org - 132.151.1.176 by isdn.net.il with Microsoft SMTPSVC; Wed, 21 Apr 1999 18:44:19 +0300 Received: by ietf.org (8.9.1a/8.9.1a) id JAA06446 for ietf-123-outbound.07@ietf.org; Wed, 21 Apr 1999 09:55:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05778; Wed, 21 Apr 1999 09:38:23 -0400 (EDT) Message-Id: <199904211338.JAA05778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7429) I-D ACTION:draft-ietf-ipngwg-hbh-ext-csi-00.txt Date: Wed, 21 Apr 1999 09:38:22 -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 : Connection/Link Status Investigation (CSI) for IPv6 IPv6 Hop-by-Hop option and ICMPv6 messages Extension Author(s) : H. Kitamura Filename : draft-ietf-ipngwg-hbh-ext-csi-00.txt Pages : 24 Date : 20-Apr-99 This document proposes a new mechanism whereby status information is collected for nodes along both the outgoing and incoming paths. This mechanism is called 'Connection/Link Status Investigation (CSI).' In order to realize the CSI mechanism, one new IPv6 Hop-by-Hop option and three new ICMPv6 messages are proposed as extensions. The CSI mechanism is as simple as the 'ping' mechanism and is also efficient, because ideally the status information of the nodes is collected with a pair of 'request/reply' ICMPv6 messages. By using the CSI mechanism, more efficient and reliable 'traceroute' type functions can be realized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-00.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-hbh-ext-csi-00.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-hbh-ext-csi-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19990420145308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-hbh-ext-csi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990420145308.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 Apr 22 06:21:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA07855 for ipng-dist; Thu, 22 Apr 1999 06:18: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 GAA07843 for ; Thu, 22 Apr 1999 06:18:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id GAA24208 for ; Thu, 22 Apr 1999 06:18:06 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA04736 for ; Thu, 22 Apr 1999 06:18:05 -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 JAA13621; Thu, 22 Apr 1999 09:18:01 -0400 (EDT) Message-Id: <199904221318.JAA13621@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: (IPng 7430) I-D ACTION:draft-ietf-ion-nhrp-mib-06.txt Date: Thu, 22 Apr 1999 09:18:01 -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 : Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) Author(s) : M. Greene, J. Cucchiara, J. Luciani Filename : draft-ietf-ion-nhrp-mib-06.txt Pages : 67 Date : 21-Apr-99 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Next Hop Resolution Protocol (NHRP) as defined in RFC 2332. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ion-nhrp-mib-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-ion-nhrp-mib-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-ion-nhrp-mib-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: <19990421140359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-nhrp-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-nhrp-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990421140359.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 Apr 22 06:21:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA07859 for ipng-dist; Thu, 22 Apr 1999 06:18:28 -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 GAA07851 for ; Thu, 22 Apr 1999 06:18:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id GAA25437 for ; Thu, 22 Apr 1999 06:18:13 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA04826 for ; Thu, 22 Apr 1999 06:18:14 -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 JAA13641; Thu, 22 Apr 1999 09:18:10 -0400 (EDT) Message-Id: <199904221318.JAA13641@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: (IPng 7431) I-D ACTION:draft-ietf-msdp-mibdraft--00.txt Date: Thu, 22 Apr 1999 09:18:10 -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 : Multicast Source Discovery protocol MIB Author(s) : B. Fenner, D. Thaler Filename : draft-ietf-msdp-mibdraft-00.txt Pages : 22 Date : 21-Apr-99 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) [17] speakers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msdp-mibdraft--00.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-msdp-mibdraft--00.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-msdp-mibdraft--00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19990421140421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msdp-mibdraft--00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msdp-mibdraft--00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990421140421.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 Apr 22 11:18:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA08247 for ipng-dist; Thu, 22 Apr 1999 11:13: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 LAA08240 for ; Thu, 22 Apr 1999 11:13:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id LAA17610 for ; Thu, 22 Apr 1999 11:13:22 -0700 (PDT) Received: from om2.gto.net.om (om2.gto.net.om [206.49.101.40]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA09628 for ; Thu, 22 Apr 1999 11:13:22 -0700 (PDT) Received: from default(as11-120.gto.net.om[212.72.7.120]) (606 bytes) by om2.gto.net.om via sendmail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 22 Apr 1999 22:12:39 +0400 (OMAN) (Smail-3.2.0.102 1998-Aug-2 #21 built 1998-Aug-20) Message-ID: <371F6688.639BCD3F@gto.net.om> Date: Thu, 22 Apr 1999 22:12:24 +0400 From: Peter Dawson X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: IPng Subject: (IPng 7432) IDRP for IPv6 X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi need some pointers / info on this; Would deployment of IDRP be better then BGP in the IPv6 envoirnement ? thanks /pete -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 22 18:08:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA08807 for ipng-dist; Thu, 22 Apr 1999 17:55: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 RAA08799 for ; Thu, 22 Apr 1999 17:55:23 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id RAA14481 for ; Thu, 22 Apr 1999 17:55:23 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA20745 for ; Thu, 22 Apr 1999 17:55:23 -0700 (PDT) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA28286; Thu, 22 Apr 1999 17:52:26 -0700 (PDT) Message-Id: <3.0.5.32.19990422175138.009b3810@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 22 Apr 1999 17:51:38 -0700 To: Peter Dawson From: Bob Hinden Subject: (IPng 7433) Re: IDRP for IPv6 Cc: IPng In-Reply-To: <371F6688.639BCD3F@gto.net.om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, >need some pointers / info on this; > >Would deployment of IDRP be better then BGP in >the IPv6 envoirnement ? As far as I can tell the ISP's are completely focused on BGP and it would be very difficult for them to consider deploying another inter-domain routing protocol. I also suspect that BGP now has more functionality than IDRP. It has been evolving while IDRP has not. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Apr 24 08:41:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA09768 for ipng-dist; Sat, 24 Apr 1999 08:38:52 -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 IAA09761 for ; Sat, 24 Apr 1999 08:38:43 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id IAA27467 for ; Sat, 24 Apr 1999 08:38:42 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA19631 for ; Sat, 24 Apr 1999 08:38: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 RAA13742; Sat, 24 Apr 1999 17:38:39 +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 RAA14288; Sat, 24 Apr 1999 17:38:39 +0200 (MET DST) Message-Id: <199904241538.RAA14288@givry.inria.fr> From: Francis Dupont To: "Aaron Griggs" cc: ipng@sunroof.eng.sun.com Subject: (IPng 7435) Re: IPSec interop question In-reply-to: Your message of Fri, 16 Apr 1999 15:31:05 EDT. <027d01be883f$addcd2c0$634cf526@east.isi.edu> Date: Sat, 24 Apr 1999 17:38:38 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The AH document (RFC 2402) states the following: 3.3 Outbound Packet Processing ... For simplicity of processing, each IPsec header SHOULD ignore the existence (i.e., not zero the contents or try to predict the contents) of IPsec headers to be applied later. ... The SHOULD means one vendor may not interoperate with another. => I agree, SHOULD doesn't specify somwthing which can work... I interpret "to be applied later" as to be inserted near the front of the packet later (then the issue is for IP_ESP_AH_DATA, my current code refuses this case :-). Francis.Dupont@inria.fr PS: I am not on the ipsec list then I have deleted it from the cc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 28 11:02:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA12549 for ipng-dist; Wed, 28 Apr 1999 10:58:11 -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 KAA12542 for ; Wed, 28 Apr 1999 10:58:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id KAA02703 for ; Wed, 28 Apr 1999 10:58:01 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA15293 for ; Wed, 28 Apr 1999 10:58:00 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Wed, 28 Apr 1999 10:57:47 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014514F5C@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 7439) simple source address selection Date: Wed, 28 Apr 1999 10:57:42 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm submitting a draft describing a simple algorithm for source address selection. This is based on an email exchange on the implementor's list back in February. ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-simple-src addr-00.txt Any comments are welcome. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 28 14:14:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA12780 for ipng-dist; Wed, 28 Apr 1999 14:08:35 -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 OAA12773 for ; Wed, 28 Apr 1999 14:08:25 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id OAA18301 for ; Wed, 28 Apr 1999 14:08:21 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id OAA11437 for ; Wed, 28 Apr 1999 14:08:21 -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 OAA26878; Wed, 28 Apr 1999 14:05:02 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014514F5C@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014514F5C@RED-MSG-50> Date: Wed, 28 Apr 1999 14:05:03 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 7440) Re: simple source address selection Cc: "'IPng List'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:57 AM -0700 4/28/99, Richard Draves wrote: >I'm submitting a draft describing a simple algorithm for source address >selection. This is based on an email exchange on the implementor's list back >in February. > >ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-simple-src >addr-00.txt > >Any comments are welcome. OK, here are some comments: >3. Introduction > > The IPv6 addressing architecture [3] allows multiple addresses to be > assigned to interfaces. These addresses may have different > reachability scopes (link-local, site-local, or global). Some of the assignable addresses are multicast addresses, which have a wider range of possible scope values. > Furthermore, addresses assigned via IPv6's auto-configuration > mechanisms [4] may be "preferred" or "deprecated". Question: does DHCPv6 support the preferred/deprecated attribute for addresses assigned via DHCP? > This document does not specify a "strong host" or "weak host" model > for source address selection [5, section 3.3.4.2]. It merely assumes > that the implementation has a set of candidate source addresses from > which one must be chosen. If the implementation uses the strong host > model, this MAY be the set of addresses assigned to the outgoing > interface that will be used for the destination address. If the > implementation uses the weak host model, this MAY be the set of all > addresses assigned to the node's interfaces. You may want to observe that, in the case of a multicast destination, one MUST use the "strong" host model, i.e., the source address must belong to the originating interface (or, more accurately, to an interface attached to the same link as the originating interface). This is a requirement of most current multicast routing protocols. Although I have long been an advocate of the strong host model for unicast as well, I finally conceded the need to allow use of a source address that belongs to a different interface than the originating one, for unusual circumstances like responding to a ping of a unidirectional interface. However, I think the source-address selection rules should cause the strong host behavior to occur whenever possible. Thus, I would advocate a Rule 0, preceding your other rules, that says if SA belongs to the outgoing interface and SB does not, you MUST use choose SA. So, for example, if a node specifies that a packet be sent out interface x, destined to an address that belongs to its own, different, interface y, it should carry one of x's addresses as a source address, which contradicts your Rule 1. Note: this example can occur only in the case were the upper layer has explicitly specified the outgoing interface, overriding the host routing layer's inclination to send the packet out -- and then looped back from -- the interface belonging to the destination address Another issue with your language above regarding the weak model -- "this MAY be the set of all addresses assigned to the node's interfaces" -- is that, when sending a packet to a less-than-global destination, there may be some of a node's unicast address that MUST NOT be used a source address under any circumstances. For example, when sending a packet to a site- local destination via interface x, you MUST NOT use a site-local or link-local source address that belongs to an interface y that is not attached to the same site as interface x. >4. Source Address Selection I know this is specified elsewhere, but you might want to throw a sentence in somewhere, reminding people that multicast addresses and anycast addresses MUST NEVER be used as source addresses. This is sort of a "Rule -1", preceding all others, that takes those kinds of addresses out of the pool of candidate source addresses. > Addresses that are manually configured (or otherwise not auto- > configured according to [4]), we treat as having "preferred" > configuration status. The answer to my earlier question about DHCPv6 may require a slight rewording here. > Rule 1: If one of the source addresses is equal to the destination > address, an implementation MUST choose that source address. This rule (and probably all of them) needs to be qualified with language about scopes and interfaces. For example, if I am sending a packet to destination site-local address A in attached site S1, I can use A as a source address ONLY IF A is one my addresses on an interface attached to site S1. If A happens to be one of my addresses only on an interface that is NOT attached to S1, it is NOT a candidate for use as source address in that packet. > scope. This mapping implicitly conflates unicast site boundaries and > multicast site boundaries. Nice word, "conflate". I had to look it up. :-) >7. Other Format Prefixes > > This document does not specify source address selection in the > presence of NSAP addresses, IPX addresses, or addresses with as-yet- > undefined format prefixes. Rather than leaving it undefined, I suggest that we say that all address prefixes other than link-local, site-local, and multicast be interpreted as global-scope unicast. If it turns out that that is the usage they eventually take on (which I think is the most likely usage), then all the fielded equipment will do the right thing without any modification. If, on the other hand, those currently-unused prefixes end up being assigned different semantics, part of their specification can be how they fit into the source-selection rules. End of comments. 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 Apr 28 21:58:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA13117 for ipng-dist; Wed, 28 Apr 1999 21:46:51 -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 VAA13110 for ; Wed, 28 Apr 1999 21:46:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id VAA22988 for ; Wed, 28 Apr 1999 21:46:42 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA26747 for ; Wed, 28 Apr 1999 21:46:43 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 28 Apr 1999 21:46:35 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014514F6F@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: "'IPng List'" Subject: (IPng 7442) RE: simple source address selection Date: Wed, 28 Apr 1999 21:46:34 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The IPv6 addressing architecture [3] allows multiple > addresses to be > > assigned to interfaces. These addresses may have different > > reachability scopes (link-local, site-local, or global). > > Some of the assignable addresses are multicast addresses, which have a > wider range of possible scope values. Yes, I guess I should say unicast to clarify. > Question: does DHCPv6 support the preferred/deprecated attribute for > addresses assigned via DHCP? Turns out the answer is yes, so I will need to update this and the other reference. > You may want to observe that, in the case of a multicast destination, > one MUST use the "strong" host model, i.e., the source address must > belong to the originating interface (or, more accurately, to an > interface attached to the same link as the originating interface). > This is a requirement of most current multicast routing protocols. OK... > Although I have long been an advocate of the strong host model for > unicast as well, I finally conceded the need to allow use of a source > address that belongs to a different interface than the > originating one, > for unusual circumstances like responding to a ping of a > unidirectional > interface. However, I think the source-address selection rules should > cause the strong host behavior to occur whenever possible. Thus, I > would advocate a Rule 0, preceding your other rules, that says if SA > belongs to the outgoing interface and SB does not, you MUST use > choose SA. I disagree with this. I implemented strong host model in MSR IPv6 (don't support unidirectional links, sorry) - the only way we'll send a packet with a mismatched source address and outgoing interface is if an application/upper layer specifies a source address on a forwarding interface. However I don't see a reason to force this choice on implementors. > So, for example, if a node specifies that a packet be sent > out interface > x, destined to an address that belongs to its own, different, > interface y, > it should carry one of x's addresses as a source address, > which contradicts > your Rule 1. Note: this example can occur only in the case > were the upper > layer has explicitly specified the outgoing interface, > overriding the host > routing layer's inclination to send the packet out -- and > then looped back > from -- the interface belonging to the destination address I don't see a contradiction here. For a strong host model implementation, the set of candidate source addresses will be those addresses assigned to interface x. So the algorithm will not use y's address as the source, despite rule 1, because it's not in the set of candidates. For a weak host model implementation, y's address will be in the set of candidate source addresses and it will be chosen as the source address, but that's OK for weak model. > Another issue with your language above regarding the weak > model -- "this > MAY be the set of all addresses assigned to the nodeís > interfaces" -- is > that, when sending a packet to a less-than-global > destination, there may > be some of a node's unicast address that MUST NOT be used a > source address > under any circumstances. For example, when sending a packet > to a site- > local destination via interface x, you MUST NOT use a site-local or > link-local source address that belongs to an interface y that is not > attached to the same site as interface x. Yes, I need to clean this up for destination addresses of less than global scope. > >4. Source Address Selection > > I know this is specified elsewhere, but you might want to throw a > sentence in somewhere, reminding people that multicast addresses and > anycast addresses MUST NEVER be used as source addresses. > This is sort > of a "Rule -1", preceding all others, that takes those kinds > of addresses > out of the pool of candidate source addresses. OK > > Addresses that are manually configured (or otherwise not auto- > > configured according to [4]), we treat as having "preferred" > > configuration status. > > The answer to my earlier question about DHCPv6 may require a slight > rewording here. Yup > > Rule 1: If one of the source addresses is equal to the destination > > address, an implementation MUST choose that source address. > > This rule (and probably all of them) needs to be qualified > with language > about scopes and interfaces. For example, if I am sending a packet to > destination site-local address A in attached site S1, I can use A as a > source address ONLY IF A is one my addresses on an interface attached > to site S1. If A happens to be one of my addresses only on > an interface > that is NOT attached to S1, it is NOT a candidate for use as source > address in that packet. Rather than qualify all the rules, isn't it simpler just to be clearer about the set of candidate source addresses? > >7. Other Format Prefixes > > > > This document does not specify source address selection in the > > presence of NSAP addresses, IPX addresses, or addresses > with as-yet- > > undefined format prefixes. > > Rather than leaving it undefined, I suggest that we say that > all address > prefixes other than link-local, site-local, and multicast be > interpreted > as global-scope unicast. If it turns out that that is the usage they > eventually take on (which I think is the most likely usage), then all > the fielded equipment will do the right thing without any > modification. > If, on the other hand, those currently-unused prefixes end up being > assigned different semantics, part of their specification can be how > they fit into the source-selection rules. OK Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 29 01:38:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA13309 for ipng-dist; Thu, 29 Apr 1999 01:35: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 BAA13302 for ; Thu, 29 Apr 1999 01:35:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id BAA08006 for ; Thu, 29 Apr 1999 01:35:35 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA29104 for ; Thu, 29 Apr 1999 01:35:33 -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 JAA97214 for ; Thu, 29 Apr 1999 09:35:11 +0100 Received: from hursley.ibm.com (9-20-31-242.dhcp.hursley.ibm.com [9.20.31.242]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id JAA26982 for ; Thu, 29 Apr 1999 09:34:51 +0100 (BST) Message-ID: <37281853.759CB060@hursley.ibm.com> Date: Thu, 29 Apr 1999 09:29:07 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "'IPng List'" Subject: (IPng 7445) Re: simple source address selection References: <4D0A23B3F74DD111ACCD00805F31D81014514F5C@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, I'm not 100% sure about this limitation of scope: > 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. It really is a trivial extension to your draft to add a recommended rule for choosing the pair - i.e. run your rules for choosing the source across all destination addresses, and pick the final pair with 1. the smallest scope and 2. the longest match. I have a vested interest in this as it would take the special case out of 6to4, but I think it's of general utility. Brian Richard Draves wrote: > > I'm submitting a draft describing a simple algorithm for source address > selection. This is based on an email exchange on the implementor's list back > in February. > > ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-simple-src > addr-00.txt > > Any comments are welcome. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 08:30:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA13498 for ipng-dist; Thu, 29 Apr 1999 08:26: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 IAA13491 for ; Thu, 29 Apr 1999 08:26:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id IAA09960 for ; Thu, 29 Apr 1999 08:26:30 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA09006 for ; Thu, 29 Apr 1999 08:26:30 -0700 (PDT) Received: from [171.69.116.90] (sj-dial-4-107.cisco.com [171.68.181.236]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA21118 for ; Thu, 29 Apr 1999 08:26:25 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: deering@postoffice Message-Id: Date: Thu, 29 Apr 1999 08:26:22 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 7446) FYI: new mailing list for generic MIB discussion Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is a message that was sent to the working group chairs which is relevant for anyone working on MIBs for IPv6 components, and for those of us concerned with ensuring that MIBs of all sorts are IPv6-ready. Steve -------- Date: Thu, 29 Apr 99 16:02:25 DST From: "Bert Wijnen" To: wgchairs@ietf.org cc: mibs@ops.ietf.org Subject: mibs@ops.ietf.org for generic MIB related discussions Chairs, we have setup a new mailing list in the Operations and Management area. This list is to discuss generic/general MIB issues. It can also be used to ask generic/general MIB questions and uestion about SMI usage. We would like that you as WG chairs make sure that all editors/authors who work on MIB or MIB-related documents subscribe to the mibs mailing list. To do so, one must send an email to mibs-request@ops.ietf.org with the word subscribe in the body of the email. The archives for this mailing list: ftp://ftp.psg.com/pub/lists/mibs* The O&M and Internet ADs have formed a small team to investigate how IP addresses can be defined/used in MIBs such that the MIB can be used in both IPv4 and IPv6 environments. Many MIBs currently use IpAddress SYNTAX which is IPv4 specific andmay cause trouble in IPv6 environments. The team will collect input via the mibs mailing list. It will then investigate and develop recommendations for a common solution. The results of the team will be documented in an I-D and they will be discussed on the mibs mailing list. So this is the first activity you will see on that mailing list. There will also be generic announcements on the mibs mailinglist. For example we will announce there when we have new MIB boilerplate text or new guidelines for the MIB security section etc. Thanks, Bert and Randy. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Apr 29 10:21:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA13632 for ipng-dist; Thu, 29 Apr 1999 10:16: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 KAA13625 for ; Thu, 29 Apr 1999 10:16:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id KAA00332 for ; Thu, 29 Apr 1999 10:16:35 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA22518 for ; Thu, 29 Apr 1999 10:16:35 -0700 (PDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 29 Apr 1999 10:16:18 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014514F76@RED-MSG-50> From: Richard Draves To: "'Brian E Carpenter'" Cc: "'IPng List'" Subject: (IPng 7447) Re: simple source address selection Date: Thu, 29 Apr 1999 10:16:13 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm not 100% sure about this limitation of scope: > > > 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. > > It really is a trivial extension to your draft to add a recommended > rule for choosing the pair - i.e. run your rules for choosing the > source across all destination addresses, and pick the final pair > with 1. the smallest scope and 2. the longest match. Yes, we could add such an extension but I don't think it would be useful. MSR IPv6 is never in a situation where it needs to pick a destination address. The destination address is always specified by an application. I believe this is also true of other implementations. So to support this would be a pretty major architectural change to how applications & upper layers interact with the IP layer. I would want a solution to address other issues, like if one dst/src pair doesn't work then being able to switch to another dst/src pair. It's certainly worth thinking about (and I am giving it thought), but it's so much more complicated that it should be a separate proposal. > I have a vested interest in this as it would take the special case > out of 6to4, but I think it's of general utility. I don't see why 6to4 needs a special case for destination/source address selection. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 29 11:07:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA13696 for ipng-dist; Thu, 29 Apr 1999 11:03:02 -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 LAA13689 for ; Thu, 29 Apr 1999 11:02:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id LAA20494 for ; Thu, 29 Apr 1999 11:02:49 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA23611 for ; Thu, 29 Apr 1999 11:02:50 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 29 Apr 1999 11:02:40 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014514F7A@RED-MSG-50> From: Richard Draves To: "'IPng List'" Cc: "'Kazu Yamamoto'" Subject: (IPng 7448) RE: simple source address selection Date: Thu, 29 Apr 1999 11:02:38 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > http://www.isoc.org/inet98/proceedings/6b/6b_3.htm Kazu sent me a pointer to the KAME source address selection algorithm. (See section 3.1, and particularly 3.1.5, in the above document.) I would summarize the main differences between the KAME algorithm and the algorithm I proposed as follows: 1. To handle the loopback address, it uses a node-local scope in addition to link-local, site-local, and global scope. 2. It's much stricter - it will never choose a deprecated source address, or a source address with scope different than the destination address. 3. There's no use of longest-matching-prefix as a tie-breaker. 4. It's sort of a mix between weak model and strong model - it first tries to pick a suitable source address assigned to the outgoing interface, but if there isn't one available it will consider source addresses assigned to other interfaces. (The details imply that KAME assumes that all interfaces on a node will belong to the same site.) 5. Not clear how v4-compatible addresses or other format prefixes are handled. Responding to this: I need to add something for loopback to my draft. I think it is a mistake to completely preclude the choice of a deprecated source address or a source address of scope different than the destination. For example, suppose I'm using a machine trying to diagnose why it didn't get configured with a site-local address. The machine does have link-local and global addresses. I try to telnet over to look at another machine in my site, but I only remember its site-local address. If the telnet fails, I'd be pretty peeved. Surely the implementation should just pick the global address for the source address. And I can imagine similar scenarios where I'm trying to figure out why a machine only has deprecated addresses. I think longest-matching-prefix is a good tiebreaker and it should be encouraged. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 29 11:33:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA13750 for ipng-dist; Thu, 29 Apr 1999 11:30:05 -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 LAA13743 for ; Thu, 29 Apr 1999 11:29:56 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id LAA28068 for ; Thu, 29 Apr 1999 11:29:53 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA11576 for ; Thu, 29 Apr 1999 11:29:55 -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 LAA08683; Thu, 29 Apr 1999 11:29:53 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014514F6F@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014514F6F@RED-MSG-50> Date: Thu, 29 Apr 1999 11:29:52 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 7449) Re: simple source address selection Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:46 PM -0700 4/28/99, Richard Draves wrote: >At 2:05 PM -0700 4/28/99, Steve Deering wrote: > > Although I have long been an advocate of the strong host model for > > unicast as well, I finally conceded the need to allow use of a source > > address that belongs to a different interface than the originating > > one, for unusual circumstances like responding to a ping of a > > unidirectional interface. However, I think the source-address > > selection rules should cause the strong host behavior to occur > > whenever possible. Thus, I would advocate a Rule 0, preceding your > > other rules, that says if SA belongs to the outgoing interface and > > SB does not, you MUST choose SA. > >I disagree with this. I implemented strong host model in MSR IPv6 (don't >support unidirectional links, sorry) - the only way we'll send a packet >with a mismatched source address and outgoing interface is if an >application/upper layer specifies a source address on a forwarding >interface. However I don't see a reason to force this choice on >implementors. I guess I'm advocating a new, "semi-strong" (or "semi-weak"?) host model. The historical debates on this topic always polarized into two positions: strong: When originating a packet from interface x, the source address MUST be one that belongs to interface x. weak: Any of a host's addresses may be used as the source address of packets originated by that host, regardless of the originating interface. The reason the Host Requirements working group could never converge on one model or the other is that both have serious problems: - The weak model permits -- and makes quite common -- behavior that defeats ICMP Redirect and can cause tripling of the traffic load on the first-hop link (each original packet, a redirected copy of each original packet, and, if not rate-controlled, an ICMP Redirect message in response to each original packet). - The strong model forbids behavior that is necessary in some circumstances, such as responding to pings of, or TCP connections to, receive-only interfaces. It also requires a more complicated host routing layer implementation, and one that is different from that of a router (which irked the Unix folks who built systems that were intended to perform either role). Rather than forcing a choice between those two problematic positions, I'm suggesting an intermediate model: semi-strong: When originating a packet from interface x, the source address SHOULD be one that belongs to interface x. The IETF definition of "SHOULD" is "do this unless you have a good reason to do otherwise". An example of a good reason is that the upper-layer protocol requests transmission of a packet out interface x with a source address belonging to interface y. Another good reason is that the upper- layer protocol requests transmission with a source address that belongs to a receive-only interface. A somewhat less good -- but still grudgingly permitted :) -- reason is the unwillingness of the implementor to do the more sophisticated host routing implementation that would ensure that a packet went out the interface corresponding to its source address in the case where the upper-layer specifies the source address but does not care which interface it goes out. Now in the case covered by your draft, the upper-layer does not care what the source address is, so there is no overriding reason to prevent the source address from being one that belongs to the outgoing interface. If hosts follow this approach, then except when there is an overriding reason to do otherwise, they will behave in a way that makes Redirect work properly. --> I'd appreciate comments on this approach from anyone, especially implementors. > > So, for example, if a node specifies that a packet be sent > > out interface x, destined to an address that belongs to its own, > > different, interface y, it should carry one of x's addresses as > > a source address, which contradicts your Rule 1. > >I don't see a contradiction here. > >For a strong host model implementation, the set of candidate source >addresses will be those addresses assigned to interface x. So the algorithm >will not use y's address as the source, despite rule 1, because it's not in >the set of candidates. > >For a weak host model implementation, y's address will be in the set of >candidate source addresses and it will be chosen as the source address, but >that's OK for weak model. You are correct that the issue does not arise in the strong-model case. It was the weak-model implementation that I was concerned about: I claimed (my opinion) that the packet "should carry one of x's addresses as a source address", but your Rule 1 would prevent that from happening. This comes back to the weak vs. semi-strong issue: the weak model says any source address is OK and there is no reason to prefer one source address over another. The semi-strong model says any source address is OK, but when given a choice, choose one that belongs to the originating interface. > > This rule (and probably all of them) needs to be qualified > > with language about scopes and interfaces... > >Rather than qualify all the rules, isn't it simpler just to be clearer about >the set of candidate source addresses? Yes, that would be the better fix. 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 Apr 29 14:32:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA14051 for ipng-dist; Thu, 29 Apr 1999 14:27: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 OAA14044 for ; Thu, 29 Apr 1999 14:26:54 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail3.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id OAA02960 for ; Thu, 29 Apr 1999 14:26:53 -0700 (PDT) Received: from hotmail.com (law2-f7.hotmail.com [216.32.181.7]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA09516 for ; Thu, 29 Apr 1999 14:26:26 -0700 (PDT) Received: (qmail 89177 invoked by uid 0); 29 Apr 1999 21:25:58 -0000 Message-ID: <19990429212558.89176.qmail@hotmail.com> Received: from 199.106.86.2 by www.hotmail.com with HTTP; Thu, 29 Apr 1999 14:25:58 PDT X-Originating-IP: [199.106.86.2] From: "Randall Shimizu" To: ipng@sunroof.eng.sun.com Subject: (IPng 7450) Mail archives (Newer archives) Date: Thu, 29 Apr 1999 14:25:58 PDT Mime-Version: 1.0 Content-type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just subscribed to this mailing list and I noticed that the mail archives are old. Is there a more current mail archive that lists the mail on a weekly or daily basis? Here is ipng discussion group (http://www.dejanews.com/~ipng/) that I have just created. _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.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 Apr 29 16:33:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA14312 for ipng-dist; Thu, 29 Apr 1999 16:28: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 QAA14305 for ; Thu, 29 Apr 1999 16:27:57 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id QAA13504 for ; Thu, 29 Apr 1999 16:27:56 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA26895 for ; Thu, 29 Apr 1999 16:27:56 -0700 (PDT) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id QAA06009; Thu, 29 Apr 1999 16:27:52 -0700 (PDT) Message-Id: <3.0.5.32.19990429162656.007d96e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 29 Apr 1999 16:26:56 -0700 To: "Randall Shimizu" From: Bob Hinden Subject: (IPng 7451) Re: Mail archives (Newer archives) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <19990429212558.89176.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randall, >I just subscribed to this mailing list and I noticed that the mail >archives are old. Is there a more current mail archive that lists the >mail on a weekly or daily basis? Here is ipng discussion group >(http://www.dejanews.com/~ipng/) that I have just created. Looks like there is a problem with the archives this calender year. I am working to fix that. There should also be archives at ftp.ietf.org. The ipng@sunroof.eng.sun.com list is the official IPng working group mailing list. Discussions relating to the working group should held here and not elsewhere. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 29 17:44:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA14390 for ipng-dist; Thu, 29 Apr 1999 17:14:42 -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 RAA14383 for ; Thu, 29 Apr 1999 17:14:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id RAA24545 for ; Thu, 29 Apr 1999 17:14:16 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA25290 for ; Thu, 29 Apr 1999 17:14:17 -0700 (PDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 29 Apr 1999 17:14:05 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014514F88@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7452) Re: simple source address selection Date: Thu, 29 Apr 1999 17:14:04 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I guess I'm advocating a new, "semi-strong" (or "semi-weak"?) > host model. > The historical debates on this topic always polarized into > two positions: > > strong: When originating a packet from interface x, the source > address MUST be one that belongs to interface x. > > weak: Any of a host's addresses may be used as the source > address of packets originated by that host, regardless > of the originating interface. > > The reason the Host Requirements working group could never converge > on one model or the other is that both have serious problems: > > - The weak model permits -- and makes quite common -- behavior > that defeats ICMP Redirect and can cause tripling of the > traffic load on the first-hop link (each original packet, > a redirected copy of each original packet, and, if not > rate-controlled, an ICMP Redirect message in response to > each original packet). > > - The strong model forbids behavior that is necessary in some > circumstances, such as responding to pings of, or TCP > connections to, receive-only interfaces. It also requires > a more complicated host routing layer implementation, and one > that is different from that of a router (which irked the Unix > folks who built systems that were intended to perform either > role). I'm trying to guess what this extra complexity is... Do you mean, because the routing module has to support two kinds of lookups? - given a dest address, give me outgoing interface & neighbor - given a dest address & outgoing interface, give me a neighbor > Rather than forcing a choice between those two problematic positions, > I'm suggesting an intermediate model: > > semi-strong: When originating a packet from interface x, the > source address SHOULD be one that belongs to > interface x. > > The IETF definition of "SHOULD" is "do this unless you have a > good reason > to do otherwise". An example of a good reason is that the upper-layer > protocol requests transmission of a packet out interface x > with a source > address belonging to interface y. Another good reason is > that the upper- > layer protocol requests transmission with a source address > that belongs > to a receive-only interface. > > A somewhat less good -- but still grudgingly permitted :) -- reason is > the unwillingness of the implementor to do the more sophisticated host > routing implementation that would ensure that a packet went out the > interface corresponding to its source address in the case where the > upper-layer specifies the source address but does not care which > interface it goes out. > > Now in the case covered by your draft, the upper-layer does not care > what the source address is, so there is no overriding reason > to prevent > the source address from being one that belongs to the > outgoing interface. This is getting at two different cases: a. The application/upper-layer has specified a source address. Should the implementation be allowed to choose a different outgoing interface? b. The application/upper-layer has not specified a source address. Should the implementation be allowed to choose a source address not assigned to the outgoing interface? > --> I'd appreciate comments on this approach from anyone, especially > implementors. I had the impression that since the historical debate was acrimonious & unresolved, it would be easiest to get an standard approved for IPv6 source address selection without trying to resolve the historical debate. But I'd like to hear from others about this issue. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 29 18:51:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA14517 for ipng-dist; Thu, 29 Apr 1999 18:43: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 SAA14508 for ; Thu, 29 Apr 1999 18:43:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id SAA10825 for ; Thu, 29 Apr 1999 18:43:08 -0700 (PDT) Received: from hotmail.com (law2-f20.hotmail.com [216.32.181.20]) by earth.sun.com (8.9.1/8.9.1) with SMTP id SAA11649 for ; Thu, 29 Apr 1999 18:43:09 -0700 (PDT) Received: (qmail 76845 invoked by uid 0); 30 Apr 1999 01:43:09 -0000 Message-ID: <19990430014309.76844.qmail@hotmail.com> Received: from 199.106.86.2 by www.hotmail.com with HTTP; Thu, 29 Apr 1999 18:43:09 PDT X-Originating-IP: [199.106.86.2] From: "Randall Shimizu" To: ipng@sunroof.eng.sun.com Subject: (IPng 7453) ipv6 precedence bit: qos implementations Date: Thu, 29 Apr 1999 18:43:09 PDT Mime-Version: 1.0 Content-type: text/plain; format=flowed; Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know how various networking companies are planning to integrate the precedence bit? For example how does Cisco plan to integrate it with other qos mechanisms such as tag switching and diff-serv? _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.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 Apr 29 19:04:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA14604 for ipng-dist; Thu, 29 Apr 1999 19:00:46 -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 TAA14597 for ; Thu, 29 Apr 1999 19:00:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id TAA12662 for ; Thu, 29 Apr 1999 19:00:33 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA20449 for ; Thu, 29 Apr 1999 19:00:35 -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 TAA22155; Thu, 29 Apr 1999 19:00:34 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014514F88@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014514F88@RED-MSG-50> Date: Thu, 29 Apr 1999 19:00:34 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 7454) Re: simple source address selection Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:14 PM -0700 4/29/99, Richard Draves wrote: > > - The strong model forbids behavior that is necessary in some > > circumstances, such as responding to pings of, or TCP > > connections to, receive-only interfaces. It also requires > > a more complicated host routing layer implementation, and one > > that is different from that of a router (which irked the Unix > > folks who built systems that were intended to perform either > > role). > >I'm trying to guess what this extra complexity is... >Do you mean, because the routing module has to support two kinds of lookups? >- given a dest address, give me outgoing interface & neighbor >- given a dest address & outgoing interface, give me a neighbor Basically, yes. Routers (and "weak" hosts) always use the first kind of lookup. "Strong" hosts use the first kind of lookup when the upper-layer does not specify the source address, and the second kind of lookup when upper-layer does specify the source address (which implies an outgoing interface, in a strong host). You could view the second lookup as taking a "slice" of the host's routing table (route cache, whatever) that includes only those routes that point out a given interface. (Now, if the API to your IP layer includes a way for the upper-layer to explicitly demand egress from a particular interface -- which I think it should -- then even if your node is acting as a router or a weak host, it really ought to be capable of doing lookups in a interface-specific slice of the routing table. But that's not something a traditional BSD Unix implementation of IP can do.) > > A somewhat less good -- but still grudgingly permitted :) -- reason is > > the unwillingness of the implementor to do the more sophisticated host > > routing implementation that would ensure that a packet went out the > > interface corresponding to its source address in the case where the > > upper-layer specifies the source address but does not care which > > interface it goes out. > > > > Now in the case covered by your draft, the upper-layer does not care > > what the source address is, so there is no overriding reason > > to prevent > > the source address from being one that belongs to the > > outgoing interface. > >This is getting at two different cases: >a. The application/upper-layer has specified a source address. Should the >implementation be allowed to choose a different outgoing interface? >b. The application/upper-layer has not specified a source address. Should >the implementation be allowed to choose a source address not assigned to the >outgoing interface? Yes, those are the two distinct cases that I was referring in the two distinct paragraphs you quoted above. I was proposing answers to each of those two cases (of which only case (b) is the topic of your new draft). > > --> I'd appreciate comments on this approach from anyone, especially > > implementors. > >I had the impression that since the historical debate was acrimonious & >unresolved, it would be easiest to get an standard approved for IPv6 source >address selection without trying to resolve the historical debate. I wouldn't characterize it as "acrimonious" -- more a recognition that there are trade-offs, neither of which is perfect, and different folks choose different poison. As one who was an avid advocate for one side of that debate, and who has since moderated his view, I thought maybe others could be persuaded to a compromise approach (what I called the semi-strong model). I think it is desirable to settle on a single model, if possible, because I think interoperation, management, and problem diagnosis are greatly facilitated by having nodes behave in a consistent, predictable manner. But if it is not possible to reach consensus on this (and the history of this topic does not give me great hope), then so be it -- we'll manage to cope just like we have with IPv4. The world will just be that much more complicated than it has to be. 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 Apr 29 23:30:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA14780 for ipng-dist; Thu, 29 Apr 1999 22:39:27 -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 WAA14769 for ; Thu, 29 Apr 1999 22:37:22 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.4) with ESMTP id WAA03779 for ; Thu, 29 Apr 1999 22:37:03 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id WAA14915 for ; Thu, 29 Apr 1999 22:37:00 -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 FA05676; Fri, 30 Apr 1999 15:36:42 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Steve Deering Cc: Richard Draves , ipng@sunroof.eng.sun.com Subject: (IPng 7455) Re: simple source address selection In-Reply-To: Your message of "Thu, 29 Apr 1999 11:29:52 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Apr 1999 15:36:40 +1000 Message-Id: <18991.925450600@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 29 Apr 1999 11:29:52 -0700 From: Steve Deering Message-ID: | An example of a good reason is that the upper-layer | protocol requests transmission of a packet out interface x with a source | address belonging to interface y. Another good reason is that the upper- | layer protocol requests transmission with a source address that belongs | to a receive-only interface. Another scenario to consider is where a multi-homed host (not a router) is connected to two links, between which there is no routing (either temporarily, or permanently). Consider the case where the router that should connect the links is temporarily out of order. A host on either link (directly, or at some remote distance) may happen to have a connection to the multi-homed host using the address that is on the "far side" of the host (in terms of the link via which packets arrive). Since there is no router available to connect the two links, the only way they can be delivered is to the "wrong" interface (which can trivially achieved via a host route at appropriate places). Similarly, the only way replies can be sent is out the "wrong" interface. Obviously this doesn't work if the host implements strict strong model (but much about the way the internet runs makes that a very rare host). | A somewhat less good -- but still grudgingly permitted :) -- reason is | the unwillingness of the implementor to do the more sophisticated host | routing implementation that would ensure that a packet went out the | interface corresponding to its source address in the case where the | upper-layer specifies the source address but does not care which | interface it goes out. Or that the host implementor has done the work to participate enough in the routing protocols and policies that it knows the best route to the destination (and would ignore an ICMP even if one were sent perhaps). | The semi-strong model says any source address is | OK, but when given a choice, choose one that belongs to the originating | interface. This seems right to me. It also seems to be in conformance with what most implementations actually do (for IPv4 anyway). There may be something which actually implements "randomly pick a source address" (true weak model), but if there is, I have not seen it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 30 03:58:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA15000 for ipng-dist; Fri, 30 Apr 1999 03:54:45 -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 DAA14993 for ; Fri, 30 Apr 1999 03:54:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.4) with ESMTP id DAA23428 for ; Fri, 30 Apr 1999 03:54:35 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA23750 for ; Fri, 30 Apr 1999 03:54:33 -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 LAA17890 for ; Fri, 30 Apr 1999 11:54:01 +0100 Received: from hursley.ibm.com (9-20-31-242.dhcp.hursley.ibm.com [9.20.31.242]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA25742 for ; Fri, 30 Apr 1999 11:53:33 +0100 (BST) Message-ID: <37298B7E.D5D301D8@hursley.ibm.com> Date: Fri, 30 Apr 1999 11:52:46 +0100 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: (IPng 7456) Re: ipv6 precedence bit: qos implementations References: <19990430014309.76844.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is no precedence bit in IPv6. Diffserv (RFC 2474) applies directly to the IPv6 traffic class field. To find out what companies plan to do, I suggest you ask them directly. Brian Randall Shimizu wrote: > > Does anyone know how various networking companies are planning to integrate > the precedence bit? For example how does Cisco plan to integrate it with > other qos mechanisms such as tag switching and diff-serv? > > _______________________________________________________________ > Get Free Email and Do More On The Web. Visit http://www.msn.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 Fri Apr 30 04:20:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA15036 for ipng-dist; Fri, 30 Apr 1999 04:17: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 EAA15029 for ; Fri, 30 Apr 1999 04:17:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id EAA20304 for ; Fri, 30 Apr 1999 04:17:10 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA00134 for ; Fri, 30 Apr 1999 04:17:08 -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 MAA32632; Fri, 30 Apr 1999 12:16:55 +0100 Received: from hursley.ibm.com (9-20-31-242.dhcp.hursley.ibm.com [9.20.31.242]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id MAA21248; Fri, 30 Apr 1999 12:16:45 +0100 (BST) Message-ID: <372990ED.44E373FB@hursley.ibm.com> Date: Fri, 30 Apr 1999 12:15:57 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Richard Draves CC: "'IPng List'" Subject: (IPng 7457) Re: simple source address selection References: <4D0A23B3F74DD111ACCD00805F31D81014514F76@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, this has got me very worried. If site A is multihomed, and a host at site B is sending to it, B should choose the topologically "best" address for site A. That is not something an entity above the network layer can decide, and it is not independent of the choice of source address if site B is also multihomed. On the contrary: they are linked. The 6to4 case is just a special case of this. Brian Richard Draves wrote: > > > I'm not 100% sure about this limitation of scope: > > > > > 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. > > > > It really is a trivial extension to your draft to add a recommended > > rule for choosing the pair - i.e. run your rules for choosing the > > source across all destination addresses, and pick the final pair > > with 1. the smallest scope and 2. the longest match. > > Yes, we could add such an extension but I don't think it would be useful. > > MSR IPv6 is never in a situation where it needs to pick a destination > address. The destination address is always specified by an application. I > believe this is also true of other implementations. > > So to support this would be a pretty major architectural change to how > applications & upper layers interact with the IP layer. I would want a > solution to address other issues, like if one dst/src pair doesn't work then > being able to switch to another dst/src pair. It's certainly worth thinking > about (and I am giving it thought), but it's so much more complicated that > it should be a separate proposal. > > > I have a vested interest in this as it would take the special case > > out of 6to4, but I think it's of general utility. > > I don't see why 6to4 needs a special case for destination/source address > selection. > > 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 Fri Apr 30 04:37:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA15073 for ipng-dist; Fri, 30 Apr 1999 04:32:55 -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 EAA15066 for ; Fri, 30 Apr 1999 04:32:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id EAA11901 for ; Fri, 30 Apr 1999 04:32:41 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA04350 for ; Fri, 30 Apr 1999 04:32:41 -0700 (PDT) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id UAA07694; Fri, 30 Apr 1999 20:31:34 +0900 (JST) To: Brian E Carpenter cc: Richard Draves , "'IPng List'" In-reply-to: brian's message of Fri, 30 Apr 1999 12:15:57 +0100. <372990ED.44E373FB@hursley.ibm.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: (IPng 7458) Re: simple source address selection From: itojun@iijlab.net Date: Fri, 30 Apr 1999 20:31:33 +0900 Message-ID: <7690.925471893@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If site A is multihomed, and a host at site B is sending to it, >B should choose the topologically "best" address for site A. That >is not something an entity above the network layer can decide, >and it is not independent of the choice of source address if >site B is also multihomed. On the contrary: they are linked. No. Normally B has no idea about topology at the destination, and B cannot really decide which is better or worse. For example, I'm from 210.160.95.97 and I cannot really choose from two destinations: 204.166.18.33 or 203.141.85.90 (just a random pick) Basically, there's nothing sender can do. If both address assignment and routing structure are tree-based, longest match may sometimes do the trick, however, this is just a heurestics. Nothing more than that. longest match can pick wrong address. >The 6to4 case is just a special case of this. 6to4 separates IPv6 ocean into two parts: 6to4 addresses and non-6to4 addresses. To use optimal route, packet toward 6to4 address should have 6to4 source address. I believe this is why 6to4 is worrying about the source address selection. 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 Fri Apr 30 04:50:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA15104 for ipng-dist; Fri, 30 Apr 1999 04:47: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 EAA15097 for ; Fri, 30 Apr 1999 04:47:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id EAA21269 for ; Fri, 30 Apr 1999 04:47:23 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id EAA08260 for ; Fri, 30 Apr 1999 04:47:22 -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 LA15688; Fri, 30 Apr 1999 21:46:10 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Brian E Carpenter Cc: Richard Draves , "'IPng List'" Subject: (IPng 7459) Re: simple source address selection In-Reply-To: Your message of "Fri, 30 Apr 1999 12:15:57 +0100." <372990ED.44E373FB@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Apr 1999 21:46:09 +1000 Message-Id: <22030.925472769@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 30 Apr 1999 12:15:57 +0100 From: Brian E Carpenter Message-ID: <372990ED.44E373FB@hursley.ibm.com> | If site A is multihomed, and a host at site B is sending to it, | B should choose the topologically "best" address for site A. If you have a method by which this can be accomplished, please do let us know. | That is not something an entity above the network layer can decide, In general we're content with an address which works, and it is essentially always chosen by the application, not the net layer. In general, we don't expect the net layer of a host to (necessarily) have much more information than a list of (its own) addresses on local links (and their netmasks) and addresses of routers on those links. It is hard to see how, with this information, the net layer could be expected to deduce anything at all about which of several destination addresses might be best under any definition of that term. Further, the API we have so far has no method of informing the net layer which particular definition of best might be appropriate for this particular packet - nor for that matter of informing the net layer that there might in fact be alternate addresses that might be equivalent. Further, the net layer can't even really be expected to understand that the addresses form part of connection identifiers for some packets, and hence can't be altered, whereas for other packets, anything that reaches the correct host will do (initial SYN for TCP, most UDP queries, etc). I really don't think that asking the net layer to start making destination address choices is going to succeed, anytime in the forseeable future. | and it is not independent of the choice of source address if | site B is also multihomed. On the contrary: they are linked This we understand, what is what Richard's draft is addressing - how to choose a source address given a particular destination address. 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 Apr 30 07:49:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA15329 for ipng-dist; Fri, 30 Apr 1999 07:46: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 HAA15322 for ; Fri, 30 Apr 1999 07:46:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id HAA18513 for ; Fri, 30 Apr 1999 07:46:16 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA24337 for ; Fri, 30 Apr 1999 07:46:16 -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 PAA74462; Fri, 30 Apr 1999 15:45:54 +0100 Received: from hursley.ibm.com (9-20-31-242.dhcp.hursley.ibm.com [9.20.31.242]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA28926; Fri, 30 Apr 1999 15:45:53 +0100 (BST) Message-ID: <3729C1F0.2433571A@hursley.ibm.com> Date: Fri, 30 Apr 1999 15:45:04 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Robert Elz CC: Richard Draves , "'IPng List'" Subject: (IPng 7460) Re: simple source address selection References: <22030.925472769@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, > | If site A is multihomed, and a host at site B is sending to it, > | B should choose the topologically "best" address for site A. > > If you have a method by which this can be accomplished, please do let us know. I've already suggested an algorithm: match each potential source address against each potential destination address; choose the pairs with smallest common scope; among those, choose the pair with longest prefix match. In an aggregated address space this will come very close to the topologically best answer. And I'm only suggesting it as a default mechanism. > | That is not something an entity above the network layer can decide, > > In general we're content with an address which works, Not true. We put up with it, but we know that it doesn't produce least-hops routes. > ...and it is essentially > always chosen by the application, not the net layer. In general, we don't > expect the net layer of a host to (necessarily) have much more information > than a list of (its own) addresses on local links (and their netmasks) and > addresses of routers on those links. It is hard to see how, with this > information, the net layer could be expected to deduce anything at all > about which of several destination addresses might be best under any definition > of that term. Well, maybe my suggestion above is unreasonable but it seems to me that in an aggregated address space thing are fundamentally different and we do have some knowledge just by looking at addresses. > ...Further, the API we have so far has no method of informing > the net layer which particular definition of best might be appropriate for > this particular packet - nor for that matter of informing the net layer that > there might in fact be alternate addresses that might be equivalent. Indeed. The second point is bothering me. > Further, the net layer can't even really be expected to understand that the > addresses form part of connection identifiers for some packets, and hence > can't be altered, whereas for other packets, anything that reaches the > correct host will do (initial SYN for TCP, most UDP queries, etc). I don't see why this is relevant - there's no reason why the address selection would change during the lifetime of a session. > > I really don't think that asking the net layer to start making destination > address choices is going to succeed, anytime in the forseeable future. So where is it specified how to choose when DNS returns multiple addresses? If this isn't specified we don't have a chance of a comprehensible solution for multihoming. > | and it is not independent of the choice of source address if > | site B is also multihomed. On the contrary: they are linked > > This we understand, what is what Richard's draft is addressing - how to > choose a source address given a particular destination address. I understand that his draft solves that problem. 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 Apr 30 08:01:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA15354 for ipng-dist; Fri, 30 Apr 1999 07:58: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 HAA15347 for ; Fri, 30 Apr 1999 07:58:23 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.4) with ESMTP id HAA11248 for ; Fri, 30 Apr 1999 07:58:22 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA00919 for ; Fri, 30 Apr 1999 07:58:18 -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 PAA137622; Fri, 30 Apr 1999 15:57:54 +0100 Received: from hursley.ibm.com (9-20-31-242.dhcp.hursley.ibm.com [9.20.31.242]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA27120; Fri, 30 Apr 1999 15:57:03 +0100 (BST) Message-ID: <3729C48E.A6ED62D5@hursley.ibm.com> Date: Fri, 30 Apr 1999 15:56:14 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: itojun@iijlab.net CC: Richard Draves , "'IPng List'" Subject: (IPng 7461) Re: simple source address selection References: <7690.925471893@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun, > If both address assignment and routing structure are tree-based, That is how I understand IPv6 aggregatable addresses (to a first approximation; as you say it has a heuristic aspect). Obviously, it would be a crazy idea for IPv4. 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 Apr 30 09:25:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA15456 for ipng-dist; Fri, 30 Apr 1999 09:18: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 JAA15446 for ; Fri, 30 Apr 1999 09:17:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.4) with ESMTP id JAA24839 for ; Fri, 30 Apr 1999 09:17:36 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA17464 for ; Fri, 30 Apr 1999 09:17:34 -0700 (PDT) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA11336; Sat, 1 May 1999 01:16:16 +0900 (JST) To: Brian E Carpenter cc: Richard Draves , "'IPng List'" In-reply-to: brian's message of Fri, 30 Apr 1999 15:56:14 +0100. <3729C48E.A6ED62D5@hursley.ibm.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: (IPng 7462) Re: simple source address selection From: itojun@iijlab.net Date: Sat, 01 May 1999 01:16:16 +0900 Message-ID: <11332.925488976@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> If both address assignment and routing structure are tree-based, >That is how I understand IPv6 aggregatable addresses (to a first >approximation; as you say it has a heuristic aspect). Obviously, >it would be a crazy idea for IPv4. I agree that address assignment is somewhat like tree (TLA, NLA, ...) but I don't believe that the actual routing is "tree-based". You will have several thousands of TLAs on the net (hopefully), and they will perform peering arrangement, route filtering, and sometimes they perform packet filtering at the borders (ugg). If you are in TLA1, and two candidate destinations are TLA2 and TLA3, you can never understand how the packet will travel from TLA1->TLA2 and TLA1->TLA3. 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 Fri Apr 30 09:57:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA15504 for ipng-dist; Fri, 30 Apr 1999 09:50: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 JAA15497 for ; Fri, 30 Apr 1999 09:50:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail1.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id JAA13461 for ; Fri, 30 Apr 1999 09:50:25 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA06392 for ; Fri, 30 Apr 1999 09:50:27 -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 RAA59716; Fri, 30 Apr 1999 17:49:49 +0100 Received: from hursley.ibm.com (9-20-31-242.dhcp.hursley.ibm.com [9.20.31.242]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA26786; Fri, 30 Apr 1999 17:49:48 +0100 (BST) Message-ID: <3729DEFA.DFF18C8@hursley.ibm.com> Date: Fri, 30 Apr 1999 17:48:58 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: itojun@iijlab.net CC: Richard Draves , "'IPng List'" Subject: (IPng 7463) Re: simple source address selection References: <11332.925488976@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >> If both address assignment and routing structure are tree-based, > >That is how I understand IPv6 aggregatable addresses (to a first > >approximation; as you say it has a heuristic aspect). Obviously, > >it would be a crazy idea for IPv4. > > I agree that address assignment is somewhat like tree (TLA, NLA, ...) > but I don't believe that the actual routing is "tree-based". > You will have several thousands of TLAs on the net (hopefully), > and they will perform peering arrangement, route filtering, and > sometimes they perform packet filtering at the borders (ugg). > > If you are in TLA1, and two candidate destinations are TLA2 and TLA3, > you can never understand how the packet will travel from TLA1->TLA2 > and TLA1->TLA3. Absolutely correct. But if the prefixes match down to say /40 you know you are pretty close in the topology. 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 Apr 30 11:50:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA15834 for ipng-dist; Fri, 30 Apr 1999 11:45: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 LAA15827 for ; Fri, 30 Apr 1999 11:45:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.4) with ESMTP id LAA29026 for ; Fri, 30 Apr 1999 11:45:38 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA18225 for ; Fri, 30 Apr 1999 11:45:36 -0700 (PDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id SAA03336; Fri, 30 Apr 1999 18:44:38 GMT Message-Id: <199904301844.SAA03336@orchard.arlington.ma.us> To: Robert Elz cc: Brian E Carpenter , Richard Draves , "'IPng List'" Subject: (IPng 7464) Destination address selection In-Reply-To: Message from Robert Elz of "Fri, 30 Apr 1999 21:46:09 +1000." <22030.925472769@munnari.OZ.AU> Date: Fri, 30 Apr 1999 14:44:38 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (note subject change). This is a problem I butted heads with in a previous job (in a client-server context, which shows through in my terminology). I'll summarize the problem as: "given a set of for different replicas of the same service, tell me what order to try them in". Information relevant to how to do this is scattered throughout the stack. The application layer really isn't in a good position to pick among a set of possible destinations. You can manually configure preferences, and keep track of recent history, but often apps aren't particularly long-lived. I've seen this code turn into a real swamp in some applications. It would be helpful if there were some semi-standard primitives out there to help an app make these distinctions. The network layer isn't in a much better position. It can prefer things based on some coarse-grained heuristics: - same host vs different host - directly connected net vs via a router - directly connected via fast link vs directly connected via slow link In some (LAN-oriented) applications, even this can be a big win, but it doesn't help you pick between a server two hops away vs one twenty hops away. The transport layer, on the other hand (at least for TCP): - is relatively long-lived and can keep state. - knows which hosts it's already talking to, and some of the ones it's talked to recently. - is measuring round trip times, so it's in a decent place to know which replicas are more or less close, and have some idea of which aren't responding at all.. I think this becomes more criticial with IPv6, since, what with link-local and site-local addresses, just about everything's going to have multiple addresses, even if they are all on a single interface. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 30 12:40:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA15907 for ipng-dist; Fri, 30 Apr 1999 12:24: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 MAA15900 for ; Fri, 30 Apr 1999 12:24:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail2.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENS_USDOMAIN,v%I%) with ESMTP id MAA24543 for ; Fri, 30 Apr 1999 12:24:16 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA11806 for ; Fri, 30 Apr 1999 12:24:05 -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 MAA17097; Fri, 30 Apr 1999 12:23:55 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: deering@postoffice Message-Id: In-Reply-To: <18991.925450600@munnari.OZ.AU> References: <18991.925450600@munnari.OZ.AU> Date: Fri, 30 Apr 1999 12:23:55 -0700 To: Robert Elz From: Steve Deering Subject: (IPng 7465) Re: simple source address selection Cc: Richard Draves , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:36 PM +1000 4/30/99, Robert Elz wrote: >Another scenario to consider is where a multi-homed host (not a router) is >connected to two links, between which there is no routing (either temporarily, >or permanently). > >Consider the case where the router that should connect the links is >temporarily out of order... In the scenario you described, I think you are talking about manual configuration of the multihomed host and one or more routers to deal with the problem. I agree that manual configuration should be able to override the default behavior of the multihomed host. > | A somewhat less good -- but still grudgingly permitted :) -- reason is > | the unwillingness of the implementor to do the more sophisticated host > | routing implementation that would ensure that a packet went out the > | interface corresponding to its source address in the case where the > | upper-layer specifies the source address but does not care which > | interface it goes out. > >Or that the host implementor has done the work to participate enough >in the routing protocols and policies that it knows the best route to >the destination (and would ignore an ICMP even if one were sent perhaps). Yeah, I suppose. > | The semi-strong model says any source address is > | OK, but when given a choice, choose one that belongs to the originating > | interface. > >This seems right to me. It also seems to be in conformance with what >most implementations actually do (for IPv4 anyway). There may be something >which actually implements "randomly pick a source address" (true weak model), >but if there is, I have not seen it. Probably not "randomly pick a source address", but I believe some implementations have the notion of a "primary address" (e.g., the first address configured at boot time) that is always used as the source address whenever the upper layer doesn't care, regardless of outgoing interface. And in the scenario that I raised in my first response to Rich's new draft, in which a host sends a packet from interface x to its own address for interface y, a weak host following Rich's Rules would be *required* to pick a source address that does *not* belong to the outgoing interface, which is even worse than random if one agrees with the semi-strong model. 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 Apr 30 14:51:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA16220 for ipng-dist; Fri, 30 Apr 1999 14:49: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 OAA16213 for ; Fri, 30 Apr 1999 14:49:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.4) with ESMTP id OAA06342 for ; Fri, 30 Apr 1999 14:49:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA09983 for ; Fri, 30 Apr 1999 14:49:02 -0700 (PDT) Received: from spruce (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id OAA28908; Fri, 30 Apr 1999 14:48:14 -0700 (PDT) Message-Id: <3.0.5.32.19990430144722.00ae2b50@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 30 Apr 1999 14:47:22 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 7466) Re: Mail archives (Newer archives) In-Reply-To: <3.0.5.32.19990429162656.007d96e0@mailhost.iprg.nokia.com> References: <19990429212558.89176.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The mail archive problem at ftp://playground.sun.com/pub/ipng is now fixed (i.e., the 1999 monthly files are now there). Also, the majordomo retrieval method continued to work. 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 Apr 30 19:38:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA16503 for ipng-dist; Fri, 30 Apr 1999 19:08:28 -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 TAA16496 for ; Fri, 30 Apr 1999 19:08:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.4) with ESMTP id TAA16727 for ; Fri, 30 Apr 1999 19:08:14 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id TAA03296 for ; Fri, 30 Apr 1999 19:08:10 -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 CA26750; Sat, 1 May 1999 12:07:18 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Brian E Carpenter Cc: itojun@iijlab.net, Richard Draves , "'IPng List'" Subject: (IPng 7467) Re: simple source address selection In-Reply-To: Your message of "Fri, 30 Apr 1999 17:48:58 +0100." <3729DEFA.DFF18C8@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 May 1999 12:07:17 +1000 Message-Id: <26856.925524437@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 30 Apr 1999 17:48:58 +0100 From: Brian E Carpenter Message-ID: <3729DEFA.DFF18C8@hursley.ibm.com> | Absolutely correct. But if the prefixes match down to say /40 | you know you are pretty close in the topology. /40? Maybe not. /48 then yes, probably. At least with current address allocation plans. But we absolutely do not want to start building any assumptions related to prefix lengths into applications, or anywhere in hosts. That is, I would say that hosts MUST NOT base interface or address selection upon any notion of specific prefix lengths (longest match is different, and OK). In an earlier message you said ... I don't see why this is relevant - there's no reason why the address selection would change during the lifetime of a session. it shouldn't (given that addresses form connection identifiers), obviously. But a net level address selection algorithm could easily do that, unless the whole network environment remains static - and there are way too many cases that are all too plausible where that would not remain true. The obvious one is where a new link comes up during the life of an application (or a connection), which is not at all infrequent. Then there's mobile hosts, which will be getting new local addresses, including new local site addresses, quite frequently potentially. And then there's the simple case of a local prefix reassignment - the likely case of this will have the new address starting to be advertised by the routers (along with the old), then the DNS being updated to switch from old to new address schemes, (and then the rest of it all). A connection that starts after the new addresses have been advertised (I know my new address) but before the DNS update has filtered through (I don't know the new address of that other guy on the adjacent hub port yet) then it is entirely possible to imagine learning of a new (and "better") destination address during the life of a connection. The point is that if you leave all this to the net layer to decide, then it doesn't really have enough information to know what addresses ought to be being assigned, and when it is safe to start choosing new ones. Whether the applications really ought be doing this, or whether there is some better choice between application and net layer I'm not sure - we only really have much experience with the applications doing destination address selection. 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 --------------------------------------------------------------------