From owner-ipng@sunroof.eng.sun.com Thu Jun 1 04:05:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e51B4Nu16573 for ipng-dist; Thu, 1 Jun 2000 04:04:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e51B4E716566 for ; Thu, 1 Jun 2000 04:04:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA19409 for ; Thu, 1 Jun 2000 04:04:14 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA11469 for ; Thu, 1 Jun 2000 04:04:14 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 01 Jun 2000 05:04:05 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 01 Jun 2000 05:08:55 -0600 From: "Narsimharao Nagampalli" To: Subject: Flow Label in IPv6 header Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e51B4F716567 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Could anyone help me understand the logic behind selecting 20 bit flow label field in the IPv6 header? IPv4 uses the src and dest addr and ports to denote a flow. Ofcourse not necessarily every 4 tuple should map to a flow, but if there was a 32 bit field, we could have right away re-used the src+dest port fields to indicate the flow in IPv6 too. Firewalls, proxies, L4 switches, QoS mechanisms at routers all need some informaiton on the specific flow to make intelligent decisions. Most them today use transport layer protocol Id and src and destination ports to identify the flow. If we provide the src and dest port information in the network layer header itself, these technologies need not violate the layering! Also if the packets were encrypted as in IPSec, this becomes more so relevant. May be I am missing some thing here. Would appreciate any clarfications. Thanks and Regards Narsi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 1 14:41:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e51Le4917238 for ipng-dist; Thu, 1 Jun 2000 14:40:04 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e51Ldx717229 for ; Thu, 1 Jun 2000 14:39:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id OAA15582 for ipng@sunroof.eng.sun.com; Thu, 1 Jun 2000 14:39:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e51LY1717202 for ; Thu, 1 Jun 2000 14:34:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA27377 for ; Thu, 1 Jun 2000 14:34:01 -0700 (PDT) Received: from dialin156.ottawa.globalserve.net (ppp14.arobas.net [205.205.36.84]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA19170 for ; Thu, 1 Jun 2000 15:34:00 -0600 (MDT) Received: (qmail 1132 invoked by uid 1000); 1 Jun 2000 21:29:56 -0000 Date: Thu, 1 Jun 2000 17:29:56 -0400 From: Jerome Etienne To: ipng@sunroof.eng.sun.com Subject: reason behind 1280bytes as minimal MTU Message-ID: <20000601172956.A1118@long-haul.net> Reply-To: jetienne@arobas.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I look for the reasons behind 1280bytes as minimal IPv6 MTU. Where can i find informations to answer questions such as "how it has been choosen ?" or "why 1280 and not 1024 or 1500 ?" thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 1 23:50:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e526mNr17536 for ipng-dist; Thu, 1 Jun 2000 23:48:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e526mC717529 for ; Thu, 1 Jun 2000 23:48:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA02667 for ; Thu, 1 Jun 2000 23:48:11 -0700 (PDT) Received: from tina.necsom.com (necsom.com [195.197.177.218]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA28418 for ; Fri, 2 Jun 2000 00:48:09 -0600 (MDT) Received: from lut.fi (IDENT:vnummela@localhost.localdomain [127.0.0.1]) by tina.necsom.com (8.9.3/8.9.3) with ESMTP id JAA03388; Fri, 2 Jun 2000 09:48:11 +0300 Message-ID: <393758AB.94635425@lut.fi> Date: Fri, 02 Jun 2000 09:48:11 +0300 From: Ville Nummela X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: fi, en MIME-Version: 1.0 To: jetienne@arobas.net CC: ipng@sunroof.eng.sun.com Subject: Re: reason behind 1280bytes as minimal MTU References: <20000601172956.A1118@long-haul.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jerome Etienne wrote: > Hi, > > I look for the reasons behind 1280bytes as minimal IPv6 MTU. Where can > i find informations to answer questions such as "how it has been choosen ?" > or "why 1280 and not 1024 or 1500 ?" The size was chosen so that most packets would get through without fragmentation. Much more detailed reasons can be found from the mailing list archive, try this address: http://www.wcug.wwu.edu/lists/ipng/199711/msg00052.html -- | vnummela@lut.fi tel: +358-40-5075560 | So Linus, what are we doing tonight? | The same thing we every night Tux. Try to take over the world! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 15:27:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e55MOW820137 for ipng-dist; Mon, 5 Jun 2000 15:24:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e55MOL720130 for ; Mon, 5 Jun 2000 15:24:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA07029 for ; Mon, 5 Jun 2000 15:24:21 -0700 (PDT) Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02538 for ; Mon, 5 Jun 2000 15:24:20 -0700 (PDT) Received: (from sms@localhost) by gate.ticl.co.uk (8.8.8/8.8.8) id XAA10434; Mon, 5 Jun 2000 23:01:44 +0100 (BST) (envelope-from pcurran@ticl.co.uk) Received: from gate.ticl.co.uk(193.32.1.5), claiming to be "creak.ticl.co.uk" via SMTP by gate.ticl.co.uk, id smtpde10432; Mon Jun 5 23:01:38 2000 Message-ID: <006901bfcf3c$d68e4a60$78e481ac@creak.ticl.co.uk> From: "peter@ticl" To: "Narsimharao Nagampalli" , Subject: Re: Flow Label in IPv6 header Date: Mon, 5 Jun 2000 23:24:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think you have answered your own question!! > >Could anyone help me understand the logic behind selecting 20 bit flow label field in the IPv6 header? > >IPv4 uses the src and dest addr and ports to denote a flow. Ofcourse not necessarily every 4 tuple should map to a flow, but if there was a 32 bit field, we could have right away re-used the src+dest port fields to indicate the flow in IPv6 too. > >Firewalls, proxies, L4 switches, QoS mechanisms at routers all need some informaiton on the specific flow to make intelligent decisions. Most them today use transport layer protocol Id and src and destination ports to identify the flow. > >If we provide the src and dest port information in the network layer header itself, these technologies need not violate the layering! > Yes - that why we have a flow label, or at least partly. >Also if the packets were encrypted as in IPSec, this becomes more so relevant. > Yes - thats why we have a flow label, or at least partly. Think of the overheads required of a firewall/router/etc to parse the daisy-chained v6 headers in order to find the transport header, and hence the application identification. What if this is encrypted inside an ESP header? Placing a single flow label in the default v6 header makes these problems vanish. You can then decide whether to use just the flow label, or the label plus src and/or dest IP address to provide your flow based processing. It seems pretty straightforward to me, but then, as I said above, I think you answered your own question. The flow label is 20 bits long because that was all that was left 'spare' in the header. (A few iterations ago it was 24 bits, but the new traffic class field needed another 4 bits when it replaced the older priority field). Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 18:45:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e561d6k20258 for ipng-dist; Mon, 5 Jun 2000 18:39:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e561cv720251 for ; Mon, 5 Jun 2000 18:38:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA17796 for ; Mon, 5 Jun 2000 18:38:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA28904 for ; Mon, 5 Jun 2000 19:38:56 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA22536; Mon, 5 Jun 2000 18:38:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id SAA06127; Mon, 5 Jun 2000 18:38:54 -0700 X-Virus-Scanned: Mon, 5 Jun 2000 18:38:54 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma005982; Mon, 5 Jun 00 18:38:49 -0700 Message-Id: <4.3.2.7.2.20000605183505.027f75d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jun 2000 18:37:06 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Web Page Updated Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I updated the IPv6 implementations page on the IPng web pages at: http://playground.sun.com/ipng Please let me know if I missed anyone's update. I plan to update the specifications page in the next day or two. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 5 22:26:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e565P5h20358 for ipng-dist; Mon, 5 Jun 2000 22:25:05 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e565Ot720351 for ; Mon, 5 Jun 2000 22:24:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA27191 for ; Mon, 5 Jun 2000 22:24:53 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA09717 for ; Mon, 5 Jun 2000 23:24:54 -0600 (MDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 05 Jun 2000 22:51:00 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 05 Jun 2000 22:56:21 -0600 From: "Narsimharao Nagampalli" To: , Subject: Re: Flow Label in IPv6 header Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e565Ou720352 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But today we do not define a standard way of creating the flow label and it is also mentioned that flow label is NOT MANDATORY. Now, since most of the technologies liek QoS, IPsec., firewalls etc use the 5 tuple way they would be forced to continue same way until there is a GAURANTEED cheaper alternative. May be the ISN on the connection or some existing mechanism can be re-used. I would be not so worried about the exact mechanism to be used as long as it is gauranteed that there would be a proper flow label in the IPv6 header. -Narsi >>> "peter@ticl" 06/06/00 03:54AM >>> I think you have answered your own question!! > >Could anyone help me understand the logic behind selecting 20 bit flow label field in the IPv6 header? > >IPv4 uses the src and dest addr and ports to denote a flow. Ofcourse not necessarily every 4 tuple should map to a flow, but if there was a 32 bit field, we could have right away re-used the src+dest port fields to indicate the flow in IPv6 too. > >Firewalls, proxies, L4 switches, QoS mechanisms at routers all need some informaiton on the specific flow to make intelligent decisions. Most them today use transport layer protocol Id and src and destination ports to identify the flow. > >If we provide the src and dest port information in the network layer header itself, these technologies need not violate the layering! > Yes - that why we have a flow label, or at least partly. >Also if the packets were encrypted as in IPSec, this becomes more so relevant. > Yes - thats why we have a flow label, or at least partly. Think of the overheads required of a firewall/router/etc to parse the daisy-chained v6 headers in order to find the transport header, and hence the application identification. What if this is encrypted inside an ESP header? Placing a single flow label in the default v6 header makes these problems vanish. You can then decide whether to use just the flow label, or the label plus src and/or dest IP address to provide your flow based processing. It seems pretty straightforward to me, but then, as I said above, I think you answered your own question. The flow label is 20 bits long because that was all that was left 'spare' in the header. (A few iterations ago it was 24 bits, but the new traffic class field needed another 4 bits when it replaced the older priority field). Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 03:06:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e56A4F720876 for ipng-dist; Tue, 6 Jun 2000 03:04:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e56A44720869 for ; Tue, 6 Jun 2000 03:04:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA00475 for ; Tue, 6 Jun 2000 03:04:03 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA17324 for ; Tue, 6 Jun 2000 04:04:02 -0600 (MDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id NAA15581; Tue, 6 Jun 2000 13:04:01 +0300 (EET DST) Date: Tue, 6 Jun 2000 13:04:01 +0300 (EET DST) From: Markku Savela Message-Id: <200006061004.NAA15581@anise.tte.vtt.fi> To: ipng@sunroof.eng.sun.com Subject: ICMP and unknown extension headers? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The RFC-2460 in chapter 4 explains that one should return a "Parameter Problem" ICMP for unrecognized extension header. This has an offset pointing to the "next header field". Question: What is the value of this offset, if the problematic "next header" was uncovered by ESP processing? Admittedly, ESP is a bad example, because one probably should not be sending the ICMP in this case. But, there might be other future funny extension headers that produce the next header value in strange ways? [Just asking before changing our implementation, which incorrectly(?) returns ICMP Unreachable (type=1, code=4) for any protocol that nobody listens. Unknown extension header is just a protocol that has no handler installed or activated]. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 06:50:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e56DmVO20943 for ipng-dist; Tue, 6 Jun 2000 06:48:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e56DmF720936 for ; Tue, 6 Jun 2000 06:48:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA15704 for ; Tue, 6 Jun 2000 06:48:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14091 for ; Tue, 6 Jun 2000 07:48:14 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02467; Tue, 6 Jun 2000 09:48:11 -0400 (EDT) Message-Id: <200006061348.JAA02467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-mld-mib-03.txt Date: Tue, 06 Jun 2000 09:48:11 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol Author(s) : B. Haberman, R. Worzella Filename : draft-ietf-ipngwg-mld-mib-03.txt Pages : 14 Date : 05-Jun-00 This document defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module which defines managed objects for implementations of the Multicast Listener Discovery Protocol [MLD]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-mld-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-03.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: <20000605102331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000605102331.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 6 17:52:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e570p6Y21420 for ipng-dist; Tue, 6 Jun 2000 17:51:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e570ow721413 for ; Tue, 6 Jun 2000 17:50:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA08284 for ; Tue, 6 Jun 2000 17:50:58 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA23896 for ; Tue, 6 Jun 2000 17:50:57 -0700 (PDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Jun 2000 17:50:55 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Tue, 6 Jun 2000 17:50:54 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA221AA@RED-MSG-50> From: Richard Draves To: "IPng List (E-mail)" Cc: "Thomas Narten (E-mail)" Subject: problems with privacy draft Date: Tue, 6 Jun 2000 17:20:19 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While implementing draft-ietf-ipngwg-addrconf-privacy-01.txt, some issues have come up that I'd like to discuss. The good news is that with the changes I propose below, it does work great. First some review... RFC 2462 section 5.5.3 discusses processing of a Prefix Information option for address auto-configuration. The basic idea is - If the interface has any auto-configured addresses that match the prefix, then their Valid & Preferred lifetimes are reset to the prefix lifetimes in the RA. (There's a complication about not decreasing the Valid Lifetime below two hours.) - If the interface has no addresses that match the prefix (auto-configured or not), and the Valid Lifetime in the RA is non-zero, then you configure a new address (prefix + interface-id) with lifetimes taken from the RA. So in normal operation, the first RA that you get will create an address, the address lifetimes will decay until the next RA arrives, and then the address lifetimes will be reset. The basic mechanism in the privacy draft is to create two addresses instead of one in response to a prefix information option. Addresses with an IEEE-derived interface identifier are called public addresses, addresses with a randomly chosen interface identifer are called anonymous addresses. If you get a DAD collision on an anonymous address, then you try again with another randomly chosen interface identifier. Anonymous addresses are intended to be fairly ephemeral - the draft recommends by default that they have a preferred lifetime of one day and a valid lifetime of two weeks. When choosing a source address, you prefer anonymous addresses to public addresses - the draft achieves this by saying public addresses are created with a zero preferred lifetime so they are deprecated. So in normal operation, the first RA that you get will create a public address and an anonymous address. The anonymous address will be deprecated after a day and a new anonymous address will be created. Eventually in steady state you'll have fourteen anonymous addresses (all but one deprecated) for each public address. The draft allows implementations to remove deprecated anonymous addresses that are known to be not in use by any application, but this is not always feasible. Some issues that came up during implementation: Issue 1. You don't want to increase the lifetimes of existing anonymous addresses when you are processing a prefix information option. You want them to age away. I think it is appropriate to lower anonymous lifetimes, in case an admin decides to start removing a prefix by lowering lifetimes in the RAs. Issue 2. If a prefix information option has a zero preferred lifetime, then you should create a public address but not an anonymous address. Creating a new anonymous address with a zero preferred lifetime is at best pointless. Issue 3. When an anonymous address becomes deprecated, should you always create a new anonymous address? What lifetimes do you use for the new anonymous address? For example, suppose an admin changes the advertisement of a prefix to have zero preferred lifetime. This causes existing public & anonymous addresses that match the prefix to become deprecated. When the existing preferred anonymous address becomes deprecated, this should not cause the creation of a new anonymous address. Issue 4. When an anonymous address is deprecated and a new anonymous address is created, there's a small window in which a new connection doesn't have a good source address choice. This is because the old anonymous address is deprecated and the new anonymous address is still tentative. (I saw this happen in testing.) Issue 5. The end result is a LOT of unicast addresses assigned to an interface. Fourteen anonymous addresses for each public address, and there might easily be multiple public addresses. The bad thing about this is that the anonymous addresses all have different low bits, so they result in different solicited-node multicast addresses, which in turn produce different ethernet multicast groups. So you likely end up putting your ethernet card in promiscuous mode because it can't handle so many groups. Issue 6. In some environments, network administrators will want to disable the privacy. For example, I was thinking of using a flag bit in the prefix information option to control whether an anonymous address is created for the prefix. But this has to be balanced with the users privacy - you don't want a home user to not get privacy because their ISP is lazy and disables it. >From an implementation view, there's the question of what kind of relationship needs to be maintained between public addresses & anonymous addresses. Do operations on the anonymous address need to refer to the corresponding public address, or vice-versa? Here is a proposal: 1. Public addresses are NOT created with a zero Preferred lifetime. Instead they have normal preferred & valid lifetimes. Source address selection has a new rule, separate from the deprecated/preferred rules, to prefer anonymous addresses over public addresses. 2. When updating the lifetimes of existing auto-configured addresses in response to a received Prefix Information option, you never raise the lifetimes of anonymous addresses. You do lower their lifetimes if the received RA has smaller lifetimes. 3. You never create an anonymous address with a zero preferred lifetime. 4. When an anonymous address becomes deprecated (because it's preferred lifetime expires normally), you create a new anonymous address only if the corresponding public address has a non-zero preferred lifetime. If an anonymous address becomes deprecated because it's preferred lifetime is set to zero while processing an RA, then you do NOT create a new anonymous address - note that the corresponding public address will also have its preferred lifetime set to zero by this RA. 5. When you create an anonymous address (either this is the first time you are creating an anonymous address corresponding to a public address, or because of DAD failing for an anonymous address, or because an old anonymous address is being deprecated), you use the following lifetimes: valid lifetime = MIN(corresponding public's valid lifetime, two weeks) preferred lifetime = MIN(corresponding public's preferred lifetime, one day) (Because the corresponding public's preferred lifetime <= its valid lifetime, these formulas will always produce an anonymous preferred lifetime <= valid lifetime.) 6. Actually, you create a new anonymous address a few seconds before an existing anonymous address becomes deprecated, instead of waiting until it's actually deprecated. This gives DAD some time to work. I think five seconds for this regenerate interval is about right. 7. So I said above it was wrong to create a new anonymous address with a preferred lifetime of zero. Actually, I think you should never create a new anonymous address with a preferred lifetime smaller than the regenerate interval - if the formula in proposal 5 produces a preferred lifetime that is smaller than five seconds, just don't create the anonymous address. 8. You don't create a new random interface-identifier each time you generate an anonymous address. Instead you keep a current random interface-identifier associated with an interface, and use it when generating an anonymous address. Whenever the random interface-identifier is more than a day old (default value: the max preferred lifetime for anonymous addresses minus the regenerate interval, so one day less five seconds), you generate a new random interface identifier. This means that if you have anonymous addresss with multiple prefixes, then they will share their interface identifers. Also I suggest lowering the default max valid lifetime from two weeks to one week. In combination, this means that you will have seven different random interface-ids in use simultaneously, no matter how many prefixes you are using. An implementation consequence of all this is that you do need to find the corresponding public addresses from an anonymous address. But the reverse direction is not mandated. Comments? 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 Jun 7 03:35:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e57AXUT22080 for ipng-dist; Wed, 7 Jun 2000 03:33:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e57AXL722073 for ; Wed, 7 Jun 2000 03:33:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA03631 for ; Wed, 7 Jun 2000 03:33:20 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA00365 for ; Wed, 7 Jun 2000 04:33:20 -0600 (MDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 07 Jun 2000 04:00:44 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 07 Jun 2000 04:00:39 -0600 From: "Narsimharao Nagampalli" To: Subject: IPv6 Host requirement specification Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e57AXM722074 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Is there any host requirement specification for IPv6 nodes? Would appreciate any pointers. Regards Narsi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 06:54:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e57Dple22183 for ipng-dist; Wed, 7 Jun 2000 06:51:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e57DpZ722176 for ; Wed, 7 Jun 2000 06:51:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA04738 for ; Wed, 7 Jun 2000 06:51:36 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25199 for ; Wed, 7 Jun 2000 06:51:35 -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 IAA19282; Wed, 7 Jun 2000 08:51:33 -0500 (CDT) Message-Id: <200006071351.IAA19282@gungnir.fnal.gov> To: Richard Draves Cc: "IPng List (E-mail)" , "Thomas Narten (E-mail)" From: "Matt Crawford" Subject: Re: problems with privacy draft In-reply-to: Your message of Tue, 06 Jun 2000 17:20:19 PDT. <4D0A23B3F74DD111ACCD00805F31D8101CA221AA@RED-MSG-50> Date: Wed, 07 Jun 2000 08:51:33 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Without addressing most of your points, I think you're (plural if necessary) overlooking a mode in which many would wish to operate: generating a new anonymous address for almost every active TCP open (I say almost because the data connection for an FTP transfer is an obvious exception) and some class of new UDP sockets. If you limit addresses to one a day and activate them by deprecating the public address, I can track anonymous addresses by tricks like connecting daily to some service which sends an "ident" query back at me. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 7 13:16:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e57KDdn22541 for ipng-dist; Wed, 7 Jun 2000 13:13:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e57KDU722534 for ; Wed, 7 Jun 2000 13:13:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA14628 for ; Wed, 7 Jun 2000 13:13:28 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA07326 for ; Wed, 7 Jun 2000 14:13:28 -0600 (MDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Jun 2000 11:35:54 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Wed, 7 Jun 2000 11:44:08 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFD0AF.6258BC60" Subject: rfc2553bis comments X-MimeOLE: Produced By Microsoft Exchange V6.0.4384.0 Date: Wed, 7 Jun 2000 11:37:07 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690C6F7A6D@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc2553bis comments Thread-Index: Ab/QsDiVBRyw+k28T5mxMLyu2erx/w== From: "Dave Thaler" To: X-OriginalArrivalTime: 07 Jun 2000 18:44:08.0209 (UTC) FILETIME=[5CF5B010:01BFD0B0] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFD0AF.6258BC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ipngwg-rfc2553bis-00.txt (and on the POSIX spec by extension...): 1) It would be very useful to be able to obtain (via getaddrinfo) the list of local addresses to which you can bind. There's at least two ways I can think of to potentially support this: a) AI_PASSIVE could return a list of sockaddrs, with the unspecified address always being first. b) Use a new flag to enable behavior of obtaining the whole list 2) In porting IPv4 apps to IPv6, it's inconvenient that nodename and servname cannot both be NULL. There are applications that actually want to bind to INADDR_ANY/in6addr_any with an unspecified port. The intuitive behavior of allowing both to be NULL would be to get back local addresses without port numbers. 3) When multicast addresses are stored in a sockaddr_in6, how is the scope id field interpreted? My interpretation of the current wording (which I agree with) is that it's interpreted the same way as for unicast addresses. That is, a link-local multicast address uses the same sin6_scope_id as a link-local unicast address on that link. A site-local multicast address uses the same scope id as a site-local unicast address in that site. For other multicast scope levels, the scope id field can contain an id identifying the interfaces in that scope. Again, I=20 believe this is the correct interpretation, and is consistent with the current=20 RFC and draft. Reasoning (in case you disagree...) For *link-local* multicast, it's very convenient to store the scope id for the link-local scope on the interface (i.e., the ifindex or whatever the implementation uses). This is especially useful in that one doesn't need to do IPV6_MULTICAST_IF before sending to a link-local multicast address, since the sockaddr in the sendto() is unambiguous. For scopes between link-local and global, the issues are: 1) is the scope_id for a site-local group the site id or an ifindex (or equivalent link id)? 2) If you say the scope_id for multicast is always the ifindex, then you cannot tell that two sockaddrs actually refer to the same group, like you could for unicast, when both interfaces are inside the same scope. 3) If the scope_id is not an ifindex, then what is the meaning for scopes other than global and site-local? Basically, there's a disconnect between some purposes wanting the ifindex to know how to send/join, and using a site id (or equivalent) to uniquely identify the address. It's more consistent with unicast to use a site id (and the current draft appears to say this is the case), not an ifindex, but this would require an id for every scope level between link and global scope. An "unspecified" value (e.g. 0) might be legal in a given implementation for non-global multicast addresses, if it allows unspecified scope ids in non-global unicast addresses. (I'd tend to disallow this all together, but others disagree.) -Dave ------_=_NextPart_001_01BFD0AF.6258BC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable rfc2553bis comments

Comments on = draft-ietf-ipngwg-rfc2553bis-00.txt
(and on the POSIX spec by = extension...):

1) It would be very useful to be able = to obtain (via getaddrinfo) the
   list of local addresses = to which you can bind.  There's at least two
   ways I can think of to = potentially support this:
   a) AI_PASSIVE could = return a list of sockaddrs, with the unspecified
      address = always being first.
   b) Use a new flag to = enable behavior of obtaining the whole list

2) In porting IPv4 apps to IPv6, it's = inconvenient that nodename and
   servname cannot both be = NULL.  There are applications that actually
   want to bind to = INADDR_ANY/in6addr_any with an unspecified port.
   The intuitive behavior of = allowing both to be NULL would be to get
   back local addresses = without port numbers.

3) When multicast addresses are stored = in a sockaddr_in6, how is the scope
   id field = interpreted?  My interpretation of the current wording = (which
   I agree with) is that = it's interpreted the same way as for unicast
   addresses.  That is, = a link-local multicast address uses the same
   sin6_scope_id as a = link-local unicast address on that link.
   A site-local multicast = address uses the same scope id as a site-local
   unicast address in that = site.  For other multicast scope levels, the scope id
   field can contain an id = identifying the interfaces in that scope.  Again, I
   believe this is the = correct interpretation, and is consistent with the current
   RFC and draft.

   Reasoning (in case you = disagree...)
   For *link-local* = multicast, it's very convenient to store the scope id
   for the link-local scope = on the interface (i.e., the ifindex or whatever
   the implementation = uses).  This is especially useful in that one doesn't
   need to do = IPV6_MULTICAST_IF before sending to a link-local multicast
   address, since the = sockaddr in the sendto() is unambiguous.

   For scopes between = link-local and global, the issues are:
   1) is the scope_id for a = site-local group the site id or an ifindex
      (or = equivalent link id)?
   2) If you say the = scope_id for multicast is always the ifindex, then
      you = cannot tell that two sockaddrs actually refer to the same group,
      like = you could for unicast, when both interfaces are inside the same
      = scope.
   3) If the scope_id is not = an ifindex, then what is the meaning for
      scopes = other than global and site-local?
   Basically, there's a = disconnect between some purposes wanting the ifindex
   to know how to send/join, = and using a site id (or equivalent) to uniquely
   identify the = address.  It's more consistent with unicast to use a site id
   (and the current draft = appears to say this is the case), not an ifindex,
   but this would require an = id for every scope level between link and global
   scope.

   An "unspecified" = value (e.g. 0) might be legal in a given implementation
   for non-global multicast = addresses, if it allows unspecified scope ids
   in non-global unicast = addresses.  (I'd tend to disallow this all
   together, but others = disagree.)

-Dave

------_=_NextPart_001_01BFD0AF.6258BC60-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 16:11:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e57N8BJ22665 for ipng-dist; Wed, 7 Jun 2000 16:08:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e57N81722658 for ; Wed, 7 Jun 2000 16:08:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA15913 for ; Wed, 7 Jun 2000 16:08:01 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA07709 for ; Wed, 7 Jun 2000 16:14:41 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 07 Jun 2000 15:14:27 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Wed, 7 Jun 2000 15:14:27 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA221AE@RED-MSG-50> From: Richard Draves To: "IPng List (E-mail)" Cc: "'ignatios@cs.uni-bonn.de'" Subject: Re: problems with privacy draft Date: Wed, 7 Jun 2000 15:14:24 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios asked me to forward his comments to the list. I'll reply separately. -----Original Message----- From: Ignatios Souvatzis [mailto:ignatios@cs.uni-bonn.de] Sent: Wednesday, June 07, 2000 3:26 AM To: Richard Draves Subject: Re: problems with privacy draft On Tue, Jun 06, 2000 at 05:20:19PM -0700, Richard Draves wrote: [This is from the proposal part] > 8. You don't create a new random interface-identifier each time you generate > an anonymous address. Instead you keep a current random interface-identifier > associated with an interface, and use it when generating an anonymous > address. This is to limit the number of multicast groups that the interface must join? While this does not affect long time correlation of the nodes communication, it allows for easier short time correlation (that is, two communicating outside observers will be able to notice, that in (prefix X) there is a machine accessing resource A close to the time where in prefix Y the same user is accessing resource B. Without this rule (if instead using a new Interface Identifier each time you create an anonymous address) accesses to resources that are at different destination addresses, which have some likelihood to use different source prefixes, will not be trackable to the same machine. I can imagine situations where this correlation should be hidden. > An implementation consequence of all this is that you do need to find the > corresponding public addresses from an anonymous address. Why? -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 8 00:24:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e587MB523028 for ipng-dist; Thu, 8 Jun 2000 00:22:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e587Lx623020 for ; Thu, 8 Jun 2000 00:21:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA05924 for ; Thu, 8 Jun 2000 00:21:58 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA04914 for ; Thu, 8 Jun 2000 00:21:59 -0700 (PDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Jun 2000 00:21:56 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Jun 2000 00:21:51 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810240CC263@RED-MSG-50> From: Richard Draves To: Matt Crawford Cc: "IPng List (E-mail)" , "Thomas Narten (E-mail)" Subject: RE: problems with privacy draft Date: Thu, 8 Jun 2000 00:21:46 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Without addressing most of your points, I think you're (plural if > necessary) overlooking a mode in which many would wish to operate: > generating a new anonymous address for almost every active TCP open > (I say almost because the data connection for an FTP transfer is an > obvious exception) and some class of new UDP sockets. The draft should allow implementations to generate anonymous addresses very frequently. I did some testing generating a new anonymous address every five seconds. Generating a new source address for every socket probably introduces unacceptable latency for DAD, but it should be allowed. Another problem with generating so many addresses is knowing when they can be removed. The draft allows implementations to remove unused deprecated anonymous addresses, but it may be difficult to tell that an address is not in use. For example an application might use getsockname, save the address in a variable, and try to bind to it later. 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 Jun 8 00:24:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e587M5n23027 for ipng-dist; Thu, 8 Jun 2000 00:22:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e587Lq623012 for ; Thu, 8 Jun 2000 00:21:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA05898 for ; Thu, 8 Jun 2000 00:21:51 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA04863 for ; Thu, 8 Jun 2000 00:21:52 -0700 (PDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Jun 2000 00:21:49 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Jun 2000 00:21:44 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810240CC264@RED-MSG-50> From: Richard Draves To: Ignatios Souvatzis Cc: "IPng List (E-mail)" Subject: RE: problems with privacy draft Date: Thu, 8 Jun 2000 00:21:46 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is to limit the number of multicast groups that the > interface must join? > While this does not affect long time correlation of the nodes > communication, it > allows for easier short time correlation (that is, two > communicating outside > observers will be able to notice, that in (prefix X) there is > a machine > accessing resource A close to the time where in prefix Y the > same user is > accessing resource B. > > Without this rule (if instead using a new Interface > Identifier each time you > create an anonymous address) accesses to resources that are > at different > destination addresses, which have some likelihood to use > different source > prefixes, will not be trackable to the same machine. I can > imagine situations > where this correlation should be hidden. Yes, my proposal (to have anonymous addesses with different prefixes sharing the same random interface identifier) does not provide as much privacy as using a different random interface identifier for each anonymous address. I think both behaviors should be allowed. Joining too many multicast groups might be a significant performance hit in some environments. > > An implementation consequence of all this is that you do > need to find the > > corresponding public addresses from an anonymous address. > > Why? Because when an anonymous address is about to be deprecated and you create a new anonymous address, I'm proposing to refer to the corresponding public address's lifetimes to use in the formulas for the lifetimes for the new anonymous address. 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 Jun 8 04:35:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e58BXqK23273 for ipng-dist; Thu, 8 Jun 2000 04:33:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e58BXh623266 for ; Thu, 8 Jun 2000 04:33:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA23733 for ; Thu, 8 Jun 2000 04:33:43 -0700 (PDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06964 for ; Thu, 8 Jun 2000 04:33:41 -0700 (PDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id NAA28614; Thu, 8 Jun 2000 13:27:10 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA10351; Thu, 8 Jun 2000 13:26:54 +0200 Date: Thu, 8 Jun 2000 13:26:54 +0200 Message-Id: <200006081126.NAA10351@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: ipng@sunroof.eng.sun.com CC: bound@zk3.dec.com Subject: (retry) rfc2553bis-00: nai_strerror() ? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am resending the message attached below since I did not get any answers so far. Is the question really so stupid? /js ------- Start of forwarded message ------- Date: Mon, 15 May 2000 09:46:09 +0200 From: Juergen Schoenwaelder To: ipng@sunroof.eng.sun.com Subject: rfc2553bis-00: nai_strerror() ? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am sure this has been asked before. But anyway. After writing some code according to RFC 2553, I was wondering why there is no nai_strerror() function which works similar to gai_strerror(). /js - -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Thu Jun 8 06:45:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e58DeHI23356 for ipng-dist; Thu, 8 Jun 2000 06:40:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e58De6623349 for ; Thu, 8 Jun 2000 06:40:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA27033 for ; Thu, 8 Jun 2000 06:40:05 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00403 for ; Thu, 8 Jun 2000 06:40:05 -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 IAA25354; Thu, 8 Jun 2000 08:40:02 -0500 (CDT) Message-Id: <200006081340.IAA25354@gungnir.fnal.gov> To: Richard Draves Cc: Ignatios Souvatzis , "IPng List (E-mail)" From: "Matt Crawford" Subject: Re: problems with privacy draft In-reply-to: Your message of Thu, 08 Jun 2000 00:21:46 PDT. <4D0A23B3F74DD111ACCD00805F31D810240CC264@RED-MSG-50> Date: Thu, 08 Jun 2000 08:40:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > think both behaviors should be allowed. Joining too many multicast groups > might be a significant performance hit in some environments. Keeping the bottom 24 bits fixed at an initial random value, or changing them less frequently than the upper 40, would cut down the number of multicast groups joined. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 8 07:31:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e58ETlG23421 for ipng-dist; Thu, 8 Jun 2000 07:29:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e58ETc623414 for ; Thu, 8 Jun 2000 07:29:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA01603 for ; Thu, 8 Jun 2000 07:29:37 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15844 for ; Thu, 8 Jun 2000 08:29:36 -0600 (MDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id OAA06071; Thu, 8 Jun 2000 14:29:25 GMT Message-Id: <200006081429.OAA06071@orchard.arlington.ma.us> To: "Matt Crawford" cc: Richard Draves , Ignatios Souvatzis , "IPng List (E-mail)" Subject: Re: problems with privacy draft In-Reply-To: Message from "Matt Crawford" of "Thu, 08 Jun 2000 08:40:01 CDT." <200006081340.IAA25354@gungnir.fnal.gov> Reply-to: sommerfeld@orchard.arlington.ma.us Date: Thu, 08 Jun 2000 10:29:25 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keeping the bottom 24 bits fixed at an initial random value, or > changing them less frequently than the upper 40, would cut down the > number of multicast groups joined. .. but make it easier to correlate multiple connections from the same host. Unless there are a *lot* of nodes on a link, most nodes will have unique 24-bit values. I don't see this as being noticeably different from the "keep the same anon address for a while" model. On the other hand, if the mapping function from node id -> ND multicast address involved a "secret" per-link parameter, this sort of correlation would be much harder. But I suspect that this isn't a can of worms we want to open.. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 8 10:51:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e58Hn7Z23703 for ipng-dist; Thu, 8 Jun 2000 10:49:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e58Hmw623696 for ; Thu, 8 Jun 2000 10:48:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA16088 for ; Thu, 8 Jun 2000 10:48:57 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13323 for ; Thu, 8 Jun 2000 11:48:53 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA24025; Fri, 9 Jun 2000 02:35:34 +0900 (JST) Date: Fri, 09 Jun 2000 02:42:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: iesg@ietf.org Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: a comment of draft-ietf-mobileip-ipv6-12.txt User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 64 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Before finishing the last call for the mobile IPv6 draft, I'd like to comment on the draft. I hope this is not too late, and apologize in advance if this has already been discussed. Section 10.2 of the draft says as follows: - Since the mobile node is away from home, the mobile node inserts a Home Address option into the packet, replacing the Source Address in the packet's IP header with a care-of address suitable for the link on which the packet is being sent, as described in Section 10.1. The Destination Options header in which the Home Address option is inserted MUST appear in the packet before the AH [11] (or ESP [12]) header, so that the Home Address option is processed by the destination node before the AH or ESP header is processed. It seems to me that the order of the destination options header including the home address option is not conformant to the recommended order of extension headers specified in RFC 2460: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. note 2: additional recommendations regarding the relative order of the Authentication and Encapsulating Security Payload headers are given in [RFC-2406]. note 3: for options to be processed only by the final destination of the packet. At least for me, the above order assumes that a destination options header placed before an authentication header (or an ESP) should also be accompanied with a routing header. However, the mobile IPv6 draft does not mention a routing header at all (I guess the draft does not care about a routing header). Is my concern about the order correct? If so, at least I want the draft to describe the intention of the unrecommended order and possible effects on implementation. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 8 16:46:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e58Ni3Z23982 for ipng-dist; Thu, 8 Jun 2000 16:44:03 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e58Nhp623975 for ; Thu, 8 Jun 2000 16:43:52 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e58NhpE627249 for ; Thu, 8 Jun 2000 16:43:51 -0700 (PDT) Date: Thu, 8 Jun 2000 16:43:30 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: WG Last Call on IPv6 allocation guidelines (Fwd) To: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200006070202.TAA15948@dthaler.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >----------------Begin Forwarded Message----------------< Date: Tue, 6 Jun 2000 19:02:18 -0700 (PDT) From: "Dave Thaler" Subject: WG Last Call on IPv6 allocation guidelines To: malloc@catarina.usc.edu This message opens a WG Last Call on the Internet Draft described below (the one on IPv6 allocation guidelines). Please send your comments to the list by June 20. Thanks, Dave Thaler MALLOC WG Co-chair ----- Forwarded message from Internet-Drafts@ietf.org ----- To: IETF-Announce: ; Cc: malloc@catarina.usc.edu From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-malloc-ipv6-guide-00.txt Date: Tue, 30 May 2000 06:35:02 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast-Address Allocation Working Group of the IETF. Title : Dynamic Allocation Guidelines for IPv6 Multicast Addresses Author(s) : B. Haberman Filename : draft-ietf-malloc-ipv6-guide-00.txt Pages : 5 Date : 26-May-00 With the current multicast address architecture and the proposed multicast address architecture, a set of guidelines is needed for multicast address allocation servers to use in assigning IPv6 multicast addresses. The purpose of these rules is to reduce the possibility of address collision not only at layer 3, but also on devices at layer 2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-ipv6-guide-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-malloc-ipv6-guide-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-malloc-ipv6-guide-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. [message/External-body is not supported, skipping...] ----- End of forwarded message from Internet-Drafts@ietf.org ----- >----------------End Forwarded Message----------------< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 9 06:13:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e59DBn024790 for ipng-dist; Fri, 9 Jun 2000 06:11:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e59DBe624783 for ; Fri, 9 Jun 2000 06:11:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA02606 for ; Fri, 9 Jun 2000 06:11:41 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA12772 for ; Fri, 9 Jun 2000 06:11:37 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id DA123377; Fri, 9 Jun 2000 08:11:36 -0500 (CDT) Received: from anw.zk3.dec.com (abelia.zk3.dec.com [16.140.64.63]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 87D4D214; Fri, 9 Jun 2000 08:11:36 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000959880; Fri, 9 Jun 2000 09:11:30 -0400 (EDT) From: Jim Bound Message-Id: <200006091311.JAA0000959880@anw.zk3.dec.com> To: Juergen Schoenwaelder Cc: ipng@sunroof.eng.sun.com Subject: Re: (retry) rfc2553bis-00: nai_strerror() ? In-reply-to: Your message of "Thu, 08 Jun 2000 13:26:54 +0200." <200006081126.NAA10351@henkell.ibr.cs.tu-bs.de> Date: Fri, 09 Jun 2000 09:11:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am resending the message attached below since I did not get any >answers so far. Is the question really so stupid? >I am sure this has been asked before. But anyway. After writing >some code according to RFC 2553, I was wondering why there is no >nai_strerror() function which works similar to gai_strerror(). We don't need an nai_strerror. We could put gai_sterror after getnameinfo and have it apply to both set of EAI_xxx error code sets. Comments. p.s. This is not a stupid question. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 9 08:48:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e59FkHu24875 for ipng-dist; Fri, 9 Jun 2000 08:46:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e59Fk7624868 for ; Fri, 9 Jun 2000 08:46:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22432 for ; Fri, 9 Jun 2000 08:46:08 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15385 for ; Fri, 9 Jun 2000 08:46:07 -0700 (PDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id EE34A22F7; Fri, 9 Jun 2000 10:46:06 -0500 (CDT) Received: from oflume.zk3.dec.com (broflume.zk3.dec.com [16.141.0.42]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 75ED7209A; Fri, 9 Jun 2000 10:46:06 -0500 (CDT) Received: from hunch.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id LAA0000030531; Fri, 9 Jun 2000 11:46:05 -0400 (EDT) Received: by hunch.zk3.dec.com (8.9.3/1.1.20.6/21Apr99-0623AM) id LAA0000110649; Fri, 9 Jun 2000 11:46:04 -0400 (EDT) Date: Fri, 9 Jun 2000 11:46:04 -0400 (EDT) From: Jack McCann Message-Id: <200006091546.LAA0000110649@hunch.zk3.dec.com> To: bound@zk3.dec.com, schoenw@ibr.cs.tu-bs.de Subject: Re: (retry) rfc2553bis-00: nai_strerror() ? Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I am sure this has been asked before. But anyway. After writing >>some code according to RFC 2553, I was wondering why there is no >>nai_strerror() function which works similar to gai_strerror(). > >We don't need an nai_strerror. We could put gai_sterror after >getnameinfo and have it apply to both set of EAI_xxx error code sets. > >Comments. We discussed this in XNET and arrived at the same conclusion: use the EAI_xxx error codes for both getaddrinfo and getnameinfo, and make the error descriptions from netdb.h/gai_strerror() generic enough to apply to both. I believe this is reflected in the update to rfc2553 (draft-ietf-ipngwg-rfc2553bis-00.txt). - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 9 11:14:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e59IBcs25271 for ipng-dist; Fri, 9 Jun 2000 11:11:38 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e59IBX625264 for ; Fri, 9 Jun 2000 11:11:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA19643 for ipng@sunroof.eng.sun.com; Fri, 9 Jun 2000 11:10:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e597A2624514 for ; Fri, 9 Jun 2000 00:10:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA10650 for ; Fri, 9 Jun 2000 00:10:02 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA12158 for ; Fri, 9 Jun 2000 01:10:01 -0600 (MDT) Received: from ecbull20.frec.bull.fr (ecbull20.frec.bull.fr [129.183.4.3]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA53332; Fri, 9 Jun 2000 09:13:01 +0200 Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1]) by ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id JAA14040; Fri, 9 Jun 2000 09:09:20 +0200 Received: from bull.net (localhost [127.0.0.1]) by isatis.frec.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA156998; Fri, 9 Jun 2000 09:09:19 +0200 (DFT) Message-ID: <3940981E.FC64AD7C@bull.net> Date: Fri, 09 Jun 2000 09:09:18 +0200 From: AIme Le-Rouzic Organization: Bull X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2) MIME-Version: 1.0 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM CC: ipng@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] a comment of draft-ietf-mobileip-ipv6-12.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In fact, the Home Address has to be also BEFORE the fragment header to allow firewalls to read it. Those firewalls can be on other destinations than those listed in the Routing Header. May be it needs to clarify to put a recommendation in RFC2460 or in the next RFC MobileIPv6 this special case. Best regards JINMEI Tatuya / $B?@L@C#:H(B wrote: > > Before finishing the last call for the mobile IPv6 draft, I'd like to > comment on the draft. > > I hope this is not too late, and apologize in advance if this has > already been discussed. > > Section 10.2 of the draft says as follows: > > - Since the mobile node is away from home, the mobile node inserts > a Home Address option into the packet, replacing the Source > Address in the packet's IP header with a care-of address suitable > for the link on which the packet is being sent, as described in > Section 10.1. The Destination Options header in which the Home > Address option is inserted MUST appear in the packet before the > AH [11] (or ESP [12]) header, so that the Home Address option is > processed by the destination node before the AH or ESP header is > processed. > > It seems to me that the order of the destination options header > including the home address option is not conformant to the recommended > order of extension headers specified in RFC 2460: > > When more than one extension header is used in the same packet, it is > recommended that those headers appear in the following order: > > IPv6 header > Hop-by-Hop Options header > Destination Options header (note 1) > Routing header > Fragment header > Authentication header (note 2) > Encapsulating Security Payload header (note 2) > Destination Options header (note 3) > upper-layer header > > note 1: for options to be processed by the first destination > that appears in the IPv6 Destination Address field > plus subsequent destinations listed in the Routing > header. > > note 2: additional recommendations regarding the relative > order of the Authentication and Encapsulating > Security Payload headers are given in [RFC-2406]. > > note 3: for options to be processed only by the final > destination of the packet. > > At least for me, the above order assumes that a destination options > header placed before an authentication header (or an ESP) should also > be accompanied with a routing header. However, the mobile IPv6 draft > does not mention a routing header at all (I guess the draft does not > care about a routing header). > > Is my concern about the order correct? If so, at least I want the > draft to describe the intention of the unrecommended order and > possible effects on implementation. > > Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- ________________________Aime LEROUZIC____________________________ BULL S.A ECHIROLLES FRANCE mailto:Aime.Lerouzic@frec.bull.fr http://www-frec.bull.com tel: +33 (0)4 76 29 75 51 Communications TCPIP http://intranet/lerouzic -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 23:28:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5A6QKM25773 for ipng-dist; Fri, 9 Jun 2000 23:26:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5A6Q6625766 for ; Fri, 9 Jun 2000 23:26:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA05890 for ; Fri, 9 Jun 2000 23:26:06 -0700 (PDT) Received: from web1005.mail.yahoo.com (web1005.mail.yahoo.com [128.11.23.95]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA10177 for ; Fri, 9 Jun 2000 23:26:06 -0700 (PDT) Received: (qmail 26131 invoked by uid 60001); 10 Jun 2000 06:26:05 -0000 Message-ID: <20000610062605.26130.qmail@web1005.mail.yahoo.com> Received: from [213.29.206.7] by web1005.mail.yahoo.com; Fri, 09 Jun 2000 23:26:05 PDT Date: Fri, 9 Jun 2000 23:26:05 -0700 (PDT) From: shahram tabandeh To: 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 Hi We are working on Segmentation and Reassembly problem of IPv6 over ATM. I have read rfc2492 related to this subject and published January 1999. It is a great help to us, if you can tell us whether those suggestions being accepted or not and whether there is some drafts or standards for this propos? Regards Shahram __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 11 19:32:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5C2V5g26337 for ipng-dist; Sun, 11 Jun 2000 19:31:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5C2Uu626330 for ; Sun, 11 Jun 2000 19:30:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA19191 for ; Sun, 11 Jun 2000 19:30:55 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA01108 for ; Sun, 11 Jun 2000 19:30:49 -0700 (PDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA06086; Mon, 12 Jun 2000 11:17:20 +0900 (JST) Date: Mon, 12 Jun 2000 11:26:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@enst-bretagne.fr Cc: ipng@sunroof.eng.sun.com Subject: Re: permission control for IPV6_REACHCONF In-Reply-To: In your message of "Sun, 28 May 2000 15:39:25 +0200" <200005281339.PAA82155@givry.rennes.enst-bretagne.fr> References: <23757.959295419@coconut.itojun.org> <200005281339.PAA82155@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 44 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 28 May 2000 15:39:25 +0200, >>>>> Francis Dupont said: >> Right, and I feel this is a tradeoff issue. I personally think it is >> okay not to restrict the use of the option as long as comments on the >> possible attacks are stated. What do others think? > => I believe this is the best solution. > I think it is unfortunate, but I vote for restrictive way (i.e. require > root privilege). another way may be to interpret, in the kernel, like > this: > - consider IPV6_REACHCONF from privileged user as very trustworthy > - consider IPV6_REACHCONF from normal user as less trustworthy > information, just as hint. do not 100% rely upon reachability > confirmation came from normal user. > not sure how to implement the latter. let me think. > => I think the word is more complex than root and normal users, there are > in modern OSs more than two levels of privileges then please keep the door > open, ie. a comment is enough. FYI: our (KAME's) latest implementation is as follows: - introduced a per-neighbor limitation that specifies how many times IPV6_REACHCONF could be issued. - each time IPV6_REACHCONF is issued, incremented a per-interface counter unless the counter is smaller than the limitation. - once the counter reached the limitation, further IPV6_REACHCONF would be ignored. - if a neighbor's reachability was confirmed by NUD, reset the counter for the neighbor. This procedure is always applied regardless of privilege. As for specification, we don't think this behavior should be documented in rfc2292bis (i.e. this is just our original workaround). However, we hope that rfc2292 mentions a confusing story about IPV6_REACHCONF that I pointed in the beginning of this thread. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 11 19:38:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5C2bM126363 for ipng-dist; Sun, 11 Jun 2000 19:37:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5C2bB626356 for ; Sun, 11 Jun 2000 19:37:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA19571 for ; Sun, 11 Jun 2000 19:37:10 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA15673 for ; Sun, 11 Jun 2000 20:37:09 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA23882; Mon, 12 Jun 2000 11:36:48 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Mon, 12 Jun 2000 11:26:59 JST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: permission control for IPV6_REACHCONF From: itojun@iijlab.net Date: Mon, 12 Jun 2000 11:36:48 +0900 Message-ID: <23880.960777408@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >FYI: our (KAME's) latest implementation is as follows: > >- introduced a per-neighbor limitation that specifies how many times > IPV6_REACHCONF could be issued. >- each time IPV6_REACHCONF is issued, incremented a per-interface > counter unless the counter is smaller than the limitation. small typo here: KAME has per-neighbor counter, not per-interface counter. (counter is in neighbor cache) >- once the counter reached the limitation, further IPV6_REACHCONF > would be ignored. >- if a neighbor's reachability was confirmed by NUD, reset the counter > for the neighbor. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 11 23:13:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5C6C6f26550 for ipng-dist; Sun, 11 Jun 2000 23:12:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5C6Bv626543 for ; Sun, 11 Jun 2000 23:11:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA20458 for ; Sun, 11 Jun 2000 23:11:53 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08370 for ; Mon, 12 Jun 2000 00:11:46 -0600 (MDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA11344; Mon, 12 Jun 2000 14:58:15 +0900 (JST) Date: Mon, 12 Jun 2000 15:07:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: msa@hemuli.tte.vtt.fi Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP and unknown extension headers? In-Reply-To: In your message of "Tue, 6 Jun 2000 13:04:01 +0300 (EET DST)" <200006061004.NAA15581@anise.tte.vtt.fi> References: <200006061004.NAA15581@anise.tte.vtt.fi> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 6 Jun 2000 13:04:01 +0300 (EET DST), >>>>> Markku Savela said: > The RFC-2460 in chapter 4 explains that one should return a "Parameter > Problem" ICMP for unrecognized extension header. This has an offset > pointing to the "next header field". > Question: What is the value of this offset, if the problematic "next > header" was uncovered by ESP processing? > Admittedly, ESP is a bad example, because one probably should not be > sending the ICMP in this case. But, there might be other future funny > extension headers that produce the next header value in strange > ways? Just as you said, I don't think it is meaningful to consider how an icmp6 error packet against an encrypted packet should be. Is this really your practical concern, or do you have another example of this kind of problem? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 11 23:29:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5C6Rdr26577 for ipng-dist; Sun, 11 Jun 2000 23:27:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5C6RM626570 for ; Sun, 11 Jun 2000 23:27:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA21300 for ; Sun, 11 Jun 2000 23:27:22 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA24518 for ; Sun, 11 Jun 2000 23:27:20 -0700 (PDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id JAA19073; Mon, 12 Jun 2000 09:27:08 +0300 (EET DST) Date: Mon, 12 Jun 2000 09:27:08 +0300 (EET DST) From: Markku Savela Message-Id: <200006120627.JAA19073@anise.tte.vtt.fi> To: jinmei@isl.rdc.toshiba.co.jp CC: ipng@sunroof.eng.sun.com In-reply-to: (jinmei@isl.rdc.toshiba.co.jp) Subject: Re: ICMP and unknown extension headers? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Just as you said, I don't think it is meaningful to consider how an > icmp6 error packet against an encrypted packet should be. Is this > really your practical concern, or do you have another example of this > kind of problem? Not really. ESP is just an example, that there are headers where an offset to the erroroneus value makes no sense. When such "problems" are uncovered, I just ask myself: is the specification truly clean? I just have architecture where extension headers can be defined and implemented in loadable handlers, ESP being one of them, means that the next header field must be returned by the handler in some way, because it does not occur in packet (after ESP). Thus the API of such handlers now has to be changed to return the offset for the ICMP in addition to actual next header value, for the case where the next header is unknown. (Or have some flag to tell that no offset is available, and assume all other headers follow the default IPv6 ext header layout...) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 12 00:23:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5C7LMg26625 for ipng-dist; Mon, 12 Jun 2000 00:21:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5C7LD626618 for ; Mon, 12 Jun 2000 00:21:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA23990 for ; Mon, 12 Jun 2000 00:21:13 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25891 for ; Mon, 12 Jun 2000 01:21:01 -0600 (MDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA11748; Mon, 12 Jun 2000 16:07:44 +0900 (JST) Date: Mon, 12 Jun 2000 16:17:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: NNARASIMHARAO@novell.com Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Host requirement specification In-Reply-To: In your message of "Wed, 07 Jun 2000 04:00:39 -0600" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 12 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 07 Jun 2000 04:00:39 -0600, >>>>> "Narsimharao Nagampalli" said: > Is there any host requirement specification for IPv6 nodes? Would appreciate any pointers. As far as I know, there's nothing so far. Maybe the working group is waiting for a volunteer for this topic... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 12 01:17:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5C8EvL26671 for ipng-dist; Mon, 12 Jun 2000 01:14:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5C8El626664 for ; Mon, 12 Jun 2000 01:14:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA07198 for ; Mon, 12 Jun 2000 01:14:46 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10996 for ; Mon, 12 Jun 2000 02:14:44 -0600 (MDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA12085; Mon, 12 Jun 2000 17:01:12 +0900 (JST) Date: Mon, 12 Jun 2000 17:10:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Aime.Le-Rouzic@bull.net Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] a comment of draft-ietf-mobileip-ipv6-12.txt In-Reply-To: In your message of "Fri, 09 Jun 2000 09:09:18 +0200" <3940981E.FC64AD7C@bull.net> References: <3940981E.FC64AD7C@bull.net> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 09 Jun 2000 09:09:18 +0200, >>>>> AIme Le-Rouzic said: > In fact, the Home Address has to be also BEFORE the fragment header to > allow firewalls to read it. Those firewalls > can be on other destinations than those listed in the Routing Header. > May be it needs to clarify to put a recommendation in RFC2460 or > in the next RFC MobileIPv6 this special case. Hmm, in any case, I hope the mobile IPv6 specification clarifies the ordering as long as it dares to break the recommendation in RFC2460 (which is already a draft-standard RFC), before the spec proceeds to an RFC status. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 12 02:12:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5C9AbP26739 for ipng-dist; Mon, 12 Jun 2000 02:10:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5C9AR626732 for ; Mon, 12 Jun 2000 02:10:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA10152 for ; Mon, 12 Jun 2000 02:10:26 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06745 for ; Mon, 12 Jun 2000 02:10:24 -0700 (PDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA12372; Mon, 12 Jun 2000 17:57:03 +0900 (JST) Date: Mon, 12 Jun 2000 18:06:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tabandeh@yahoo.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: In your message of "Fri, 9 Jun 2000 23:26:05 -0700 (PDT)" <20000610062605.26130.qmail@web1005.mail.yahoo.com> References: <20000610062605.26130.qmail@web1005.mail.yahoo.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 9 Jun 2000 23:26:05 -0700 (PDT), >>>>> shahram tabandeh said: > We are working on Segmentation and Reassembly problem > of IPv6 over ATM. I have read rfc2492 related to this > subject and published January 1999. > It is a great help to us, if you can tell us whether > those suggestions being accepted or not and whether > there is some drafts or standards for this propos? What exeactly do you mean by "Segmentation and Reassembly problem of IPv6 over ATM"? It seems to me RFC2492 does not mention such issues. Or do you mean the ATM-level negotiation on MTU described in Section 4.2 of the RFC? (But I'm still not sure what your concern is...) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 12 02:50:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5C9n9N26785 for ipng-dist; Mon, 12 Jun 2000 02:49:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5C9n0626778 for ; Mon, 12 Jun 2000 02:49:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA11920 for ; Mon, 12 Jun 2000 02:48:58 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16679 for ; Mon, 12 Jun 2000 02:48:55 -0700 (PDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA12636 for ; Mon, 12 Jun 2000 18:35:52 +0900 (JST) Date: Mon, 12 Jun 2000 18:45:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: permission control for IPV6_REACHCONF In-Reply-To: In your message of "Mon, 12 Jun 2000 11:36:48 +0900" <23880.960777408@coconut.itojun.org> References: <23880.960777408@coconut.itojun.org> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 12 Jun 2000 11:36:48 +0900, >>>>> itojun@iijlab.net said: >> FYI: our (KAME's) latest implementation is as follows: >> >> - introduced a per-neighbor limitation that specifies how many times >> IPV6_REACHCONF could be issued. >> - each time IPV6_REACHCONF is issued, incremented a per-interface >> counter unless the counter is smaller than the limitation. > small typo here: KAME has per-neighbor counter, not per-interface > counter. (counter is in neighbor cache) You're right. Thanks for the correction. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 12 07:00:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5CDwQU26936 for ipng-dist; Mon, 12 Jun 2000 06:58:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5CDwH626929 for ; Mon, 12 Jun 2000 06:58:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA27113 for ; Mon, 12 Jun 2000 06:58:17 -0700 (PDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05967 for ; Mon, 12 Jun 2000 06:58:17 -0700 (PDT) Received: from [171.68.181.6] (sj-dial-4-84.cisco.com [171.68.181.213]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id GAA17650; Mon, 12 Jun 2000 06:58:12 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006061004.NAA15581@anise.tte.vtt.fi> References: <200006061004.NAA15581@anise.tte.vtt.fi> Date: Mon, 12 Jun 2000 06:58:04 -0700 To: msa@hemuli.tte.vtt.fi (Markku Savela) From: Steve Deering Subject: Re: ICMP and unknown extension headers? Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:04 PM +0300 6/6/00, Markku Savela wrote: >The RFC-2460 in chapter 4 explains that one should return a "Parameter >Problem" ICMP for unrecognized extension header. This has an offset >pointing to the "next header field". > >Question: What is the value of this offset, if the problematic "next >header" was uncovered by ESP processing? It should be the offset of the byte containing the unrecognized or unsupported Next header value, counting from the beginning of the packet. >Admittedly, ESP is a bad example, because one probably should not be >sending the ICMP in this case. But, there might be other future funny >extension headers that produce the next header value in strange >ways? Every extension header has a Next Header field somewhere, and that field has some offset from the start of the packet, so what's the problem? >[Just asking before changing our implementation, which incorrectly(?) >returns ICMP Unreachable (type=1, code=4) for any protocol that >nobody listens. That is indeed incorrect. That error message should only be used for protocols that: - you *do* recognize - are known to have ports - have no process listening on the destination port - have no protocol-specific method to report the error (such as TCP reset). In practice, this means destination unreachable - port unreachable is only intended for UDP. (It's a little layer violation that it exists.) > Unknown extension header is just a protocol that has >no handler installed or activated]. That's fine. Such cases should be reported as parameter error - unrecognized next header. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 12 09:10:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5CG8nu27103 for ipng-dist; Mon, 12 Jun 2000 09:08:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5CG8c627096 for ; Mon, 12 Jun 2000 09:08:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA16245 for ; Mon, 12 Jun 2000 09:08:38 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21810 for ; Mon, 12 Jun 2000 09:08:37 -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 LAA13938 for ; Mon, 12 Jun 2000 11:08:36 -0500 (CDT) Message-Id: <200006121608.LAA13938@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: IPv6 Host requirement specification In-reply-to: Your message of Mon, 12 Jun 2000 16:17:22 +0900. Date: Mon, 12 Jun 2000 11:08:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Is there any host requirement specification for IPv6 nodes? Would > > appreciate any pointers. > > As far as I know, there's nothing so far. Maybe the working group is > waiting for a volunteer for this topic... The question has been raised >= twice before, with the response that it was too soon. It certainly seems appropriate to raise the question again, though. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 13 05:06:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5DC4Qd27652 for ipng-dist; Tue, 13 Jun 2000 05:04:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5DC4F627645 for ; Tue, 13 Jun 2000 05:04:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA07671 for ; Tue, 13 Jun 2000 05:04:14 -0700 (PDT) Received: from lychee.itojun.org (kame220.kame.net [203.178.141.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23401 for ; Tue, 13 Jun 2000 06:04:13 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e5DC2wk29283 for ; Tue, 13 Jun 2000 21:02:58 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: sin6_flowinfo and sendto/recvfrom 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, 13 Jun 2000 21:02:58 +0900 Message-ID: <29281.960897778@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello, I'm having hard time trying to remember sin6_flowinfo semantics. RFC2553/2292 are not very clear to me. for example, could someone answer these questions? (1) on recvfrom, how sin6_flowinfo should be filled? (2) on sendto, how will the kernel interpret sin6_flowinfo from the userland? (3) any other interface to manipulate traffic class/flow label? from my personal email archive, there are mixed opinions, and the discussion did not reflected into 2553/2292. - Eric's summary: (IPng 6324) (1) sin6_flowinfo will be filled by ip6->ip6_flow. (2) sin6_flowinfo will be copied into ip6->ip6_flow. if you do not want any special behavior, userland programs should fill it by 0. (3) nope. >No, it just means that the naive flow label unaware UDP application >needs to clear sin6_flowinfo in the address it got from recvfrom >before it uses that address in a sendto call. That is what we will document >here at Sun. - Alexey's summary: (IPng 6334) (1) sin6_flowinfo will be filled by zero. (2) sin6_flowinfo must carry traffic class bits only. (3) setsockopt or ancillary data (but how?). >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain >only class bits in sendto(). It is much more convenient to make with >setsockopt() or ancillary data. It seems to me that Eric is more in sync with the current documents, since there's no standard setsockopt nor ancillary data to manipulate traffic class/flow label fields. i'd love to see it clarificed in near future 2553bis/2292bis. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 13 05:09:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5DC8Qs27670 for ipng-dist; Tue, 13 Jun 2000 05:08:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5DC8F627663 for ; Tue, 13 Jun 2000 05:08:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA07931 for ; Tue, 13 Jun 2000 05:08:13 -0700 (PDT) Received: from lychee.itojun.org (kame220.kame.net [203.178.141.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16282 for ; Tue, 13 Jun 2000 05:08:13 -0700 (PDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e5DC75k29324 for ; Tue, 13 Jun 2000 21:07:05 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Tue, 13 Jun 2000 21:02:58 JST. <29281.960897778@lychee.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: sin6_flowinfo and sendto/recvfrom From: Jun-ichiro itojun Hagino Date: Tue, 13 Jun 2000 21:07:05 +0900 Message-ID: <29322.960898025@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > hello, I'm having hard time trying to remember sin6_flowinfo semantics. > RFC2553/2292 are not very clear to me. for example, could someone > answer these questions? > (1) on recvfrom, how sin6_flowinfo should be filled? > (2) on sendto, how will the kernel interpret sin6_flowinfo from the > userland? > (3) any other interface to manipulate traffic class/flow label? more questions (I could not find answer from my archive): (4) what happens if we connect(2) with sin6_flowinfo filled? my guess is that sin6_flowinfo sticks into pcb, and will be attached to every packet we will send. (5) what happens if we bind(2) with sin6_flowinfo filled? my guess is (a) to raise some error, or (b) accept packets only if they carry specified ip6->ip6_flow field. (6) what is the endian of sin6_flowinfo? I guess it is network byte order, since it appears on the wire. (7) what happens if the peer transmits packets with ip6->ip6_flow set, and it is connection oriented socket (SOCK_STREAM)? 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 Wed Jun 14 20:10:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5F38oh28887 for ipng-dist; Wed, 14 Jun 2000 20:08:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5F38e628880 for ; Wed, 14 Jun 2000 20:08:40 -0700 (PDT) Received: from fenris.spnusw.sun.com (halley.EBay.Sun.COM [129.150.111.35]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA23176 for ; Wed, 14 Jun 2000 20:08:39 -0700 (PDT) Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.3]) by fenris.spnusw.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08070 for ; Wed, 14 Jun 2000 19:55:52 -0700 (PDT) Received: from orpheus.amdahl.com (localhost [127.0.0.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id UAA04434 for ; Wed, 14 Jun 2000 20:08:38 -0700 (PDT) Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.253.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id UAA04430 for ; Wed, 14 Jun 2000 20:08:38 -0700 (PDT) Received: from fujitsuI.fujitsu.com (localhost [127.0.0.1]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id UAA11538 for ; Wed, 14 Jun 2000 20:08:37 -0700 (PDT) Received: from abroad.proxy.fujitsu.co.jp ([133.161.11.30]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id UAA11534 for ; Wed, 14 Jun 2000 20:08:36 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp by abroad.proxy.fujitsu.co.jp (8.9.3/3.7W-0006-Abroad Gateway) id MAA29987; Thu, 15 Jun 2000 12:08:35 +0900 (JST) Received: from mailserv.kawasaki.flab.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0006-Fujitsu Domain Master) id MAA25931; Thu, 15 Jun 2000 12:08:34 +0900 (JST) Received: from localhost (gifu.kawasaki.flab.fujitsu.co.jp [10.25.159.35]) by mailserv.kawasaki.flab.fujitsu.co.jp (8.8.8+Sun/8.8.8) with ESMTP id MAA08100 for ; Thu, 15 Jun 2000 12:08:33 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: MDO6-kit version 0.1 is now available. Reply-To: kimai@flab.fujitsu.co.jp Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mew version 1.92.4 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Message-Id: <20000615120513H.kimai@flab.fujitsu.co.jp> Date: Thu, 15 Jun 2000 12:05:13 +0900 From: IMAI Yuji X-Dispatcher: imput version 971024 Lines: 236 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry if you would get duplicated message. We are glad to release our MDO6-kit for the Internet research community. The MDO6(Multiple Destination Option on IPv6) is a experimental protocol that provides multicast system scalable in the number of multicast group, easy to deploy and suitable for small and private group communication. We release the MDO6-kit for the purpose to prove the validity of MDO6. MDO6-kit is be acuired from ftp://ftp.kame.net/pub/kame/contrib/mdo6/mdo6-kit-20000614.tar.gz (Special thanks for KAME project. http://www.kame.net) MDO6 is a one of the variants of xcast(Explicit Multicast for small groups) and we are now collaborating with xcast colleagues. Visit http://www.alcatel.com/xcast to know what xcast is. Here follows README file of MDO6-kit. Enjoy! ------------------------ MDO6 Team FUJITSU LABORATORIES LTD. ========================================================================= README -MDO6 kit for KAME version 0.1 - FUJITSU LABORATORIES LTD. Wed Jun 14 00:37:13 JST 2000 [What's MDO6.] The MDO6(Multiple Destination Option on IPv6) is an IPv6 multicast system that has following characters. - Scalability concerning with the number of multicast groups. - Multicast application programs can freely join and prune by adding/deleting destination addresses to/from a list of destinations without any request for intermediate routers on a multicast delivery tree. MDO6 is a kind of the Explicit Multicast that is a yet another multicast mechanism such that datagram has a list of unicast addresses as a destination of oneself. Several variants of the Elastic Multicast are proposed in IETF and we have collaborating group named xcast to achieve the standard of Explicit Multicast. See http://www.alcatel.com/xcast for more details about the explicit Multicast and the xcast group. [Kit] Current MDO6 kit includes 4 parts. - patch for KAME ( ./mdo6_for_kame228_200004.diff ) Based on the kame IPv6 protocol stack. (See http://www.kame.net) It is base on the KAME stable_200004. - vic/MDO6 ( ./vic/ ) vic(VIdeo Conference tool) was originally written by LNBL (http://www-nrg.ee.lbl.gov/vic/). This version is based on the UCLA version(). - rat/MDO6 ( ./rat ) - documents ( ./doc/ ) draft-imai-mdo6-01.txt: Internet Draft of MDO6. ja/EM6.tex: A memorandum of structure and API of MDO6 modification. (Sorry, it is written in Japanese.) README: This file. [Environment] We are driving our experiment network with following machines and cards. Hardware: i386 PC-ATs: Video Captured Card: Hauppauge! WinTV GO for PCI Using FreeBSD BT848/BT878 Driver version 1.74. ftp://telepresence.dmem.strath.ac.uk/pub/bt848/driver/1.74 Sound Card: AOpen AW35(CS4237 chip), SB16 Using build in pcm driver in FreeBSD 2.2.8 . Operating System: FreeBSD 2.2.8 IPv6 Protocol Stack KAME stable_200004 ftp://ftp.kame.net/pub/kame/stable/kame-20000425-freebsd228-stable.tgz [Install] - Patch for KAME i) acquire KAME source & mdo6 kit % setenv BASE_DIR `pwd` % tar zxfv kame-20000425-freebsd228-stable.tgz % tar zxfv mdo6-kit-20000614.tgz ii) patch the diff for KAME tree % cd $BASE_DIR % patch -p0 < $BASE_DIR/mdo6-kit-20000614/mdo6_kame_stable_200004.diff iii) build & install as same was as ordinal KAME. GENERIC.v6+EM6 is a sample configuration file for MDO6. In order to use MDO6, append ``option EM6'' in your CONFIGFILE. (MDO6 is formaly called EM6: Elastic Multicast over IPv6) You had better read KAME INSTALL documents first. You must append pcm(sound card) options and bt848(video capture) drivers if you try to use RAT or vic. See pcm manuals and documents for bt848 driver. % make TARGET=freebsd2 prepare % cd $BASE_DIR/kame/freebsd2/sys/i386/conf % config GENERIC.v6+EM6 % cd ../../compile/GENERIC.v6+EM6 % make depend % make # make install % cd $BASE_DIR/kame/freebsd2/ % make includes # make install-includes (/usr/include/em6lib.h & /usr/include/netinet/em6.h are installed.) % make ($BASE_DIR/kame/freebsd2/lib/libem6/libem6.a is build.) # make install (/usr/local/v6/lib/libem6.a is installed.) iv) Edit /usr/local/v6/etc/rc.net6, /etc/rc.local and /etc/inetd.conf. and reboot. - VIC i) add package of tcl7.5 & tk4.1 from FreeBSD 2.2.8 RELEASE pkg_add or use /stand/sysinstall will be convineint. ii) build, make & install % cd $BASE_DIR/mdo6-kit-20000614/vic % ./configure % make # make install You can specify the destination by -l option following ',' (comma) separated IPv6 addresses and hostnames instead of the group multicast address. You must specify dummy string name as a hostname but just ignored. % vic -n ip6 -l node1,3ffe:501:100d:4000::1234,node3 dummy/11111 - RAT i) build libraries.(Tcl, Tk and common) % cd $BASE_DIR/mdo6-kit-20000614/rat/tcl-8.0/unix % ./configure % make % cd $BASE_DIR/mdo6-kit-20000614/rat/tk-8.0/unix % ./configure % make % cd $BASE_DIR/mdo6-kit-20000614/rat/common/ % ./configure --enable-ipv6 --enable-mdo6 % make ii) build rat & install % cd $BASE_DIR/mdo6-kit-20000614/rat/rat % ./configure --enable-ipv6 --enable-mdo6 % make # make install iii) enjoy RAT/MDO6 You can specify the destination by ','(comma) separated IPv6 addresses and hostnames instead of the group multicast address. % rat-4.2.4 node1,3ffe:501:100d:4000::1234,node3/11111 [Contact] In order to discuss about MDO6, we maintained ML for users "mdo6-users@ml.flab.fujitsu.co.jp" . To subscribe, Send majordomo type control message like following. % mail mdo6-users-request@ml.flab.fujitsu.co.jp subscribe mdo6-users ^D If you wish to contact with core team directly, you can send message for "mdo6-core@ml.flab.fujitsu.co.jp". [Todo] - En-comment and clean up of em6.[ch], em6lib.h, libem6/*[ch] - Manuals - Code for FreeBSD[3,4], NetBSD and OpenBSD. - Tractable list mechanism is written but not tested at all. - Implement the port list option. - Distribute applications in FreeBSD package style. - bzflag/MDO6 is under development.... Enjoy! MDO6 Team FUJITSU LABORATORIES LTD. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 15 00:00:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5F6wYg29025 for ipng-dist; Wed, 14 Jun 2000 23:58:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5F6wN629018 for ; Wed, 14 Jun 2000 23:58:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA14979 for ; Wed, 14 Jun 2000 23:58:24 -0700 (PDT) Received: from un.cct.ydc.co.jp (ydcspingw.ydc.co.jp [202.33.211.252]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA07379 for ; Thu, 15 Jun 2000 00:58:21 -0600 (MDT) Received: from italy (Italy.cct.ydc.co.jp [10.21.0.135]) by un.cct.ydc.co.jp (8.9.1+3.1W/3.7W) with ESMTP id QAA03728 for ; Thu, 15 Jun 2000 16:00:57 +0900 (JST) Message-Id: <4.2.0.58.J.20000615155533.027994f0@un.cct.ydc.co.jp> X-Sender: miyata@imap.cct.ydc.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 15 Jun 2000 15:58:23 +0900 To: ipng@sunroof.eng.sun.com From: Hiroshi Miyata Subject: Change in schedule of TAHI Test Event Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! Today, we would like to inform you that there is a minor change in the schedule of the 2nd TAHI Interoperability Test Event: that is, the Test Event starts on July 15, Saturday, instead of July 16, Sunday. We are very sorry for the change and causing you troubles of rescheduling. For more information, please look up our web site: http://www.tahi.org.inop/2ndinterop.html For those who have not signed up for registration yet, please note that the registration will be closed soon! Looking forward to meeting you in Yokohama, With best regards ----------------------------- Hiroshi Miyata @ TAHI project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 15 01:45:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5F8hgH29181 for ipng-dist; Thu, 15 Jun 2000 01:43:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5F8gN629159; Thu, 15 Jun 2000 01:42:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA15034; Thu, 15 Jun 2000 01:42:21 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17311; Thu, 15 Jun 2000 02:42:21 -0600 (MDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id RAA24590; Thu, 15 Jun 2000 17:42: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 RAA16049; Thu, 15 Jun 2000 17:42: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 RAA28932; Thu, 15 Jun 2000 17:42:19 +0900 (JST) Date: Thu, 15 Jun 2000 17:42:54 +0900 (JST) Message-Id: <20000615.174254.15194874.kazu@Mew.org> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: IPv6 stuff on INET 2000 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b39 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, I would like to summarize the current status of IPv6 stuff on INET 2000: (1) Network Training Workshop (NTW) at Keio Univ. (not at Hokoyama), 7/10-14 I'm now negotiating with some track leaders whether or not we will be able to take time to give IPv6 tutorial for students from developing countries. Itojun and Kazu have committed to be tutors. (2) Network at the venue, Hotel, and the exhibition hall The network will be, of course, IPv6-ready including terminal clusters, external connectivity, and wireless LAN. We will also set up a TCP-relay tranlator. (3) TAHI event at the venue, 7/15-18 TAHI Project will hold the 2nd test events. See: http://www.tahi.org/inop/2ndinterop.html (4) IPv6 booth 7/14 Hot stage at the same room of the TAHI event 7/18 Building up the booth in the exhibition hall 7/19-21 Demo This is basically the same of IPv6 ShowCase, N+I 2000 Tokyo, which achieved great success. We will report this event later. Anyway, highlight of this booth would be as follows: - Router racks - Home routers - Hosts including Windows 2000, BSD, and Linux - IPv6 protocol analyzers - Web IE and Netscape Gaining access to IPv4 server via translators - Shooting game "Quake" - Video stream over 1394 (5) IPv6 session, 7/19 11:00-12:30 See: http://www.isoc.org/inet2000/schedule3e.html (6) IPv6 tutorial, 7/18 9:00-17:30 "IP Version 6 Primer", Florent Parent and Marc Blanchet --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 15 09:49:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FGkmp29544 for ipng-dist; Thu, 15 Jun 2000 09:46:48 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FGkb629537 for ; Thu, 15 Jun 2000 09:46:37 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e5FGhx0321093; Thu, 15 Jun 2000 09:43:59 -0700 (PDT) Date: Thu, 15 Jun 2000 09:45:44 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ICMP and unknown extension headers? To: Steve Deering Cc: Markku Savela , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Every extension header has a Next Header field somewhere, and that > field has some offset from the start of the packet, so what's the > problem? I think the stated problem is that extension headers past an ESP header it offset might not be well defined. For instance, ESP + destination options where the dstops header has an unknown next header field. Imagine an ESP algorithm that does compression (and encryption). Is the implementation supposed to determine at what offset the offending next header value "lived" in the packet that was received (i.e. in the encrypted and compressed packet). Or is the implementation supposed to derive some pseudo offset from the begining of the decrypted packet? Similar things might appear (but less severe) when there is a fragment header before the header which has an unknown next header field. I suspect many implementations remove the fragment header when the reassembly is done, which means that the next header offset the implementations return in ICMP errors would be off by the size of the fragmentation header. However, if the offending next header field doesn't fit in the first fragment then what should the correct offset be in an ICMP payoad type unknown? My assumption is that the offset is undefined both past ESP headers and when it doesn't fit in the first fragment. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 15 10:44:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FHfer29642 for ipng-dist; Thu, 15 Jun 2000 10:41:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FHfU629631 for ; Thu, 15 Jun 2000 10:41:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA07629; Thu, 15 Jun 2000 10:41:23 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09821; Thu, 15 Jun 2000 10:41:22 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id KAA26450; Thu, 15 Jun 2000 10:40:42 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Thu, 15 Jun 2000 10:41:11 -0700 To: Erik Nordmark From: Steve Deering Subject: Re: ICMP and unknown extension headers? Cc: Markku Savela , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:45 AM -0700 6/15/00, Erik Nordmark wrote: > > Every extension header has a Next Header field somewhere, and that > > field has some offset from the start of the packet, so what's the > > problem? > >I think the stated problem is that extension headers past an ESP header >it offset might not be well defined. For instance, ESP + destination options >where the dstops header has an unknown next header field. At the point in time at which one looks at a Next Header field and determines that its value is unknown, that field is at some known offset from the packet start (known to the node doing the inspection, that is). The packet (or as much of it as will fit) will be sent back to the source in the ICMP error message, and the offset will point to the troublesome Next Header field in that returned packet. >Imagine an ESP algorithm that does compression (and encryption). >Is the implementation supposed to determine at what offset >the offending next header value "lived" in the packet that was received >(i.e. in the encrypted and compressed packet). The receiver would have decrypted and decompressed the packet in order to examine the Next Header field. At that point, the location of the Next Header field is known. The location of the Next Header field *has* to be known in order to determine that it contains an unknown/unsupported value, doesn't it? >My assumption is that the offset is undefined both past ESP headers and >when it doesn't fit in the first fragment. The offset is always defined in the context of the packet (or partial packet) returned in the ICMP error message. 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 Jun 15 11:24:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FIMli29740 for ipng-dist; Thu, 15 Jun 2000 11:22:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FIMb629733 for ; Thu, 15 Jun 2000 11:22:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA29596; Thu, 15 Jun 2000 11:22:35 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10603; Thu, 15 Jun 2000 11:22:34 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id LAA29764; Thu, 15 Jun 2000 11:21:55 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Thu, 15 Jun 2000 11:22:24 -0700 To: Erik Nordmark From: Steve Deering Subject: Re: ICMP and unknown extension headers? Cc: Markku Savela , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:41 AM -0700 6/15/00, Steve Deering wrote: >The receiver would have decrypted and decompressed the packet in order to >examine the Next Header field. At that point, the location of the Next >Header field is known. The location of the Next Header field *has* to be >known in order to determine that it contains an unknown/unsupported value, >doesn't it? On second thought, an implementation obviously shouldn't be sending a decryption of a packet inside of an ICMP error message, so this case is moot. 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 Jun 15 11:33:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FIWTZ29783 for ipng-dist; Thu, 15 Jun 2000 11:32:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FIWK629776 for ; Thu, 15 Jun 2000 11:32:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA02291; Thu, 15 Jun 2000 11:32:19 -0700 (PDT) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17693; Thu, 15 Jun 2000 11:32:18 -0700 (PDT) Received: from sture.lysator.liu.se (nisse@sture.lysator.liu.se [130.236.254.21]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id UAA01352; Thu, 15 Jun 2000 20:31:41 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id UAA09890; Thu, 15 Jun 2000 20:31:35 +0200 (MET DST) To: Erik Nordmark Cc: Steve Deering , Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: ICMP and unknown extension headers? References: From: nisse@lysator.liu.se (Niels Möller) Date: 15 Jun 2000 20:31:35 +0200 In-Reply-To: Erik Nordmark's message of "Thu, 15 Jun 2000 09:45:44 -0700 (PDT)" Message-ID: Lines: 67 X-Mailer: Gnus v5.7/Emacs 20.5 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > > Every extension header has a Next Header field somewhere, and that > > field has some offset from the start of the packet, so what's the > > problem? > > I think the stated problem is that extension headers past an ESP header > it offset might not be well defined. For instance, ESP + destination options > where the dstops header has an unknown next header field. I believe it should be possible to define a sensible value for the offset, where "sensible" means that it should make some sense to the sender of the packet. > Imagine an ESP algorithm that does compression (and encryption). > Is the implementation supposed to determine at what offset > the offending next header value "lived" in the packet that was received > (i.e. in the encrypted and compressed packet). In this case, one way to define the offset is as the length of the packet up to and including the ESP header, plus the offset into the cleartext (i.e. *after* decryption and decompression) data protected by ESP. You could end up with an offset larger than the actual packet as it appeared on the wire, but that should not necessarily be a problem? > Or is the implementation supposed to derive some pseudo offset from > the begining of the decrypted packet? One way to do that would be to keep track of the total length of the headers already processed, and let each module handling a particular header, on error, return an offset into the data that module was supposed to handle, which the ip engine can add to the total when building a icmp error message. > Similar things might appear (but less severe) when there is a > fragment header before the header which has an unknown next header > field. > > I suspect many implementations remove the fragment header when the reassembly > is done, which means that the next header offset the implementations > return in ICMP errors would be off by the size of the fragmentation header. > However, if the offending next header field doesn't fit in the first fragment > then what should the correct offset be in an ICMP payoad type unknown? Hmm. Is it possible to apply ESP first and then fragment the resulting encrypted packet? If so, you might end up with a first fragment containing an ESP header and (after decryption) some partial but valid additional headers, and then the next fragment, after decryption, contains a bad header that should result in an ICMP error packet. That seems to make things more complicated. It seems that one needs some way to indicate if the offset is relative to an individual fragment or to some "logical" reassembled packet. > My assumption is that the offset is undefined both past ESP headers and > when it doesn't fit in the first fragment. I think it should be possible to define a reasonable offset value in all cases, but it might be simpler to make it possible to say "oops, I can't deal with this packet, but I won't go to the effort to tell you the offset of the header or data I'm having trouble with.". /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 15 12:22:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FJJbk29912 for ipng-dist; Thu, 15 Jun 2000 12:19:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FJJQ629905 for ; Thu, 15 Jun 2000 12:19:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13912; Thu, 15 Jun 2000 12:19:24 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11600; Thu, 15 Jun 2000 13:19:15 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id EAA29598; Fri, 16 Jun 2000 04:19:10 +0900 (JST) To: nisse@lysator.liu.se (Niels Mller) cc: Erik Nordmark , Steve Deering , Markku Savela , ipng@sunroof.eng.sun.com In-reply-to: nisse's message of 15 Jun 2000 20:31:35 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ICMP and unknown extension headers? From: itojun@iijlab.net Date: Fri, 16 Jun 2000 04:19:10 +0900 Message-ID: <29596.961096750@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please do read IPsec spec first.... >Is it possible to apply ESP first and then fragment the resulting >encrypted packet? that is how IPsec is specified. on sender side, you encrypt then fragment. If so, you might end up with a first fragment >containing an ESP header and (after decryption) some partial but valid >additional headers, and then the next fragment, after decryption, >contains a bad header that should result in an ICMP error packet. That >seems to make things more complicated. there is no need to worry about this. on receiver side, you will reassemble then decrypt. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 15 13:01:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FJrbZ29973 for ipng-dist; Thu, 15 Jun 2000 12:53:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FJrR629963 for ; Thu, 15 Jun 2000 12:53:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA10449; Thu, 15 Jun 2000 12:53:24 -0700 (PDT) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14683; Thu, 15 Jun 2000 12:53:22 -0700 (PDT) Received: from sture.lysator.liu.se (nisse@sture.lysator.liu.se [130.236.254.21]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id VAA05924; Thu, 15 Jun 2000 21:53:18 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id VAA10560; Thu, 15 Jun 2000 21:53:12 +0200 (MET DST) To: itojun@iijlab.net Cc: Erik Nordmark , Steve Deering , Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: ICMP and unknown extension headers? References: <29596.961096750@coconut.itojun.org> From: nisse@lysator.liu.se (Niels Möller) Date: 15 Jun 2000 21:53:11 +0200 In-Reply-To: itojun@iijlab.net's message of "Fri, 16 Jun 2000 04:19:10 +0900" Message-ID: Lines: 57 X-Mailer: Gnus v5.7/Emacs 20.5 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > Please do read IPsec spec first.... Sorry if I'm not updated on all of the relevant spec. > >If so, you might end up with a first fragment > >containing an ESP header and (after decryption) some partial but valid > >additional headers, and then the next fragment, after decryption, > >contains a bad header that should result in an ICMP error packet. That > >seems to make things more complicated. > > there is no need to worry about this. on receiver side, you will > reassemble then decrypt. In this context, the problem is how to report errors by ICMP. If you detect some problem (say an unknown header) *after* reassembly and decryption, how do you report the error? Do you compute the offset relative to the fragment that contained the cryptotext corresponding to the bad header (and if so, how would you define the offset if the data is compressed before encryption?), or do you compute it relative to an reassembled packet that never appeared on the wire? And as Steve pointed out, even if one computes the offset relative to the decrypted packet, one must not quote the decrypted packet in the ICMP packet. It seems that an ICMP packet should quote an initial segment of the *encrypted* packet (as much of it as is needed to reconstruct all data up to and including the data that caused the error), but compute an offset that is interpreted after the packet is decrypted. For interpreting the offset, the packet should be viewed as some random headers (that were sent in the clear) an ESP header additional headers and data *after* decryption and decompression, depending on the ESP and on the corresponding secret keys. Do we agree so far? But this kind of breaks down in the presence of fragmentation, where you need to be able to report errors (i) in the headers preceeding the ESP, (ii) in headers (or data) that appear only after decryption and possibly decompression, i.e. after ESP processing, (iii) in the cleartext headers (headers before the fragment header are sent in the clear, right?) of fragments other than the first. To me, a proper definition of the error offset seems possible but non-obvious, and appearantly it's not obvious to Markku or Erik either, so it needs to be spelled out clearly. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 15 13:02:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FJuri29983 for ipng-dist; Thu, 15 Jun 2000 12:56:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FJuf629976 for ; Thu, 15 Jun 2000 12:56:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA11253; Thu, 15 Jun 2000 12:56:36 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16781; Thu, 15 Jun 2000 12:56:35 -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 OAA06532; Thu, 15 Jun 2000 14:56:32 -0500 (CDT) Message-Id: <200006151956.OAA06532@gungnir.fnal.gov> To: Steve Deering Cc: Erik Nordmark , Markku Savela , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: ICMP and unknown extension headers? In-reply-to: Your message of Thu, 15 Jun 2000 11:22:24 PDT. Date: Thu, 15 Jun 2000 14:56:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On second thought, an implementation obviously shouldn't be sending a > decryption of a packet inside of an ICMP error message, so this case > is moot. Not at all. Either you send the ICMP error back down the same SA as the offending packet or, if the selectors don't permit that, you negotiate a new SA to send the error. This has been thought of before, although 2401 could be a lot clearer. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 15 13:19:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FK9hk00042 for ipng-dist; Thu, 15 Jun 2000 13:09:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FK9Y600035 for ; Thu, 15 Jun 2000 13:09:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA24837; Thu, 15 Jun 2000 13:09:33 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.hamachi.org [4.255.0.98]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18998; Thu, 15 Jun 2000 14:09:11 -0600 (MDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id UAA17411; Thu, 15 Jun 2000 20:09:02 GMT Message-Id: <200006152009.UAA17411@orchard.arlington.ma.us> To: "Matt Crawford" cc: Steve Deering , Erik Nordmark , Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: ICMP and unknown extension headers? In-Reply-To: Message from "Matt Crawford" of "Thu, 15 Jun 2000 14:56:32 CDT." <200006151956.OAA06532@gungnir.fnal.gov> Reply-to: sommerfeld@orchard.arlington.ma.us Date: Thu, 15 Jun 2000 16:09:02 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Not at all. Either you send the ICMP error back down the same SA as > the offending packet... Uhh, SA's are unidirectional. Perhaps you mean "send the ICMP packet using the same SA a normal, non-errored response would use.." - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 15 13:27:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FKLcJ00252 for ipng-dist; Thu, 15 Jun 2000 13:21:38 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FKLM600227 for ; Thu, 15 Jun 2000 13:21:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA27498; Thu, 15 Jun 2000 13:21:20 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28465; Thu, 15 Jun 2000 14:21:18 -0600 (MDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id XAA22329; Thu, 15 Jun 2000 23:21:13 +0300 (EET DST) Date: Thu, 15 Jun 2000 23:21:13 +0300 (EET DST) From: Markku Savela Message-Id: <200006152021.XAA22329@anise.tte.vtt.fi> To: sommerfeld@orchard.arlington.ma.us CC: crawdad@fnal.gov, deering@cisco.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200006152009.UAA17411@orchard.arlington.ma.us> (message from Bill Sommerfeld on Thu, 15 Jun 2000 16:09:02 -0400) Subject: Re: ICMP and unknown extension headers? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Uhh, SA's are unidirectional. Perhaps you mean "send the ICMP packet > using the same SA a normal, non-errored response would use.." This is what I have been thinking that would make sense. At least in IPv6 ICMP, the error messages are clearly distingquished. So I have been wondering if it would be a good rule as follows: for IPv6 ICMP Error reports, outbound: apply policy and IPSEC to the error packed based on the header of the received packet (except the src/dst swapped as if the packet were going out) inbound: the policy check on ICMP error packets is based on the contained header (not the outer ICMP). Thus, if the contained packet would have required some IPSEC operations, the *whole* ICMP error should have been protected by this IPSEC. Whether above would be useful, I don't know. I just know that in my code it would be fairly simple change: when extracting the parameters from the packet for selector search, I would just have a branch for ICMP error types to fetch the same values from the inner header... -- msa -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 15 15:06:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5FM4wj00487 for ipng-dist; Thu, 15 Jun 2000 15:04:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5FM4m600480 for ; Thu, 15 Jun 2000 15:04:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA24475; Thu, 15 Jun 2000 15:04:48 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17535; Thu, 15 Jun 2000 16:04:42 -0600 (MDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA14520; Thu, 15 Jun 2000 15:02:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: <29596.961096750@coconut.itojun.org> Date: Thu, 15 Jun 2000 15:03:09 -0700 To: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=96ller?= ) From: Steve Deering Subject: Re: ICMP and unknown extension headers? Cc: itojun@iijlab.net, Erik Nordmark , Markku Savela , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e5FM4n600481 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:53 PM +0200 6/15/00, Niels M–ller wrote: >To me, a proper definition of the error offset seems possible but >non-obvious, ..., so it needs to be spelled out clearly. The error offset (in the ICMP Pointer field) is an index into the returned packet or truncated packet carried in the payload of an ICMP error message, pointing to the Next Header field that contains the unknown/unsupported value that caused the ICMP error message to be sent. (In the unusual case where the problematical Next Header field does not fall within that part of the packet that fits within the ICMP error message, the offset points beyond the end of the returned packet, to where the field would be if it did fit.) I think that definition is clear enough. But that leaves open the question of what the returned packet itself should look like, in some of the unclear cases people have been talking about. My own opinion is that the returned packet or truncated packet should just be the packet in the form it (logically) appears in the memory of the receiver at the point in time when the unrecognized Next Header value is detected. By "logically", I mean assuming that the receiver is not stripping off and discarding headers as they are processed (except as specified for fragment reassembly) or scattering them around to separated places in memory. Thus, if the unrecognized value is in a header following a Fragment header, then the returned packet is the reassembled packet (or as much of the reassembled packet as will fit, if the whole packet doesn't fit). If the unrecognized value was found after decompressing a packet, the returned packet is the decompressed packet (if the security rules allow it to be sent at all). I don't think it matters that the returned packet might not be identical to something that was actually sent on the wire, and in fact it is likely to be more useful as a diagnostic tool if it contains the "processed" packet. I also think it would be an unwarranted burden to require implementations to keep around a copy of an unprocessed received packet, just in case an error message may have to be sent about it. 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 Thu Jun 15 22:34:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5G5VfR00701 for ipng-dist; Thu, 15 Jun 2000 22:31:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5G5VU600694 for ; Thu, 15 Jun 2000 22:31:30 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e5G5VRa154903; Thu, 15 Jun 2000 22:31:27 -0700 (PDT) Date: Thu, 15 Jun 2000 22:30:46 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ICMP and unknown extension headers? To: Steve Deering Cc: Erik Nordmark , Markku Savela , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At the point in time at which one looks at a Next Header field and > determines that its value is unknown, that field is at some known offset > from the packet start (known to the node doing the inspection, that is). > The packet (or as much of it as will fit) will be sent back to the source > in the ICMP error message, and the offset will point to the troublesome > Next Header field in that returned packet. Sorry for my confusion. I don't know what the security crowd thinks about decrypting a packet and then including at least part of that packet in an ICMP error that might be sent in the clear. But that is a different issue. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 16 01:14:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5G8BYn00993 for ipng-dist; Fri, 16 Jun 2000 01:11:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5G8BM600986 for ; Fri, 16 Jun 2000 01:11:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA23717 for ; Fri, 16 Jun 2000 01:11:22 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA25716 for ; Fri, 16 Jun 2000 02:11:21 -0600 (MDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id B1CAB1E00C; Fri, 16 Jun 2000 04:11:20 -0400 (EDT) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id EAA12016; Fri, 16 Jun 2000 04:11:19 -0400 (EDT) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 0D65635DC2; Fri, 16 Jun 2000 04:11:19 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Erik Nordmark Cc: Steve Deering , Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: ICMP and unknown extension headers? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jun 2000 04:11:18 -0400 Message-Id: <20000616081119.0D65635DC2@smb.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Erik Nordmark w rites: > >> At the point in time at which one looks at a Next Header field and >> determines that its value is unknown, that field is at some known offset >> from the packet start (known to the node doing the inspection, that is). >> The packet (or as much of it as will fit) will be sent back to the source >> in the ICMP error message, and the offset will point to the troublesome >> Next Header field in that returned packet. > >Sorry for my confusion. > >I don't know what the security crowd thinks about decrypting a packet >and then including at least part of that packet in an ICMP error >that might be sent in the clear. But that is a different issue. > The security folks *really* don't like that sort of thing... If it's sent encrypted, any replies containing it MUST be encrypted. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 17 12:00:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5HIwBw02389 for ipng-dist; Sat, 17 Jun 2000 11:58:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5HIw1602382 for ; Sat, 17 Jun 2000 11:58:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA13390 for ; Sat, 17 Jun 2000 11:58:00 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01636 for ; Sat, 17 Jun 2000 12:57:59 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5HIviK36490; Sat, 17 Jun 2000 20:57:44 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA19328; Sat, 17 Jun 2000 20:57:43 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id UAA84840; Sat, 17 Jun 2000 20:59:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006171859.UAA84840@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: "IPng List (E-mail)" , "Thomas Narten (E-mail)" Subject: Re: problems with privacy draft In-reply-to: Your message of Tue, 06 Jun 2000 17:20:19 PDT. <4D0A23B3F74DD111ACCD00805F31D8101CA221AA@RED-MSG-50> Date: Sat, 17 Jun 2000 20:59:24 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe you can make your set of rules simpler if you introduce a new lifetime (or condition if one needs something smarter than a delay). I'll call it "regen lifetime" and when the regen lifetime of an anonymous address expires then a new address is created, checked by DAD then is used as the anonymous address, the old one is deprecated. With this we can keep the current deprecated/invalid mechanism on RA receptions (this is complex enough with the two hour rule and all the side effects we can get from short lifetimes (mis)used for mobility). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 17 12:12:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5HJAZO02428 for ipng-dist; Sat, 17 Jun 2000 12:10:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5HJAQ602421 for ; Sat, 17 Jun 2000 12:10:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA05250 for ; Sat, 17 Jun 2000 12:10:25 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18587 for ; Sat, 17 Jun 2000 12:10:23 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5HJAFK18239; Sat, 17 Jun 2000 21:10:16 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA19410; Sat, 17 Jun 2000 21:10:14 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id VAA84897; Sat, 17 Jun 2000 21:11:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006171911.VAA84897@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dave Thaler" cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Wed, 07 Jun 2000 11:37:07 PDT. <19398D273324D3118A2B0008C7E9A5690C6F7A6D@SIT.platinum.corp.microsoft.com> Date: Sat, 17 Jun 2000 21:11:56 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote (after reformatting into text): 3) When multicast addresses are stored in a sockaddr_in6, how is the scope id field Interpreted? => I believe it should be an interface index because it is the way it works today (or before scope id introduction if you prefer :-): IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with interface sets. Another point en passant, should in this case a bind() with a non-zero scope_id do an automatical IPV6_JOIN_GROUP? Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 19 00:18:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5J7FhS03105 for ipng-dist; Mon, 19 Jun 2000 00:15:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5J7FG603098 for ; Mon, 19 Jun 2000 00:15:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA24332 for ; Mon, 19 Jun 2000 00:15:17 -0700 (PDT) Received: from mmu.edu.my (ext-dns.mmu.edu.my [203.106.62.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14255 for ; Mon, 19 Jun 2000 01:15:15 -0600 (MDT) Received: from venus.cyber.mmu.edu.my (venus.cyber.mmu.edu.my [203.106.62.12]) by mmu.edu.my (8.9.1b+Sun/8.9.1) with ESMTP id PAA29502 for ; Mon, 19 Jun 2000 15:01:35 +0800 (MYT) Received: from Ettikan.cyber.mmu.edu.my ([10.100.24.81]) by venus.cyber.mmu.edu.my (8.8.8+Sun/8.8.8) with SMTP id PAA16761 for ; Mon, 19 Jun 2000 15:12:51 +0800 (SGT) Message-ID: <002b01bfd9bd$e59d4980$5118640a@Ettikan.cyber.mmu.edu.my> From: "Ettikan" To: Subject: IPv6 Network Simulators Date: Mon, 19 Jun 2000 15:13:38 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01BFDA00.F236DC40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01BFDA00.F236DC40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 Are there any kind of Network Simulators for IPv6 !! If there are, please kindly pass me the details. If aren't, do feel free to suggest = any simulators that can be modified !!! Thanks for your information. -ettikan ------=_NextPart_000_0028_01BFDA00.F236DC40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
     Are there = any kind of=20 Network Simulators for IPv6 !!  If there are,
please kindly = pass me the=20 details. If aren't, do feel free to suggest  any
simulators that can be modified !!!
 
Thanks for your = information.
 
-ettikan
------=_NextPart_000_0028_01BFDA00.F236DC40-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 19 09:39:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5JGan203655 for ipng-dist; Mon, 19 Jun 2000 09:36:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5JGad603648 for ; Mon, 19 Jun 2000 09:36:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA19747 for ; Mon, 19 Jun 2000 09:36:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05018 for ; Mon, 19 Jun 2000 10:36:38 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA10027; Mon, 19 Jun 2000 09:36:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA12585; Mon, 19 Jun 2000 09:36:28 -0700 X-Virus-Scanned: Mon, 19 Jun 2000 09:36:28 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma012100; Mon, 19 Jun 00 09:36:16 -0700 Message-Id: <4.3.2.7.2.20000619093150.024a7028@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jun 2000 09:34:19 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol Author(s) : B. Haberman, R. Worzella Filename : draft-ietf-ipngwg-mld-mib-03.txt Pages : 14 Date : 05-Jun-00 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on July 3, 2000. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 19 12:00:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5JIwPS03760 for ipng-dist; Mon, 19 Jun 2000 11:58:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5JIwF603753 for ; Mon, 19 Jun 2000 11:58:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA21243 for ; Mon, 19 Jun 2000 11:58:14 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18930 for ; Mon, 19 Jun 2000 12:58:13 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24004; Mon, 19 Jun 2000 11:48:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA09971; Mon, 19 Jun 2000 11:48:58 -0700 X-Virus-Scanned: Mon, 19 Jun 2000 11:48:58 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma009700; Mon, 19 Jun 00 11:48:48 -0700 Message-Id: <4.3.2.7.2.20000619114236.024a7028@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Jun 2000 11:46:52 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Request for Agenda Items for Pittsburgh IPng Sessions Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are starting to work on the agenda for the Pittsburgh IETF meeting. Please send requests to us for agenda slots. Thanks, Bob Hinden / Steve Deering IPng Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 20 03:27:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5KAPCk04573 for ipng-dist; Tue, 20 Jun 2000 03:25:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5KAP1604566 for ; Tue, 20 Jun 2000 03:25:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA25135 for ; Tue, 20 Jun 2000 03:24:59 -0700 (PDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27693 for ; Tue, 20 Jun 2000 04:24:57 -0600 (MDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id MAA21694; Tue, 20 Jun 2000 12:24:55 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id MAA26827; Tue, 20 Jun 2000 12:24:54 +0200 Date: Tue, 20 Jun 2000 12:24:54 +0200 Message-Id: <200006201024.MAA26827@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: ipng@sunroof.eng.sun.com In-reply-to: <4.3.2.7.2.20000619093150.024a7028@mailhost.iprg.nokia.com> (message from Bob Hinden on Mon, 19 Jun 2000 09:34:19 -0700) Subject: Re: W.G. Last Call on "IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol" References: <4.3.2.7.2.20000619093150.024a7028@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> Bob Hinden writes: Bob> This is a IPng working group last call for comments on advancing Bob> the following document as a Proposed Standard: Bob> Title : IP Version 6 Management Information Base for the Bob> Multicast Listener Discovery Protocol Author(s) : B. Haberman, Bob> R. Worzella Filename : draft-ietf-ipngwg-mld-mib-03.txt Pages : Bob> 14 Date : 05-Jun-00 There are several syntactical errors in the MIB module (see list below). But some other suggestions for improvements first: 1: Change the MIB module name to IPV6-MLD-MIB since the MIB is IPv6 only and the naming scheme would be consistent with IPV6-ICMP-MIB IPV6-MIB IPV6-TC IPV6-TCP-MIB IPV6-UDP-MIB. 2: What is the purpose of the mld OID node? Why are the tables not directly registered below mldMIBObjects? 3: Why is mldInterfaceIfIndex of type Ipv6IfIndexOrZero and not of type Ipv6IfIndex? Note that the Ipv6IfIndexOrZero requires to define when the value zero is being used. 4: mldInterfaceQueryInterval allows negative intervals. Perhaps adding a range restriction or using Unsigned32 makes more sense? 5: The description of mldInterfaceStatus talks about enabling/disabling MLD. Is this really being done via row creation and deletion? Or should rows not exist all the time and you have the usual mldInterfaceAdminStatus/mldInterfaceOperStatus combination? BTW, what is the persistence of such a change? Will it survive a reboot? 6: mldInterfaceVersion: can it be negative? Is there a reference to an MLD document which defines a version number? Or where is the default value 1 coming from? 7: mldInterfaceQueryMaxResponseDelay: Negative seconds? 8: mldInterfaceRobustness: Negative robustness? Reference to the robustness definition in the MLD specification? 9: mldInterfaceLastListenQueryIntvl: Negative seconds? 10: mldCacheIfIndex: when do I use the value 0? 11: mldCacheStatus: What exactly does the mldCacheStatus do? Can I create new cache entries via row creation? What does it mean to bring a row into a notInService state? What is the persistence of a row addition? Will it survive a reboot? 12: Row creation/deletion in the mldCacheTable is required for conformance while row creation/deletion in the mldInterfaceTable is not required for conformance. Is that by accident or by intention? 13: Any reason why mldInterfaceLastListenQueryIntvl is not spelled out as mldInterfaceLastListenQueryInterval? Note that mldInterfaceQueryInterval is already spelled out and mldInterfaceQueryMaxResponseDelay is longer than 32 characters anyway. Now to the syntactical errors: S1: Need to import InterfaceIndexOrZero from IF-MIB. S2: The REVISION statement should be: REVISION "200006021500Z" DESCRIPTION "Initial version, published as RFC XXXX." S3: OBJECT-TYPE missing after mldInterfaceProxtIfIndex S4: mldInterfaceProxtIfIndex should really be mldInterfaceProxyIfIndex (spelling of proxy) S5: final " missing in some DESCRIPTION clauses S6: MldMIBGroups must be mldMIBGroups (capitalization) S7: The descriptors mldInterfaceProxyIfIndex, mldInterfaceQueryMaxResponseTime and mldInterfaceLastMemQueryIntvl are used in the group definitions but not defined with this name /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 17:10:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5L08a305068 for ipng-dist; Tue, 20 Jun 2000 17:08:36 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5L08S605061 for ; Tue, 20 Jun 2000 17:08:29 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id RAA06833 for ipng@sunroof.eng.sun.com; Tue, 20 Jun 2000 17:07:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5L02p605049 for ; Tue, 20 Jun 2000 17:02:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA16085 for ; Tue, 20 Jun 2000 17:02:46 -0700 (PDT) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA14191 for ; Tue, 20 Jun 2000 17:02:45 -0700 (PDT) Received: from gopal (dhcp-171-70-57-4.cisco.com [171.70.57.4]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id RAA20348; Tue, 20 Jun 2000 17:02:44 -0700 (PDT) Message-Id: <4.1.20000620165828.02167290@omega.cisco.com> X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 20 Jun 2000 17:08:20 -0700 To: ipng@sunroof.eng.sun.com From: Gopal Dommety Subject: Next Header Cc: gdommety@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello: In IPv6 the next header is a 8 bit field. Is this limiting (i.e, I can have only 255 values)? Thanks Gopal -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 20 20:32:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5L3UFi05182 for ipng-dist; Tue, 20 Jun 2000 20:30:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5L3U6605175 for ; Tue, 20 Jun 2000 20:30:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA15748 for ; Tue, 20 Jun 2000 20:30:05 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA27602 for ; Tue, 20 Jun 2000 21:30:05 -0600 (MDT) Received: from [10.19.238.179] (atlantis-dial-1-95.cisco.com [171.68.181.96]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id UAA15190; Tue, 20 Jun 2000 20:29:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4.1.20000620165828.02167290@omega.cisco.com> References: <4.1.20000620165828.02167290@omega.cisco.com> Date: Tue, 20 Jun 2000 20:29:43 -0700 To: Gopal Dommety From: Steve Deering Subject: Re: Next Header Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:08 PM -0700 6/20/00, Gopal Dommety wrote: > In IPv6 the next header is a 8 bit field. Is this limiting (i.e, I can have only 255 values)? Gopal, In the unlikely event that we someday use up the 8-bit Next Header / Protocol numbering space, we could invent another extension header (identified by the last remaining 8-bit value) that contains a 16-bit (or 32-bit or whatever) field to identify a whole bunch more Next Header types. So, no, it is not limiting. 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 Jun 21 13:50:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LKmWr06074 for ipng-dist; Wed, 21 Jun 2000 13:48:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LKmH606066 for ; Wed, 21 Jun 2000 13:48:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA17702 for ; Wed, 21 Jun 2000 13:48:16 -0700 (PDT) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02585 for ; Wed, 21 Jun 2000 14:48:12 -0600 (MDT) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id FAA22808; Thu, 22 Jun 2000 05:48:05 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id FAA20872; Thu, 22 Jun 2000 05:48:05 +0900 (JST) Received: from localhost (kddlon0211.mobile.toshiba.co.jp [10.1.11.30]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id FAA12929; Thu, 22 Jun 2000 05:48:02 +0900 (JST) Date: Wed, 21 Jun 2000 08:34:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP and unknown extension headers? In-Reply-To: In your message of "Thu, 15 Jun 2000 15:03:09 -0700" References: <29596.961096750@coconut.itojun.org> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 15 Jun 2000 15:03:09 -0700, >>>>> Steve Deering said: > Thus, if the unrecognized value is in a header following a Fragment header, > then the returned packet is the reassembled packet (or as much of the > reassembled packet as will fit, if the whole packet doesn't fit). Agreed. > If the > unrecognized value was found after decompressing a packet, the returned ^^^^^^^^^^^^^you mean decrypting? > packet is the decompressed packet (if the security rules allow it to be > sent at all). Agreed, although (if you meant decrypting) security folks would think the error should not be sent as a security point of view. (If you just meant a compressed packet, I completely agree with you.) ICMP error packets are just for diagnosis. A receiver of the error should not care about how the returned packet look like, as long as the receiver can detect the point of the error correctly. I'm not sure whether this should explicitly stated in an ipng document, but it would be useful information for implementors. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 21 13:50:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LKmRO06073 for ipng-dist; Wed, 21 Jun 2000 13:48:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LKmD606058 for ; Wed, 21 Jun 2000 13:48:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA00699 for ; Wed, 21 Jun 2000 13:48:08 -0700 (PDT) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02501 for ; Wed, 21 Jun 2000 14:48:04 -0600 (MDT) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id FAA22792; Thu, 22 Jun 2000 05:47:52 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id FAA20856; Thu, 22 Jun 2000 05:47:52 +0900 (JST) Received: from localhost (kddlon0211.mobile.toshiba.co.jp [10.1.11.30]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id FAA12902; Thu, 22 Jun 2000 05:47:49 +0900 (JST) Date: Wed, 21 Jun 2000 07:50:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: msa@hemuli.tte.vtt.fi Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP and unknown extension headers? In-Reply-To: In your message of "Thu, 15 Jun 2000 23:21:13 +0300 (EET DST)" <200006152021.XAA22329@anise.tte.vtt.fi> References: <200006152009.UAA17411@orchard.arlington.ma.us> <200006152021.XAA22329@anise.tte.vtt.fi> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 15 Jun 2000 23:21:13 +0300 (EET DST), >>>>> Markku Savela said: > This is what I have been thinking that would make sense. At least in > IPv6 ICMP, the error messages are clearly distingquished. So I have > been wondering if it would be a good rule as follows: > for IPv6 ICMP Error reports, > outbound: apply policy and IPSEC to the error packed based on the > header of the received packet (except the src/dst swapped as if the > packet were going out) > inbound: the policy check on ICMP error packets is based on the > contained header (not the outer ICMP). Thus, if the contained packet > would have required some IPSEC operations, the *whole* ICMP error > should have been protected by this IPSEC. But how can you examine the contained header, which might be encrypted, for the policy check? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 21 15:54:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LMq8E06223 for ipng-dist; Wed, 21 Jun 2000 15:52:08 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LMpn606211 for ; Wed, 21 Jun 2000 15:51:50 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e5LMpma906731; Wed, 21 Jun 2000 15:51:48 -0700 (PDT) Date: Wed, 21 Jun 2000 10:56:23 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: sin6_flowinfo and sendto/recvfrom To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > more questions (I could not find answer from my archive): > (4) what happens if we connect(2) with sin6_flowinfo filled? > my guess is that sin6_flowinfo sticks into pcb, and > will be attached to every packet we will send. My assumption is the same as your guess. > (5) what happens if we bind(2) with sin6_flowinfo filled? > my guess is (a) to raise some error, or (b) accept packets > only if they carry specified ip6->ip6_flow field. Or c) silently ignore the sin6_flowinfo field. Doing b) adds code to the critical lookup code, and I don't see any need for that. So either a) or c) are fine with me. > (6) what is the endian of sin6_flowinfo? > I guess it is network byte order, since it appears on the wire. Doesn't the basic API say that everything is in network byte order? There used to be some macros to take apart the flowinfo into a tclass and a flowlabel but I can't find those in 2553 for 2292bis. Those macros were different based on byte order which indicates that the interpretation was network byte order for sin6_flowinfo. Clarifying this in RFC2553 would be good. > (7) what happens if the peer transmits packets with ip6->ip6_flow set, > and it is connection oriented socket (SOCK_STREAM)? Are you concerned about different packets arriving with different tclass or flowlabel for a single connection? I don't think the receiving TCP should care. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 21 15:54:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LMq8F06222 for ipng-dist; Wed, 21 Jun 2000 15:52:08 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LMpm606207 for ; Wed, 21 Jun 2000 15:51:48 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e5LMpla906704; Wed, 21 Jun 2000 15:51:47 -0700 (PDT) Date: Wed, 21 Jun 2000 10:47:28 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: sin6_flowinfo and sendto/recvfrom To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain > >only class bits in sendto(). It is much more convenient to make with > >setsockopt() or ancillary data. My take it also that accept() should behave the same as recvfrom, since a native application might take the address returned by accept() and use it in a subsequent connect() or sendto(). But why do you think that you can only use the traffic class component in sendto()? (and connect() I assume) I don't see the need for that restriction. > It seems to me that Eric is more in sync with the current documents, > since there's no standard setsockopt nor ancillary data to manipulate > traffic class/flow label fields. > > i'd love to see it clarificed in near future 2553bis/2292bis. This has recently come up as a potential porting issue: applications which use the IP_TOS setsockopt with IPv4 to set the diffserv bits can't easily be ported to IPv6. Should we add an IPV6_TCLASS socket option? Presumably if we do it can be used both with setsockopt and as ancillary data. How about a separate IPV6_FLOWID socket option to be complete? Since recv*() can't set sin6_flowinfo do we need a way for an application to retrieve the tclass and flowid? That would imply additional IPV6_RECV* options to enable the receipt of ancillary data. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 21 16:17:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LNET906268 for ipng-dist; Wed, 21 Jun 2000 16:14:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LNEH606261 for ; Wed, 21 Jun 2000 16:14:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA11277; Wed, 21 Jun 2000 16:14:17 -0700 (PDT) Received: from lychee.itojun.org (dhcp107.conference.usenix.org [209.179.127.107]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28332; Wed, 21 Jun 2000 16:14:14 -0700 (PDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e5LNCww00717; Thu, 22 Jun 2000 08:12:58 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 21 Jun 2000 10:56:23 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: sin6_flowinfo and sendto/recvfrom From: Jun-ichiro itojun Hagino Date: Thu, 22 Jun 2000 08:12:58 +0900 Message-ID: <715.961629178@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello, >> (6) what is the endian of sin6_flowinfo? >> I guess it is network byte order, since it appears on the wire. >Doesn't the basic API say that everything is in network byte order? >There used to be some macros to take apart the flowinfo into a tclass >and a flowlabel but I can't find those in 2553 for 2292bis. >Those macros were different based on byte order which indicates that the >interpretation was network byte order for sin6_flowinfo. >Clarifying this in RFC2553 would be good. RFC2553 does not really talk about endian issue. i agree clarification would be nice. summary is like below: sin6_len (44BSD only) single byte, so order does not matter sin6_family non-44BSD: host order, 44BSD: single bye sin6_port net order sin6_flowinfo net order sin6_addr net order sin6_scope_id host order the last one may be wrong. i remember there were some discussons on this, and the conclusion was (IIRC) that sin6_scope_id is host endian since it does not appear on the wire. >> (7) what happens if the peer transmits packets with ip6->ip6_flow set, >> and it is connection oriented socket (SOCK_STREAM)? >Are you concerned about different packets arriving with different tclass or >flowlabel for a single connection? >I don't think the receiving TCP should care. yes, i was concerned about the issue. i'm okay TCP should not care as long as it is documented. this rejects (b) in question (5), quoted below: >> (5) what happens if we bind(2) with sin6_flowinfo filled? >> my guess is (a) to raise some error, or (b) accept packets >> only if they carry specified ip6->ip6_flow field. >Or c) silently ignore the sin6_flowinfo field. >Doing b) adds code to the critical lookup code, and I don't see any need >for that. So either a) or c) are fine with me. 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 Wed Jun 21 16:20:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LNISp06286 for ipng-dist; Wed, 21 Jun 2000 16:18:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LNII606279 for ; Wed, 21 Jun 2000 16:18:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA15185 for ; Wed, 21 Jun 2000 16:18:19 -0700 (PDT) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA12861 for ; Wed, 21 Jun 2000 17:18:18 -0600 (MDT) Received: from [209.179.127.143] (ssh.cisco.com [171.69.10.34]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA03282; Wed, 21 Jun 2000 16:17:39 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: References: <29596.961096750@coconut.itojun.org> Date: Wed, 21 Jun 2000 16:17:12 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: ICMP and unknown extension headers? Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:34 AM +0900 6/21/00, JINMEI Tatuya wrote: > >>>>> Steve Deering said: > > If the > > unrecognized value was found after decompressing a packet, the returned > ^^^^^^^^^^^^^you mean decrypting? > > packet is the decompressed packet (if the security rules allow it to be > > sent at all). I did mean decompressing. I thought someone brought up the example of using the ESP encapsulation to implement compression (or maybe using a new kind of extension header for compression). 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 Jun 21 16:21:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LNIwB06295 for ipng-dist; Wed, 21 Jun 2000 16:18:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LNIg606288 for ; Wed, 21 Jun 2000 16:18:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA15340 for ; Wed, 21 Jun 2000 16:18:43 -0700 (PDT) Received: from lychee.itojun.org (dhcp107.conference.usenix.org [209.179.127.107]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00723 for ; Wed, 21 Jun 2000 16:18:41 -0700 (PDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e5LNHUw00975; Thu, 22 Jun 2000 08:17:30 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 21 Jun 2000 10:47:28 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: sin6_flowinfo and sendto/recvfrom From: Jun-ichiro itojun Hagino Date: Thu, 22 Jun 2000 08:17:30 +0900 Message-ID: <973.961629450@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain >> >only class bits in sendto(). It is much more convenient to make with >> >setsockopt() or ancillary data. >My take it also that accept() should behave the same as recvfrom, >since a native application might take the address returned by accept() and >use it in a subsequent connect() or sendto(). >But why do you think that you can only use the traffic class component >in sendto()? (and connect() I assume) >I don't see the need for that restriction. just to clarify, the quoted portion was not my thinking, just a summary of past discussion. 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 Wed Jun 21 16:24:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LNMHv06322 for ipng-dist; Wed, 21 Jun 2000 16:22:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LNM4606315 for ; Wed, 21 Jun 2000 16:22:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA08366 for ; Wed, 21 Jun 2000 16:22:05 -0700 (PDT) Received: from lychee.itojun.org (dhcp107.conference.usenix.org [209.179.127.107]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02639 for ; Wed, 21 Jun 2000 16:22:03 -0700 (PDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e5LNKuw01037; Thu, 22 Jun 2000 08:20:56 +0900 (JST) To: Steve Deering cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-reply-to: deering's message of Wed, 21 Jun 2000 16:17:12 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ICMP and unknown extension headers? From: Jun-ichiro itojun Hagino Date: Thu, 22 Jun 2000 08:20:56 +0900 Message-ID: <1035.961629656@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > unrecognized value was found after decompressing a packet, the returned >> ^^^^^^^^^^^^^you mean decrypting? >> > packet is the decompressed packet (if the security rules allow it to be >> > sent at all). >I did mean decompressing. I thought someone brought up the example of >using the ESP encapsulation to implement compression (or maybe using >a new kind of extension header for compression). IPComp? (RFC2393) 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 Wed Jun 21 16:36:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LNYFV06360 for ipng-dist; Wed, 21 Jun 2000 16:34:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LNY2606353 for ; Wed, 21 Jun 2000 16:34:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA17029 for ; Wed, 21 Jun 2000 16:34:01 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA23759 for ; Wed, 21 Jun 2000 17:34:00 -0600 (MDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id CAA26585; Thu, 22 Jun 2000 02:33:54 +0300 (EET DST) Date: Thu, 22 Jun 2000 02:33:54 +0300 (EET DST) From: Markku Savela Message-Id: <200006212333.CAA26585@anise.tte.vtt.fi> To: jinmei@isl.rdc.toshiba.co.jp CC: ipng@sunroof.eng.sun.com In-reply-to: (jinmei@isl.rdc.toshiba.co.jp) Subject: Re: ICMP and unknown extension headers? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > outbound: apply policy and IPSEC to the error packed based on the > > header of the received packet (except the src/dst swapped as if the > > packet were going out) > > > inbound: the policy check on ICMP error packets is based on the > > contained header (not the outer ICMP). Thus, if the contained packet > > would have required some IPSEC operations, the *whole* ICMP error > > should have been protected by this IPSEC. > > But how can you examine the contained header, which might be > encrypted, for the policy check? I don't see any problem. Packet is in clear at this point already. On inbound, the policy check is of course done after IPSEC decryption, as with any other IPSEC packet. This applies to the ICMP's that come from the other end point. If ICMP is generated on the route by some router, then I would not try to decipher it too much (with truncation and ESP, things get messy). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 16:59:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5LNvs706401 for ipng-dist; Wed, 21 Jun 2000 16:57:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5LNvj606394 for ; Wed, 21 Jun 2000 16:57:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA16580 for ; Wed, 21 Jun 2000 16:57:45 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA07124 for ; Wed, 21 Jun 2000 17:57:44 -0600 (MDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Jun 2000 16:57:00 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Wed, 21 Jun 2000 16:56:59 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024775653@RED-MSG-50> From: Richard Draves To: Erik Nordmark , Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: RE: sin6_flowinfo and sendto/recvfrom Date: Wed, 21 Jun 2000 16:56:52 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My assumption was that recvfrom() and accept() should return sin6_flowinfo from the received packet, and connect() and sendto() should take sin6_flowinfo and put it into sent packets. For bind(), I'd say either error if sin6_flowinfo is non-zero, or ignore sin6_flowinfo. Rich > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Wednesday, June 21, 2000 10:47 AM > To: Jun-ichiro itojun Hagino > Cc: ipng@sunroof.eng.sun.com > Subject: Re: sin6_flowinfo and sendto/recvfrom > > > > > >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain > > >only class bits in sendto(). It is much more convenient to > make with > > >setsockopt() or ancillary data. > > My take it also that accept() should behave the same as recvfrom, > since a native application might take the address returned by > accept() and > use it in a subsequent connect() or sendto(). > > But why do you think that you can only use the traffic class component > in sendto()? (and connect() I assume) > I don't see the need for that restriction. > > > It seems to me that Eric is more in sync with the > current documents, > > since there's no standard setsockopt nor ancillary data > to manipulate > > traffic class/flow label fields. > > > > i'd love to see it clarificed in near future 2553bis/2292bis. > > This has recently come up as a potential porting issue: applications > which use the IP_TOS setsockopt with IPv4 to set the diffserv bits > can't easily be ported to IPv6. > Should we add an IPV6_TCLASS socket option? > Presumably if we do it can be used both with setsockopt > and as ancillary data. > How about a separate IPV6_FLOWID socket option to be complete? > > Since recv*() can't set sin6_flowinfo do we need a way for an > application > to retrieve the tclass and flowid? > That would imply additional IPV6_RECV* options to enable the > receipt of > ancillary data. > > Erik > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 17:12:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M0AO306427 for ipng-dist; Wed, 21 Jun 2000 17:10:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M0AD606420 for ; Wed, 21 Jun 2000 17:10:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA24573 for ; Wed, 21 Jun 2000 17:10:13 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13843 for ; Wed, 21 Jun 2000 18:10:12 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA06202; Wed, 21 Jun 2000 17:10:32 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA22356; Wed, 21 Jun 2000 17:10:32 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id RAA02649; Wed, 21 Jun 2000 17:13:48 -0700 (PDT) Date: Wed, 21 Jun 2000 17:13:48 -0700 (PDT) From: Tim Hartrick Message-Id: <200006220013.RAA02649@feller.mentat.com> To: richdr@microsoft.com Subject: RE: sin6_flowinfo and sendto/recvfrom Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > > My assumption was that recvfrom() and accept() should return sin6_flowinfo > from the received packet, and connect() and sendto() should take > sin6_flowinfo and put it into sent packets. > > For bind(), I'd say either error if sin6_flowinfo is non-zero, or ignore > sin6_flowinfo. > Not surprisingly this is the exact opposite of what I thought.:-) Since the flow ID is source oriented it seems to make the most sense to me to specify it on the bind() call and return it in calls which return a source address (recvfrom, recvmsg, accept). It should be silently ignored on connect, sendto and sendmsg. Of course the traffic class is destination oriented so the opposite logic applies. It is silently ignored by bind and placed in the packet as a result of connect, sendto and sendmsg calls. Calls to recvfrom, recvmsg and accept return what was received. Of course I suspect I held a different opinion about this in the past and the next time it comes up I will hold yet another opinion.:-) Needless to say it needs to be written down. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 21 17:37:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M0ZGp06509 for ipng-dist; Wed, 21 Jun 2000 17:35:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M0Z6606502 for ; Wed, 21 Jun 2000 17:35:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA24282 for ; Wed, 21 Jun 2000 17:35:06 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA26726 for ; Wed, 21 Jun 2000 18:35:03 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Jun 2000 17:34:16 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Wed, 21 Jun 2000 17:34:15 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8102477567C@RED-MSG-50> From: Richard Draves To: Francis Dupont , Dave Thaler Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments Date: Wed, 21 Jun 2000 17:34:14 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 3) When multicast addresses are stored in a sockaddr_in6, > how is the > scope id field Interpreted? > > => I believe it should be an interface index because it is the way > it works today (or before scope id introduction if you prefer :-): > IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with > interface sets. I think Francis's position is easier to implement. Dave's *might* be more useful to applications but it's messy because there isn't a 1-1 correspondence between unicast scopes and multicast scopes. > Another point en passant, should in this case a bind() with a non-zero > scope_id do an automatical IPV6_JOIN_GROUP? I don't follow this - you can't bind() a multicast address. 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 Jun 21 17:37:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M0YrH06500 for ipng-dist; Wed, 21 Jun 2000 17:34:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M0Yi606493 for ; Wed, 21 Jun 2000 17:34:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA29244 for ; Wed, 21 Jun 2000 17:34:43 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA26495 for ; Wed, 21 Jun 2000 18:34:42 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 21 Jun 2000 17:34:21 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Wed, 21 Jun 2000 17:34:21 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8102477567D@RED-MSG-50> From: Richard Draves To: Francis Dupont Cc: "IPng List (E-mail)" , "Thomas Narten (E-mail)" Subject: RE: problems with privacy draft Date: Wed, 21 Jun 2000 17:34:14 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I believe you can make your set of rules simpler if you introduce > a new lifetime (or condition if one needs something smarter than > a delay). I'll call it "regen lifetime" and when the regen lifetime > of an anonymous address expires then a new address is created, checked > by DAD then is used as the anonymous address, the old one is > deprecated. > With this we can keep the current deprecated/invalid mechanism on RA > receptions (this is complex enough with the two hour rule and all the > side effects we can get from short lifetimes (mis)used for mobility). I don't think this works. Suppose you have an existing anonymous address, say with a zero preferred lifetime and a 3 hour valid lifetime. (And you also have other anonymous addresses and a public address with the same prefix.) Now you receive an RA with a matching prefix information option. The lifetimes in the option are 1 day preferred and 1 week valid. You don't want to change the lifetimes of the existing anonymous address. Hence, the rules for processing lifetimes in prefix information options do need a special case for anonymous addresses. 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 Jun 21 23:39:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M6c6g06780 for ipng-dist; Wed, 21 Jun 2000 23:38:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M6bv606773 for ; Wed, 21 Jun 2000 23:37:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA02193 for ; Wed, 21 Jun 2000 23:37:57 -0700 (PDT) Received: from hotmail.com (law2-f118.hotmail.com [216.32.181.118]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA28307 for ; Thu, 22 Jun 2000 00:37:57 -0600 (MDT) Received: (qmail 35595 invoked by uid 0); 22 Jun 2000 06:37:56 -0000 Message-ID: <20000622063756.35594.qmail@hotmail.com> Received: from 213.8.210.194 by www.hotmail.com with HTTP; Wed, 21 Jun 2000 23:37:56 PDT X-Originating-IP: [213.8.210.194] From: "Yuval Shaul" To: ipng@sunroof.eng.sun.com Subject: IPv4 - IPv6 translation Date: Thu, 22 Jun 2000 06:37:56 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anybody know of anything (RFC, implementation, idea etc)about converting IPv4 packets to IPv6 packets ? This could be usefull for older stations (most currently working windows) that would like to connect to IPv6 only servers. (Do such servers exist ?) Yuval ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 00:31:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M7QxR06922 for ipng-dist; Thu, 22 Jun 2000 00:26:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M7Qm606915 for ; Thu, 22 Jun 2000 00:26:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA05989 for ; Thu, 22 Jun 2000 00:26:48 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA14247 for ; Thu, 22 Jun 2000 01:26:48 -0600 (MDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Jun 2000 00:26:43 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Thu, 22 Jun 2000 00:26:42 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF010FC0@red-msg-24.redmond.corp.microsoft.com> From: Brian Zill To: "'Yuval Shaul'" , ipng@sunroof.eng.sun.com Subject: RE: IPv4 - IPv6 translation Date: Thu, 22 Jun 2000 00:26:39 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yuval Shaul asks: > > Does anybody know of anything (RFC, implementation, idea etc) > about converting IPv4 packets to IPv6 packets? Erik Nordmark and George Tsirtsis have written a couple of handy RFCs on this topic, see: RFC 2565, "Stateless IP/ICMP Translation Algorithm" RFC 2566, "Network Address Translation - Protocol Translation" We have an implementation of a NAT-PT, orginally by Marc Fiuczynski. See http://www.research.microsoft.com/msripv6; it's available from the same download page as our stack. It includes the source code if you want to see how it works. > This could be usefull for older stations (most currently > working windows) that would like to connect to IPv6 only > servers. (Do such servers exist ?) There are IPv6 only servers out there (we have one, try http://ipv6.research.microsoft.com from your IPv6 capable web browser, it won't answer to IPv4), but I suspect they're mostly just for testing at the moment. Most servers are expected to run both IPv6 and IPv4 for at the least the beginning of the transition period. I think translators are more likely to be useful for people who want to run only IPv6 on their own network (for ease of administration, etc) but still need to talk to the occasional luddite out in IPv4 land. But they'll undoubtedly be used both ways. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 00:38:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M7afK06984 for ipng-dist; Thu, 22 Jun 2000 00:36:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M7aW606977 for ; Thu, 22 Jun 2000 00:36:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA17158 for ; Thu, 22 Jun 2000 00:36:31 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA17799 for ; Thu, 22 Jun 2000 01:36:31 -0600 (MDT) Received: from lsh ([75.2.35.99]) by ns.sait.samsung.co.kr (8.9.3/8.9.3) with SMTP id QAA06303; Thu, 22 Jun 2000 16:33:59 +0900 (KST) Message-ID: <005f01bfdc1c$a32e9fc0$6323024b@sait.samsung.co.kr> From: =?ks_c_5601-1987?B?wMy788jG?= To: "Yuval Shaul" Cc: References: <20000622063756.35594.qmail@hotmail.com> Subject: Re: IPv4 - IPv6 translation Date: Thu, 22 Jun 2000 16:36:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id e5M7aX606978 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think you should read RFC2765. ----- Original Message ----- From: "Yuval Shaul" To: Sent: Thursday, June 22, 2000 3:37 PM Subject: IPv4 - IPv6 translation > Does anybody know of anything (RFC, implementation, idea etc)about > converting IPv4 packets to IPv6 packets ? > This could be usefull for older stations (most currently working windows) > that would like to connect to IPv6 only servers. > (Do such servers exist ?) > > Yuval > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 02:15:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M9DCc07181 for ipng-dist; Thu, 22 Jun 2000 02:13:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M9D2607174 for ; Thu, 22 Jun 2000 02:13:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA14432 for ; Thu, 22 Jun 2000 02:13:01 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA20648 for ; Thu, 22 Jun 2000 03:13:00 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5M9CoK32473; Thu, 22 Jun 2000 11:12:50 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA22350; Thu, 22 Jun 2000 11:12:48 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA21873; Thu, 22 Jun 2000 11:14:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006220914.LAA21873@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: Dave Thaler , ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Wed, 21 Jun 2000 17:34:14 PDT. <4D0A23B3F74DD111ACCD00805F31D8102477567C@RED-MSG-50> Date: Thu, 22 Jun 2000 11:14:56 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Another point en passant, should in this case a bind() with a non-zero > scope_id do an automatical IPV6_JOIN_GROUP? I don't follow this - you can't bind() a multicast address. => I can and in fact I can bind() many sockets to the same multicast address with the same port using SO_REUSEPORT... Of course such sockets should be used only for incoming traffic (ie don't send a packet with a multicast source address :-). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 02:27:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M9PeX07269 for ipng-dist; Thu, 22 Jun 2000 02:25:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M9PV607262 for ; Thu, 22 Jun 2000 02:25:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA13504 for ; Thu, 22 Jun 2000 02:25:29 -0700 (PDT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA25118 for ; Thu, 22 Jun 2000 03:25:29 -0600 (MDT) Received: from godel.logique.jussieu.fr (root@godel.logique.jussieu.fr [134.157.19.1]) by shiva.jussieu.fr (8.10.0/jtpda-5.3.3) with ESMTP id e5M9PO929605 ; Thu, 22 Jun 2000 11:25:24 +0200 (CEST) Received: from bernays.logique.jussieu.fr (bernays.logique.jussieu.fr [134.157.19.71]) by godel.logique.jussieu.fr (8.9.3/jtpda-5.3.1) with ESMTP id LAA24793 ; Thu, 22 Jun 2000 11:25:23 +0200 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200006220914.LAA21873@givry.rennes.enst-bretagne.fr> Date: Thu, 22 Jun 2000 11:25:24 +0200 (CEST) From: Yves Legrandgerard To: Francis Dupont Subject: Re: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com, Dave Thaler , Richard Draves Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 22-Jun-00 Francis Dupont wrote: > In your previous mail you wrote: > > > Another point en passant, should in this case a bind() with a non-zero > > scope_id do an automatical IPV6_JOIN_GROUP? > > I don't follow this - you can't bind() a multicast address. > > => I can and in fact I can bind() many sockets to the same multicast address > with the same port using SO_REUSEPORT... Of course such sockets should be > used only for incoming traffic (ie don't send a packet with a multicast > source address :-). > You're right Francis, BSD manual of socket syscall says: SO_REUSEPORT allows completely duplicate bindings by multiple processes if they all set SO_REUSEPORT before binding the port. This option per- mits multiple instances of a program to each receive UDP/IP multicast or broadcast datagrams destined for the bound port. Yves. ---------------------------------- Yves Legrandgérard E-Mail: ylg@logique.jussieu.fr Date: 22-Jun-00 Time: 11:22:46 ---------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 02:52:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M9p7R07331 for ipng-dist; Thu, 22 Jun 2000 02:51:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M9ow607324 for ; Thu, 22 Jun 2000 02:50:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA25885; Thu, 22 Jun 2000 02:50:54 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11800; Thu, 22 Jun 2000 02:50:49 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5M9ofK40850; Thu, 22 Jun 2000 11:50:43 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA23097; Thu, 22 Jun 2000 11:50:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA22235; Thu, 22 Jun 2000 11:52:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006220952.LAA22235@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: sin6_flowinfo and sendto/recvfrom In-reply-to: Your message of Wed, 21 Jun 2000 10:56:23 PDT. Date: Thu, 22 Jun 2000 11:52:46 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > more questions (I could not find answer from my archive): > (4) what happens if we connect(2) with sin6_flowinfo filled? > my guess is that sin6_flowinfo sticks into pcb, and > will be attached to every packet we will send. My assumption is the same as your guess. => my concern about sin6_flowinfo is the fact there are two flowinfos per PCB, one for incoming packets (this one cannot be set) and one for outgoing packets... > (5) what happens if we bind(2) with sin6_flowinfo filled? > my guess is (a) to raise some error, or (b) accept packets > only if they carry specified ip6->ip6_flow field. Or c) silently ignore the sin6_flowinfo field. Doing b) adds code to the critical lookup code, and I don't see any need for that. So either a) or c) are fine with me. => I use it for a d) (:-): if the flowID is set then outgoing packets will get a non-zero flowID, for instance new connections to a TCP service will have a (new/random *) ip6->ip6_flow in outgoing packets. (*) each connection has its own flow ID, ie. the sin6_flowinfo field is used as a flag. > (6) what is the endian of sin6_flowinfo? > I guess it is network byte order, since it appears on the wire. Doesn't the basic API say that everything is in network byte order? There used to be some macros to take apart the flowinfo into a tclass and a flowlabel but I can't find those in 2553 for 2292bis. Those macros were different based on byte order which indicates that the interpretation was network byte order for sin6_flowinfo. Clarifying this in RFC2553 would be good. => I agree with Itojun, the rationate is that things which appear on the wire are in the wire byte order, others are in the host byte order. Regards Francis.Dupont@enst-bretagne.fr PS: I think we should find concrete usage of flow ID before conclude this discussion. For instance I don't know if we need to be able to set flowIDs or if per default flow IDs should be zero or not. Of course to leave the whole stuff nearly unspecified as it is today is not the best thing to do too... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 02:59:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5M9vgW07371 for ipng-dist; Thu, 22 Jun 2000 02:57:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5M9vX607364 for ; Thu, 22 Jun 2000 02:57:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA15288; Thu, 22 Jun 2000 02:57:31 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA14314; Thu, 22 Jun 2000 02:57:30 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5M9vPK32574; Thu, 22 Jun 2000 11:57:26 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA23238; Thu, 22 Jun 2000 11:57:25 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA22276; Thu, 22 Jun 2000 11:59:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006220959.LAA22276@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: Erik Nordmark , Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: sin6_flowinfo and sendto/recvfrom In-reply-to: Your message of Wed, 21 Jun 2000 16:56:52 PDT. <4D0A23B3F74DD111ACCD00805F31D81024775653@RED-MSG-50> Date: Thu, 22 Jun 2000 11:59:33 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: My assumption was that recvfrom() and accept() should return sin6_flowinfo from the received packet, and connect() and sendto() should take sin6_flowinfo and put it into sent packets. For bind(), I'd say either error if sin6_flowinfo is non-zero, or ignore sin6_flowinfo. => this is reasonable but we need rules for getsockname() and getpeername() too (note that accept() and getpeername() often are the same thing then it will be hard to agree about getsockname()). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 03:19:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MAHCe07420 for ipng-dist; Thu, 22 Jun 2000 03:17:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MAH3607413 for ; Thu, 22 Jun 2000 03:17:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA12182 for ; Thu, 22 Jun 2000 03:17:02 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14606 for ; Thu, 22 Jun 2000 04:16:59 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5MAGmK24795; Thu, 22 Jun 2000 12:16:48 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA23574; Thu, 22 Jun 2000 12:16:47 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA22383; Thu, 22 Jun 2000 12:18:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006221018.MAA22383@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: "IPng List (E-mail)" , "Thomas Narten (E-mail)" Subject: Re: problems with privacy draft In-reply-to: Your message of Wed, 21 Jun 2000 17:34:14 PDT. <4D0A23B3F74DD111ACCD00805F31D8102477567D@RED-MSG-50> Date: Thu, 22 Jun 2000 12:18:55 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I believe you can make your set of rules simpler if you introduce > a new lifetime (or condition if one needs something smarter than > a delay). I'll call it "regen lifetime" and when the regen lifetime > of an anonymous address expires then a new address is created, checked > by DAD then is used as the anonymous address, the old one is > deprecated. > With this we can keep the current deprecated/invalid mechanism on RA > receptions (this is complex enough with the two hour rule and all the > side effects we can get from short lifetimes (mis)used for mobility). I don't think this works. Suppose you have an existing anonymous address, say with a zero preferred lifetime and a 3 hour valid lifetime. (And you also have other anonymous addresses and a public address with the same prefix.) => I believe this anonymous address is an old one, ie. its preferred lifetime is zero because its regen lifetime has expired. Now you receive an RA with a matching prefix information option. The lifetimes in the option are 1 day preferred and 1 week valid. You don't want to change the lifetimes of the existing anonymous address. => when the regen lifetime has expired received RAs can only shorten the valid lifetime, for instance if the announced valid lifetime is X, the remaining valid lifetime Y with X < Y then the valid lifetime will be set to X modulo the two hour rule. When the regen lifetime has not expired then the standard RA processing can be used. Hence, the rules for processing lifetimes in prefix information options do need a special case for anonymous addresses. => yes but my purpose was (and still is) to get a simpler set of rules and I think this is easier with three lifetimes than with a hierarchy of exceptions: just apply the KISS principle (:-). Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 09:19:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MGHZT07597 for ipng-dist; Thu, 22 Jun 2000 09:17:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MGHQ607590 for ; Thu, 22 Jun 2000 09:17:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA10930 for ; Thu, 22 Jun 2000 09:17:24 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29077 for ; Thu, 22 Jun 2000 10:17:21 -0600 (MDT) Received: by DFSSL.dns.microsoft.com with Internet Mail Service (5.5.2652.35) id ; Thu, 22 Jun 2000 09:09:05 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690D8CEE22@SIT.platinum.corp.microsoft.com> From: Dave Thaler To: "'Francis.Dupont@enst-bretagne.fr'" , ipng@sunroof.eng.sun.com Subject: FW: rfc2553bis comments Date: Thu, 22 Jun 2000 09:10:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just got a bounce message from the first time, apologies if this is a duplicate. -----Original Message----- From: Dave Thaler Sent: Wednesday, June 21, 2000 5:44 PM To: Richard Draves; Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments > > Another point en passant, should in this case a bind() with a non-zero > > scope_id do an automatical IPV6_JOIN_GROUP? > > I don't follow this - you can't bind() a multicast address. Yes you can. There's a discussion of this in (for example) Stevens, Unix Network Programming, Vol. 1, 2nd ed., pp498-499. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 10:40:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MHc4807685 for ipng-dist; Thu, 22 Jun 2000 10:38:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MHbt607678 for ; Thu, 22 Jun 2000 10:37:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA29670 for ; Thu, 22 Jun 2000 10:37:54 -0700 (PDT) Received: from decoy.sfc.keio.ac.jp (decoy.sfc.keio.ac.jp [133.27.84.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11675 for ; Thu, 22 Jun 2000 10:37:52 -0700 (PDT) Received: from localhost (localhost.sfc.keio.ac.jp [127.0.0.1]) by decoy.sfc.keio.ac.jp (8.9.3/8.9.3) with ESMTP id CAA12542; Fri, 23 Jun 2000 02:37:33 +0900 (JST) (envelope-from say@sfc.wide.ad.jp) To: yuval_sl@hotmail.com Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv4 - IPv6 translation From: ARIGA Seiji In-Reply-To: <20000622063756.35594.qmail@hotmail.com> References: <20000622063756.35594.qmail@hotmail.com> X-Mailer: Mew version 1.95b3 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-Publickey: http://decoy.sfc.keio.ac.jp/~say/key.txt X-PGP-Fingerprint: 8E 70 AB 20 44 E6 8A 8A 1C 49 B3 30 44 1B B3 BA Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000623023733B.say@decoy.sfc.keio.ac.jp> Date: Fri, 23 Jun 2000 02:37:33 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 22 Jun 2000 06:37:56 GMT, "Yuval Shaul" wrote, : Does anybody know of anything (RFC, implementation, idea etc)about : converting IPv4 packets to IPv6 packets ? There are two implemented IPv4 - IPv6 translator using Socks. # It doesn't actually 'convert' packets, thought. You can find the patch for Socks5 server at KAME distribution. And the following site will help you to use this translator with IPv4 only applications. http://www.socks.nec.com/translator.html http://www.pds-flab.rwcp.or.jp/SOCKS64/ draft-ietf-ngtrans-socks-gateway-04.txt describes how this translator woks. // ARIGA Seiji -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 12:32:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MJUjQ07938 for ipng-dist; Thu, 22 Jun 2000 12:30:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MJUa607931 for ; Thu, 22 Jun 2000 12:30:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA22367 for ; Thu, 22 Jun 2000 12:30:35 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA26494 for ; Thu, 22 Jun 2000 13:30:34 -0600 (MDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Jun 2000 12:30:03 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Thu, 22 Jun 2000 12:30:02 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810247758CD@RED-MSG-50> From: Richard Draves To: Francis Dupont Cc: Dave Thaler , ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments Date: Thu, 22 Jun 2000 12:30:00 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Another point en passant, should in this case a bind() > with a non-zero > > scope_id do an automatical IPV6_JOIN_GROUP? > > I don't follow this - you can't bind() a multicast address. > > => I can Winsock (or least, the MS implementation) doesn't allow this. I didn't know that recent BSD variants have this capability - thanks for the correction. To answer your question - yes, the bind() of a multicast address should automatically join the group. So this is another reason to make sin6_scope_id field be an interface id for multicast addresses of all scopes. 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 Jun 22 12:47:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MJeNL07962 for ipng-dist; Thu, 22 Jun 2000 12:40:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MJeC607955 for ; Thu, 22 Jun 2000 12:40:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA18150 for ; Thu, 22 Jun 2000 12:40:11 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03063 for ; Thu, 22 Jun 2000 13:40:09 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA09928; Thu, 22 Jun 2000 12:40:08 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA12251; Thu, 22 Jun 2000 12:40:08 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA02985; Thu, 22 Jun 2000 12:43:25 -0700 (PDT) Date: Thu, 22 Jun 2000 12:43:25 -0700 (PDT) From: Tim Hartrick Message-Id: <200006221943.MAA02985@feller.mentat.com> To: Francis.Dupont@enst-bretagne.fr, richdr@microsoft.com Subject: RE: rfc2553bis comments Cc: DTHALER@exchange.microsoft.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, Francis, > > To answer your question - yes, the bind() of a multicast address should > automatically join the group. So this is another reason to make > sin6_scope_id field be an interface id for multicast addresses of all > scopes. > I disagree with both of these things and generally agree with Dave Thaler's previous note on this subject. The sin6_scope_id specifies the link, site, organization, etc. depending on the scope of the multicast address. The binding of a multicast address to socket by an application should be independent of the joining of a multicast group on a particular interface. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 13:32:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MKTie07992 for ipng-dist; Thu, 22 Jun 2000 13:29:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MKTW607985 for ; Thu, 22 Jun 2000 13:29:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA10131 for ; Thu, 22 Jun 2000 13:29:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06588 for ; Thu, 22 Jun 2000 14:29:29 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA21994; Thu, 22 Jun 2000 13:29:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA31746; Thu, 22 Jun 2000 13:29:19 -0700 X-Virus-Scanned: Thu, 22 Jun 2000 13:29:19 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma031113; Thu, 22 Jun 00 13:29:01 -0700 Message-Id: <4.3.2.7.2.20000622131857.02474088@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Jun 2000 13:26:59 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification Author(s) : A. Conta Filename : draft-ietf-ion-ipv6-ind-03.txt Pages : 22 Date : 27-Oct-99 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two week from today on July 6, 2000. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 13:41:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MKbmw08020 for ipng-dist; Thu, 22 Jun 2000 13:37:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MKbb608011 for ; Thu, 22 Jun 2000 13:37:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA28913 for ; Thu, 22 Jun 2000 13:37:35 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04560 for ; Thu, 22 Jun 2000 13:37:34 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA22856; Thu, 22 Jun 2000 13:37:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id NAA13054; Thu, 22 Jun 2000 13:37:31 -0700 X-Virus-Scanned: Thu, 22 Jun 2000 13:37:31 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma012625; Thu, 22 Jun 00 13:37:17 -0700 Message-Id: <4.3.2.7.2.20000622133314.02474088@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Jun 2000 13:35:14 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" In-Reply-To: <4.3.2.7.2.20000622131857.02474088@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I forgot to add that this document is now an IPng w.g. document. We inherited it when the ION w.g. concluded. Bob At 01:26 PM 6/22/2000 -0700, Bob Hinden wrote: >This is a IPng working group last call for comments on advancing the >following document as a Proposed Standard: > > Title : Extensions to IPv6 Neighbor Discovery for Inverse > Discovery Specification > Author(s) : A. Conta > Filename : draft-ietf-ion-ipv6-ind-03.txt > Pages : 22 > Date : 27-Oct-99 > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the author. This last call period will end two >week from today on July 6, 2000. > >Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 15:41:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MMdNT08202 for ipng-dist; Thu, 22 Jun 2000 15:39:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MMdD608195 for ; Thu, 22 Jun 2000 15:39:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA12261 for ; Thu, 22 Jun 2000 15:39:13 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06815 for ; Thu, 22 Jun 2000 16:39:11 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id HAA02725; Fri, 23 Jun 2000 07:26:20 +0900 (JST) Date: Fri, 23 Jun 2000 07:33:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@enst-bretagne.fr Cc: dthaler@Exchange.Microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-Reply-To: In your message of "Sat, 17 Jun 2000 21:11:56 +0200" <200006171911.VAA84897@givry.rennes.enst-bretagne.fr> References: <19398D273324D3118A2B0008C7E9A5690C6F7A6D@SIT.platinum.corp.microsoft.com> <200006171911.VAA84897@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 42 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 17 Jun 2000 21:11:56 +0200, >>>>> Francis Dupont said: > In your previous mail you wrote (after reformatting into text): > 3) When multicast addresses are stored in a sockaddr_in6, how is the > scope id field Interpreted? > => I believe it should be an interface index because it is the way > it works today (or before scope id introduction if you prefer :-): It would work, but I'd rather use the same semantics for both unicast and multicast. That is, sin6_scope_id should just specify a zone ID, not an interface, even for a multicast address. > IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with > interface sets. Yes, these are interfaces oriented. But, it sin6_scope_id is not, at least in my understanding of scope architecture. Specifying a particular interface by the sin6_scope_id field seems to me overspecification, if the scope is wider than interface (i.e. link or broader scopes). Also, if the sin6_scope_id field specified a single interface for a multicast address, we couldn't do - bind a socket to a site-local multicast address with an appropriate sin6_scope_id, - set IPV6_JOIN_GROUP for that address on multiple interfaces (of the specified scope zone), and then - receive packets that arrive on the specified interfaces via the socket I don't think this is really a practical example, but IMO, this type of behavior is allowed in IPv4 (i.e. bind once, and call IP_ADD_MEMBERSHIP multiple times to receive packets to the group on multiple interfaces), and should be allowed in IPv6 as well. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 22 16:09:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5MN6V708233 for ipng-dist; Thu, 22 Jun 2000 16:06:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5MN6N608226 for ; Thu, 22 Jun 2000 16:06:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA03865 for ; Thu, 22 Jun 2000 16:06:22 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA29870 for ; Thu, 22 Jun 2000 16:06:22 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA07917; Thu, 22 Jun 2000 16:06:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA06683; Thu, 22 Jun 2000 16:06:20 -0700 X-Virus-Scanned: Thu, 22 Jun 2000 16:06:20 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xmaa06415; Thu, 22 Jun 00 16:06:12 -0700 Message-Id: <4.3.2.7.2.20000622160204.0247cff0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Jun 2000 16:04:10 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" In-Reply-To: <4.3.2.7.2.20000622133314.02474088@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20000622131857.02474088@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The author of this draft's email address has changed. His new address is: aconta@txc.com Bob At 01:35 PM 6/22/2000 -0700, Bob Hinden wrote: >I forgot to add that this document is now an IPng w.g. document. We >inherited it when the ION w.g. concluded. > >Bob > >At 01:26 PM 6/22/2000 -0700, Bob Hinden wrote: >>This is a IPng working group last call for comments on advancing the >>following document as a Proposed Standard: >> >> Title : Extensions to IPv6 Neighbor Discovery for Inverse >> Discovery Specification >> Author(s) : A. Conta >> Filename : draft-ietf-ion-ipv6-ind-03.txt >> Pages : 22 >> Date : 27-Oct-99 >> >>Please send substantive comments to the ipng mailing list, and minor >>editorial comments to the author. This last call period will end two >>week from today on July 6, 2000. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 23 02:17:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5N9FW108567 for ipng-dist; Fri, 23 Jun 2000 02:15:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5N9FG608560 for ; Fri, 23 Jun 2000 02:15:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA14383 for ; Fri, 23 Jun 2000 02:15:14 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08092 for ; Fri, 23 Jun 2000 03:15:12 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5N9BqK10651; Fri, 23 Jun 2000 11:11:53 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA06465; Fri, 23 Jun 2000 11:11:50 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA26784; Fri, 23 Jun 2000 11:14:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006230914.LAA26784@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dthaler@Exchange.Microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Fri, 23 Jun 2000 07:33:37 +0900. Date: Fri, 23 Jun 2000 11:14:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> On Sat, 17 Jun 2000 21:11:56 +0200, >>>>> Francis Dupont said: > In your previous mail you wrote (after reformatting into text): > 3) When multicast addresses are stored in a sockaddr_in6, how is the > scope id field Interpreted? > => I believe it should be an interface index because it is the way > it works today (or before scope id introduction if you prefer :-): It would work, but I'd rather use the same semantics for both unicast and multicast. That is, sin6_scope_id should just specify a zone ID, not an interface, even for a multicast address. => it is a matter of taste... and things are very complex because we'd like to have different interpretation on emission and reception sides (my comment was about the emission side but for the reception side your proposal seems better) > IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with > interface sets. Yes, these are interfaces oriented. But, it sin6_scope_id is not, at least in my understanding of scope architecture. => unfortunately the scope architecture is still waiting for its documentation (:-)... Specifying a particular interface by the sin6_scope_id field seems to me overspecification, if the scope is wider than interface (i.e. link or broader scopes). => to (over)specify an interface is better for emission, for reception the whole thing is very different, for instance IPV6_JOIN_GROUP has a global effect, ie it just enables reception of packets with the specified multicast destination address on an interface, any socket bound to the address or unbound will get them. The IPv6 scope ID with your interpretation can make this different/better than in IPv4 (where you may have to get and check the receiving interface). Also, if the sin6_scope_id field specified a single interface for a multicast address, we couldn't do => before listing these, can zero sin6_scope_id give the traditional (ie IPv4) behaviour? - bind a socket to a site-local multicast address with an appropriate sin6_scope_id, - set IPV6_JOIN_GROUP for that address on multiple interfaces (of the specified scope zone), and then - receive packets that arrive on the specified interfaces via the socket => with the traditional behaviour the last point must be done by the user I don't think this is really a practical example, but IMO, this type of behavior is allowed in IPv4 (i.e. bind once, and call IP_ADD_MEMBERSHIP multiple times to receive packets to the group on multiple interfaces), and should be allowed in IPv6 as well. => if your purpose is to get (optionally) the same behaviour than for IPv4 then the zero sin6_scope_id is enough. But your idea perhaps is to enable smarter filtering on reception? Regards Francis.Dupont@enst-bretagne.fr PS: today my code ignores the sin6_scope_id for multicast address on reception (ie. in6_pcbbind() resets it to zero and udp6_input() doesn't check it in the multicast case loop). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 14:29:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5NLRGJ09738 for ipng-dist; Fri, 23 Jun 2000 14:27:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5NLR6609731 for ; Fri, 23 Jun 2000 14:27:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25756 for ; Fri, 23 Jun 2000 14:27:06 -0700 (PDT) Received: from dthaler.microsoft.com ([131.107.152.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27112 for ; Fri, 23 Jun 2000 15:27:05 -0600 (MDT) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id PAA15967; Fri, 23 Jun 2000 15:56:31 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <200006232256.PAA15967@dthaler.microsoft.com> Subject: Re: rfc2553bis comments In-Reply-To: <200006230914.LAA26784@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Jun 23, 2000 11:14: 2 am" To: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Fri, 23 Jun 2000 15:56:31 -0700 (PDT) Cc: jinmei@isl.rdc.toshiba.co.jp, dthaler@Exchange.Microsoft.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > >>>>> On Sat, 17 Jun 2000 21:11:56 +0200, > >>>>> Francis Dupont said: > > > In your previous mail you wrote (after reformatting into text): > > 3) When multicast addresses are stored in a sockaddr_in6, how is the > > scope id field Interpreted? > > > => I believe it should be an interface index because it is the way > > it works today (or before scope id introduction if you prefer :-): > > It would work, but I'd rather use the same semantics for both unicast > and multicast. That is, sin6_scope_id should just specify a zone ID, > not an interface, even for a multicast address. > > => it is a matter of taste... and things are very complex because > we'd like to have different interpretation on emission and reception sides > (my comment was about the emission side but for the reception side your > proposal seems better) I _really_ don't like having more than one interpretation. Since joining/leaving/specifying the outgoing interface can all be done by ifindex using existing apis without the scope_id, I don't see them as being a good argument for use of scope_id. The bind, getaddrinfo (when DNS returns a multicast address for a given name), etc calls are the ones that should be of primary interest in my opinion. These tend to argue for zone ids, not interface indexes (except for link-scoped where they're the same thing). > > IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with > > interface sets. > > Yes, these are interfaces oriented. But, it sin6_scope_id is not, at > least in my understanding of scope architecture. > > => unfortunately the scope architecture is still waiting for its > documentation (:-)... > > Specifying a > particular interface by the sin6_scope_id field seems to me > overspecification, if the scope is wider than interface (i.e. link or > broader scopes). Right. > => to (over)specify an interface is better for emission, for reception > the whole thing is very different, for instance IPV6_JOIN_GROUP has > a global effect, ie it just enables reception of packets with > the specified multicast destination address on an interface, any socket > bound to the address or unbound will get them. The IPv6 scope ID > with your interpretation can make this different/better than in IPv4 > (where you may have to get and check the receiving interface). > > Also, if the sin6_scope_id field specified a single interface for a > multicast address, we couldn't do > > => before listing these, can zero sin6_scope_id give the traditional > (ie IPv4) behaviour? This is a different (but important) question, which some of us have also been discussing offline. One good argument is that you should get the same behavior for link-local unicast and multicast link-scoped addresses if scope_id is zero. (Whether that behavior is an error, or an arbitrary choice is a different decision, and perhaps ought to be left to local policy.) > - bind a socket to a site-local multicast address with an appropriate > sin6_scope_id, > - set IPV6_JOIN_GROUP for that address on multiple interfaces (of the > specified scope zone), and then > - receive packets that arrive on the specified interfaces via the > socket > > => with the traditional behaviour the last point must be done by the user > > I don't think this is really a practical example, but IMO, this type > of behavior is allowed in IPv4 (i.e. bind once, and call > IP_ADD_MEMBERSHIP multiple times to receive packets to the group on > multiple interfaces), and should be allowed in IPv6 as well. I agree with this. -Dave Thaler -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 14:38:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5NLaud09764 for ipng-dist; Fri, 23 Jun 2000 14:36:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5NLal609757 for ; Fri, 23 Jun 2000 14:36:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA13176 for ; Fri, 23 Jun 2000 14:36:48 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01455 for ; Fri, 23 Jun 2000 14:36:46 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA16722; Fri, 23 Jun 2000 14:36:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA32581; Fri, 23 Jun 2000 14:36:44 -0700 X-Virus-Scanned: Fri, 23 Jun 2000 14:36:44 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma032311; Fri, 23 Jun 00 14:36:33 -0700 Message-Id: <4.3.2.7.2.20000623143215.01c42da8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Jun 2000 14:34:31 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Revised IPng Working Group Charter Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Attached is a draft of a revised charter for the working group. Updating the charter was agreed to at the Grenoble and Minneapolis working group meetings, but it took the chairs and AD's a while to draft a new one. The charter includes changing the name of the working group to the "IP Version 6 Working Group", but will keep the acronym of "ipngwg". This will avoid having to rename all current internet drafts. Please send comments on the new charter to the mailing list. There will be a short session in Pittsburgh to discuss it as well. Bob Hinden / Steve Deering ----------------------------------------------------------------------------- Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft ----------------------------------------------------------------------------- IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym Chair(s): Bob Hinden Steve Deering Document Editor Bob Hinden (hinden@iprg.nokia.com) Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:ipng@sunroof.eng.sun.com To Subscribe: majordomo@sunroof.eng.sun.com In Body: in body: subscribe ipng Archive: ftp://playground.sun.com/pub/ipng/mail-archive Description of Working Group: IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) is intended to support the continued growth of the Internet, both in size and capabilities, by offering a greatly increased IP address space and other enhancements over IPv4. The working group was originally chartered to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. Most of the tasks in that original charter have been completed, and the core IPv6 protocol specifications are now on the IETF standards track. The working group's ongoing responsibilities are as follows: - Complete work from the original charter and follow-on work, as outlined below. - Keep all IPv6 working group documents moving along publication / standardization track. - Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups. - Provide a home for IPv6-related work that doesn't fit in an existing IETF working group and doesn't merit a working group of its own. - Provide technical input to ICANN, Internet Address Registries, and IANA with regard to IPv6 address allocation policies and procedures. - Provide technical input and review to IANA with regard to IPv6 protocol and parameter assignments. The list of the working group's current work items is as follows: - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, editorial) - Revise Generic Tunneling spec (add bidirectional tunnels) - Update Basic and Advanced API specs - Complete Router Renumbering spec - Complete Scoped Address Architecture spec and any necessary revisions to other working group drafts required to properly implement support for IPv6 address scoping - Complete work on recommended address-selection algorithms - Work on new solutions to site-multihoming problems, possibly including both host-based and router-based solutions. - Complete work on local IPv6 networking as part of IPv6 plug-and-play - Complete work on privacy extensions to stateless address configuration - Document IPv6 renumbering model - Complete the GSE Analysis document - Complete the Inverse Neighbor Discovery spec - Complete the IPv6 Node Information Queries spec - Complete MIB specs as required by any working group protocol specs New work items not listed above require the approval of the working group and Internet Area directors before they will be taken on by the working group. The working group would welcome contributions on the following topics (this is not an exhaustive list): - Flow label standardization - Solutions to other multihoming issues, beyond those specific to site-multihoming - Integration of autoconfiguration, mobility, DNS, service discovery and other technologies to enhance IPv6 plug-and-play - IPv6 dial-up issues relating to address assignment, use of Neighbor Discovery, etc. (not including AAA work) - Specifications for IPv6 over additional media - Extending MLD to include functionality of IGMPv3 - Host use of anycast; TCP use of anycast - Support for multi-link subnets (single subnet spans multiple links) - Scope-name discovery - IPv6 protocol extensions to accommodate mobile wireless networks. Goals and Milestones: Aug 2000 Complete MLD MIB and submit for Proposed Standard Aug 2000 Complete privacy extensions specification and submit for Proposed Standard Aug 2000 Completed revision of GSE Analysis document and resubmit for Informational Aug 2000 Complete the Inverse Neighbor Discovery specification and submit for Proposed Standard Aug 2000 Complete IPv6 Multihoming with Route Aggregation and submit for Informational. Oct 2000 Update ICMP document and resubmit for Draft Standard Oct 2000 Update Generic Tunneling specification and resubmit for Proposed Standard Oct 2000 Complete updates to Basic and Advanced API specifications and submit for Informational Dec 2000 Complete Scoped Address Architecture and submit for Proposed Standard Dec 2000 Compete Address Selection specification and submit for Proposed Standard Dec 2000 Complete Local IPv6 Networking Specification and submit for Proposed Standard Dec 2000 Complete the IPv6 Node Information Queries specification and submit for Proposed Standard Mar 2001 Complete IPv6 renumbering model document and submit for Informational ----------------------------------------------------------------------------- Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft ----------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 16:24:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5NNMQ510012 for ipng-dist; Fri, 23 Jun 2000 16:22:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5NNMH610005 for ; Fri, 23 Jun 2000 16:22:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA01703 for ; Fri, 23 Jun 2000 16:22:17 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07124 for ; Fri, 23 Jun 2000 17:22:17 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA26521; Fri, 23 Jun 2000 16:22:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA29604; Fri, 23 Jun 2000 16:22:13 -0700 X-Virus-Scanned: Fri, 23 Jun 2000 16:22:13 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma029285; Fri, 23 Jun 00 16:22:03 -0700 Message-Id: <4.3.2.7.2.20000623161843.01f28f98@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Jun 2000 16:20:01 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as Informational: Title : IPv6 Multihoming with Route Aggregation Author(s) : J. Yu Filename : draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt Pages : 7 Date : 24-Nov-99 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two week from today on July 7, 2000. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 25 19:23:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5Q2LC411143 for ipng-dist; Sun, 25 Jun 2000 19:21:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5Q2L1611136 for ; Sun, 25 Jun 2000 19:21:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA09307 for ; Sun, 25 Jun 2000 19:20:57 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12139 for ; Sun, 25 Jun 2000 19:20:47 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA12226; Mon, 26 Jun 2000 11:07:59 +0900 (JST) Date: Mon, 26 Jun 2000 06:20:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: msa@hemuli.tte.vtt.fi Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP and unknown extension headers? In-Reply-To: In your message of "Thu, 22 Jun 2000 02:33:54 +0300 (EET DST)" <200006212333.CAA26585@anise.tte.vtt.fi> References: <200006212333.CAA26585@anise.tte.vtt.fi> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 22 Jun 2000 02:33:54 +0300 (EET DST), >>>>> Markku Savela said: >> But how can you examine the contained header, which might be >> encrypted, for the policy check? > I don't see any problem. Packet is in clear at this point already. > On inbound, the policy check is of course done after IPSEC decryption, > as with any other IPSEC packet. This applies to the ICMP's that come > from the other end point. If ICMP is generated on the route by some > router, then I would not try to decipher it too much (with truncation > and ESP, things get messy). Ah, I see. I misunderstood the order of processing. Thanks for the clarification. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 25 19:23:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5Q2KuM11134 for ipng-dist; Sun, 25 Jun 2000 19:20:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5Q2Kk611127 for ; Sun, 25 Jun 2000 19:20:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA09289 for ; Sun, 25 Jun 2000 19:20:46 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12070 for ; Sun, 25 Jun 2000 19:20:35 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA12196; Mon, 26 Jun 2000 11:07:06 +0900 (JST) Date: Mon, 26 Jun 2000 05:01:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@enst-bretagne.fr Cc: dthaler@Exchange.Microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-Reply-To: In your message of "Fri, 23 Jun 2000 11:14:02 +0200" <200006230914.LAA26784@givry.rennes.enst-bretagne.fr> References: <200006230914.LAA26784@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 94 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 23 Jun 2000 11:14:02 +0200, >>>>> Francis Dupont said: >> In your previous mail you wrote (after reformatting into text): >> 3) When multicast addresses are stored in a sockaddr_in6, how is the >> scope id field Interpreted? >> => I believe it should be an interface index because it is the way >> it works today (or before scope id introduction if you prefer :-): > It would work, but I'd rather use the same semantics for both unicast > and multicast. That is, sin6_scope_id should just specify a zone ID, > not an interface, even for a multicast address. > => it is a matter of taste... and things are very complex because > we'd like to have different interpretation on emission and reception sides > (my comment was about the emission side but for the reception side your > proposal seems better) I admit it would be a matter of taste, but I personally don't want to have the different interpretation. The semantics of sin_scope_id can be same for the reception and emission, and (IMO) it sould be same. >> IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with >> interface sets. > Yes, these are interfaces oriented. But, it sin6_scope_id is not, at > least in my understanding of scope architecture. > => unfortunately the scope architecture is still waiting for its > documentation (:-)... Yes, it's just my understanding. So let's discuss this, and the consensus should be documented (maybe in rfc2553bis?). > Specifying a > particular interface by the sin6_scope_id field seems to me > overspecification, if the scope is wider than interface (i.e. link or > broader scopes). > => to (over)specify an interface is better for emission, for reception I don't think it is not necessarily a better thing. A user might just want to specify a multicast group (with some zone ID) and let the kernel send packets to that group on an appropriate interface(s) according to the kernel's routing table, etc. > the whole thing is very different, for instance IPV6_JOIN_GROUP has > a global effect, ie it just enables reception of packets with > the specified multicast destination address on an interface, any socket > bound to the address or unbound will get them. The IPv6 scope ID > with your interpretation can make this different/better than in IPv4 > (where you may have to get and check the receiving interface). > Also, if the sin6_scope_id field specified a single interface for a > multicast address, we couldn't do > => before listing these, can zero sin6_scope_id give the traditional > (ie IPv4) behaviour? Good question...my take is that zero means a "system default" zone of the scope, but we could interpret zero as "wildcard". Anyway, it should also be clarified, IMO. > - bind a socket to a site-local multicast address with an appropriate > sin6_scope_id, > - set IPV6_JOIN_GROUP for that address on multiple interfaces (of the > specified scope zone), and then > - receive packets that arrive on the specified interfaces via the > socket > => with the traditional behaviour the last point must be done by the user > I don't think this is really a practical example, but IMO, this type > of behavior is allowed in IPv4 (i.e. bind once, and call > IP_ADD_MEMBERSHIP multiple times to receive packets to the group on > multiple interfaces), and should be allowed in IPv6 as well. > => if your purpose is to get (optionally) the same behaviour than for IPv4 > then the zero sin6_scope_id is enough. yes, if we interpreted zero sin6_scope_id as wildcard. > But your idea perhaps is to enable > smarter filtering on reception? Yes, the above example described the case that a user wanted to receive multicast packets of a specified group *with a specified scope zone*. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 25 21:13:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5Q4BaW11220 for ipng-dist; Sun, 25 Jun 2000 21:11:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5Q4BR611213 for ; Sun, 25 Jun 2000 21:11:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA12440 for ; Sun, 25 Jun 2000 21:11:26 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA05247 for ; Sun, 25 Jun 2000 21:11:12 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA12647 for ; Mon, 26 Jun 2000 12:58:54 +0900 (JST) Date: Mon, 26 Jun 2000 13:07:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-Reply-To: In your message of "Mon, 26 Jun 2000 05:01:38 +0900" References: <200006230914.LAA26784@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 26 Jun 2000 05:01:38 +0900, >>>>> JINMEI Tatuya said: >> Specifying a >> particular interface by the sin6_scope_id field seems to me >> overspecification, if the scope is wider than interface (i.e. link or >> broader scopes). >> => to (over)specify an interface is better for emission, for reception > I don't think it is not necessarily a better thing. Sorry, the wording was wrong here. My intention was "I think it is not necessarily a better thing." JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 00:52:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5Q7oIj11323 for ipng-dist; Mon, 26 Jun 2000 00:50:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5Q7o9611316 for ; Mon, 26 Jun 2000 00:50:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA13783 for ; Mon, 26 Jun 2000 00:50:10 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA27859 for ; Mon, 26 Jun 2000 01:50:07 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5Q7mKK44025; Mon, 26 Jun 2000 09:48:20 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA00830; Mon, 26 Jun 2000 09:48:18 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA00736; Mon, 26 Jun 2000 09:49:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006260749.JAA00736@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dave Thaler cc: jinmei@isl.rdc.toshiba.co.jp, dthaler@Exchange.Microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Fri, 23 Jun 2000 15:56:31 PDT. <200006232256.PAA15967@dthaler.microsoft.com> Date: Mon, 26 Jun 2000 09:49:00 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => it is a matter of taste... and things are very complex because > we'd like to have different interpretation on emission and reception sides > (my comment was about the emission side but for the reception side your > proposal seems better) I _really_ don't like having more than one interpretation. => I don't believe we should specify two different interpretations but obviously we have to do the choice between: - use interface indexes and make scope IDs not very useful for the receiving side - use traditional (ie as for unicast) scope IDs and make the sin6_scope_id field nearly useless for emission to destinations to a scope larger than link-local (the only thing I can see is to check interfaces specified by IPV6_MULTICAST_IF are in the right zone) I was in favour of the first solution, now I believe the second is better. Since joining/leaving/specifying the outgoing interface can all be done by ifindex using existing apis without the scope_id, I don't see them as being a good argument for use of scope_id. The bind, getaddrinfo (when DNS returns a multicast address for a given name), etc calls are the ones that should be of primary interest in my opinion. These tend to argue for zone ids, not interface indexes (except for link-scoped where they're the same thing). => I agree (I've changed my mind) > => before listing these, can zero sin6_scope_id give the traditional > (ie IPv4) behaviour? This is a different (but important) question, which some of us have also been discussing offline. => you should have guess I am in favour of this too... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 00:59:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5Q7vs211394 for ipng-dist; Mon, 26 Jun 2000 00:57:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5Q7vj611387 for ; Mon, 26 Jun 2000 00:57:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA14366 for ; Mon, 26 Jun 2000 00:57:46 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA09588 for ; Mon, 26 Jun 2000 00:57:44 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5Q7ujK51870; Mon, 26 Jun 2000 09:56:45 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA00329; Mon, 26 Jun 2000 09:56:44 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA00781; Mon, 26 Jun 2000 09:57:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006260757.JAA00781@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: dthaler@Exchange.Microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Mon, 26 Jun 2000 05:01:38 +0900. Date: Mon, 26 Jun 2000 09:57:26 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => it is a matter of taste... and things are very complex because > we'd like to have different interpretation on emission and reception sides > (my comment was about the emission side but for the reception side your > proposal seems better) I admit it would be a matter of taste, but I personally don't want to have the different interpretation. The semantics of sin_scope_id can be same for the reception and emission, and (IMO) it should be same. => it must be the same but we have to sacrify one side! I don't think it is not necessarily a better thing. A user might just want to specify a multicast group (with some zone ID) and let the kernel send packets to that group on an appropriate interface(s) according to the kernel's routing table, etc. => do you mean we should use the multicast routing table for genuine packets (BSD IPv4 multicast is not very clear about this for me, I have no concern but the specs need to be clear(er) about this). This can make IPV6_MULTICAST_IF useless and/or things even more complex: what semantics for sin6_scope_id on the sending side do you propose (and is there a special case for the zero sin6_scope_id)? Good question...my take is that zero means a "system default" zone of the scope, but we could interpret zero as "wildcard". Anyway, it should also be clarified, IMO. => I agree! Regards Francis.Dupont@enst-bretagne.fr PS: I can see some progress (and a general agreement about both the need for clarification (:-) and about the interest of this). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 09:28:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QGQHf11678 for ipng-dist; Mon, 26 Jun 2000 09:26:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QGQ7611671 for ; Mon, 26 Jun 2000 09:26:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA12343 for ; Mon, 26 Jun 2000 09:26:07 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA25542 for ; Mon, 26 Jun 2000 10:26:06 -0600 (MDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jun 2000 09:07:59 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Mon, 26 Jun 2000 09:17:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4397.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDF88.D61B2434" Subject: RE: rfc2553bis comments Date: Mon, 26 Jun 2000 09:08:59 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690D8CEE40@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc2553bis comments Thread-Index: Ab/fQj/zVvKLgkm7RCyjBs94gDD2jgARqdjA From: "Dave Thaler" To: "Francis Dupont" , "Dave Thaler" Cc: , X-OriginalArrivalTime: 26 Jun 2000 16:17:06.0311 (UTC) FILETIME=[F88C2170:01BFDF89] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFDF88.D61B2434 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francis Dupont writes: > =3D> I don't believe we should specify two different interpretations > but obviously we have to do the choice between: > - use interface indexes and make scope IDs not very useful for the > receiving side > - use traditional (ie as for unicast) scope IDs and make the sin6_scope_id > field nearly useless for emission to destinations to a scope larger > than link-local (the only thing I can see is to check interfaces > specified by IPV6_MULTICAST_IF are in the right zone) > I was in favour of the first solution, now I believe the second is better. It's not useless on emission, since it's not required to do IPV6_MULTICAST_IF. If you don't do IPV6_MULTICAST_IF, the meaning would be to send via some interface in the set identified by scope_id. However, when IPV6_MULTICAST_IF is done, the most you can use it for is a sanity check and fail the send if you try to send out an interace not in the given scope. -Dave ------_=_NextPart_001_01BFDF88.D61B2434 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: rfc2553bis comments

Francis Dupont writes:
> =3D> I don't believe we should specify two = different interpretations
> but obviously we have to do the choice = between:
>  - use interface indexes and make scope IDs = not very useful for the
>    receiving side
>  - use traditional (ie as for unicast) = scope IDs and make the sin6_scope_id
>    field nearly useless for = emission to destinations to a scope larger
>    than link-local (the only = thing I can see is to check interfaces
>    specified by IPV6_MULTICAST_IF = are in the right zone)
> I was in favour of the first solution, now I = believe the second is better.

It's not useless on emission, since it's not required = to do IPV6_MULTICAST_IF.
If you don't do IPV6_MULTICAST_IF, the meaning = would
be to send via some interface in the set identified = by scope_id.

However, when IPV6_MULTICAST_IF is done, the most you = can use it for
is a sanity check and fail the send if you try to = send out an interace
not in the given scope.

-Dave

------_=_NextPart_001_01BFDF88.D61B2434-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 10:15:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QHD6c11816 for ipng-dist; Mon, 26 Jun 2000 10:13:06 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QHD1611809 for ; Mon, 26 Jun 2000 10:13:01 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA15395 for ipng@sunroof.eng.sun.com; Mon, 26 Jun 2000 10:11:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5O2na610183 for ; Fri, 23 Jun 2000 19:49:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA26387 for ; Fri, 23 Jun 2000 19:49:35 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA12361 for ; Fri, 23 Jun 2000 20:49:34 -0600 (MDT) Received: (qmail 21419 invoked from network); 24 Jun 2000 02:51:51 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 24 Jun 2000 02:51:51 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Fri, 23 Jun 2000 19:43:41 +4100 Date: Fri, 23 Jun 2000 19:43:41 -0700 From: Ben Black To: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000623194341.D12159@layer8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from vijay@umbc.edu on Fri, Jun 23, 2000 at 10:14:25PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please direct your attention to the lengthy discussion of the numerous flaws in this draft on the ipng list starting on September 14, 1999. I do not believe this draft provides any benefit ro network operators. The draft on multihoming by itojun is a far superior work (as disscussed last September). Ben > Date: Fri, 23 Jun 2000 16:20:01 -0700 > From: Bob Hinden > To: ipng@sunroof.eng.sun.com > Subject: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" > > This is a IPng working group last call for comments on advancing the > following document as Informational: > > Title : IPv6 Multihoming with Route Aggregation > Author(s) : J. Yu > Filename : draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt > Pages : 7 > Date : 24-Nov-99 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the author. This last call period will end two > week from today on July 7, 2000. > > Bob Hinden / Steve Deering > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 10:32:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QHUa911912 for ipng-dist; Mon, 26 Jun 2000 10:30:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QHUQ611905 for ; Mon, 26 Jun 2000 10:30:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA06659 for ; Mon, 26 Jun 2000 10:30:26 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15541 for ; Mon, 26 Jun 2000 11:30:25 -0600 (MDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id E079057FA; Mon, 26 Jun 2000 13:30:23 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id AB7D55A19; Mon, 26 Jun 2000 13:30:22 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0000620941; Mon, 26 Jun 2000 13:30:18 -0400 (EDT) From: Jim Bound Message-Id: <200006261730.NAA0000620941@anw.zk3.dec.com> To: Ben Black Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Fri, 23 Jun 2000 19:43:41 PDT." <20000623194341.D12159@layer8.net> Date: Mon, 26 Jun 2000 13:30:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben, >Please direct your attention to the lengthy discussion of the >numerous flaws in this draft on the ipng list starting >on September 14, 1999. I do not believe this draft provides >any benefit ro network operators. The draft on multihoming by >itojun is a far superior work (as disscussed last September). I disagree with you and J. Yu's draft does provide benefit to network operators. I also believe Itojun's does too. All I will say which is about as much context you gave me in your mail. But thats my opinion. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 10:37:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QHYmW11942 for ipng-dist; Mon, 26 Jun 2000 10:34:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QHYb611935 for ; Mon, 26 Jun 2000 10:34:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA23079 for ; Mon, 26 Jun 2000 10:34:37 -0700 (PDT) Received: from web3004.mail.yahoo.com (web3004.mail.yahoo.com [204.71.202.167]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA20456 for ; Mon, 26 Jun 2000 10:34:36 -0700 (PDT) Received: (qmail 10460 invoked by uid 60001); 26 Jun 2000 17:34:36 -0000 Message-ID: <20000626173436.10459.qmail@web3004.mail.yahoo.com> Received: from [141.212.130.253] by web3004.mail.yahoo.com; Mon, 26 Jun 2000 10:34:36 PDT Date: Mon, 26 Jun 2000 10:34:36 -0700 (PDT) From: Jessica Yu Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" To: Ben Black , hinden@iprg.nokia.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 As I recall, the conclusion of that lengthy discussion you mentioned is that both mechanism can be useful for different situations and the group decided (at the interim meeting in Japan) to have adopt both mechanisms (see minutes of that Interim meeting). --jessica --- Ben Black wrote: > Please direct your attention to the lengthy > discussion of the > numerous flaws in this draft on the ipng list > starting > on September 14, 1999. I do not believe this draft > provides > any benefit ro network operators. The draft on > multihoming by > itojun is a far superior work (as disscussed last > September). > > > Ben > > > > Date: Fri, 23 Jun 2000 16:20:01 -0700 > > From: Bob Hinden > > To: ipng@sunroof.eng.sun.com > > Subject: W.G. Last Call on "IPv6 Multihoming with > Route Aggregation" > > > > This is a IPng working group last call for > comments on advancing the > > following document as Informational: > > > > Title : IPv6 Multihoming with Route Aggregation > > Author(s) : J. Yu > > Filename : > draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt > > Pages : 7 > > Date : 24-Nov-99 > > > > Please send substantive comments to the ipng > mailing list, and minor > > editorial comments to the author. This last call > period will end two > > week from today on July 7, 2000. > > > > Bob Hinden / Steve Deering > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: > http://playground.sun.com/ipng > > FTP archive: > ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 10:44:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QHf2E11987 for ipng-dist; Mon, 26 Jun 2000 10:41:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QHer611979 for ; Mon, 26 Jun 2000 10:40:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA24803 for ; Mon, 26 Jun 2000 10:40:53 -0700 (PDT) Received: from mx2out.umbc.edu (mx2out.umbc.edu [130.85.253.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24291 for ; Mon, 26 Jun 2000 11:40:51 -0600 (MDT) Received: from gl.umbc.edu (vijay@umbc8.umbc.edu [130.85.60.8]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA10916; Mon, 26 Jun 2000 13:40:48 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id NAA10628454; Mon, 26 Jun 2000 13:40:47 -0400 (EDT) X-Authentication-Warning: umbc8.umbc.edu: vijay owned process doing -bs Date: Mon, 26 Jun 2000 13:40:46 -0400 From: Vijay Gill To: Jim Bound cc: Ben Black , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-Reply-To: <200006261730.NAA0000620941@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 26 Jun 2000, Jim Bound wrote: > I disagree with you and J. Yu's draft does provide benefit to network > operators. I also believe Itojun's does too. All I will say which is > about as much context you gave me in your mail. But thats my opinion. Speaking as a potential customer and sometimes operator, I am still trying to figure out what exactly does this draft buy me (a customer) in terms of added resilience over just getting diversely homed to the primary ISP in the first place. /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 10:49:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QHltA12055 for ipng-dist; Mon, 26 Jun 2000 10:47:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QHlj612048 for ; Mon, 26 Jun 2000 10:47:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA18052 for ; Mon, 26 Jun 2000 10:47:45 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29209 for ; Mon, 26 Jun 2000 10:47:44 -0700 (PDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 26 Jun 2000 12:45:41 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 12:47:11 -0500 Message-ID: From: "Peter Tam" To: Bob Hinden , ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" Date: Mon, 26 Jun 2000 12:47:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDF96.8CDC2C92" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDF96.8CDC2C92 Content-Type: text/plain; charset="ISO-8859-1" Bob: This is the 1st time I read this draft. Apology if the following have been discussed before: 1. Must the Target Address List option in the Inverse Neighbor Discovery Advertisement (InvNDA) message not contain unicast IPv6 addresses only? I think it must. Then it will affect section 4.3.2 on the validation procedures. 2. Should it not also support unsolicited InvNDA, when 1 or more of an inteface's IP addresses have been changed? It should, and should also enforce to re-advertise all the addresses on that interface. Otherwise, it is not possible to cover the scenario where an IP address on the interface was deleted. 3. Appendix A: Frame Relay (FR) as a link-layer address. But it should have a note up front that the DLCI applies to the member DLCI in the case of a Multi-link Frame Relay. 4. Why is there a preference of FR to ATM in Appendix A? Should also include the case for ATM as a link-layer technology. Regards... Peter Tam, Nortel Networks, Ottawa -----Original Message----- From: Bob Hinden [SMTP:hinden@iprg.nokia.com] Sent: Thursday, June 22, 2000 4:27 PM To: ipng@sunroof.eng.sun.com Subject: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification Author(s) : A. Conta Filename : draft-ietf-ion-ipv6-ind-03.txt Pages : 22 Date : 27-Oct-99 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two week from today on July 6, 2000. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01BFDF96.8CDC2C92 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: W.G. Last Call on "Extensions to IPv6 Neighbor = Discovery for Inverse Discovery Specification"

Bob:

This is the 1st = time I read this draft. Apology if the following have been discussed = before:

  1. Must the Target Address = List option in the Inverse Neighbor Discovery Advertisement (InvNDA) = message not contain unicast IPv6 addresses only? I think it must. Then = it will affect section 4.3.2 on the validation procedures.
  2. Should it not also support = unsolicited InvNDA, when 1 or more of an inteface's IP addresses have = been changed? It should, and should also enforce to re-advertise all = the addresses on that interface. Otherwise, it is not possible to cover = the scenario where an IP address on the interface was deleted. =
  3. Appendix A: Frame Relay (FR) as a = link-layer address. But it should have a note up front that the DLCI = applies to the member DLCI in the case of a Multi-link Frame = Relay.
  4. Why is there a preference of FR to = ATM in Appendix A? Should also include the case for ATM as a link-layer = technology.

Regards... Peter Tam,
Nortel Networks, Ottawa

    -----Original = Message-----
    From:   Bob Hinden = [SMTP:hinden@iprg.nokia.com]
    Sent:   Thursday, June 22, 2000 4:27 PM
    To:     ipng@sunroof.eng.sun.com
    Subject:       = W.G. Last Call on "Extensions = to IPv6 Neighbor Discovery for Inverse  Discovery = Specification"

    This is a IPng working group last call = for comments on advancing the
    following document as a Proposed = Standard:

            Title   =         : Extensions to IPv6 = Neighbor Discovery for Inverse
             &nb= sp;           &nb= sp;    Discovery Specification
            Author(s)       : A. = Conta
            Filename        : = draft-ietf-ion-ipv6-ind-03.txt
            Pages   =         : 22
            Date    =         : 27-Oct-99

    Please send substantive comments to = the ipng mailing list, and minor
    editorial comments to the author. = ; This last call period will end two
    week from today on July 6, = 2000.

    Bob Hinden / Steve Deering

    ---------------------------------------------------------= -----------
    IETF IPng Working Group Mailing = List
    IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
    FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
    Direct all administrative requests to = majordomo@sunroof.eng.sun.com
    ---------------------------------------------------------= -----------

------_=_NextPart_001_01BFDF96.8CDC2C92-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 11:24:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QIM9m12182 for ipng-dist; Mon, 26 Jun 2000 11:22:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QIM0612175 for ; Mon, 26 Jun 2000 11:22:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA13433 for ; Mon, 26 Jun 2000 11:22:00 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22607 for ; Mon, 26 Jun 2000 11:21:56 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA01096; Mon, 26 Jun 2000 11:21:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA04584; Mon, 26 Jun 2000 11:21:21 -0700 X-Virus-Scanned: Mon, 26 Jun 2000 11:21:21 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma004409; Mon, 26 Jun 00 11:21:16 -0700 Message-Id: <4.3.2.7.2.20000626110919.01f19940@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Jun 2000 11:19:13 -0700 To: Ben Black From: Bob Hinden Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20000626103352.B12267@layer8.net> References: <20000626173436.10459.qmail@web3004.mail.yahoo.com> <20000626173436.10459.qmail@web3004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben, >At 10:33 AM 6/26/2000 -0700, Ben Black wrote: >Where can I find these interim meeting minutes and do they >include information on exactly what situations your draft >covers which Itojun's does not? The minutes can be found at: http://playground.sun.com/pub/ipng/html/meetings.html It was the consensus of the working group to publish this document and Itojun's draft (and possibly others) as multihoming solutions that help in specific situations. It was clear that they are not universal solutions. The w.g. is also moving forward with other related work such as Rich Draves address selection procedures. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 11:24:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QIMt412191 for ipng-dist; Mon, 26 Jun 2000 11:22:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QIMi612184 for ; Mon, 26 Jun 2000 11:22:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA06616 for ; Mon, 26 Jun 2000 11:22:44 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00328 for ; Mon, 26 Jun 2000 12:22:42 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5QILIK56172; Mon, 26 Jun 2000 20:21:19 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA07752; Mon, 26 Jun 2000 20:21:17 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id UAA02868; Mon, 26 Jun 2000 20:22:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006261822.UAA02868@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dave Thaler" cc: "Dave Thaler" , jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Mon, 26 Jun 2000 09:08:59 PDT. <19398D273324D3118A2B0008C7E9A5690D8CEE40@SIT.platinum.corp.microsoft.com> Date: Mon, 26 Jun 2000 20:22:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: It's not useless on emission, since it's not required to do IPV6_MULTICAST_IF. => I believe most of us will disagree... If you don't do IPV6_MULTICAST_IF, the meaning would be to send via some interface in the set identified by scope_id. => some = one, all, any subset? This needs some clarifications of the scope is not the link-local one. However, when IPV6_MULTICAST_IF is done, the most you can use it for is a sanity check and fail the send if you try to send out an interace not in the given scope. => this is the only useful thing which can be done then I still think in this case the scope ID is nearly useless... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 11:47:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QIj5p12248 for ipng-dist; Mon, 26 Jun 2000 11:45:05 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QIj0612241 for ; Mon, 26 Jun 2000 11:45:00 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA15554 for ipng@sunroof.eng.sun.com; Mon, 26 Jun 2000 11:43:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5Q9K5611515 for ; Mon, 26 Jun 2000 02:20:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA19244 for ; Mon, 26 Jun 2000 02:20:05 -0700 (PDT) Received: from mailhostnew.tbit.dk (mailhostnew.tbit.dk [194.182.135.150]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08485 for ; Mon, 26 Jun 2000 02:19:59 -0700 (PDT) Received: from mhr.tbit.dk (mhr.tbit.dk [194.182.135.76]) by mailhostnew.tbit.dk (8.9.3+Sun/8.9.3) with ESMTP id LAA08391 for ; Mon, 26 Jun 2000 11:19:53 +0200 (MET DST) Received: (from mhr@localhost) by mhr.tbit.dk (8.9.3/8.9.3) id LAA04902; Mon, 26 Jun 2000 11:19:54 +0200 To: ipng@sunroof.eng.sun.com Subject: Stateless autoconf and dial-on-demand From: Morten Heiberg Rasmussen Date: 26 Jun 2000 11:19:54 +0200 Message-ID: Lines: 31 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi I have a question regarding IPv6 stateless address autoconfiguration in combination with dial-on-demand network access. Suppose I have a network configured using only stateless address autoconfiguration. At this point all hosts have a link local address but nothing with wider scope. When a connection to the outside world is opened the gateway node starts to receive router advertisements from our ISP with a globally routable prefix. This prefix is distributed to the hosts on the local network so that they can form complete, global IP addresses. How does one implement dial-on-demand in such a setting? The gateway for the network needs an outbound packet to trigger the dialing process, but at that time the emitting host does not have a global address to select as the packet source address. Hence the packet cannot be sent. Is there any way to avoid having to rewrite the first outbound packets in the gateway? If it is not acceptable to open the connection when no traffic is being sent and if we cannot assume that everybody uses DNS I don't really see how it could be done. Best regards Morten Heiberg -- Morten Heiberg Rasmussen System Developer, M. Sc. Ericsson Telebit A/S Tel: +45 86 28 81 76 Fabrikvej 11 Fax: +45 86 28 81 86 DK-8260 Viby J, Denmark E-mail: mhr@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 Mon Jun 26 11:49:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QImJQ12285 for ipng-dist; Mon, 26 Jun 2000 11:48:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QIm9612278 for ; Mon, 26 Jun 2000 11:48:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA29692 for ; Mon, 26 Jun 2000 11:48:08 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10307 for ; Mon, 26 Jun 2000 11:48:08 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id E2A36603; Mon, 26 Jun 2000 13:48:05 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 559467A3; Mon, 26 Jun 2000 13:48:05 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id OAA0000631892; Mon, 26 Jun 2000 14:48:04 -0400 (EDT) From: Jim Bound Message-Id: <200006261848.OAA0000631892@anw.zk3.dec.com> To: Ben Black Cc: Jim Bound , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Mon, 26 Jun 2000 10:27:50 PDT." <20000626102750.A12267@layer8.net> Date: Mon, 26 Jun 2000 14:48:04 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have the thread and will parse it. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 11:52:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QIpc412320 for ipng-dist; Mon, 26 Jun 2000 11:51:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QIpS612308 for ; Mon, 26 Jun 2000 11:51:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA14507 for ; Mon, 26 Jun 2000 11:51:28 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12397 for ; Mon, 26 Jun 2000 11:51:26 -0700 (PDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 08FFD4E6; Mon, 26 Jun 2000 13:51:26 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 7F23E716; Mon, 26 Jun 2000 13:51:25 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id OAA0000632798; Mon, 26 Jun 2000 14:51:24 -0400 (EDT) From: Jim Bound Message-Id: <200006261851.OAA0000632798@anw.zk3.dec.com> To: Vijay Gill Cc: Jim Bound , Ben Black , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Mon, 26 Jun 2000 13:40:46 EDT." Date: Mon, 26 Jun 2000 14:51:23 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I disagree with you and J. Yu's draft does provide benefit to network >> operators. I also believe Itojun's does too. All I will say which is >> about as much context you gave me in your mail. But thats my opinion. > >Speaking as a potential customer and sometimes operator, I am still trying >to figure out what exactly does this draft buy me (a customer) in terms of >added resilience over just getting diversely homed to the primary ISP in >the first place. Exactly. J. Yu's draft works now by administration just like IPv4. No better, no worse. Anything else is not even proposed std and no product vendor code bases I am aware of or more directly router vendor v6 code bases are implementing any IPng disucssion which did not result in any consensus for IPv6 Working Group. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 12:04:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QJ1to12359 for ipng-dist; Mon, 26 Jun 2000 12:01:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QJ1k612352 for ; Mon, 26 Jun 2000 12:01:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA08730 for ; Mon, 26 Jun 2000 12:01:45 -0700 (PDT) Received: from web3002.mail.yahoo.com (web3002.mail.yahoo.com [204.71.202.165]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA03427 for ; Mon, 26 Jun 2000 13:01:43 -0600 (MDT) Received: (qmail 17900 invoked by uid 60001); 26 Jun 2000 19:01:36 -0000 Message-ID: <20000626190136.17899.qmail@web3002.mail.yahoo.com> Received: from [141.212.130.253] by web3002.mail.yahoo.com; Mon, 26 Jun 2000 12:01:36 PDT Date: Mon, 26 Jun 2000 12:01:36 -0700 (PDT) From: Jessica Yu Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" To: Vijay Gill , Jim Bound Cc: Ben Black , hinden@iprg.nokia.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 Hi, Vijay: Some of the benefits Simple multihoming mechanism than multihoming to one ISP are as follows: The tail circuits to the customer have the opportunity to go through diverse infrastructure (e.g. fiber) which would increase reliability. Instead of going to different POPs from the same ISP, the customer will be able to go to the close POPs of two ISPs. Therefore, the distance for the 2nd tail circuit can be shorter resulting money saving. The customer can reach part of the Internet (at least customers of ISP2) without relying on ISP1. --jessica This is going to be an informational. A relatively simple mechanism for multihoming while achiving maxmium aggregation. An option for people whose situation fits. --- Vijay Gill wrote: > > > On Mon, 26 Jun 2000, Jim Bound wrote: > > > I disagree with you and J. Yu's draft does provide > benefit to network > > operators. I also believe Itojun's does too. All > I will say which is > > about as much context you gave me in your mail. > But thats my opinion. > > Speaking as a potential customer and sometimes > operator, I am still trying > to figure out what exactly does this draft buy me (a > customer) in terms of > added resilience over just getting diversely homed > to the primary ISP in > the first place. > > /vijay > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 12:04:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QJ2YK12368 for ipng-dist; Mon, 26 Jun 2000 12:02:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QJ2O612361 for ; Mon, 26 Jun 2000 12:02:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03078 for ; Mon, 26 Jun 2000 12:02:23 -0700 (PDT) Received: from mx3out.umbc.edu (mx3out.umbc.edu [130.85.253.53]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19605 for ; Mon, 26 Jun 2000 12:02:22 -0700 (PDT) Received: from gl.umbc.edu (vijay@umbc8.umbc.edu [130.85.60.8]) by mx3out.umbc.edu (8.9.3/8.9.3) with ESMTP id PAA29976; Mon, 26 Jun 2000 15:02:20 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id PAA10409591; Mon, 26 Jun 2000 15:02:19 -0400 (EDT) X-Authentication-Warning: umbc8.umbc.edu: vijay owned process doing -bs Date: Mon, 26 Jun 2000 15:02:18 -0400 From: Vijay Gill To: Jim Bound cc: Ben Black , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-Reply-To: <200006261851.OAA0000632798@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 26 Jun 2000, Jim Bound wrote: > Exactly. J. Yu's draft works now by administration just like IPv4. No > better, no worse. Anything else is not even proposed std and no product > vendor code bases I am aware of or more directly router vendor v6 code > bases are implementing any IPng disucssion which did not result in any > consensus for IPv6 Working Group. Jim, this is probably because english is my second language, but the above paragraph made no sense whatsoever to me. /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 12:13:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QJBZ212418 for ipng-dist; Mon, 26 Jun 2000 12:11:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QJBG612409 for ; Mon, 26 Jun 2000 12:11:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA18913 for ; Mon, 26 Jun 2000 12:11:15 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA10983 for ; Mon, 26 Jun 2000 13:11:15 -0600 (MDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jun 2000 11:19:53 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Mon, 26 Jun 2000 11:28:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4397.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDF9B.4DAAC3A8" Subject: RE: rfc2553bis comments Date: Mon, 26 Jun 2000 11:21:10 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690D8CEE47@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc2553bis comments Thread-Index: Ab/fmpy0W/DfSaSCRSWzHxCw+cBFnQAAW8Pw From: "Dave Thaler" To: "Francis Dupont" Cc: "Dave Thaler" , , X-OriginalArrivalTime: 26 Jun 2000 18:28:57.0139 (UTC) FILETIME=[63C4B030:01BFDF9C] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFDF9B.4DAAC3A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francis Dupont writes: > If you don't do IPV6_MULTICAST_IF, the meaning would > be to send via some interface in the set identified by scope_id. > =20 > =3D> some =3D one, all, any subset? This needs some clarifications of > the scope is not the link-local one. Exactly one. Same as in IPv4. -Dave ------_=_NextPart_001_01BFDF9B.4DAAC3A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: rfc2553bis comments

Francis Dupont writes:
>    If you don't do = IPV6_MULTICAST_IF, the meaning would
>    be to send via some interface = in the set identified by scope_id.
>   
> =3D> some =3D one, all, any subset? This = needs some clarifications of
> the scope is not the link-local one.

Exactly one.  Same as in IPv4.

-Dave

------_=_NextPart_001_01BFDF9B.4DAAC3A8-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 12:14:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QJCES12439 for ipng-dist; Mon, 26 Jun 2000 12:12:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QJC1612432 for ; Mon, 26 Jun 2000 12:12:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA25823 for ; Mon, 26 Jun 2000 12:12:00 -0700 (PDT) Received: from mx1out.umbc.edu (mx1out.umbc.edu [130.85.253.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25429 for ; Mon, 26 Jun 2000 12:11:59 -0700 (PDT) Received: from gl.umbc.edu (vijay@umbc8.umbc.edu [130.85.60.8]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id PAA29619; Mon, 26 Jun 2000 15:11:56 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id PAA10715910; Mon, 26 Jun 2000 15:11:56 -0400 (EDT) X-Authentication-Warning: umbc8.umbc.edu: vijay owned process doing -bs Date: Mon, 26 Jun 2000 15:11:55 -0400 From: Vijay Gill To: Jessica Yu cc: Jim Bound , Ben Black , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-Reply-To: <20000626190136.17899.qmail@web3002.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 26 Jun 2000, Jessica Yu wrote: Jessica, > The tail circuits to the customer have the opportunity to go through > diverse infrastructure (e.g. fiber) which would increase reliability. So would they if I just went to two different ISP's and got them to punch a hole in their aggregate for the netblock assigned to me from the first ISP. [paragragh X] > Instead of going to different POPs from the same ISP, > the customer will be able to go to the close POPs of > two ISPs. Therefore, the distance for the 2nd tail > circuit can be shorter resulting money saving. See Paragraph X. > The customer can reach part of the Internet (at least > customers of ISP2) without relying on ISP1. See Paragraph X. This also buys me the additional safety of being shielded from complete failure of one of the upstream ISPs. With network connectivity now becoming fundamental to doing business, I submit that there isn't a single sensible company who would rely upon this draft under discussion for a critical need. Instead most of them would immediately try and go for Paragraph X. Speaking as an operator, when clients are throwing $n million contracts at you, there is a powerful incentive to accomodate them. /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 12:49:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QJiFt12558 for ipng-dist; Mon, 26 Jun 2000 12:44:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QJhq612551 for ; Mon, 26 Jun 2000 12:43:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13497 for ; Mon, 26 Jun 2000 12:43:43 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05286 for ; Mon, 26 Jun 2000 13:43:25 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id OAA24273; Mon, 26 Jun 2000 14:43:21 -0500 (CDT) Message-Id: <200006261943.OAA24273@gungnir.fnal.gov> To: Morten Heiberg Rasmussen Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Stateless autoconf and dial-on-demand In-reply-to: Your message of 26 Jun 2000 11:19:54 +0200. Date: Mon, 26 Jun 2000 14:43:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If your dialup router is in command of the whole process, what happens if it holds the first outbound packet for a while, then advertises the new global prefix, *then* sends the initiator an ICMP "beyond scope of source address"? Will the initiator's stack then retry with the new global-scope address? Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 13:11:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QK9G812581 for ipng-dist; Mon, 26 Jun 2000 13:09:16 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QK9C612574 for ; Mon, 26 Jun 2000 13:09:12 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA15611 for ipng@sunroof.eng.sun.com; Mon, 26 Jun 2000 13:07:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QHXs611923 for ; Mon, 26 Jun 2000 10:33:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA00070 for ; Mon, 26 Jun 2000 10:33:54 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA18631 for ; Mon, 26 Jun 2000 11:33:52 -0600 (MDT) Received: (qmail 22225 invoked from network); 26 Jun 2000 17:36:05 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 26 Jun 2000 17:36:05 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 26 Jun 2000 10:27:50 -0700 Date: Mon, 26 Jun 2000 10:27:50 -0700 From: Ben Black To: Jim Bound Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000626102750.A12267@layer8.net> References: <20000623194341.D12159@layer8.net> <200006261730.NAA0000620941@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006261730.NAA0000620941@anw.zk3.dec.com>; from bound@zk3.dec.com on Mon, Jun 26, 2000 at 01:30:18PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I provided no context beyond the reference to the previous thread as I did not see any need to rehash that thread and waste everyones time. I have previously stated quite clearly the numerous deficiencies in J. Yu's draft and encourage you to read the original thread on the subject. I will be happy to forward the entire thread to you if you missed it. Ben On Mon, Jun 26, 2000 at 01:30:18PM -0400, Jim Bound wrote: > Ben, > > >Please direct your attention to the lengthy discussion of the > >numerous flaws in this draft on the ipng list starting > >on September 14, 1999. I do not believe this draft provides > >any benefit ro network operators. The draft on multihoming by > >itojun is a far superior work (as disscussed last September). > > I disagree with you and J. Yu's draft does provide benefit to network > operators. I also believe Itojun's does too. All I will say which is > about as much context you gave me in your mail. But thats my opinion. > > /jim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 13:13:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QKAsa12596 for ipng-dist; Mon, 26 Jun 2000 13:10:54 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QKAm612589 for ; Mon, 26 Jun 2000 13:10:48 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA15655 for ipng@sunroof.eng.sun.com; Mon, 26 Jun 2000 13:09:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QHdq611967 for ; Mon, 26 Jun 2000 10:39:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA15765 for ; Mon, 26 Jun 2000 10:39:52 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA23389 for ; Mon, 26 Jun 2000 11:39:51 -0600 (MDT) Received: (qmail 22241 invoked from network); 26 Jun 2000 17:42:08 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 26 Jun 2000 17:42:08 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 26 Jun 2000 10:33:52 -0700 Date: Mon, 26 Jun 2000 10:33:52 -0700 From: Ben Black To: Jessica Yu Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000626103352.B12267@layer8.net> References: <20000626173436.10459.qmail@web3004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000626173436.10459.qmail@web3004.mail.yahoo.com>; from jyy_99@yahoo.com on Mon, Jun 26, 2000 at 10:34:36AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Where can I find these interim meeting minutes and do they include information on exactly what situations your draft covers which Itojun's does not? Ben On Mon, Jun 26, 2000 at 10:34:36AM -0700, Jessica Yu wrote: > As I recall, the conclusion of that lengthy discussion > you mentioned is that both mechanism can be useful for > different situations and the group decided (at the > interim meeting in Japan) to have adopt both > mechanisms (see minutes of that Interim meeting). > > --jessica > > --- Ben Black wrote: > > Please direct your attention to the lengthy > > discussion of the > > numerous flaws in this draft on the ipng list > > starting > > on September 14, 1999. I do not believe this draft > > provides > > any benefit ro network operators. The draft on > > multihoming by > > itojun is a far superior work (as disscussed last > > September). > > > > > > Ben > > > > > > > Date: Fri, 23 Jun 2000 16:20:01 -0700 > > > From: Bob Hinden > > > To: ipng@sunroof.eng.sun.com > > > Subject: W.G. Last Call on "IPv6 Multihoming with > > Route Aggregation" > > > > > > This is a IPng working group last call for > > comments on advancing the > > > following document as Informational: > > > > > > Title : IPv6 Multihoming with Route Aggregation > > > Author(s) : J. Yu > > > Filename : > > draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt > > > Pages : 7 > > > Date : 24-Nov-99 > > > > > > Please send substantive comments to the ipng > > mailing list, and minor > > > editorial comments to the author. This last call > > period will end two > > > week from today on July 7, 2000. > > > > > > Bob Hinden / Steve Deering > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > > http://playground.sun.com/ipng > > > FTP archive: > > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > > majordomo@sunroof.eng.sun.com > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: > > http://playground.sun.com/ipng > > FTP archive: > > ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to > > majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 13:24:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QKLZh12681 for ipng-dist; Mon, 26 Jun 2000 13:21:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QKLQ612674 for ; Mon, 26 Jun 2000 13:21:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA21573 for ; Mon, 26 Jun 2000 13:21:25 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08488 for ; Mon, 26 Jun 2000 13:21:24 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5QKKAK40790; Mon, 26 Jun 2000 22:20:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA08784; Mon, 26 Jun 2000 22:20:10 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id WAA03395; Mon, 26 Jun 2000 22:20:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006262020.WAA03395@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dave Thaler" cc: "Dave Thaler" , jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Mon, 26 Jun 2000 11:21:10 PDT. <19398D273324D3118A2B0008C7E9A5690D8CEE47@SIT.platinum.corp.microsoft.com> Date: Mon, 26 Jun 2000 22:20:55 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > If you don't do IPV6_MULTICAST_IF, the meaning would > be to send via some interface in the set identified by scope_id. > > => some = one, all, any subset? This needs some clarifications of > the scope is not the link-local one. Exactly one. Same as in IPv4. => I think this interface will be selected according to the routing table, ie. in general it will be the interface used for the default route, won't it? (it is what happens with IPv4 and sin6_scope_id (in your proposal) will not be used for the outgoing interface selection itself, only for a check about the selection soundness, ie. with only a little improvement over standard IPv4 multicast for emission) Regards Francis.Dupont@enst-bretagne.fr PS: about the (still missing) scope/zone specs, the zone A `is included in the zone B if A < B (using for A and B the multicast scope numbers like 2 (link), 5 (site), 8 (org), ...). This is in *no* current specs... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 13:38:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QKa4A12726 for ipng-dist; Mon, 26 Jun 2000 13:36:04 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QKZw612719 for ; Mon, 26 Jun 2000 13:35:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA15722 for ipng@sunroof.eng.sun.com; Mon, 26 Jun 2000 13:34:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QJOi612505 for ; Mon, 26 Jun 2000 12:24:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA08471 for ; Mon, 26 Jun 2000 12:24:43 -0700 (PDT) Received: from dial.paul.labrats.com (dial.paul.labrats.com [209.236.66.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21385 for ; Mon, 26 Jun 2000 13:24:42 -0600 (MDT) Received: from pflores ([208.145.18.248]) by dial.paul.labrats.com (8.9.3/8.8.8) with SMTP id OAA01345; Mon, 26 Jun 2000 14:22:35 -0500 (CDT) (envelope-from pflores@labrats.com) Reply-To: From: "Paul Flores" To: "'Vijay Gill'" , "Jessica Yu" Cc: "Jim Bound" , "Ben Black" , , Subject: RE: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Date: Mon, 26 Jun 2000 14:21:59 -0500 Message-ID: <000c01bfdfa3$cd6254a0$f81291d0@pflores.labrats.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Subject: Re: W.G. Last Call on "IPv6 Multihoming with >Route Aggregation" See Paragraph X. >This also buys me the additional safety of being >shielded from complete >failure of one of the upstream ISPs. With network >connectivity now >becoming fundamental to doing business, I submit that >there isn't a single >sensible company who would rely upon this draft under >discussion for a >critical need. Instead most of them would immediately >try and go for >Paragraph X. Speaking as an operator, when clients are >throwing $n >million contracts at you, there is a powerful incentive >to accomodate >them. > >/vijay That doesn't mean it the concept should not be properly documented. You know some marketing droid will find a way to sell the concept of dual homing to the same provider, no matter how technically defensible it is. (I actually know a few ISPs who _brag_ that they were able to get such an arraignment). Takes all Kinds.. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 13:38:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QKYlB12717 for ipng-dist; Mon, 26 Jun 2000 13:34:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QKYa612710 for ; Mon, 26 Jun 2000 13:34:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA00205 for ; Mon, 26 Jun 2000 13:34:32 -0700 (PDT) Received: from lychee.itojun.org (dhcp215.nttmcl.com [216.69.69.215]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17378 for ; Mon, 26 Jun 2000 13:34:32 -0700 (PDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e5QKVeB00701; Tue, 27 Jun 2000 05:31:40 +0900 (JST) To: Bob Hinden cc: Ben Black , ipng@sunroof.eng.sun.com In-reply-to: hinden's message of Mon, 26 Jun 2000 11:19:13 MST. <4.3.2.7.2.20000626110919.01f19940@mailhost.iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" From: Jun-ichiro itojun Hagino Date: Tue, 27 Jun 2000 05:31:40 +0900 Message-ID: <699.962051500@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The minutes can be found at: > http://playground.sun.com/pub/ipng/html/meetings.html >It was the consensus of the working group to publish this document and >Itojun's draft (and possibly others) as multihoming solutions that help in >specific situations. It was clear that they are not universal >solutions. The w.g. is also moving forward with other related work such as >Rich Draves address selection procedures. Just for clarification. My draft is still alive. there was some problem with i-d editor and it confused me, and possibly co-chairs (01 draft is marked expired in i-d repository, however, I have never submitted 01 draft as far as I remeber) I have re-submitted my draft on multihoming (RFC2260 lookalike) with wording clarifications and some reference updates. it should appear into internet-drafts repository soon. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 13:49:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QKkvC12804 for ipng-dist; Mon, 26 Jun 2000 13:46:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QKkc612787 for ; Mon, 26 Jun 2000 13:46:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA03446 for ; Mon, 26 Jun 2000 13:46:35 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA24644 for ; Mon, 26 Jun 2000 13:46:21 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jun 2000 13:45:47 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Mon, 26 Jun 2000 13:45:45 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810249B8E7A@RED-MSG-50> From: Richard Draves To: Dave Thaler , Francis.Dupont@enst-bretagne.fr Cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments Date: Mon, 26 Jun 2000 13:45:36 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ... These tend to argue for zone ids, not interface indexes > (except for link-scoped where they're the same thing). Implementations today use the same number space for interface indices and link-scoped zone ids, but they are not necessarily the same thing. One could number links separately from interfaces. I'm warming up to Dave's proposal, but I would not invent new zone ids for all the different multicast scope levels. (Or at least I'd leave this optional for implementations.) I'd map the multicast scope levels into the link-local/site-local/global unicast scopes. 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 Mon Jun 26 14:21:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QLJaD12888 for ipng-dist; Mon, 26 Jun 2000 14:19:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QLJR612881 for ; Mon, 26 Jun 2000 14:19:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25804 for ; Mon, 26 Jun 2000 14:19:28 -0700 (PDT) Received: from web3002.mail.yahoo.com (web3002.mail.yahoo.com [204.71.202.165]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA15809 for ; Mon, 26 Jun 2000 14:19:27 -0700 (PDT) Received: (qmail 7054 invoked by uid 60001); 26 Jun 2000 21:19:27 -0000 Message-ID: <20000626211927.7053.qmail@web3002.mail.yahoo.com> Received: from [141.212.130.253] by web3002.mail.yahoo.com; Mon, 26 Jun 2000 14:19:27 PDT Date: Mon, 26 Jun 2000 14:19:27 -0700 (PDT) From: Jessica Yu Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" To: Vijay Gill Cc: Jim Bound , Ben Black , hinden@iprg.nokia.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 So now, we changed topic to multihoming to two ISPs with hole-punching, right? This is what we do today with two issues: a) increase the size of the global routing table since it can not be aggregated, and b) The longer prefixes (the hole) could be blocked by certain providers resulting in no access to that part of the Internet. I think this mechanism works today in IPv4 and there is no reason why can not be used for Ipv6. However, it does not hurt to have other mechanism which allow better aggregation available if there are concerns about the scaling and routability issues listed above. Speaking as a person who had worked for ISPs and dealt with operations for many many years, I submit there are entities who would like to have the arrangement as described in the ID. Thanks! --Jessica --- Vijay Gill wrote: > On Mon, 26 Jun 2000, Jessica Yu wrote: > > Jessica, > > > > The tail circuits to the customer have the > opportunity to go through > > diverse infrastructure (e.g. fiber) which would > increase reliability. > > So would they if I just went to two different ISP's > and got them to punch > a hole in their aggregate for the netblock assigned > to me from the first > ISP. [paragragh X] > > > Instead of going to different POPs from the same > ISP, > > the customer will be able to go to the close POPs > of > > two ISPs. Therefore, the distance for the 2nd tail > > circuit can be shorter resulting money saving. > > See Paragraph X. > > > The customer can reach part of the Internet (at > least > > customers of ISP2) without relying on ISP1. > > See Paragraph X. > > This also buys me the additional safety of being > shielded from complete > failure of one of the upstream ISPs. With network > connectivity now > becoming fundamental to doing business, I submit > that there isn't a single > sensible company who would rely upon this draft > under discussion for a > critical need. Instead most of them would > immediately try and go for > Paragraph X. Speaking as an operator, when clients > are throwing $n > million contracts at you, there is a powerful > incentive to accomodate > them. > > /vijay > > __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 14:45:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QLh3Z12952 for ipng-dist; Mon, 26 Jun 2000 14:43:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QLgq612945 for ; Mon, 26 Jun 2000 14:42:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA01734 for ; Mon, 26 Jun 2000 14:42:52 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA06139 for ; Mon, 26 Jun 2000 15:42:51 -0600 (MDT) Received: (qmail 22531 invoked from network); 26 Jun 2000 21:45:08 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 26 Jun 2000 21:45:08 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 26 Jun 2000 14:36:51 -0700 Date: Mon, 26 Jun 2000 14:36:51 -0700 From: Ben Black To: Jessica Yu Cc: Vijay Gill , Jim Bound , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000626143651.D12267@layer8.net> References: <20000626211927.7053.qmail@web3002.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000626211927.7053.qmail@web3002.mail.yahoo.com>; from jyy_99@yahoo.com on Mon, Jun 26, 2000 at 02:19:27PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Jun 26, 2000 at 02:19:27PM -0700, Jessica Yu wrote: > So now, we changed topic to multihoming to two ISPs > with hole-punching, right? This is what we do today > with two issues: > > a) increase the size of the global routing table since > it can not be aggregated, and > This issue verges on irrelevant given current hardware (even completely ignoring improvements in hardware over time). > b) The longer prefixes (the hole) could be blocked by > certain providers resulting in no access to that part > of the Internet. > No access to certain parts of the net during failure. This would seem to be a feature superior to your proposal in that you can access parts of the net beyond simply your direct peers. > I think this mechanism works today in IPv4 and there > is no reason why can not be used for Ipv6. However, it > does not hurt to have other mechanism which allow > better aggregation available if there are concerns > about the scaling and routability issues listed above. > Agreed, and I would add that those mechanisms should be as consistent as possible with the approaches in IPv4 unless there is a compelling technical reason for a previously unused mechanism. The Itojun proposal, based on the existing RFC2260 approach, meets those requirements. Your proposal introduces a new mechanism which lacks a compelling technical case. It is for these reasons that I am arguing it not be moved further along the track. Ben > Speaking as a person who had worked for ISPs and dealt > with operations for many many years, I submit there > are entities who would like to have the arrangement as > described in the ID. > > Thanks! > > --Jessica > > --- Vijay Gill wrote: > > On Mon, 26 Jun 2000, Jessica Yu wrote: > > > > Jessica, > > > > > > > The tail circuits to the customer have the > > opportunity to go through > > > diverse infrastructure (e.g. fiber) which would > > increase reliability. > > > > So would they if I just went to two different ISP's > > and got them to punch > > a hole in their aggregate for the netblock assigned > > to me from the first > > ISP. [paragragh X] > > > > > Instead of going to different POPs from the same > > ISP, > > > the customer will be able to go to the close POPs > > of > > > two ISPs. Therefore, the distance for the 2nd tail > > > circuit can be shorter resulting money saving. > > > > See Paragraph X. > > > > > The customer can reach part of the Internet (at > > least > > > customers of ISP2) without relying on ISP1. > > > > See Paragraph X. > > > > This also buys me the additional safety of being > > shielded from complete > > failure of one of the upstream ISPs. With network > > connectivity now > > becoming fundamental to doing business, I submit > > that there isn't a single > > sensible company who would rely upon this draft > > under discussion for a > > critical need. Instead most of them would > > immediately try and go for > > Paragraph X. Speaking as an operator, when clients > > are throwing $n > > million contracts at you, there is a powerful > > incentive to accomodate > > them. > > > > /vijay > > > > > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 16:47:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5QNjdk13150 for ipng-dist; Mon, 26 Jun 2000 16:45:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5QNjU613143 for ; Mon, 26 Jun 2000 16:45:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA08881 for ; Mon, 26 Jun 2000 16:45:30 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24919 for ; Mon, 26 Jun 2000 17:45:30 -0600 (MDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id QAA07786; Mon, 26 Jun 2000 16:44:45 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006262020.WAA03395@givry.rennes.enst-bretagne.fr> References: <200006262020.WAA03395@givry.rennes.enst-bretagne.fr> Date: Mon, 26 Jun 2000 16:45:17 -0700 To: Francis Dupont From: Steve Deering Subject: Re: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm sure I'm not following all the intricacies of the arguments, but maybe this is helpful (or maybe not, or maybe not even relevant): When sending a multicast packet in IPv4, one has the choice of either identifying a specific outgoing interface or leaving it to the IP layer to choose an outgoing interface (the "default" multicast interface). For IPv6, with its scoped addresses, the analogous capabilities would be a choice among: - identifying a particular outgoing interface, or - identifying only the outgoing zone (for non-global destinations), and leaving it to the IP layer to choose an outgoing interface within that zone, or - leaving it to the IP layer to choose both the outgoing zone (of the scope of the destination address) and the outgoing interface within that zone. All this could be done with the single sin6_scope_id field in the sending API, if the local indexes for the interfaces plus all zones (i.e., links, sites, and any additional multicast zones configured on the node) are given distinct values out of the same scope_id space, and if one index value (say, 0) is reserved to mean "unspecified". Then, I think we could probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it). On reception, the upper-layer should be told the arrival interface, from which it can also determine the arrival zones of each possible scope, since each interface can belong to only one zone of each scope. At 10:20 PM +0200 6/26/00, Francis Dupont wrote: >PS: about the (still missing) scope/zone specs,... The scope/zone spec is not "still missing", though it certainly still needs work. draft-ietf-ipngwg-scoping-arch-00.txt was published before Adelaide, and an -01 revision was posted to the ipng mailing list by Brian Haberman on March 22. That -01 version never made it into the Internet Drafts directories (it was posted during the time just before Adelaide while ID submissions were being refused), but we will rectify that ASAP. >...the zone A `is included in the zone B if A < B (using for A and B the >multicast scope numbers like 2 (link), 5 (site), 8 (org), ...). This is >in *no* current specs... >From draft-ietf-ipngwg-scoping-arch-00.txt: > There is an ordering relationship among scopes: > > o for unicast scopes, link-local is a smaller scope than site- > local, and site-local is smaller scope than global. > o for multicast scopes, scopes with lesser values in the > "scop" subfield of the multicast address [RFC 2373, section > 2.7] are smaller than scopes with greater values, with node- > local being the smallest and global being the largest. > > However, two scopes of different size may cover the exact same region > of topology, for example, a site may consist of a single link, in which > both link-local and site-local scope effectively cover the same > topological "distance". > >... > > Zones have the following additional properties: > > o Zone boundaries cut through nodes, not links. (There are > two exceptions: the global zone has no boundary, and the > boundary of a node-local zone conceptually cuts through an > interface between a node and a link.) > o Zones of the same scope cannot overlap, i.e., they can have > no links or interfaces in common. > o A zone of a given scope (less than global) falls completely > within zones of larger scope, i.e., a smaller scope zone > cannot include more topology than any larger scope zone with > which it shares any links or interfaces. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 18:06:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R149613272 for ipng-dist; Mon, 26 Jun 2000 18:04:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R140613265 for ; Mon, 26 Jun 2000 18:04:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA02702 for ; Mon, 26 Jun 2000 18:04:00 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07880 for ; Mon, 26 Jun 2000 18:04:00 -0700 (PDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id D482F5AD7; Mon, 26 Jun 2000 21:03:59 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id ABC8A5930; Mon, 26 Jun 2000 21:03:59 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id VAA0000695110; Mon, 26 Jun 2000 21:03:58 -0400 (EDT) From: Jim Bound Message-Id: <200006270103.VAA0000695110@anw.zk3.dec.com> To: Vijay Gill Cc: Jim Bound , Ben Black , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Mon, 26 Jun 2000 15:02:18 EDT." Date: Mon, 26 Jun 2000 21:03:58 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vijay, >> Exactly. J. Yu's draft works now by administration just like IPv4. No >> better, no worse. Anything else is not even proposed std and no product >> vendor code bases I am aware of or more directly router vendor v6 code >> bases are implementing any IPng disucssion which did not result in any >> consensus for IPv6 Working Group. >Jim, > >this is probably because english is my second language, but the above >paragraph made no sense whatsoever to me. Well the best I can do. Then I suggest you take Bob Hinden's mail to heart. We will have multiple solutions for now. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 18:18:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R1GXm13297 for ipng-dist; Mon, 26 Jun 2000 18:16:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R1GM613290 for ; Mon, 26 Jun 2000 18:16:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA11386 for ; Mon, 26 Jun 2000 18:16:12 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA10873 for ; Mon, 26 Jun 2000 19:16:10 -0600 (MDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 81864AB4; Mon, 26 Jun 2000 21:16:10 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3FC9D93F; Mon, 26 Jun 2000 21:16:10 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id VAA0000697593; Mon, 26 Jun 2000 21:16:09 -0400 (EDT) From: Jim Bound Message-Id: <200006270116.VAA0000697593@anw.zk3.dec.com> To: Ben Black Cc: Jessica Yu , Vijay Gill , Jim Bound , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Mon, 26 Jun 2000 14:36:51 PDT." <20000626143651.D12267@layer8.net> Date: Mon, 26 Jun 2000 21:16:09 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chairs, I stongly support this draft moving forward. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 18:34:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R1Vk113329 for ipng-dist; Mon, 26 Jun 2000 18:31:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R1Va613322 for ; Mon, 26 Jun 2000 18:31:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA19945 for ; Mon, 26 Jun 2000 18:31:36 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA16924 for ; Mon, 26 Jun 2000 19:31:35 -0600 (MDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id CAE7743D; Mon, 26 Jun 2000 21:31:34 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8B8CB709; Mon, 26 Jun 2000 21:31:34 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id VAA0000704647; Mon, 26 Jun 2000 21:31:07 -0400 (EDT) From: Jim Bound Message-Id: <200006270131.VAA0000704647@anw.zk3.dec.com> To: Steve Deering Cc: Francis Dupont , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: rfc2553bis comments In-reply-to: Your message of "Mon, 26 Jun 2000 16:45:17 PDT." Date: Mon, 26 Jun 2000 21:31:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, I am just listening but your mail has caused me to respond. >I'm sure I'm not following all the intricacies of the arguments, but >maybe this is helpful (or maybe not, or maybe not even relevant): Very relevant as you bring up important issue. > When sending a multicast packet in IPv4, one has the choice of either > identifying a specific outgoing interface or leaving it to the IP layer > to choose an outgoing interface (the "default" multicast interface). Exactly and this is all we should do for the basic API right now. Ergo I have not heard compelling technical or better yet implementation real world arguments to alter the behavior of the spec to something different for today. It could be down the road when scopes (or zones) are better understood and defined and in fact used in the "real world" we need an adjunct to RFC 2553. But right now we are deploying regular old interfaces and this is a regular old basic API. But after all air their views on this we can put statement for future direction and work. Just like you done with the flowlabel, anycast addresses and a few others I can't think of off the top of my head. I feel we need to do the same with this API and leave very very simple and basic for the IPv6 ISV community for the intial ports to IPv6. But on to your comments. > For IPv6, with its scoped addresses, the analogous capabilities would > be a choice among: > > - identifying a particular outgoing interface, or Yes we can do this today as the spec is written. > > - identifying only the outgoing zone (for non-global destinations), > and leaving it to the IP layer to choose an outgoing interface > within that zone, or There is not a concept of zone other than in drafts in mail discussions and some prototype implementations. This is premature for a real world API. > - leaving it to the IP layer to choose both the outgoing zone (of > the scope of the destination address) and the outgoing interface > within that zone. Its just an interface not a zone. > All this could be done with the single sin6_scope_id field in the sending > API, if the local indexes for the interfaces plus all zones (i.e., links, > sites, and any additional multicast zones configured on the node) are > given distinct values out of the same scope_id space, and if one index > value (say, 0) is reserved to mean "unspecified". Then, I think we could > probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it). I would claim all this sounds good but not real. In fact I think things will change again if we adopt global unique identifiers for site-local addresses which will be presented at some point in time to the WG. > On reception, the upper-layer should be told the arrival interface, > from which it can also determine the arrival zones of each possible > scope, since each interface can belong to only one zone of each scope. What I would suggest is let implementations evolve. For now its simply an interface in and out. If we want to deprecate it later that can be done and in a friendly manner. >At 10:20 PM +0200 6/26/00, Francis Dupont wrote: >>PS: about the (still missing) scope/zone specs,... > >The scope/zone spec is not "still missing", though it certainly still needs >work. draft-ietf-ipngwg-scoping-arch-00.txt was published before Adelaide, >and an -01 revision was posted to the ipng mailing list by Brian Haberman >on March 22. That -01 version never made it into the Internet Drafts >directories (it was posted during the time just before Adelaide while >ID submissions were being refused), but we will rectify that ASAP. Still needs work is an under statement. But its not done and we cannot base our API on work-in-progress and a very compelling argument for leaving things alone for now. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 18:48:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R1hcp13374 for ipng-dist; Mon, 26 Jun 2000 18:43:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R1hM613367 for ; Mon, 26 Jun 2000 18:43:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA27088 for ; Mon, 26 Jun 2000 18:43:22 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA21760 for ; Mon, 26 Jun 2000 18:43:21 -0700 (PDT) Received: (qmail 22645 invoked from network); 27 Jun 2000 01:45:39 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 27 Jun 2000 01:45:39 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 26 Jun 2000 18:37:21 +4100 Date: Mon, 26 Jun 2000 18:37:21 -0700 From: Ben Black To: Jim Bound Cc: Jessica Yu , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000626183721.A12295@layer8.net> References: <20000626143651.D12267@layer8.net> <200006270116.VAA0000697593@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006270116.VAA0000697593@anw.zk3.dec.com>; from bound@zk3.dec.com on Mon, Jun 26, 2000 at 09:16:09PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pending any description of how this draft provides *any* technical benefit (for example, what situations it covers which cannot be accomplished for efficiently and effectively with the RFC2260-based proposal), I am strongly against this draft moving forward. Ben On Mon, Jun 26, 2000 at 09:16:09PM -0400, Jim Bound wrote: > Chairs, > > I stongly support this draft moving forward. > > regards, > /jim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 18:50:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R1n6R13392 for ipng-dist; Mon, 26 Jun 2000 18:49:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R1ms613385 for ; Mon, 26 Jun 2000 18:48:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA15309 for ; Mon, 26 Jun 2000 18:48:39 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24078 for ; Mon, 26 Jun 2000 19:48:38 -0600 (MDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 0EB3E744; Mon, 26 Jun 2000 20:48:38 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 5FB0D6DB; Mon, 26 Jun 2000 20:48:37 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id VAA0000712015; Mon, 26 Jun 2000 21:48:36 -0400 (EDT) From: Jim Bound Message-Id: <200006270148.VAA0000712015@anw.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of "Fri, 23 Jun 2000 14:34:31 PDT." <4.3.2.7.2.20000623143215.01c42da8@mailhost.iprg.nokia.com> Date: Mon, 26 Jun 2000 21:48:36 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I think we need to also discuss the global identification of the reserved bits in the site-local address. If this can be done then IPv6 will be able to be deployed without causing alterations to Internet network server applications like DNS, DHCP, and Network Server Database Applications on customers networks. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 18:52:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R1o8E13401 for ipng-dist; Mon, 26 Jun 2000 18:50:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R1nt613394 for ; Mon, 26 Jun 2000 18:49:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA27882 for ; Mon, 26 Jun 2000 18:49:55 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24201 for ; Mon, 26 Jun 2000 18:49:55 -0700 (PDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id F21FE59D1; Mon, 26 Jun 2000 21:49:54 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BC3385B99 for ; Mon, 26 Jun 2000 21:49:54 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id VAA0000712371; Mon, 26 Jun 2000 21:49:54 -0400 (EDT) From: Jim Bound Message-Id: <200006270149.VAA0000712371@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Global Prefixes in IPv6 Date: Mon, 26 Jun 2000 21:49:53 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone support the use of Global prefixes being used on more than one link? I beleive it is not permitted by our standards. Comments? regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 18:54:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R1rBf13428 for ipng-dist; Mon, 26 Jun 2000 18:53:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R1qu613421 for ; Mon, 26 Jun 2000 18:52:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA15799 for ; Mon, 26 Jun 2000 18:52:56 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA25889 for ; Mon, 26 Jun 2000 19:52:55 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jun 2000 18:52:49 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Mon, 26 Jun 2000 18:52:50 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF010FCC@red-msg-24.redmond.corp.microsoft.com> From: Brian Zill To: "'Steve Deering'" Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments Date: Mon, 26 Jun 2000 18:52:43 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > When sending a multicast packet in IPv4, one has the > choice of either identifying a specific outgoing > interface or leaving it to the IP layer to choose an > outgoing interface (the "default" multicast interface). > > For IPv6, with its scoped addresses, the analogous > capabilities would be a choice among: > > - identifying a particular outgoing interface, or > - identifying only the outgoing zone (for non-global > destinations), and leaving it to the IP layer to > choose an outgoing interface within that zone, or > - leaving it to the IP layer to choose both the > outgoing zone (of the scope of the destination > address) and the outgoing interface within that zone. I agree completely. As I see it, having to select an interface when sending a multicast packet in IPv4 is just a hack to get around the lack of the zone concept in IPv4. This the architecturally clean and simple way to do it. We shouldn't propagate bad hacks forward from v4 into v6. > Then, I think we could probably get rid of > IPV6_MULTICAST_IF altogether (i.e., deprecate it). Yes. > The scope/zone spec is not "still missing", though it > certainly still needs work. Well, the draft itself might need a little bit of cleanup, but the concepts contained therein are well understood, exist in multiple implementations, etc. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 18:56:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R1t6b13439 for ipng-dist; Mon, 26 Jun 2000 18:55:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R1sl613430 for ; Mon, 26 Jun 2000 18:54:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA28327 for ; Mon, 26 Jun 2000 18:54:47 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA26660 for ; Mon, 26 Jun 2000 19:54:46 -0600 (MDT) Received: (qmail 22658 invoked from network); 27 Jun 2000 01:57:04 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 27 Jun 2000 01:57:04 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 26 Jun 2000 18:48:47 +4100 Date: Mon, 26 Jun 2000 18:48:47 -0700 From: Ben Black To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000626184846.A12308@layer8.net> References: <20000626173436.10459.qmail@web3004.mail.yahoo.com> <20000626173436.10459.qmail@web3004.mail.yahoo.com> <20000626103352.B12267@layer8.net> <4.3.2.7.2.20000626110919.01f19940@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <4.3.2.7.2.20000626110919.01f19940@mailhost.iprg.nokia.com>; from hinden@iprg.nokia.com on Mon, Jun 26, 2000 at 11:19:13AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The only references to this draft is the following: viewed that both could be useful, depending on ISP wishes. Asked both to flesh out and continue both. Not sure if will be stds track or BCP or what. Asked authors to use more descriptive names, e.g. "tunnels for MH site fallback", "prefix prop agreements for MH site fallback" The draft under consideration in this case is identical to that presented originally, having neither been fleshed out nor clarified in its applicability. I again request that the situations in which this draft is more appropriate than the Itojun draft be specifically described. Ben On Mon, Jun 26, 2000 at 11:19:13AM -0700, Bob Hinden wrote: > Ben, > > >At 10:33 AM 6/26/2000 -0700, Ben Black wrote: > >Where can I find these interim meeting minutes and do they > >include information on exactly what situations your draft > >covers which Itojun's does not? > > The minutes can be found at: > > http://playground.sun.com/pub/ipng/html/meetings.html > > It was the consensus of the working group to publish this document and > Itojun's draft (and possibly others) as multihoming solutions that help in > specific situations. It was clear that they are not universal > solutions. The w.g. is also moving forward with other related work such as > Rich Draves address selection procedures. > > Bob > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 19:14:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R2C2r13478 for ipng-dist; Mon, 26 Jun 2000 19:12:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R2Bp613471 for ; Mon, 26 Jun 2000 19:11:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA10175 for ; Mon, 26 Jun 2000 19:11:50 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA01827 for ; Mon, 26 Jun 2000 19:11:50 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id WAA04852; Mon, 26 Jun 2000 22:02:39 -0400 (EDT) Date: Mon, 26 Jun 2000 22:02:39 -0400 (EDT) From: Scott Bradner Message-Id: <200006270202.WAA04852@newdev.harvard.edu> To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Global Prefixes in IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does anyone support the use of Global prefixes being used on more than > one link? I beleive it is not permitted by our standards. the ability to support this is part of neighbor discovery but much other would would have to be done to make it work Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 19:18:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R2HPe13500 for ipng-dist; Mon, 26 Jun 2000 19:17:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R2HF613493 for ; Mon, 26 Jun 2000 19:17:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA10737 for ; Mon, 26 Jun 2000 19:17:14 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA03647 for ; Mon, 26 Jun 2000 19:17:14 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id TAA13990; Mon, 26 Jun 2000 19:10:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006270131.VAA0000704647@anw.zk3.dec.com> References: <200006270131.VAA0000704647@anw.zk3.dec.com> Date: Mon, 26 Jun 2000 19:10:36 -0700 To: Jim Bound From: Steve Deering Subject: Re: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:31 PM -0400 6/26/00, Jim Bound wrote: > > - identifying only the outgoing zone (for non-global destinations), > > and leaving it to the IP layer to choose an outgoing interface > > within that zone, or > >There is not a concept of zone other than in drafts in mail discussions >and some prototype implementations. This is premature for a real world >API. Fair enough. But I believe the API can be written today in a way that would allow later implementation of zones as proposed, without any change to that API. On the other hand, maybe the WG can come to agreement quickly on the scope/zone architecture, and we can make that explicit in the basic API spec. (Hope springs eternal.) > > All this could be done with the single sin6_scope_id field in the sending > > API, if the local indexes for the interfaces plus all zones (i.e., links, > > sites, and any additional multicast zones configured on the node) are > > given distinct values out of the same scope_id space, and if one index > > value (say, 0) is reserved to mean "unspecified". Then, I think we could > > probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it). > >I would claim all this sounds good but not real. In fact I think things >will change again if we adopt global unique identifiers for site-local >addresses which will be presented at some point in time to the WG. If you are going to propose a different scoping model, I strongly suggest that you document it in an ID before Pittsburgh. From what I hear, implementors would like this settled soon (actually, a long time ago). In any case, I *think* the existing sin6_scope_id field in the API makes IPv6_MULTICAST_IF redundant, so the latter could be deprecated now, even if sin6_scope_id is only ever used to identify interfaces, rather than interfaces plus zones. > >The scope/zone spec is not "still missing", though it certainly still needs > >work. draft-ietf-ipngwg-scoping-arch-00.txt was published before Adelaide, > >and an -01 revision was posted to the ipng mailing list by Brian Haberman > >on March 22. That -01 version never made it into the Internet Drafts > >directories (it was posted during the time just before Adelaide while > >ID submissions were being refused), but we will rectify that ASAP. > >Still needs work is an under statement. I don't recall receiving any comments on the draft, so apart from the work the authors' know is still needed (mostly discussion of scoping in the context of mobility), we haven't got any feedback to tell us about other perceived inadequacies of the current document. I encourage everyone to look it over (the -01 version, please) and let us know. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 19:21:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R2Jqm13518 for ipng-dist; Mon, 26 Jun 2000 19:19:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R2Jg613511 for ; Mon, 26 Jun 2000 19:19:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA25165 for ; Mon, 26 Jun 2000 19:19:42 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06984 for ; Mon, 26 Jun 2000 20:19:42 -0600 (MDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id CD73B7E3; Mon, 26 Jun 2000 22:19:41 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8E92F7A7; Mon, 26 Jun 2000 22:19:41 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id WAA0000721425; Mon, 26 Jun 2000 22:19:40 -0400 (EDT) From: Jim Bound Message-Id: <200006270219.WAA0000721425@anw.zk3.dec.com> To: Hideaki YOSHIFUJI Cc: ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 In-reply-to: Your message of "Mon, 26 Jun 2000 18:49:33 +0900." <20000626184933W.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Mon, 26 Jun 2000 22:19:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi XXXXX, >Dear authors, I have cc'd the IETF IPng Working Group with my response. All co-authors are on this list, except for Richard Stevens who has passed on. These comments are my view of the world. I sent it here to get the working group to provide comments. >>The Linux IPv6 Users JP, and I would like to comment on your ID >>entitled "Basic Socket Interface Extensions for IPv6" >>(draft-ietf-ipngwg-rfc2553bis-00). >1. Section 6.4: Protocol-Independent Nodename and Service Name Translation >* struct addrinfo{} > Type of ai_addrlen member should be delcared as socklen_t, > not size_t. > (it can be used as 3rd argument for connect() or bind() directly; > otherwise, we must do a "cast" operation. Hmmm. Works fine for me??? But I do see your point. We are following XNET lead here see code snippet below and tell me why I will not work for you? >* All paragraphs: > All constants related to ai_family should be PF_* as commented in > the definition of struct addrinfo{}; do not use AF_*. I will have to check this in the spec? I thought we had fixed this? If we missed it it was an edit error. Thanks. >* AI_V4MAPPED > This name is not suitable for getaddrinfo as a protocol-independent > function. It should be changed to more protocol-independent name; > for example, AI_MAPPED. This name has been around a long time. Also the V4 part has a specific meaning and is NOT protocol independent. So I don't agree and will not make the change. > Note: Currently, the values of AI_* of the GNU C Library are conflicted: >#define AI_V4MAPPED 1 /* IPv4-mapped addresses are acceptable. */ >#define AI_ALL 2 /* Return both IPv4 and IPv6 addresses. */ >#define AI_ADDRCONFIG 4 /* Use configuration of this host to choose > returned address type. */ Well first I have heard of it and GNU C libray does not rule but POSIX according to me view of the world and ANSI C. Change GNU library. ># define AI_PASSIVE 1 /* Socket address is intended for `bind'. */ ># define AI_CANONNAME 2 /* Request for canonical name. */ ># define AI_NUMERICHOST 4 /* Don't use name resolution. */ Same answer. >2. Section 6.5: Socket Address Structure to Nodename and Service Name >* NI_WITHSCOPEID > Please define NI_WITHSOCPE. With this flag, getnameinfo() will return > with scope-identifiers for link-local, site-local, org-local addresses if > NI_NUMERICHOST is supplied; otherwise, no scope-identifier will be > returned. Without providing this flag, applications that assumes > INET6_ADDRSTRLEN maximum length of IPv6 address may be crashed. > (Even if you re-define the value of INET6_ADDRSTRLEN, we need this > flag because binaries already compiled may be crashed.) Whats wrong with ????? - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the scope identifier is returned (for example, interface index) instead of its name. This flag is ignored if the sa argument is not an IPv6 address. >* If sin6_scope_id is filled and the name for id (interface name for > link-local addresses), what should we do? > Option: raise an error (EAI_NONAME) if called with NI_NAMEREQD; > otherwise, return numeric scope-id. > Option: always raise an error (EAI_NONAME) Sounds like a fair implementation choice. I would argue it will fail because one should not be putting link-local addresses in the DNS. >* I want to have a new value "NI_MAXSCOPE" which indicates maximum length of > scope-name including scope-delimiter / excluding terminating null-character. > It already have IF_NAMESIZE for link-local scope-names, but it is not > sufficient; we also have site-local scope identifiers. Why? It can't be larger than uint32_t ???? > char *sa2host(struct sockaddr *sa, socklen_t salen){ > int gni; > static char addrbuf[INET6_ADDRSTRLEN + NI_MAXSCOPE]; > gni = getnameinfo(sa, salen, > addrbuf, sizeof(addrbuf), NULL, 0, > NI_WITHSCOPE); > return (gni ? NULL : addrbuf); > } > > Or, we may re-define the value of INET6_ADDRSTRLEN; > it can be named "NI_MAXNUMHOST". If you define NI_MAXSCOPE to sin6_scope_id length then it will work. We were very clear on separating addresses from scopes. Two different datums. >* I want to have a new flag NI_UNMAPPED not to have "::ffff:127.0.0.1" > but "127.0.0.1" for mapped-addresses. This is "inverse-function" of > AI_MAPPED flags. I don't agree its the inverse at all? All you do is request PF_INET. > This is useful for the following situations: > - when you logs peer addresses; > some people want to see "127.0.0.1", not "::ffff:127.0.0.1" Yes we can put a health warning for this and its an implementation issue. >> - when we use peer-address for authentication. > With this, we are free from a lot of painful work to convert > ipv4-addresses to ipv4-mapped addresses. Just use PF_INET? >3. Others > >* I want to have getifaddrs(3) (first implemented by BSDi) standarized > (or documented); ths function is used to get interface addresses. I think this should be done in the advanced API. The reason is it presents a large set of new problems for scoping this spec should not be dealing with. >4. POSIX Consideration > >* Please add "POSIX Consideration" > Glibc people says declarations for some functions (like > inet_{pton,ntop}() or getnameinf()) in RFC2553 are conflicted > with ones in POSIX. This we need to check. But realize POSIX will use this spec with XNET approval. They are out of wack now but are in the process of synching up. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 19:46:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R2ipq13558 for ipng-dist; Mon, 26 Jun 2000 19:44:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R2if613551 for ; Mon, 26 Jun 2000 19:44:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA02545 for ; Mon, 26 Jun 2000 19:44:41 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12653 for ; Mon, 26 Jun 2000 19:44:41 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id B5EC5627; Mon, 26 Jun 2000 22:44:40 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6E15E7EB; Mon, 26 Jun 2000 22:44:40 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id WAA0000727646; Mon, 26 Jun 2000 22:44:39 -0400 (EDT) From: Jim Bound Message-Id: <200006270244.WAA0000727646@anw.zk3.dec.com> To: Brian Zill Cc: "'Steve Deering'" , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: rfc2553bis comments In-reply-to: Your message of "Mon, 26 Jun 2000 18:52:43 PDT." <2E3FA0558747934A8F753CC533A3F6DF010FCC@red-msg-24.redmond.corp.microsoft.com> Date: Mon, 26 Jun 2000 22:44:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I completely disagree that we understand enough about zones to recommend it to anyone. We need to find a middle ground here. The spirit of the spec at this point was not that IPv4 was a hack but correct for what it did. If we want to change that it will require much discussion and may not be appropriate for rfc2553. I would like to hear a lot of discussion on this from the working group. Before this change will be supported. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 19:54:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R2rnk13580 for ipng-dist; Mon, 26 Jun 2000 19:53:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R2re613573 for ; Mon, 26 Jun 2000 19:53:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA03054 for ; Mon, 26 Jun 2000 19:53:40 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA15264 for ; Mon, 26 Jun 2000 19:53:40 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id C82B0ABB; Mon, 26 Jun 2000 22:53:39 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9A584B14; Mon, 26 Jun 2000 22:53:39 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id WAA0000730085; Mon, 26 Jun 2000 22:53:38 -0400 (EDT) From: Jim Bound Message-Id: <200006270253.WAA0000730085@anw.zk3.dec.com> To: Scott Bradner Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Global Prefixes in IPv6 In-reply-to: Your message of "Mon, 26 Jun 2000 22:02:39 EDT." <200006270202.WAA04852@newdev.harvard.edu> Date: Mon, 26 Jun 2000 22:53:36 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, >> Does anyone support the use of Global prefixes being used on more than >> one link? I beleive it is not permitted by our standards. >the ability to support this is part of neighbor discovery but much >other would would have to be done to make it work Where in ND? I have looked at that and the Addr Arch spec. But we need to think about the ramifications here. If a global prefix can be advertrised on multiple links and as we have already stated in the IPng WG the link-local adddresses may not be globally unique? We have just said IPv6 cannot support Global Addresses. This means Ipv6 is a lie????? I suggest strongly any who believe this is possible defend it, show us in the specs where this is permitted, and I believe very important. This means we need special routing code for global addresses? I can go on and on.......... regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 20:03:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R32Fu13605 for ipng-dist; Mon, 26 Jun 2000 20:02:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R326613598 for ; Mon, 26 Jun 2000 20:02:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA28110 for ; Mon, 26 Jun 2000 20:02:06 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA18067 for ; Mon, 26 Jun 2000 20:02:06 -0700 (PDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id 93EBF18B1; Mon, 26 Jun 2000 22:02:05 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id EE60E1A2A; Mon, 26 Jun 2000 22:02:04 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000732213; Mon, 26 Jun 2000 23:02:03 -0400 (EDT) From: Jim Bound Message-Id: <200006270302.XAA0000732213@anw.zk3.dec.com> To: Hideaki YOSHIFUJI , ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 In-reply-to: Your message of "Mon, 26 Jun 2000 22:19:38 EDT." <200006270219.WAA0000721425@anw.zk3.dec.com> Date: Mon, 26 Jun 2000 23:02:02 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hideaki, (assume you can speak for JP linux group)...?? Forgot to add the code snippet in my response. Sorry about that. Here it is now for this issue from one of our mail messsages when parsing the parameters some time ago... regards, /jim >>* struct addrinfo{} >> Type of ai_addrlen member should be delcared as socklen_t, >> not size_t. >> (it can be used as 3rd argument for connect() or bind() directly; >> otherwise, we must do a "cast" operation. > >Hmmm. Works fine for me??? But I do see your point. We are following >XNET lead here see code snippet below and tell me why I will not work >for you? int myconnect(char *hostname, char *servicename) { struct addrinfo *res, *aip; struct addrinfo hints; int sock = -1; int error; /* Get host address. Any type of address will do. */ bzero(&hints, sizeof (hints)); hints.ai_flags = AI_ALL|AI_ADDRCONFIG; hints.ai_socktype = SOCK_STREAM; error = getaddrinfo(hostname, servicename, &hints, &aip); if (error != 0) { (void) fprintf(stderr, "getaddrinfo: %s for host %s service %s\n", gai_strerror(error), hostname, servicename); return (-1); } /* Open socket. */ sock = socket(aip->ai_family, aip->ai_socktype, aip->ai_protocol); if (sock == -1) { perror("socket"); freeaddrinfo(res); return (-1); } /* Connect to the host. */ if (connect(sock, aip->ai_addr, aip->ai_addrlen) == -1) { perror("connect"); (void) close(sock); return (-1); } freeaddrinfo(res); return (sock); } -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 20:20:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R3JDU13632 for ipng-dist; Mon, 26 Jun 2000 20:19:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R3J4613625 for ; Mon, 26 Jun 2000 20:19:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA05003 for ; Mon, 26 Jun 2000 20:19:04 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23754 for ; Mon, 26 Jun 2000 20:19:03 -0700 (PDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id 5DF1E1B78; Mon, 26 Jun 2000 22:19:03 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id B1A8F1975; Mon, 26 Jun 2000 22:19:02 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000735882; Mon, 26 Jun 2000 23:19:01 -0400 (EDT) From: Jim Bound Message-Id: <200006270319.XAA0000735882@anw.zk3.dec.com> To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: rfc2553bis comments In-reply-to: Your message of "Mon, 26 Jun 2000 19:10:36 PDT." Date: Mon, 26 Jun 2000 23:19:00 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >If you are going to propose a different scoping model, I strongly suggest >that you document it in an ID before Pittsburgh. From what I hear, >implementors would like this settled soon (actually, a long time ago). I know exactly what each "PRODUCT IMPLEMENTATION" offers and the idea of scoping is not even on the table for deployment. No one is even suggesting who ships real products breaking the server apps I spoke of they would be out of business right now for IPv6. Hello, Mr. Customer I am vendor X and here is my new IPv6 product, but beware it will break your network server apps but go ahead implement sitelocal addresses with overlapping servers. I am speaking of an Open Systems enviornment where all IETF standards are adhered too and proprietary extensions are frowned upon by the customer, that would break multi-vendor total interoperability. But we need to work on it quickly I agree. This API is for now not tomorrow. It could be we need adjuncts to the API, and new specs like we may have new Addressing specs. As far as my idea. No way will I have a draft before Pittsburgh. That ain't happening. I am willing to present the idea on the agenda depending on what times/days IPng is happening at Pittsburgh. Thats ujp to you and Bob. I did not suggest it as I could not get a full draft written up by the deadline or the IETF meeting. But I also have one hell of an argument prepared for the IESG if we don't fix the overlapping app problem in our deliberations for scoping. I think I will at least raise some questions. >In any case, I *think* the existing sin6_scope_id field in the API makes >IPv6_MULTICAST_IF redundant, so the latter could be deprecated now, >even if sin6_scope_id is only ever used to identify interfaces, rather >than interfaces plus zones. This is possible if we qualify for now that it is just an interface. This is the first time it came up really we have been living with do what IPv4 did. We can do different but I don't want to open up a six month debate on the API update and we are now faced with backwards compatibility so we will need to support both. We can't break ISV apps each time we update this API spec and after this update we move to API part II or put it in the Advanced API. So we will need both if we go this route. Again folks have already ported applications we cannot break those apps. So for this spec deprecation is not a good idea. >> >The scope/zone spec is not "still missing", though it certainly still needs >> >work. draft-ietf-ipngwg-scoping-arch-00.txt was published before Adelaide, >> >and an -01 revision was posted to the ipng mailing list by Brian Haberman >> >on March 22. That -01 version never made it into the Internet Drafts >> >directories (it was posted during the time just before Adelaide while >> >ID submissions were being refused), but we will rectify that ASAP. >> >>Still needs work is an under statement. > >I don't recall receiving any comments on the draft, so apart from the work >the authors' know is still needed (mostly discussion of scoping in the >context of mobility), we haven't got any feedback to tell us about other >perceived inadequacies of the current document. I encourage everyone to >look it over (the -01 version, please) and let us know. Hmmm for some reason I can't find the -01 version. I will check that. But I thought the draft was fine except I want another draft that makes all addresses except link-local unique within a site. This prevents breaking Internet Server Apps that cross site boundaries. I sent input to that affect. I do need now to check you did nothing to prohibit what I want to suggest but I don't think you did? regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 20:28:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R3RBe13659 for ipng-dist; Mon, 26 Jun 2000 20:27:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R3R0613652 for ; Mon, 26 Jun 2000 20:27:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA15816 for ; Mon, 26 Jun 2000 20:26:59 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA01786 for ; Mon, 26 Jun 2000 21:26:59 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA03793; Mon, 26 Jun 2000 20:26:35 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA00499; Mon, 26 Jun 2000 20:26:35 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id UAA08422; Mon, 26 Jun 2000 20:30:24 -0700 (PDT) Date: Mon, 26 Jun 2000 20:30:24 -0700 (PDT) From: Tim Hartrick Message-Id: <200006270330.UAA08422@feller.mentat.com> To: deering@cisco.com, bzill@microsoft.com Subject: RE: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Steve, > > I agree completely. As I see it, having to select an interface when sending > a multicast packet in IPv4 is just a hack to get around the lack of the zone > concept in IPv4. This the architecturally clean and simple way to do it. > We shouldn't propagate bad hacks forward from v4 into v6. > > > Then, I think we could probably get rid of > > IPV6_MULTICAST_IF altogether (i.e., deprecate it). > > Yes. > > > The scope/zone spec is not "still missing", though it > > certainly still needs work. > > Well, the draft itself might need a little bit of cleanup, but the concepts > contained therein are well understood, exist in multiple implementations, > etc. > I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_- scope_id for what it was originally intended, to identify the zone from which a datagram was received and to identify the zone to which a datagram should be sent. To the extent that that overlaps with what IPV6_MULTICAST_IF does that is unfortunate but it certainly isn't the only or even the worst example of duplicated functionality in the API specifications. Application writers are familiar and confortable with the notion of specifying the outgoing interface to be used for multicast and I just don't see the upside to obsoleting IPV6_MULTICAST_IF in an effort to make application writers' lives easier. Gratuitous changes to APIs piss people off even if they are improvements. I have been as guilty as anyone of beating the snot out of the dead horse that is rfc2553 but I don't see any upside to making this change at this late date. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 21:11:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R49dH13716 for ipng-dist; Mon, 26 Jun 2000 21:09:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R49U613709 for ; Mon, 26 Jun 2000 21:09:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA18669 for ; Mon, 26 Jun 2000 21:09:29 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA16138 for ; Mon, 26 Jun 2000 22:09:29 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id VAA17018; Mon, 26 Jun 2000 21:02:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006270149.VAA0000712371@anw.zk3.dec.com> References: <200006270149.VAA0000712371@anw.zk3.dec.com> Date: Mon, 26 Jun 2000 21:03:23 -0700 To: Jim Bound From: Steve Deering Subject: Re: Global Prefixes in IPv6 Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:49 PM -0400 6/26/00, Jim Bound wrote: >Does anyone support the use of Global prefixes being used on more than >one link? I beleive it is not permitted by our standards. Jim, I don't understand the question. Are you talking about using the same globally-unique subnet prefix on more than one link (which is apparently what Scott thought you meant)? Or different globally- unique subnet prefixes for different links? Or are you perhaps talking about prefixes shorter than subnet prefixes? Need more input. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 21:51:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R4nqD13756 for ipng-dist; Mon, 26 Jun 2000 21:49:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R4nh613749 for ; Mon, 26 Jun 2000 21:49:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA21864 for ; Mon, 26 Jun 2000 21:49:41 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA29734 for ; Mon, 26 Jun 2000 22:49:42 -0600 (MDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id E61245B75; Tue, 27 Jun 2000 00:49:41 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9BF1D5A48; Tue, 27 Jun 2000 00:49:41 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id AAA0000742563; Tue, 27 Jun 2000 00:49:40 -0400 (EDT) From: Jim Bound Message-Id: <200006270449.AAA0000742563@anw.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: Global Prefixes in IPv6 In-reply-to: Your message of "Mon, 26 Jun 2000 21:03:23 PDT." Date: Tue, 27 Jun 2000 00:49:39 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk steve, the same globally unique prefix on multiple links. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 23:06:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R64m713838 for ipng-dist; Mon, 26 Jun 2000 23:04:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R64b613831 for ; Mon, 26 Jun 2000 23:04:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA03205 for ; Mon, 26 Jun 2000 23:04:38 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA28171 for ; Tue, 27 Jun 2000 00:04:37 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id WAA19783; Mon, 26 Jun 2000 22:57:25 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006270253.WAA0000730085@anw.zk3.dec.com> References: <200006270253.WAA0000730085@anw.zk3.dec.com> Date: Mon, 26 Jun 2000 22:58:35 -0700 To: Jim Bound From: Steve Deering Subject: Re: Global Prefixes in IPv6 Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:53 PM -0400 6/26/00, Jim Bound wrote: >Where in ND? I have looked at that and the Addr Arch spec. ND provides a way to tell the hosts not to assume that all nodes within the same subnet prefix are on the same link, and therefore to initially use the router to reach another host with the same subnet prefix rather than doing a neighbor solicitation. The purpose of that capability is to support subnets than span more than one link (both for globally-unique and site-local subnets). >If a global prefix can be advertrised on multiple links and as we have >already stated in the IPng WG the link-local adddresses may not be >globally unique? We have just said IPv6 cannot support Global >Addresses. What the heck are you talking about? Of course IPv6 can support Global Addresses -- that's what all of deployed IPv6 today is using, and they do seem to work. If you are concerned about routing advertisement messages carrying information about subnets that span multiple links, they still go hop-by-hop, one link at a time, so non-globally-unique link-local addresses can be used to carry them from router to router. The trick to making multi-link subnets work is not to advertise the subnet prefix among the routers within the subnet, but rather to advertise individual node addresses (i.e., "host routes") for all nodes within the subnet. Those then get aggregated into a subnet route for advertisement across links that are *not* part of the multi-link subnet. > This means Ipv6 is a lie????? That's quite a leap. We've never claimed that multi-link subnet are a feature of IPv6, so where is the lie? Perhaps if anyone ever gets around to designing the rest of the necessary pieces and implements them, we'll discover some unexpected, fatal flaw. Until then, we won't know absolutely for sure. But no one's lying about any of this. >I suggest strongly any who believe this is possible defend it, show us >in the specs where this is permitted, and I believe very important. Why do you believe it is "very important"? If it's very important to support multi-link subnets, why have you not brought this up years ago, and why has no one else complained about their absence? (By the way, you'll see that multi-link subnets is one of the topics in the draft new ipngwg charter that Bob posted on Friday, in the category of stuff that we would welcome contributions on.) >This means we need special routing code for global addresses? No. Regular old routing code works fine for global addresses. >I can go on and on.......... I know. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 23:18:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R6G4Z13857 for ipng-dist; Mon, 26 Jun 2000 23:16:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R6Fr613850 for ; Mon, 26 Jun 2000 23:15:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA15726 for ; Mon, 26 Jun 2000 23:15:44 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA02175 for ; Tue, 27 Jun 2000 00:15:28 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id XAA20341; Mon, 26 Jun 2000 23:14:46 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006270330.UAA08422@feller.mentat.com> References: <200006270330.UAA08422@feller.mentat.com> Date: Mon, 26 Jun 2000 23:15:56 -0700 To: Tim Hartrick From: Steve Deering Subject: RE: rfc2553bis comments Cc: bzill@microsoft.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:30 PM -0700 6/26/00, Tim Hartrick wrote: >I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_- >scope_id for what it was originally intended, to identify the zone from >which a datagram was received and to identify the zone to which a datagram >should be sent. To the extent that that overlaps with what IPV6_MULTICAST_IF >does that is unfortunate but it certainly isn't the only or even the worst >example of duplicated functionality in the API specifications. Sure, there's a good backwards compatibility argument for keeping IPV6_MULTICAST_IF, and I don't pretend to be able to judge how much hassle it would be for anyone if it were to disappear, so it's not something I want to argue strongly for. But if it is indeed duplicated functionality, we should perhaps at least point that out in one of the API specs, so users don't have to scratch their heads wondering if it is or it isn't. >Application writers are familiar and confortable with the notion of >specifying the outgoing interface to be used for multicast and I just don't >see the upside to obsoleting IPV6_MULTICAST_IF in an effort to make >application writers' lives easier. Gratuitous changes to APIs piss >people off even if they are improvements. Point taken and conceded. >I have been as guilty as anyone of beating the snot out of the dead horse >that is rfc2553 but I don't see any upside to making this change at this >late date. Probably right. I'm more interested in us all understanding and agreeing on the architecture, so we can actually agree whether a particular API function is redundant or not, than to produce a pristine API. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 26 23:27:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R6QLa13892 for ipng-dist; Mon, 26 Jun 2000 23:26:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R6QC613885 for ; Mon, 26 Jun 2000 23:26:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA04466 for ; Mon, 26 Jun 2000 23:26:13 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA06042 for ; Tue, 27 Jun 2000 00:26:12 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id XAA20487; Mon, 26 Jun 2000 23:19:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: <200006270253.WAA0000730085@anw.zk3.dec.com> Date: Mon, 26 Jun 2000 23:20:10 -0700 To: Jim Bound From: Steve Deering Subject: Re: Global Prefixes in IPv6 Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Correcting a possibly-confusing typo in my message: >The purpose of that capability [in ND] is to support subnets >than span more than one link ^^^^ 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 Tue Jun 27 00:00:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R6waf13942 for ipng-dist; Mon, 26 Jun 2000 23:58:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R6wR613935 for ; Mon, 26 Jun 2000 23:58:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA17878 for ; Mon, 26 Jun 2000 23:58:28 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06341 for ; Mon, 26 Jun 2000 23:58:28 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id XAA21172; Mon, 26 Jun 2000 23:51:12 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006270319.XAA0000735882@anw.zk3.dec.com> References: <200006270319.XAA0000735882@anw.zk3.dec.com> Date: Mon, 26 Jun 2000 23:52:22 -0700 To: Jim Bound From: Steve Deering Subject: Re: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:19 PM -0400 6/26/00, Jim Bound wrote: >Hello, Mr. Customer I am vendor X and here is my new IPv6 product, but >beware it will break your network server apps but go ahead implement >sitelocal addresses with overlapping servers. By "overlapping server", do you mean a server directly connected to more than one site? If so, sensible vendors Y and Z would say: Hello, Mr. Customer I am vendor Y and here is my new IPv6 product [ported in two hours from my old IPv4 product]. If you are using site-local addressing, be aware that each site will need its own copy of the server. We have a special deal for you if you buy more than one. :-) Hello, Mr. Customer I am vendor Z and here is my new IPv6 product which has been enhanced to support multiple sites from the same server. >As far as my idea. No way will I have a draft before Pittsburgh. That >ain't happening. I am willing to present the idea on the agenda >depending on what times/days IPng is happening at Pittsburgh. >Thats ujp to you and Bob. Let's see how the discussion here plays out before deciding about that. > >In any case, I *think* the existing sin6_scope_id field in the API makes > >IPv6_MULTICAST_IF redundant, so the latter could be deprecated now, > >even if sin6_scope_id is only ever used to identify interfaces, rather > >than interfaces plus zones. > >...So for this spec deprecation is not a good idea. OK, you and and Tim have convinced me of that. >Hmmm for some reason I can't find the -01 version. It should appear in the ID directories in a day or two. It was posted to the ipng list on March 22, so if you archive past ipng mail, you might find it sooner there. (Or send me mail and I will send you a personal copy.) 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 Tue Jun 27 00:07:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R769g13968 for ipng-dist; Tue, 27 Jun 2000 00:06:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R75w613961 for ; Tue, 27 Jun 2000 00:05:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA00147 for ; Tue, 27 Jun 2000 00:05:58 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA19335 for ; Tue, 27 Jun 2000 01:05:57 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id QAA10314; Tue, 27 Jun 2000 16:05:51 +0900 (JST) To: crawdad@fnal.gov cc: ipng@sunroof.eng.sun.com Subject: icmp-name-lookups-05 X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Tue, 27 Jun 2000 16:05:51 +0900 Message-ID: <10312.962089551@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, I really need your input on this. Note that we really are implementing code based on the document, and in a serious need for clarification. itojun ------- Forwarded Messages Return-Path: Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id AAA17608 for ; Wed, 10 May 2000 00:57:51 +0900 (JST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24425; Tue, 9 May 2000 09:57:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29117; Tue, 9 May 2000 08:53:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e49FVIp27307 for ipng-dist; Tue, 9 May 2000 08:31:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e49FV4727300 for ; Tue, 9 May 2000 08:31:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12781 for ; Tue, 9 May 2000 08:31:00 -0700 (PDT) Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04072 for ; Tue, 9 May 2000 09:30:49 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e49FUQE05019; Wed, 10 May 2000 00:30:26 +0900 (JST) To: crawdad@fnal.gov cc: ipng@sunroof.eng.sun.com Subject: icmp-name-lookups-05.txt>: NOOP 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: Wed, 10 May 2000 00:30:26 +0900 Message-ID: <5017.957886226@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org icmp-name-lookups-05 says the following. >5.1. NOOP > > This NI type has no defined flags and never has a Data field. A > Reply to a NI NOOP Query tells the Querier that a node with the > Queried Address is up and reachable, implements the Node Information > protocol, and incidentally happens to reveal whether the Queried > Address was an anycast address. However, since these seem to be no Code defined for empty Data field, it is not possible for a Querier to transmit NOOP packet with empty Data field. Definition of NOOP and Code seems, at least, contradictory. Or is the evaluation of Code field dependent to Qtype field? (i.e. we should ignore Code field if Qtype equals to NOOP or Qtype equals to Supported Qtypes) 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 - -------------------------------------------------------------------- ------- Message 2 Return-Path: Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA06859 for ; Thu, 18 May 2000 01:36:13 +0900 (JST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28739; Wed, 17 May 2000 10:34:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA03043; Wed, 17 May 2000 07:30:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HE2aH03546 for ipng-dist; Wed, 17 May 2000 07:02:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HE2L703539 for ; Wed, 17 May 2000 07:02:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA02818 for ; Wed, 17 May 2000 07:02:20 -0700 (PDT) Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12895 for ; Wed, 17 May 2000 08:02:18 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e4HDX8f04271; Wed, 17 May 2000 22:33:08 +0900 (JST) cc: ipng@sunroof.eng.sun.com to: crawdad@fnal.gov 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: ipngwg-icmp-name-lookups-05: dns compression From: Jun-ichiro itojun Hagino Date: Wed, 17 May 2000 22:33:08 +0900 Message-ID: <4269.958570388@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org Hello, again I have couple of questions about name-lookups-05. if we (as ipngwg) are more likely to go to multicast DNS than icmp name lookup, please tell us so - we at KAME are very interested in zeroconf-oriented configurations and love to provide/test common local name lookup mechanisms without config twists. itojun 1. DNS compression the draft uses DNS wire format (as defined in RFC1035) in two places; subject DNS name in queries (very last paragraph in section 3), and DNS names in replies (5.3). My question is: if we are to use DNS message compression (RFC1035 4.1.4), where should we count offset from? Will it be the beginning of ICMPv6 message, or beginning of the part formatted by DNS wire format? or is DNS message compression is not permitted at all? 2. restriction on IPv6 destination address for validation on receiving side, section 4 says like the folloing: > Upon receiving a NI Query, the Responder must check the Query's IPv6 > destination address and discard the Query without further processing > unless it is one of the Responder's unicast or anycast addresses, a > NI Group Address for a name belonging to the Responder, or a NI > Group Address for a name for which the Responder is providing proxy > service. considering that ICMPv6 specification recommends a node to reply to ICMPv6 echo request toward multicast destination, I'm not sure if the above restriction buys us much protection. I can query hostnames for all nodes in the site, by the following steps: - ping6 ff05::1 - for all nodes answered, send node information query, with subject address (equal to IPv6 destination) I agree that icmp6 to wide-area multicast would be insecure, however, at least name-lookup draft is not very consistent with ICMPv6 RFC. Also, we find name lookup queries to ff02::1 very useful as debugging tool. How about permitting these? - unicast address - anycast address - link-local multicast addresses the node joins the last item is less strict than 05 draft. sender rule needs to be changed too if we take this route. 4. Subject address validation for validation on receiving side, section 4 says like the folloing: > A Responder must also silently discard a Query whose > Subject Address or Name (in the Data field) does not belong to that > node, unless it is providing proxy service for that Subject. A > single-component Subject Name matches any fully-qualified name whose > first label matches the Subject. All name matching is done in a > case-independent manner. What defines "address belongs to node"? for example, is "::1" valid as subject address? all IPv6 nodes supposed to have ::1 on loopback interface, so ::1 is valid for all nodes. Is a query packet with empty Subject valid? what should the code field be? also, we may have scope issue here. What should happen in the following cases: - if you got node information query from/to global IPv6 address, with link-local subject address for your node - if we got query from/to link-local address on interface A, with link-local subject address for interface B - if your (receiving) node node offers proxy service, and you've got scoped subject address in a query packet, how should we interpret the subject address? what is the suggested behavior? 5. code field on queries again, I don't understand how should a responding node must validate code field and subject field in the query message. (this is a recap) I'm not sure about the following: - what should be put into code field when subject part needs to be empty (NOOP, supported qtypes) - if it is legal to leave Subject portion of query empty, what should be put into code field? Basically, I think we'd need a table of valid combinations. the text leaves many cases unanswered. - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Messages -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 00:33:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R7RFU14002 for ipng-dist; Tue, 27 Jun 2000 00:27:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R7R7613995 for ; Tue, 27 Jun 2000 00:27:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA01663 for ; Tue, 27 Jun 2000 00:27:06 -0700 (PDT) Received: from thomson.uni2.net (thomson.uni2.net [195.82.195.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA17420 for ; Tue, 27 Jun 2000 00:27:06 -0700 (PDT) Received: from arhexch01.martin.dk (arhexch01.martin.dk [129.142.130.8]) by thomson.uni2.net (8.10.0/8.9.1) with ESMTP id e5R7R3D11914; Tue, 27 Jun 2000 09:27:03 +0200 Received: by NTAARHUS1 with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Jun 2000 09:27:02 +0200 Message-ID: <7051F68CB706D211A8F200002440F723E7C2B1@NTAARHUS1> From: Ole Pedersen To: "'Morten Heiberg Rasmussen'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Stateless autoconf and dial-on-demand Date: Tue, 27 Jun 2000 09:27:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Wouldn't it be possible to send out Router Solicitations on the dial-up interface on initialization and with (long) interval? By doing this, the connection is open, so the ISP is able to return a Router Advertisement packet... Best regards, Ole Pedersen Martin Professional A/S Email: ole.pedersen@martin.dk -----Original Message----- From: Morten Heiberg Rasmussen [mailto:mhr@tbit.dk] Sent: 26. juni 2000 11:20 To: ipng@sunroof.eng.sun.com Subject: Stateless autoconf and dial-on-demand Hi I have a question regarding IPv6 stateless address autoconfiguration in combination with dial-on-demand network access. Suppose I have a network configured using only stateless address autoconfiguration. At this point all hosts have a link local address but nothing with wider scope. When a connection to the outside world is opened the gateway node starts to receive router advertisements from our ISP with a globally routable prefix. This prefix is distributed to the hosts on the local network so that they can form complete, global IP addresses. How does one implement dial-on-demand in such a setting? The gateway for the network needs an outbound packet to trigger the dialing process, but at that time the emitting host does not have a global address to select as the packet source address. Hence the packet cannot be sent. Is there any way to avoid having to rewrite the first outbound packets in the gateway? If it is not acceptable to open the connection when no traffic is being sent and if we cannot assume that everybody uses DNS I don't really see how it could be done. Best regards Morten Heiberg -- Morten Heiberg Rasmussen System Developer, M. Sc. Ericsson Telebit A/S Tel: +45 86 28 81 76 Fabrikvej 11 Fax: +45 86 28 81 86 DK-8260 Viby J, Denmark E-mail: mhr@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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 01:07:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5R84vh14064 for ipng-dist; Tue, 27 Jun 2000 01:04:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5R84l614057 for ; Tue, 27 Jun 2000 01:04:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA10905 for ; Tue, 27 Jun 2000 01:04:47 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01885 for ; Tue, 27 Jun 2000 01:04:45 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5R84DK32663; Tue, 27 Jun 2000 10:04:13 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12422; Tue, 27 Jun 2000 10:04:13 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA05747; Tue, 27 Jun 2000 10:05:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006270805.KAA05747@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Mon, 26 Jun 2000 16:45:17 PDT. Date: Tue, 27 Jun 2000 10:05:01 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => I apologize because I've forgotten the draft-ietf-ipngwg-scoping-arch-00.txt document (I was disturbed by the fact that the -01 was never/not yet available in the I-D directories). The zone inclusion property is in the I-D and there are some rules about emission using it as: For this reason (selection of a sub-zone), an implementation might find it useful to assign a distinct value for each zone index, so that they are unique across all zones, regardless of scope. If we have distinct values then we can implement any kind of outgoing zone selection, ie. we can specify in the sin6_scope_id field the zone of the outgoing interface, the only restriction is its scope must be smaller or equal to the address scope. Then I have three questions about this: - a link zone can have more than one interface, is there practical example where this can be a problem? - should we extend this model to global addresses (this is a proposal for the sin6_scope_id meaning)? - should we extend this model to the reception side, ie. one matches only when the incoming interface belongs to the right zone? This seems not hard to implement (other opinions?), we just need a scoped routing table (already needed today) and a good zone naming scheme (users should understand it :-). Last point, where to put this? In the rfc2553bis or the scoping arch? (we can introduce a hard dependence between the two I-Ds) I'm sure I'm not following all the intricacies of the arguments, but maybe this is helpful (or maybe not, or maybe not even relevant): => this is relevant! When sending a multicast packet in IPv4, one has the choice of either identifying a specific outgoing interface or leaving it to the IP layer to choose an outgoing interface (the "default" multicast interface). For IPv6, with its scoped addresses, the analogous capabilities would be a choice among: - identifying a particular outgoing interface, or => do you mean a particular outgoing link (someone has already corrected me about the difference :-) or do you rely on IPV6_MULTICAST_IF? - identifying only the outgoing zone (for non-global destinations), and leaving it to the IP layer to choose an outgoing interface within that zone, or => I don't know if the non-global restriction is really needed. There are some situations where it is very nice to have a per-interface (sorry, a per-link) default route(r). - leaving it to the IP layer to choose both the outgoing zone (of the scope of the destination address) and the outgoing interface within that zone. All this could be done with the single sin6_scope_id field in the sending API, => we can do a similar thing in the receiving API. I'd like to have the same kind of usage between the sending and the receiving sides (in fact, this point is the reason I've jumped into this discussion :-). if the local indexes for the interfaces plus all zones (i.e., links, sites, and any additional multicast zones configured on the node) are given distinct values out of the same scope_id space, and if one index value (say, 0) is reserved to mean "unspecified". Then, I think we could probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it). => the only reason we should have to keep IPV6_MULTICAST_IF is an interface specification can be finer than a link one... On reception, the upper-layer should be told the arrival interface, => how? The sin6_scope_id should contains the index of the zone of the address scope (this rule implies global addresses in any cases will get the zero sin6_scope_id in recvfrom() because there is only one global zone). from which it can also determine the arrival zones of each possible scope, since each interface can belong to only one zone of each scope. => there are two points: API (what the user will get) and PCB matching then I don't fully understand you... That -01 version never made it into the Internet Drafts directories (it was posted during the time just before Adelaide while ID submissions were being refused), but we will rectify that ASAP. => thanks! Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 03:29:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RAR9X14180 for ipng-dist; Tue, 27 Jun 2000 03:27:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RAQx614173 for ; Tue, 27 Jun 2000 03:27:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA12434 for ; Tue, 27 Jun 2000 03:26:58 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA25681 for ; Tue, 27 Jun 2000 03:26:57 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5RAOJK03203; Tue, 27 Jun 2000 12:24:20 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA13834; Tue, 27 Jun 2000 12:24:18 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA06440; Tue, 27 Jun 2000 12:25:07 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006271025.MAA06440@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Mon, 26 Jun 2000 21:31:07 EDT. <200006270131.VAA0000704647@anw.zk3.dec.com> Date: Tue, 27 Jun 2000 12:25:07 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > When sending a multicast packet in IPv4, one has the choice of either > identifying a specific outgoing interface or leaving it to the IP layer > to choose an outgoing interface (the "default" multicast interface). Exactly and this is all we should do for the basic API right now. => we'd like to keep this when the sin6_scope_id is zero. In fact I believe the current idea is to extend the (non-zero) sin6_scope_id semantics and to specify what happens with multicast (where different incompatible proposals are already implemented). If someone uses the old style (mainly interface indexes for link-local and zero sin6_scope_id for others) then one should get *exactly* the same behaviour. > ... Then, I think we could > probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it). I would claim all this sounds good but not real. => I believe that Steve has launched the idea of a nice extension of the current API. If it is a sound extension (ie. the old part remains as it is) this will satify both your concern (not yet a new API!) and our (do the best possible usage of sin6_scope_id). In fact I think things will change again if we adopt global unique identifiers for site-local addresses which will be presented at some point in time to the WG. => I believe this point is about multi-sited nodes where the old API can't help (just because we didn't understand the issue) then the new extension can only be an improvement. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 03:32:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RAUrH14205 for ipng-dist; Tue, 27 Jun 2000 03:30:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RAUi614198 for ; Tue, 27 Jun 2000 03:30:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA12733 for ; Tue, 27 Jun 2000 03:30:43 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04925 for ; Tue, 27 Jun 2000 04:30:42 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5RAUWK27384; Tue, 27 Jun 2000 12:30:32 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA13914; Tue, 27 Jun 2000 12:30:31 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA06479; Tue, 27 Jun 2000 12:31:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006271031.MAA06479@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Zill cc: "'Steve Deering'" , ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Mon, 26 Jun 2000 18:52:43 PDT. <2E3FA0558747934A8F753CC533A3F6DF010FCC@red-msg-24.redmond.corp.microsoft.com> Date: Tue, 27 Jun 2000 12:31:20 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As I see it, having to select an interface when sending a multicast packet in IPv4 is just a hack to get around the lack of the zone concept in IPv4. This the architecturally clean and simple way to do it. We shouldn't propagate bad hacks forward from v4 into v6. => we agree but Jim's concern is still valid, ie. we should keep the old way for old applications. The zero sin6_scope_id seems to be able to do that. > The scope/zone spec is not "still missing", though it > certainly still needs work. Well, the draft itself might need a little bit of cleanup, but the concepts contained therein are well understood, exist in multiple implementations, etc. => can you add more details about "exist in multiple implementations"? Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 03:35:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RAXoR14235 for ipng-dist; Tue, 27 Jun 2000 03:33:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RAXf614228 for ; Tue, 27 Jun 2000 03:33:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA00769 for ; Tue, 27 Jun 2000 03:33:40 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA28017 for ; Tue, 27 Jun 2000 03:33:39 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5RAXRK03115; Tue, 27 Jun 2000 12:33:27 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA13949; Tue, 27 Jun 2000 12:33:27 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA06498; Tue, 27 Jun 2000 12:34:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006271034.MAA06498@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: deering@cisco.com, bzill@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Mon, 26 Jun 2000 20:30:24 PDT. <200006270330.UAA08422@feller.mentat.com> Date: Tue, 27 Jun 2000 12:34:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_- scope_id for what it was originally intended, to identify the zone from which a datagram was received and to identify the zone to which a datagram should be sent. To the extent that that overlaps with what IPV6_MULTICAST_IF does that is unfortunate but it certainly isn't the only or even the worst example of duplicated functionality in the API specifications. => if the functionality is duplicated (and it is in this case) we have to specify who has the precedence, ie. what happens when both are used. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 03:46:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RAid014270 for ipng-dist; Tue, 27 Jun 2000 03:44:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RAiT614263 for ; Tue, 27 Jun 2000 03:44:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA20664 for ; Tue, 27 Jun 2000 03:44:28 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA09750 for ; Tue, 27 Jun 2000 04:44:27 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06357; Tue, 27 Jun 2000 06:44:26 -0400 (EDT) Message-Id: <200006271044.GAA06357@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-2260-00.txt Date: Tue, 27 Jun 2000 06:44:26 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 multihoming support at site exit routers Author(s) : J. Hagino Filename : draft-ietf-ipngwg-ipv6-2260-00.txt Pages : 9 Date : 26-Jun-00 The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-2260-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-ipv6-2260-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-ipv6-2260-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: <20000626133610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-2260-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-2260-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000626133610.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 06:22:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RDKN914353 for ipng-dist; Tue, 27 Jun 2000 06:20:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RDKE614346 for ; Tue, 27 Jun 2000 06:20:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA06249 for ; Tue, 27 Jun 2000 06:20:14 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA04025 for ; Tue, 27 Jun 2000 06:20:13 -0700 (PDT) Received: from classic.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.net [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.9.3) with ESMTP id JAA17237; Tue, 27 Jun 2000 09:21:07 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <4.3.2.7.2.20000627085001.02b94008@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Jun 2000 08:54:38 -0400 To: Bob Hinden , ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: Re: Revised IPng Working Group Charter Cc: hinden@iprg.nokia.com, deering@cisco.com In-Reply-To: <4.3.2.7.2.20000623143215.01c42da8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At/À 14:34 2000-06-23 -0700, Bob Hinden you wrote/vous écriviez: >Folks, > >Attached is a draft of a revised charter for the working group. Updating >the charter was agreed to at the Grenoble and Minneapolis working group >meetings, but it took the chairs and AD's a while to draft a new one. > >The charter includes changing the name of the working group to the "IP >Version 6 Working Group", but will keep the acronym of "ipngwg". This >will avoid having to rename all current internet drafts. The chairs have probably talked about it, but I would suggest to change the acronym, since: - we want to "get rid" of ng - ipngwg is the one of the few wg that have "wg" in their acronym - acronym is used often in presentations, media, etc..., so it has importance too. Would suggest "ipv6" as acronym. > The list of the working group's current work items is as follows: host and router requirements doc ? >Goals and Milestones: Given the work items, it seems to me that the milestones are pretty aggressive. Marc. Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 06:26:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RDOt214371 for ipng-dist; Tue, 27 Jun 2000 06:24:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RDOk614364 for ; Tue, 27 Jun 2000 06:24:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA10609 for ; Tue, 27 Jun 2000 06:24:46 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27077 for ; Tue, 27 Jun 2000 07:24:45 -0600 (MDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 552F1504; Tue, 27 Jun 2000 08:24:45 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id F3F774B0; Tue, 27 Jun 2000 08:24:44 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000819031; Tue, 27 Jun 2000 09:24:21 -0400 (EDT) From: Jim Bound Message-Id: <200006271324.JAA0000819031@anw.zk3.dec.com> To: Morten Heiberg Rasmussen Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Stateless autoconf and dial-on-demand In-reply-to: Your message of "26 Jun 2000 11:19:54 +0200." Date: Tue, 27 Jun 2000 09:24:21 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Morten, We have not developed specs for this operation. Whether we will is TBD. I do believe we should be able to do router renumbering from the ISP though. But initially I would imagine that there is some SLA with ones ISP to develop the entire relationship and with that customer. At that time an IPv6 Prefix would be part of that SLA. Once you have that prefix the connection between the ISP and the customer can be set up over the medium to the ISP site and customer site. I believe you will see products on the market for IPv6 to do this very soon. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 07:02:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RDxxQ14411 for ipng-dist; Tue, 27 Jun 2000 06:59:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RDxo614404 for ; Tue, 27 Jun 2000 06:59:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA26227 for ; Tue, 27 Jun 2000 06:59:50 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18564 for ; Tue, 27 Jun 2000 07:59:48 -0600 (MDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id 9187013D1; Tue, 27 Jun 2000 08:59:46 -0500 (CDT) Received: from yquarry.zk3.dec.com (byquarry.zk3.dec.com [16.140.96.30]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 2B9E5118A; Tue, 27 Jun 2000 08:59:46 -0500 (CDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id JAA0000010635; Tue, 27 Jun 2000 09:59:45 -0400 (EDT) From: Jim Bound Message-Id: <200006271359.JAA0000010635@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Global Prefixes in IPv6 In-reply-to: Your message of "Mon, 26 Jun 2000 22:58:35 PDT." Date: Tue, 27 Jun 2000 09:59:45 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk steve, I know all that about ND. For some reason we are passing each other in this conversation. Also I have no issue of prefixes spanning multiple links unless the following happens. Node A on link1 has fe35::1 as global address. AND Node B on link2 has fe35::1 as global address. Because when the prefix spanned multiple links (link1 and link2) Node A and B have the same link-local address 64bit ID in this case Unicast Aggregate Format for this discussion. They end up with the same global address meaning they are not global by my definition. Oh yeah. My assumption of a global address may be different than yours? So ND would have to make sure also that the link-local is unique across the multiple links. That could be difficult. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 07:38:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5REaHh14439 for ipng-dist; Tue, 27 Jun 2000 07:36:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5REa8614432 for ; Tue, 27 Jun 2000 07:36:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11486 for ; Tue, 27 Jun 2000 07:36:08 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11273 for ; Tue, 27 Jun 2000 08:36:07 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id HAA02692; Tue, 27 Jun 2000 07:28:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006271359.JAA0000010635@yquarry.zk3.dec.com> References: <200006271359.JAA0000010635@yquarry.zk3.dec.com> Date: Tue, 27 Jun 2000 07:30:05 -0700 To: Jim Bound From: Steve Deering Subject: Re: Global Prefixes in IPv6 Cc: Jim Bound , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:59 AM -0400 6/27/00, Jim Bound wrote: >Also I have no issue of prefixes spanning multiple >links unless the following happens. > >Node A on link1 has fe35::1 as global address. > >AND > >Node B on link2 has fe35::1 as global address. > >Because when the prefix spanned multiple links (link1 and link2) Node A >and B have the same link-local address 64bit ID in this case Unicast >Aggregate Format for this discussion. Part of the (not-yet-written-down) work of supporting multi-link subnets is making sure that the routers that connect a multi-link subnet ensure that DAD messages are relayed/proxied to all links in that subnet (or in some other way detect and prevent duplicate interface IDs being used within the subnet). In theory, it would be OK for link-local IPv6 addresses to be duplicated on different links within the subnet (because they would still be scoped to a single link); only the site-local and global addresses would have to be unique across the subnet. But the practice of doing DAD only on the link-local address and then auto-generating the larger-scope addresses from that means we'd really want to just do DAD-relaying for all address types. >They end up with the same global address meaning they are not global by >my definition. Right, that has to be prevented. >Oh yeah. My assumption of a global address may be different than yours? It sounds like it's the same. You just didn't explain your specific concern well enough for me to understand before. >So ND would have to make sure also that the link-local is unique across >the multiple links. That could be difficult. Could be, but I don't think so. One thing we could have done to make this work more cleanly (i.e., eliminate the need for special-case DAD-relay function in the routers in multi-link subnets) is to define a "subnet-local" multicast scope (greater than or equal to link-local), and then require DAD to use subnet-local multicast. But it's not worth trying to change that now, and the DAD-relay idea should suffice You still didn't explain what you think is Very Important about any of this. 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 Tue Jun 27 07:44:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5REhNk14458 for ipng-dist; Tue, 27 Jun 2000 07:43:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5REhE614451 for ; Tue, 27 Jun 2000 07:43:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA14047 for ; Tue, 27 Jun 2000 07:43:14 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15912 for ; Tue, 27 Jun 2000 08:43:13 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id HAA02943; Tue, 27 Jun 2000 07:36:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006271408.KAA0000012829@yquarry.zk3.dec.com> References: <200006271408.KAA0000012829@yquarry.zk3.dec.com> Date: Tue, 27 Jun 2000 07:37:11 -0700 To: Jim Bound From: Steve Deering Subject: Re: rfc2553bis comments Cc: Jim Bound , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:08 AM -0400 6/27/00, Jim Bound wrote: >Well 2 hours is a bit short but ISVs will not want to mess with their >architecture for applications either and thats what this is all about. >Also not all customers want two servers. How common is it for a single server to be *directly* connected to more than one customer site? Usually, sites are connected via routers, either indirectly through ISPs or directly through "back-door" private links. > Hello, Mr. Customer I am vendor Z and here is my new IPv6 product > which has been enhanced to support multiple sites from the same server. > >That would mean having to differentiate sin6_scope_id for each address >which is not well defined today for anyone. Yes, that's what we are trying to define so we can move forward. 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 Tue Jun 27 07:53:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5REphD14495 for ipng-dist; Tue, 27 Jun 2000 07:51:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5REpY614488 for ; Tue, 27 Jun 2000 07:51:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA19572 for ; Tue, 27 Jun 2000 07:51:34 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25927 for ; Tue, 27 Jun 2000 07:51:32 -0700 (PDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 42104556; Tue, 27 Jun 2000 09:51:31 -0500 (CDT) Received: from yquarry.zk3.dec.com (byquarry.zk3.dec.com [16.140.96.30]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id E5B38756; Tue, 27 Jun 2000 09:51:30 -0500 (CDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id KAA0000020601; Tue, 27 Jun 2000 10:47:44 -0400 (EDT) From: Jim Bound Message-Id: <200006271447.KAA0000020601@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Global Prefixes in IPv6 In-reply-to: Your message of "Tue, 27 Jun 2000 07:30:05 PDT." Date: Tue, 27 Jun 2000 10:47:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, OK I am on board here. I agree it would be a nice feature to support this but I also think we need to make sure its backwards compatible with all the ND code out there now ok. Thats first what is very important and I did not state this yet. But what was very important was we not have an issue where we don't have Global Addresses for IPv6. Mail on the DHCPv6 mailing list made it sound like that is what was happening. I had to make sure that was misunderstood to support this feature. IPv6 without global addresses would be a bummer. The key is that a solution will have to support what you relayed for DAD in some manner across multiple links. This new feature should be transparent to protocols assuming IPv6 does support the concept of Global Addresses even when prefixes span multiple links. Hmmm. If we make sure link-locals can be unique across multiple links that also opens new opportunities elsewhere too !!! Are there proposals on the table? I would like to look at this worrying about backwards compatibility with ND and Addrconf as they exist today too? regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 07:57:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5REuIU14514 for ipng-dist; Tue, 27 Jun 2000 07:56:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5REu8614507 for ; Tue, 27 Jun 2000 07:56:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA14263 for ; Tue, 27 Jun 2000 07:54:54 -0700 (PDT) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28331 for ; Tue, 27 Jun 2000 07:54:51 -0700 (PDT) Received: from sture.lysator.liu.se (nisse@sture.lysator.liu.se [130.236.254.21]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id QAA22802; Tue, 27 Jun 2000 16:46:36 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA06029; Tue, 27 Jun 2000 16:46:33 +0200 (MET DST) To: Ben Black Cc: Jim Bound , Jessica Yu , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" References: <20000626143651.D12267@layer8.net> <200006270116.VAA0000697593@anw.zk3.dec.com> <20000626183721.A12295@layer8.net> From: nisse@lysator.liu.se (Niels Möller) Date: 27 Jun 2000 16:46:32 +0200 In-Reply-To: Ben Black's message of "Mon, 26 Jun 2000 18:37:21 -0700" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.5 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben Black writes: > Pending any description of how this draft provides *any* > technical benefit (for example, what situations it covers > which cannot be accomplished for efficiently and effectively > with the RFC2260-based proposal), I am strongly against > this draft moving forward. I'm I bystander here, but as far as I can see, it appears that some people like the approach, and really want to try it out. Then it ought to be a good thing to have it published so that both people implementing it and people shooting it down can have a clear description to refer to. After all, we're talking about an _informational_ rfc, not standards track. Regards, /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 08:36:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RFYpu14643 for ipng-dist; Tue, 27 Jun 2000 08:34:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RFYg614636 for ; Tue, 27 Jun 2000 08:34:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22074 for ; Tue, 27 Jun 2000 08:33:27 -0700 (PDT) Received: from web3002.mail.yahoo.com (web3002.mail.yahoo.com [204.71.202.165]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA24144 for ; Tue, 27 Jun 2000 08:33:20 -0700 (PDT) Received: (qmail 2167 invoked by uid 60001); 27 Jun 2000 15:32:55 -0000 Message-ID: <20000627153255.2166.qmail@web3002.mail.yahoo.com> Received: from [63.88.104.20] by web3002.mail.yahoo.com; Tue, 27 Jun 2000 08:32:55 PDT Date: Tue, 27 Jun 2000 08:32:55 -0700 (PDT) From: Jessica Yu Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" To: Ben Black Cc: Vijay Gill , Jim Bound , hinden@iprg.nokia.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 I found it very trouble-some that you make assertions without compelling (sometimes inaccurate) technical arguments neither knowledge of current practice. This is showing in the message below (see my response inline) and the thread of discussion last year on the same topic. Also, please go back and read the thread on this topic on this list. What you pointed out about my proposal had been either dismissed and/or answered/addressed. It was based on that the WG decided to move forward. Inline comments below ... --- Ben Black wrote: > On Mon, Jun 26, 2000 at 02:19:27PM -0700, Jessica Yu > wrote: > > So now, we changed topic to multihoming to two > ISPs > > with hole-punching, right? This is what we do > today > > with two issues: > > > > a) increase the size of the global routing table > since > > it can not be aggregated, and > > > > This issue verges on irrelevant given current > hardware > (even completely ignoring improvements in hardware > over > time). Are you saying that reducing the routes in the global routing table to improve routing scalability is irrelevant? You are deadly wrong on this. Go ask the ISP community. Go read I-Ds including IAB's routing workshop report on routing scalability and stability. You may still think that memory on router is the issue but that's not the only issue, as well known in the operation community. In fact, rfc2260's main motivation is to reduce prefixes in the global routing table. > > > b) The longer prefixes (the hole) could be blocked > by > > certain providers resulting in no access to that > part > > of the Internet. > > > > No access to certain parts of the net during > failure. > This would seem to be a feature superior to your > proposal > in that you can access parts of the net beyond > simply > your direct peers. Obviously, you do not understand this. What I am talking about is that the second connection can not be a backup since the longer prefix will be filtered. Your assertion of this is better than the mechanism described in my I-D raised the question if you understand the proposal. > > > I think this mechanism works today in IPv4 and > there > > is no reason why can not be used for Ipv6. > However, it > > does not hurt to have other mechanism which allow > > better aggregation available if there are concerns > > about the scaling and routability issues listed > above. > > > > Agreed, and I would add that those mechanisms should > be > as consistent as possible with the approaches in > IPv4 unless > there is a compelling technical reason for a > previously > unused mechanism. The Itojun proposal, based on the > > existing RFC2260 approach, meets those requirements. > Your > proposal introduces a new mechanism which lacks a > compelling > technical case. It is for these reasons that I am > arguing it > not be moved further along the track. > You seem to indicate that the current v4 multihoming practice is using rfc2260. That is just simply untrue. The majority multihoming sites just simply advertise one prefix. Some of those prefix are PI and some from one of providers CIDR block with no tunnels or other involved whatsoever. By making this assertion, it really shows that either you do not understand what the current practice is; or you do not understand rfc2260 or Itojun proposal; or neither. > > Ben --jessica > > > Speaking as a person who had worked for ISPs and > dealt > > with operations for many many years, I submit > there > > are entities who would like to have the > arrangement as > > described in the ID. > > > > Thanks! > > > > --Jessica > > > > --- Vijay Gill wrote: > > > On Mon, 26 Jun 2000, Jessica Yu wrote: > > > > > > Jessica, > > > > > > > > > > The tail circuits to the customer have the > > > opportunity to go through > > > > diverse infrastructure (e.g. fiber) which > would > > > increase reliability. > > > > > > So would they if I just went to two different > ISP's > > > and got them to punch > > > a hole in their aggregate for the netblock > assigned > > > to me from the first > > > ISP. [paragragh X] > > > > > > > Instead of going to different POPs from the > same > > > ISP, > > > > the customer will be able to go to the close > POPs > > > of > > > > two ISPs. Therefore, the distance for the 2nd > tail > > > > circuit can be shorter resulting money saving. > > > > > > See Paragraph X. > > > > > > > The customer can reach part of the Internet > (at > > > least > > > > customers of ISP2) without relying on ISP1. > > > > > > See Paragraph X. > > > > > > This also buys me the additional safety of being > > > shielded from complete > > > failure of one of the upstream ISPs. With > network > > > connectivity now > > > becoming fundamental to doing business, I submit > > > that there isn't a single > > > sensible company who would rely upon this draft > > > under discussion for a > > > critical need. Instead most of them would > > > immediately try and go for > > > Paragraph X. Speaking as an operator, when > clients > > > are throwing $n > > > million contracts at you, there is a powerful > > > incentive to accomodate > > > them. > > > > > > /vijay > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Get Yahoo! Mail - Free email you can access from > anywhere! > > http://mail.yahoo.com/ > > __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 08:41:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RFdc314665 for ipng-dist; Tue, 27 Jun 2000 08:39:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RFdT614658 for ; Tue, 27 Jun 2000 08:39:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA16123 for ; Tue, 27 Jun 2000 08:39:29 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28778 for ; Tue, 27 Jun 2000 08:39:24 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 96F9B27C7; Tue, 27 Jun 2000 11:13:31 -0400 (EDT) Received: from yquarry.zk3.dec.com (byquarry.zk3.dec.com [16.140.96.30]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7FA0B740; Tue, 27 Jun 2000 11:02:43 -0400 (EDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id LAA0000024503; Tue, 27 Jun 2000 11:02:43 -0400 (EDT) From: Jim Bound Message-Id: <200006271502.LAA0000024503@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: rfc2553bis comments In-reply-to: Your message of "Tue, 27 Jun 2000 07:37:11 PDT." Date: Tue, 27 Jun 2000 11:02:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >How common is it for a single server to be *directly* connected to more >than one customer site? Usually, sites are connected via routers, either >indirectly through ISPs or directly through "back-door" private links. Well first we are not sure yet how they will define site? If they use site as "department" is how I view it and maybe a good assumption for this discussion as a model to determine the pain. But DNS and DHCP for sure. Other less known apps are the ones developed by Oracle, Sybase, Informix etc... where IP addresses are used to identify clients records (much like DNS and DHCP do). But once could have: fec0::1 site A | Router | fec0::1 site B Where all DHCP and DNS and Database accesses for both sites (departments) are in site B. Or department B maintains all servers for all other departments (other sites). The problem is that the src address to site B will be feco::1 or from site A. The server apps needs to know the zone via the sin6_scope_id from the packet. Then if the database lookup was: IPv6 address It would have to change that to: IPv6 Address + sin6_scope_id Site B would know this from the router connection to Site A (likewise Site A would know B). It really is putting a completely new variable in the net communications paradigm for these apps. Bottom line I would like to see us avoid that architecturally for applications for Ipv6 and keep it simple as it was for IPv4. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 09:11:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RG9rb14714 for ipng-dist; Tue, 27 Jun 2000 09:09:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RG9i614707 for ; Tue, 27 Jun 2000 09:09:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA24037 for ; Tue, 27 Jun 2000 09:09:43 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20540 for ; Tue, 27 Jun 2000 09:09:38 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA39006; Tue, 27 Jun 2000 17:09:29 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA22004; Tue, 27 Jun 2000 17:09:26 +0100 (BST) Message-ID: <3958D134.16F37FCD@hursley.ibm.com> Date: Tue, 27 Jun 2000 11:07:16 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bob Hinden CC: ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter References: <4.3.2.7.2.20000623143215.01c42da8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I can't hekp wondering whether the flow label issue should be sent off to the Transport area for consideration. Brian Bob Hinden wrote: > > Folks, > > Attached is a draft of a revised charter for the working group. Updating > the charter was agreed to at the Grenoble and Minneapolis working group > meetings, but it took the chairs and AD's a while to draft a new one. > > The charter includes changing the name of the working group to the "IP > Version 6 Working Group", but will keep the acronym of "ipngwg". This will > avoid having to rename all current internet drafts. > > Please send comments on the new charter to the mailing list. There will be > a short session in Pittsburgh to discuss it as well. > > Bob Hinden / Steve Deering > > ----------------------------------------------------------------------------- > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > ----------------------------------------------------------------------------- > > IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym > > Chair(s): > > Bob Hinden > Steve Deering > > Document Editor > > Bob Hinden (hinden@iprg.nokia.com) > > Internet Area Director(s): > > Thomas Narten > Erik Nordmark > > Internet Area Advisor: > > Thomas Narten > > Mailing Lists: > > General Discussion:ipng@sunroof.eng.sun.com > To Subscribe: majordomo@sunroof.eng.sun.com > In Body: in body: subscribe ipng > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > Description of Working Group: > > IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) > is intended to support the continued growth of the Internet, both in > size and capabilities, by offering a greatly increased IP address space > and other enhancements over IPv4. The working group was originally > chartered to implement the recommendations of the IPng Area Directors > as outlined at the July 1994 IETF meeting and in "The Recommendation > for the IP Next Generation Protocol," RFC1752, January 1995. Most of > the tasks in that original charter have been completed, and the core > IPv6 protocol specifications are now on the IETF standards track. > The working group's ongoing responsibilities are as follows: > > - Complete work from the original charter and follow-on work, as > outlined below. > > - Keep all IPv6 working group documents moving along publication / > standardization track. > > - Serve as a review board and body of competence and coordination for > IPv6 architectural issues that span multiple IETF working groups. > > - Provide a home for IPv6-related work that doesn't fit in an existing > IETF working group and doesn't merit a working group of its own. > > - Provide technical input to ICANN, Internet Address Registries, and > IANA with regard to IPv6 address allocation policies and procedures. > > - Provide technical input and review to IANA with regard to IPv6 > protocol and parameter assignments. > > The list of the working group's current work items is as follows: > > - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, > editorial) > - Revise Generic Tunneling spec (add bidirectional tunnels) > - Update Basic and Advanced API specs > - Complete Router Renumbering spec > - Complete Scoped Address Architecture spec and any necessary revisions > to other working group drafts required to properly implement support > for IPv6 address scoping > - Complete work on recommended address-selection algorithms > - Work on new solutions to site-multihoming problems, possibly including > both host-based and router-based solutions. > - Complete work on local IPv6 networking as part of IPv6 plug-and-play > - Complete work on privacy extensions to stateless address configuration > - Document IPv6 renumbering model > - Complete the GSE Analysis document > - Complete the Inverse Neighbor Discovery spec > - Complete the IPv6 Node Information Queries spec > - Complete MIB specs as required by any working group protocol specs > > New work items not listed above require the approval of the working > group and Internet Area directors before they will be taken on by the > working group. > > The working group would welcome contributions on the following topics > (this is not an exhaustive list): > > - Flow label standardization > - Solutions to other multihoming issues, beyond those specific to > site-multihoming > - Integration of autoconfiguration, mobility, DNS, service discovery > and other technologies to enhance IPv6 plug-and-play > - IPv6 dial-up issues relating to address assignment, use of Neighbor > Discovery, etc. (not including AAA work) > - Specifications for IPv6 over additional media > - Extending MLD to include functionality of IGMPv3 > - Host use of anycast; TCP use of anycast > - Support for multi-link subnets (single subnet spans multiple links) > - Scope-name discovery > - IPv6 protocol extensions to accommodate mobile wireless networks. > > Goals and Milestones: > > Aug 2000 Complete MLD MIB and submit for Proposed Standard > > Aug 2000 Complete privacy extensions specification and submit for > Proposed Standard > > Aug 2000 Completed revision of GSE Analysis document and resubmit > for Informational > > Aug 2000 Complete the Inverse Neighbor Discovery specification > and submit for Proposed Standard > > Aug 2000 Complete IPv6 Multihoming with Route Aggregation and submit > for Informational. > > Oct 2000 Update ICMP document and resubmit for Draft Standard > > Oct 2000 Update Generic Tunneling specification and resubmit for > Proposed Standard > > Oct 2000 Complete updates to Basic and Advanced API specifications > and submit for Informational > > Dec 2000 Complete Scoped Address Architecture and submit for Proposed > Standard > > Dec 2000 Compete Address Selection specification and submit for Proposed > Standard > > Dec 2000 Complete Local IPv6 Networking Specification and submit for > Proposed Standard > > Dec 2000 Complete the IPv6 Node Information Queries specification > and submit for Proposed Standard > > Mar 2001 Complete IPv6 renumbering model document and submit for > Informational > > ----------------------------------------------------------------------------- > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > ----------------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 09:16:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RGEZj14733 for ipng-dist; Tue, 27 Jun 2000 09:14:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RGEP614726 for ; Tue, 27 Jun 2000 09:14:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA29855 for ; Tue, 27 Jun 2000 09:14:25 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23844 for ; Tue, 27 Jun 2000 09:14:21 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5RGBYK27635; Tue, 27 Jun 2000 18:11:35 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA17725; Tue, 27 Jun 2000 18:11:29 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA08307; Tue, 27 Jun 2000 18:12:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006271612.SAA08307@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: Global Prefixes in IPv6 In-reply-to: Your message of Tue, 27 Jun 2000 09:59:45 EDT. <200006271359.JAA0000010635@yquarry.zk3.dec.com> Date: Tue, 27 Jun 2000 18:12:19 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: ... unless the following happens. Node A on link1 has fe35::1 as global address. AND Node B on link2 has fe35::1 as global address. They end up with the same global address meaning they are not global by my definition. => then you concern is about duplicate global address detection only? So ND would have to make sure also that the link-local is unique across the multiple links. That could be difficult. => of course current ND DAD doesn't work in this case but a management tool can easily fill the hole (for instance if we require nodes must register new addresses in a central (ie with the multiple link scope) database then it will be easy to detect duplicates. I'd like to use DHCPv6 for that (then I am *not* happy with the last I-D which makes this impossible, even this is not (yet) written down) but this function is easy to implement if the way interface IDs are built does not imply they are unique). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 09:22:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RGKAt14755 for ipng-dist; Tue, 27 Jun 2000 09:20:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RGK1614748 for ; Tue, 27 Jun 2000 09:20:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA01300 for ; Tue, 27 Jun 2000 09:20:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00491 for ; Tue, 27 Jun 2000 10:19:59 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA15748; Tue, 27 Jun 2000 09:19:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA23102; Tue, 27 Jun 2000 09:19:55 -0700 X-Virus-Scanned: Tue, 27 Jun 2000 09:19:55 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma022447; Tue, 27 Jun 00 09:19:40 -0700 Message-ID: <3958D41D.41DF7CEB@iprg.nokia.com> Date: Tue, 27 Jun 2000 09:19:41 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve Deering CC: ipng@sunroof.eng.sun.com Subject: Re: Global Prefixes in IPv6 References: <200006271447.KAA0000020601@yquarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I think that this discussion came up in the first place because Francis Dupont pointed out that DHCPv6 does not specifically support multi-link subnets. They aren't typically implemented as part of stateless autoconfiguration, and we don't know how to support them directly with DHCPv6, and DHCPv6 is already late by a year+. So, I would like to avoid seeing DHCPv6 encumbered with any requirement to support multi-link subnets, except insofar as avoiding the obvious problem of assigning the same IP address to two different DHCP clients on the same subnet. This latter problem does not exist in the current spec. I suggest that the existing DHCPv6 specification does not need to deal with the issue at all, because ensuring uniqueness is a problem for DAD, not DHCPv6. Whatever DAD does, will work as well for DHCPv6 as for stateless. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 09:28:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RGQrn14778 for ipng-dist; Tue, 27 Jun 2000 09:26:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RGQj614771 for ; Tue, 27 Jun 2000 09:26:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA02564 for ; Tue, 27 Jun 2000 09:25:29 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04768 for ; Tue, 27 Jun 2000 10:25:25 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA13894; Tue, 27 Jun 2000 17:23:41 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA22754; Tue, 27 Jun 2000 17:23:18 +0100 (BST) Message-ID: <3958D471.4C1A09E0@hursley.ibm.com> Date: Tue, 27 Jun 2000 11:21:05 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ben Black CC: Jim Bound , Jessica Yu , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" References: <20000626143651.D12267@layer8.net> <200006270116.VAA0000697593@anw.zk3.dec.com> <20000626183721.A12295@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the basis that this draft is helpful in certain circumstances, I support its publication. It doesn't invalidate the 2260-like approach, which I agree is better in other circumstances. Having multiple solutions is good. Brian Carpenter Ben Black wrote: > > Pending any description of how this draft provides *any* > technical benefit (for example, what situations it covers > which cannot be accomplished for efficiently and effectively > with the RFC2260-based proposal), I am strongly against > this draft moving forward. > > Ben > > On Mon, Jun 26, 2000 at 09:16:09PM -0400, Jim Bound wrote: > > Chairs, > > > > I stongly support this draft moving forward. > > > > regards, > > /jim > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 09:30:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RGSTV14789 for ipng-dist; Tue, 27 Jun 2000 09:28:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RGSA614780 for ; Tue, 27 Jun 2000 09:28:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA05339 for ; Tue, 27 Jun 2000 09:28:10 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04301 for ; Tue, 27 Jun 2000 10:27:59 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA06237; Tue, 27 Jun 2000 09:24:37 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA13681; Tue, 27 Jun 2000 09:24:37 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id JAA08679; Tue, 27 Jun 2000 09:28:27 -0700 (PDT) Date: Tue, 27 Jun 2000 09:28:27 -0700 (PDT) From: Tim Hartrick Message-Id: <200006271628.JAA08679@feller.mentat.com> To: Francis.Dupont@enst-bretagne.fr Subject: Re: rfc2553bis comments Cc: deering@cisco.com, bzill@microsoft.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, > > I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_- > scope_id for what it was originally intended, to identify the zone from > which a datagram was received and to identify the zone to which a datagram > should be sent. To the extent that that overlaps with what IPV6_MULTICAST_IF > does that is unfortunate but it certainly isn't the only or even the worst > example of duplicated functionality in the API specifications. > > => if the functionality is duplicated (and it is in this case) we have to > specify who has the precedence, ie. what happens when both are used. > Sure. But we would need to do that if we "deprecated" IPV6_MULTICAST_IF since the IPV6_MULTICAST_IF option isn't really going anywhere. None of the implementors I know is going to be able to simply erase it from their implementation. If we have to keep it then we should just specify how the sin6_scope_id interacts with it and move on. >From my perspective it is clear that because the sin6_scope_id has a finer granularity of the application that it should take precedence over the IPV6_MULTICAST_IF option. For site-local, organization-local, other-local addresses this means that when a non-zero sin6_scope_id is specified the outgoing interface is determined by the routing table if the interface specified by the IPV6_MULTICAST_IF is not part of the zone referenced by the sin6_scope_id. For link-local addresses a non-zero sin6_scope_id overrides the IPV6_MULTICAST_IF option. For global addresses the sin6_scope_id is not interpreted so the IPV6_MULTICAST_IF, if set, determines which interface is to be used. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 09:30:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RGSuQ14805 for ipng-dist; Tue, 27 Jun 2000 09:28:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RGSg614798 for ; Tue, 27 Jun 2000 09:28:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA28174 for ; Tue, 27 Jun 2000 09:28:41 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04159 for ; Tue, 27 Jun 2000 09:28:39 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 08EAB27BF; Tue, 27 Jun 2000 10:19:04 -0400 (EDT) Received: from yquarry.zk3.dec.com (byquarry.zk3.dec.com [16.140.96.30]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E4F4325EB; Tue, 27 Jun 2000 10:08:16 -0400 (EDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id KAA0000012829; Tue, 27 Jun 2000 10:08:16 -0400 (EDT) From: Jim Bound Message-Id: <200006271408.KAA0000012829@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: rfc2553bis comments In-reply-to: Your message of "Mon, 26 Jun 2000 23:52:22 PDT." Date: Tue, 27 Jun 2000 10:08:16 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >At 11:19 PM -0400 6/26/00, Jim Bound wrote: >>Hello, Mr. Customer I am vendor X and here is my new IPv6 product, but >>beware it will break your network server apps but go ahead implement >>sitelocal addresses with overlapping servers. >By "overlapping server", do you mean a server directly connected to more >than one site? If so, sensible vendors Y and Z would say: Yes I believe that was obvious sorry if it was not and I too terse. Hello, Mr. Customer I am vendor Y and here is my new IPv6 product [ported in two hours from my old IPv4 product]. If you are using site-local addressing, be aware that each site will need its own copy of the server. We have a special deal for you if you buy more than one. :-) Well 2 hours is a bit short but ISVs will not want to mess with their architecture for applications either and thats what this is all about. Also not all customers want two servers. Hello, Mr. Customer I am vendor Z and here is my new IPv6 product which has been enhanced to support multiple sites from the same server. That would mean having to differentiate sin6_scope_id for each address which is not well defined today for anyone. Also with my thought of a fix this all becomes uncessary if we use the rsvd bits in site-local to provide uniqueness. Not a big fan of site-locals in DNS either but thats another discussion. >It should appear in the ID directories in a day or two. It was posted >to the ipng list on March 22, so if you archive past ipng mail, you >might find it sooner there. (Or send me mail and I will send you a >personal copy.) I am sured I pulled it over. Hmmm................... thanks, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 09:34:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RGWVc14832 for ipng-dist; Tue, 27 Jun 2000 09:32:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RGWK614825 for ; Tue, 27 Jun 2000 09:32:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA04131 for ; Tue, 27 Jun 2000 09:32:19 -0700 (PDT) Received: from lychee.itojun.org (p79.stsn.com [12.23.74.79] (may be forged)) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02852 for ; Tue, 27 Jun 2000 09:31:56 -0700 (PDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e5RGNu504703; Wed, 28 Jun 2000 01:23:56 +0900 (JST) To: Bob Hinden cc: ipng@sunroof.eng.sun.com, deering@cisco.com In-reply-to: hinden's message of Fri, 23 Jun 2000 14:34:31 MST. <4.3.2.7.2.20000623143215.01c42da8@mailhost.iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Revised IPng Working Group Charter From: Jun-ichiro itojun Hagino Date: Wed, 28 Jun 2000 01:23:46 +0900 Message-ID: <4701.962123026@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not sure if I have sent this already. please forgive me if there's duplicate messages. > The working group would welcome contributions on the following topics > (this is not an exhaustive list): > - Host use of anycast; TCP use of anycast and also UDP. UDP anycast will be very useful for DNS. most of already-defined UDP services require us to use the same src/dst pair for query/reply (reverse order for reply, of course). therefore, we have conflict between them. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 09:57:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RGt3Q14898 for ipng-dist; Tue, 27 Jun 2000 09:55:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RGss614891 for ; Tue, 27 Jun 2000 09:54:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA10048 for ; Tue, 27 Jun 2000 09:54:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20282 for ; Tue, 27 Jun 2000 09:54:38 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA18006; Tue, 27 Jun 2000 09:40:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA26409; Tue, 27 Jun 2000 09:40:10 -0700 X-Virus-Scanned: Tue, 27 Jun 2000 09:40:10 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma025693; Tue, 27 Jun 00 09:39:54 -0700 Message-ID: <3958D8DC.96B9BD56@iprg.nokia.com> Date: Tue, 27 Jun 2000 09:39:56 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng@sunroof.eng.sun.com Subject: Re: Global Prefixes in IPv6 References: <200006271612.SAA08307@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Francis, I saw your note after I had already written my previous note. > => of course current ND DAD doesn't work in this case but a management > tool can easily fill the hole (for instance if we require nodes must > register new addresses in a central (ie with the multiple link scope) > database then it will be easy to detect duplicates. I'd like to use > DHCPv6 for that (then I am *not* happy with the last I-D which makes > this impossible, even this is not (yet) written down) but this function > is easy to implement if the way interface IDs are built does not imply > they are unique). If you can contribute the necessary text to the DHCPv6 specification, and if there is agreement that this problem needs to be fixed now, then maybe that will make things different. Until then, I would hope to avoid this delay. I don't see the easy solution. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 10:27:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RHOrR14933 for ipng-dist; Tue, 27 Jun 2000 10:24:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RHOh614926 for ; Tue, 27 Jun 2000 10:24:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA12423 for ; Tue, 27 Jun 2000 10:24:42 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA20483 for ; Tue, 27 Jun 2000 11:24:10 -0600 (MDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Jun 2000 09:53:28 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 27 Jun 2000 10:00:18 -0700 content-class: urn:content-classes:message Subject: RE: rfc2553bis comments MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE058.196CD06E" X-MimeOLE: Produced By Microsoft Exchange V6.0.4406.0 Date: Tue, 27 Jun 2000 09:52:37 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690C6F7AA4@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc2553bis comments Thread-Index: Ab/gUge3HBFj5fwQRaSUFR4dq0/4TAABDgug From: "Dave Thaler" To: "Francis Dupont" , "Steve Deering" Cc: X-OriginalArrivalTime: 27 Jun 2000 17:00:18.0580 (UTC) FILETIME=[2C12BD40:01BFE059] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFE058.196CD06E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve Deering writes: > if the local indexes for the interfaces plus all zones=20 > (i.e., links, > sites, and any additional multicast zones configured on=20 > the node) are > given distinct values out of the same scope_id space,=20 > and if one index > value (say, 0) is reserved to mean "unspecified". Then,=20 > I think we could > probably get rid of IPV6_MULTICAST_IF altogether (i.e.,=20 > deprecate it). I really don't like the idea of sharing the same numbering space between interface ids and scope ids of higher levels, and requiring uniqueness among them. My reasoning is that ifindices are a link-layer id (per their original definition in MIB-II), whereas site ids are network-layer (and IPv6 only) ids with a very different meaning. It's a layer violation to ask for=20 uniqueness among them. If the implementation used interface ids that were not ifindices, that would be a different thing, but then if_nametoindex() and related functions wouldn't be helpful for an app wanting to choosing a link. Francis Dupont, responding, writes: > =3D> the only reason we should have to keep IPV6_MULTICAST_IF is an > interface specification can be finer than a link one... I agree with that reason, but obviously I don't think it's the only reason :) > On reception, the upper-layer should be told the arrival=20 > interface, > =3D> how? The sin6_scope_id should contains the index of the zone of = the > address scope (this rule implies global addresses in any=20 > cases will get > the zero sin6_scope_id in recvfrom() because there is only=20 > one global zone). I believe the reception interface (for both unicast and multicast) can already be obtained if you use recvmsg. =20 > from which it can also determine the arrival zones of=20 > each possible > scope, since each interface can belong to only one zone=20 > of each scope. -Dave ------_=_NextPart_001_01BFE058.196CD06E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: rfc2553bis comments

Steve Deering writes:
>      if the local = indexes for the interfaces plus all zones
> (i.e., links,
>      sites, and any = additional multicast zones configured on
> the node) are
>      given distinct = values out of the same scope_id space,
> and if one index
>      value (say, 0) is = reserved to mean "unspecified".  Then,
> I think we could
>      probably get rid = of IPV6_MULTICAST_IF altogether (i.e.,
> deprecate it).

I really don't like the idea of sharing the same = numbering space
between interface ids and scope ids of higher levels, = and requiring
uniqueness among them.

My reasoning is that ifindices are a link-layer id = (per their original
definition in MIB-II), whereas site ids are = network-layer (and IPv6 only)
ids with a very different meaning.  It's a layer = violation to ask for
uniqueness among them.

If the implementation used interface ids that were not = ifindices, that would
be a different thing, but then if_nametoindex() and = related functions wouldn't
be helpful for an app wanting to choosing a = link.

Francis Dupont, responding, writes:
> =3D> the only reason we should have to keep = IPV6_MULTICAST_IF is an
> interface specification can be finer than a link = one...

I agree with that reason, but obviously I don't think = it's the
only reason :)

>      On reception, the = upper-layer should be told the arrival
> interface,

> =3D> how? The sin6_scope_id should contains = the index of the zone of the
> address scope (this rule implies global = addresses in any
> cases will get
> the zero sin6_scope_id in recvfrom() because = there is only
> one global zone).

I believe the reception interface (for both = unicast
and multicast) can already be obtained if you use = recvmsg.
 
>      from which it can = also determine the arrival zones of
> each possible
>      scope, since each = interface can belong to only one zone
> of each scope.

-Dave

------_=_NextPart_001_01BFE058.196CD06E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 10:37:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RHYwJ14952 for ipng-dist; Tue, 27 Jun 2000 10:34:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RHYn614945 for ; Tue, 27 Jun 2000 10:34:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA15375 for ; Tue, 27 Jun 2000 10:34:48 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02278 for ; Tue, 27 Jun 2000 11:34:44 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA19762; Wed, 28 Jun 2000 02:22:15 +0900 (JST) Date: Wed, 28 Jun 2000 02:28:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments In-Reply-To: In your message of "Mon, 26 Jun 2000 20:30:24 -0700 (PDT)" <200006270330.UAA08422@feller.mentat.com> References: <200006270330.UAA08422@feller.mentat.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 26 Jun 2000 20:30:24 -0700 (PDT), >>>>> Tim Hartrick said: > I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_- > scope_id for what it was originally intended, to identify the zone from > which a datagram was received and to identify the zone to which a datagram > should be sent. To the extent that that overlaps with what IPV6_MULTICAST_IF > does that is unfortunate but it certainly isn't the only or even the worst > example of duplicated functionality in the API specifications. > Application writers are familiar and confortable with the notion of > specifying the outgoing interface to be used for multicast and I just don't > see the upside to obsoleting IPV6_MULTICAST_IF in an effort to make > application writers' lives easier. Gratuitous changes to APIs piss > people off even if they are improvements. I agree with this. We could implement Steve's proposal if we invented unique space of identifiers that covers all scopes. And I admit it would be useful if we can specify the outgoing interface by the sin6_scope_id field without any other APIs (such as socket options), but it would be too complecated for application programmers, especially on properly using different type of sin6_scope_id values (i.e. sometimes use it as an interface identifier, and sometimes use it as a zone identifier of a larger scope). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 11:28:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RIQPI15071 for ipng-dist; Tue, 27 Jun 2000 11:26:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RIQF615064 for ; Tue, 27 Jun 2000 11:26:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA20940 for ; Tue, 27 Jun 2000 11:26:14 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA14355 for ; Tue, 27 Jun 2000 12:26:03 -0600 (MDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Jun 2000 10:38:47 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 27 Jun 2000 10:46:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4406.0 content-class: urn:content-classes:message Subject: FW: rfc2553bis comments MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE05E.81477ADA" Date: Tue, 27 Jun 2000 10:38:29 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690D8CEE62@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc2553bis comments Thread-Index: Ab/gUge3HBFj5fwQRaSUFR4dq0/4TAABDgugAAJAiGA= From: "Dave Thaler" To: , Cc: X-OriginalArrivalTime: 27 Jun 2000 17:46:09.0643 (UTC) FILETIME=[93D5A3B0:01BFE05F] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFE05E.81477ADA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks like the last try went out as HTML. Resending, sorry for duplicate. -Dave -----Original Message----- From: Dave Thaler=20 Sent: Tuesday, June 27, 2000 9:53 AM To: Francis Dupont; Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments=20 Steve Deering writes:=20 > if the local indexes for the interfaces plus all zones=20 > (i.e., links,=20 > sites, and any additional multicast zones configured on=20 > the node) are=20 > given distinct values out of the same scope_id space,=20 > and if one index=20 > value (say, 0) is reserved to mean "unspecified". Then,=20 > I think we could=20 > probably get rid of IPV6_MULTICAST_IF altogether (i.e.,=20 > deprecate it).=20 I really don't like the idea of sharing the same numbering space=20 between interface ids and scope ids of higher levels, and requiring=20 uniqueness among them.=20 My reasoning is that ifindices are a link-layer id (per their original=20 definition in MIB-II), whereas site ids are network-layer (and IPv6 only)=20 ids with a very different meaning. It's a layer violation to ask for=20 uniqueness among them.=20 If the implementation used interface ids that were not ifindices, that would=20 be a different thing, but then if_nametoindex() and related functions wouldn't=20 be helpful for an app wanting to choosing a link.=20 Francis Dupont, responding, writes:=20 > =3D> the only reason we should have to keep IPV6_MULTICAST_IF is an=20 > interface specification can be finer than a link one...=20 I agree with that reason, but obviously I don't think it's the=20 only reason :)=20 > On reception, the upper-layer should be told the arrival=20 > interface,=20 > =3D> how? The sin6_scope_id should contains the index of the zone of = the > address scope (this rule implies global addresses in any=20 > cases will get=20 > the zero sin6_scope_id in recvfrom() because there is only=20 > one global zone).=20 I believe the reception interface (for both unicast=20 and multicast) can already be obtained if you use recvmsg.=20 =20 > from which it can also determine the arrival zones of=20 > each possible=20 > scope, since each interface can belong to only one zone=20 > of each scope.=20 -Dave=20 ------_=_NextPart_001_01BFE05E.81477ADA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: rfc2553bis comments

Looks like the last try went out as HTML.
Resending, sorry for duplicate.
-Dave

-----Original Message-----
From: Dave Thaler
Sent: Tuesday, June 27, 2000 9:53 AM
To: Francis Dupont; Steve Deering
Cc: ipng@sunroof.eng.sun.com
Subject: RE: rfc2553bis comments

Steve Deering writes:
>      if the local = indexes for the interfaces plus all zones
> (i.e., links,
>      sites, and any = additional multicast zones configured on
> the node) are
>      given distinct = values out of the same scope_id space,
> and if one index
>      value (say, 0) is = reserved to mean "unspecified".  Then,
> I think we could
>      probably get rid = of IPV6_MULTICAST_IF altogether (i.e.,
> deprecate it).
I really don't like the idea of sharing the same = numbering space
between interface ids and scope ids of higher levels, = and requiring
uniqueness among them.
My reasoning is that ifindices are a link-layer id = (per their original
definition in MIB-II), whereas site ids are = network-layer (and IPv6 only)
ids with a very different meaning.  It's a layer = violation to ask for
uniqueness among them.
If the implementation used interface ids that were = not ifindices, that would
be a different thing, but then if_nametoindex() and = related functions wouldn't
be helpful for an app wanting to choosing a link. =
Francis Dupont, responding, writes:
> =3D> the only reason we should have to keep = IPV6_MULTICAST_IF is an
> interface specification can be finer than a link = one...
I agree with that reason, but obviously I don't think = it's the
only reason :)
>      On reception, the = upper-layer should be told the arrival
> interface,
> =3D> how? The sin6_scope_id should contains = the index of the zone of the
> address scope (this rule implies global = addresses in any
> cases will get
> the zero sin6_scope_id in recvfrom() because = there is only
> one global zone).
I believe the reception interface (for both unicast =
and multicast) can already be obtained if you use = recvmsg.
 
>      from which it can = also determine the arrival zones of
> each possible
>      scope, since each = interface can belong to only one zone
> of each scope.
-Dave

------_=_NextPart_001_01BFE05E.81477ADA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 12:06:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RJ41Z15135 for ipng-dist; Tue, 27 Jun 2000 12:04:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RJ3q615128 for ; Tue, 27 Jun 2000 12:03:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA14210 for ; Tue, 27 Jun 2000 12:03:51 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27828 for ; Tue, 27 Jun 2000 12:03:50 -0700 (PDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 1370XZ-0004Ws-00; Tue, 27 Jun 2000 14:56:57 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA20224; Tue, 27 Jun 00 14:54:29 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA17034; Tue, 27 Jun 2000 14:59:32 -0400 Message-Id: <3958F960.70E0980A@txc.com> Date: Tue, 27 Jun 2000 14:58:40 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Global Prefixes in IPv6 References: <200006271359.JAA0000010635@yquarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > At 9:59 AM -0400 6/27/00, Jim Bound wrote: > >Also I have no issue of prefixes spanning multiple > >links unless the following happens. > > > >Node A on link1 has fe35::1 as global address. > > > >AND > > > >Node B on link2 has fe35::1 as global address. > > > >Because when the prefix spanned multiple links (link1 and link2) Node A > >and B have the same link-local address 64bit ID in this case Unicast > >Aggregate Format for this discussion. > > Part of the (not-yet-written-down) work of supporting multi-link subnets is > making sure that the routers that connect a multi-link subnet ensure that > DAD messages are relayed/proxied to all links in that subnet (or in some > other way detect and prevent duplicate interface IDs being used within the > subnet). It is a neat idea to have a subnet span different type of links, in particular when such a solution seem to apply so well in a scenario that is more and more frequent in home or small office networking environments. Since DHCPv6 seems to have a problem with this, it would be good to have this documented ASAP. With the number of IPv6 documents on continue growth, and with the delay incurred with writing and posting a new I-D, and since this problem occurs only with non-unique interface IDs, wouldn't it be more efficient - in terms of documenting the solution - to add to the specifications that document the generation of such IDs a section that suggests the solution(s)? Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 12:12:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RJB9K15189 for ipng-dist; Tue, 27 Jun 2000 12:11:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RJB0615181 for ; Tue, 27 Jun 2000 12:11:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA15848 for ; Tue, 27 Jun 2000 12:10:59 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02490 for ; Tue, 27 Jun 2000 12:10:59 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id A41B6BE2; Tue, 27 Jun 2000 15:10:58 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8B493AB4; Tue, 27 Jun 2000 15:10:58 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000865346; Tue, 27 Jun 2000 15:10:58 -0400 (EDT) From: Jim Bound Message-Id: <200006271910.PAA0000865346@anw.zk3.dec.com> To: Francis Dupont Cc: Jim Bound , Steve Deering , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Global Prefixes in IPv6 In-reply-to: Your message of "Tue, 27 Jun 2000 18:12:19 +0200." <200006271612.SAA08307@givry.rennes.enst-bretagne.fr> Date: Tue, 27 Jun 2000 15:10:58 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, If you want to discuss dhcpv6 do it on that list. And link-local addresses are unique right now on a link. When prefixes span multiple links then they will be unique there. There is no problem I am done discussing this thread on IPv6 working group until we see work for us to do. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 12:14:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RJCnc15211 for ipng-dist; Tue, 27 Jun 2000 12:12:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RJCc615197 for ; Tue, 27 Jun 2000 12:12:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA02450 for ; Tue, 27 Jun 2000 12:12:37 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03525 for ; Tue, 27 Jun 2000 12:12:36 -0700 (PDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 9CB9458F1; Tue, 27 Jun 2000 15:12:35 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 570A658DF; Tue, 27 Jun 2000 15:12:33 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000866020; Tue, 27 Jun 2000 15:12:32 -0400 (EDT) From: Jim Bound Message-Id: <200006271912.PAA0000866020@anw.zk3.dec.com> To: Brian E Carpenter Cc: Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com, bound@zk3.dec.com Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of "Tue, 27 Jun 2000 11:07:16 CDT." <3958D134.16F37FCD@hursley.ibm.com> Date: Tue, 27 Jun 2000 15:12:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk flowlabel should be done here or in routing area. those are the people who understand it and ramifications. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 12:27:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RJOeY15270 for ipng-dist; Tue, 27 Jun 2000 12:24:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RJOV615263 for ; Tue, 27 Jun 2000 12:24:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA18781 for ; Tue, 27 Jun 2000 12:24:30 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11071 for ; Tue, 27 Jun 2000 12:24:29 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 6236C9EF; Tue, 27 Jun 2000 15:24:28 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 4B966933; Tue, 27 Jun 2000 15:24:28 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000867684; Tue, 27 Jun 2000 15:24:28 -0400 (EDT) From: Jim Bound Message-Id: <200006271924.PAA0000867684@anw.zk3.dec.com> To: Alex Conta Cc: Steve Deering , Jim Bound , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Global Prefixes in IPv6 In-reply-to: Your message of "Tue, 27 Jun 2000 14:58:40 EDT." <3958F960.70E0980A@txc.com> Date: Tue, 27 Jun 2000 15:24:27 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, Francis was misguided on the issue. DHCPv6 has no problem. When it gets executed DHCPv6 will work. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 13:16:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RKDGu15322 for ipng-dist; Tue, 27 Jun 2000 13:13:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RKD6615315 for ; Tue, 27 Jun 2000 13:13:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA04921 for ; Tue, 27 Jun 2000 13:13:05 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04779 for ; Tue, 27 Jun 2000 14:12:57 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA34598; Tue, 27 Jun 2000 21:12:53 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA14992; Tue, 27 Jun 2000 21:12:51 +0100 (BST) Message-ID: <39590A57.F333B30E@hursley.ibm.com> Date: Tue, 27 Jun 2000 15:11:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter References: <200006271912.PAA0000866020@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But the people who understand QOS are in the transport area, and so far they have ignored it. Brian Jim Bound wrote: > > flowlabel should be done here or in routing area. > those are the people who understand it and ramifications. > > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 13:32:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RKUPc15344 for ipng-dist; Tue, 27 Jun 2000 13:30:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RKUG615337 for ; Tue, 27 Jun 2000 13:30:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA02425 for ; Tue, 27 Jun 2000 13:29:00 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23564 for ; Tue, 27 Jun 2000 13:28:59 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 398E87E6; Tue, 27 Jun 2000 15:28:57 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 8FA726FB; Tue, 27 Jun 2000 15:28:56 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id QAA0000558366; Tue, 27 Jun 2000 16:27:40 -0400 (EDT) From: Jim Bound Message-Id: <200006272027.QAA0000558366@anw.zk3.dec.com> To: Jessica Yu Cc: Ben Black , Vijay Gill , Jim Bound , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Tue, 27 Jun 2000 08:32:55 PDT." <20000627153255.2166.qmail@web3002.mail.yahoo.com> Date: Tue, 27 Jun 2000 16:27:40 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jessica, Your work should go thru as info RFC I see no reason at all to defend your draft any further for that goal. You have done a good job to give us a means to work with our ISP customers with IPv6 to set up some pilots with IPv6 using BGP+w/v6 to begin testing this and I also will be proposing that 3GPP look at your proposal very seriously for IMT2000. Chairs - again there is no compelling reason past or present to prevent this work from moving to info rfc and begin using it as a tool for the many IPv6 pilots springing up with our customers. I am not saying the discussion is 100% complete and I don't think it ever will be as we evolve IPv6, but I do think the decision has been made, and we should move on here. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 13:35:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RKXfZ15366 for ipng-dist; Tue, 27 Jun 2000 13:33:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RKXU615359 for ; Tue, 27 Jun 2000 13:33:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA09597 for ; Tue, 27 Jun 2000 13:33:29 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19650 for ; Tue, 27 Jun 2000 14:33:27 -0600 (MDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 656964BA; Tue, 27 Jun 2000 15:33:26 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id D1CB0796; Tue, 27 Jun 2000 15:33:25 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id QAA0000876720; Tue, 27 Jun 2000 16:33:24 -0400 (EDT) From: Jim Bound Message-Id: <200006272033.QAA0000876720@anw.zk3.dec.com> To: Brian E Carpenter Cc: Jim Bound , Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of "Tue, 27 Jun 2000 15:11:03 CDT." <39590A57.F333B30E@hursley.ibm.com> Date: Tue, 27 Jun 2000 16:33:24 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >But the people who understand QOS are in the transport area, and so far >they have ignored it. I would agree that the rsvp work folks did supports that. but I also think there are a lot of "implementation" issues and thats not there yet to my knowledge in the transport area. we would have to transport folks from here to the transport area for sure. Why not have them come to IPv6 WG to work on it instead? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 13:47:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RKi5F15411 for ipng-dist; Tue, 27 Jun 2000 13:44:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RKhu615404 for ; Tue, 27 Jun 2000 13:43:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA12006 for ; Tue, 27 Jun 2000 13:43:55 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03415 for ; Tue, 27 Jun 2000 13:43:53 -0700 (PDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 0D43658A6; Tue, 27 Jun 2000 16:43:53 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id F0415590A for ; Tue, 27 Jun 2000 16:43:52 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id QAA0000878009; Tue, 27 Jun 2000 16:43:52 -0400 (EDT) From: Jim Bound Message-Id: <200006272043.QAA0000878009@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: draft-ipngwg-scoping-arch-01.txt Date: Tue, 27 Jun 2000 16:43:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk steve/brian/brian, I read the spec wearing my ietf spec reveiwer and architecture hat. I like the clarification on zones. It is all clear to me. I have not one issue with it at this point. Clearly as I start to envision what it means to the IP and transport layer in our implementation and the API suite other questions may arise. But thats step 2. Also my proposed fix for the multisited app server would not interfere at all with your spec here. Very roughly. What I am thinking about is when the address is passed to the app and its a sitelocal a unique identifier would be embedded in the sitelocal address which would make it unique across multiple sites or in cases where two sites merged or whatever. My intention is NOT to prevent using the zone/scope semantics but make them transparent to application servers. I found many holes and have only plugged half of them thus far but I think they can all be plugged. The unique identifier would never be passed on the wire. There may be one exception and that is if Erik's draft is to keep moving he may be able to use the way I want to do this with ND and then they would exist within the context of a sitelocal ND msg. Thanks for doing this work we needed it bad. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 14:29:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5RLRGw15455 for ipng-dist; Tue, 27 Jun 2000 14:27:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5RLR7615448 for ; Tue, 27 Jun 2000 14:27:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA12242 for ; Tue, 27 Jun 2000 14:27:07 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00829 for ; Tue, 27 Jun 2000 15:27:03 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA42122; Tue, 27 Jun 2000 22:26:54 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA17448; Tue, 27 Jun 2000 22:26:52 +0100 (BST) Message-ID: <39591B46.2C1B5180@hursley.ibm.com> Date: Tue, 27 Jun 2000 16:23:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jim Bound CC: Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter References: <200006272033.QAA0000876720@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, it's not just RSVP, there is also diffserv where I see a lot of very practical implementation people. Wouldn't you rather infect the TSV area with IPv6 than have them in a network area WG? Brian Jim Bound wrote: > > >But the people who understand QOS are in the transport area, and so far > >they have ignored it. > > I would agree that the rsvp work folks did supports that. but I also > think there are a lot of "implementation" issues and thats not there yet > to my knowledge in the transport area. we would have to transport folks > from here to the transport area for sure. > > Why not have them come to IPv6 WG to work on it instead? > > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 17:09:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S072p15631 for ipng-dist; Tue, 27 Jun 2000 17:07:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S06q615624 for ; Tue, 27 Jun 2000 17:06:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA20570 for ; Tue, 27 Jun 2000 17:06:51 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01868 for ; Tue, 27 Jun 2000 17:06:52 -0700 (PDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 6DC664BD; Tue, 27 Jun 2000 19:06:51 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id EF61C679; Tue, 27 Jun 2000 19:06:50 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id UAA0000901953; Tue, 27 Jun 2000 20:06:49 -0400 (EDT) From: Jim Bound Message-Id: <200006280006.UAA0000901953@anw.zk3.dec.com> To: Brian E Carpenter Cc: Jim Bound , Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of "Tue, 27 Jun 2000 16:23:18 CDT." <39591B46.2C1B5180@hursley.ibm.com> Date: Tue, 27 Jun 2000 20:06:49 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >Jim, it's not just RSVP, there is also diffserv where I see a lot >of very practical implementation people. Wouldn't you rather >infect the TSV area with IPv6 than have them in a network area WG? Excellent point on infecting TSV. Ok I am sold. I just hope the efforts are better than I have been able to do to get dhcpv4 people to work on DHCPv6. Mike, Charlie, and I just put together what I think is a pretty good piece of work. Except for Francis we have had no input. Unfortuneately in dhc WG they want to hear yeah or nay. Unlike here. We think we have addressed all persons issues which was a real lot of work. Anyway I am not moaning about it but trying to get areas to work on IPv6 is still an up hill battle. I believe the IESG and IAB are doing great now with IPv6 (and for awhile) now we need to get the rest of the community on board. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 17:19:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S0HpE15670 for ipng-dist; Tue, 27 Jun 2000 17:17:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S0Hd615663 for ; Tue, 27 Jun 2000 17:17:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA27695 for ; Tue, 27 Jun 2000 17:17:39 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA06274 for ; Tue, 27 Jun 2000 17:17:35 -0700 (PDT) Received: (qmail 23219 invoked from network); 28 Jun 2000 00:19:53 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 28 Jun 2000 00:19:53 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Tue, 27 Jun 2000 17:11:33 +4100 Date: Tue, 27 Jun 2000 17:11:33 -0700 From: Ben Black To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: Jim Bound , Jessica Yu , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000627171133.D12321@layer8.net> References: <20000626143651.D12267@layer8.net> <200006270116.VAA0000697593@anw.zk3.dec.com> <20000626183721.A12295@layer8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from nisse@lysator.liu.se on Tue, Jun 27, 2000 at 04:46:32PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jun 27, 2000 at 04:46:32PM +0200, Niels Möller wrote: > Ben Black writes: > > > Pending any description of how this draft provides *any* > > technical benefit (for example, what situations it covers > > which cannot be accomplished for efficiently and effectively > > with the RFC2260-based proposal), I am strongly against > > this draft moving forward. > > I'm I bystander here, but as far as I can see, it appears that some > people like the approach, and really want to try it out. Then it ought Actually, I am looking for any indication that there is, in fact, *anyone* who wants to use this approach. So far, all my requests for an application of this approach which isn't *better* handled with another, existing method have gone unanswered. > to be a good thing to have it published so that both people > implementing it and people shooting it down can have a clear > description to refer to. After all, we're talking about an I do not see why an informational RFC is needed just as a point of reference for a debate. The draft is just fine for that purpose. An informational RFC in this context should be documentation of a potential approach offering benefits to the network operator not offered by other approaches. So, I once again ask that someone provide a reasonable scenario in which the approach in the J. Yu draft offers benefits over the RFC2260/Itojun approach. Ben -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 17:55:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S0r5h15694 for ipng-dist; Tue, 27 Jun 2000 17:53:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S0qs615687 for ; Tue, 27 Jun 2000 17:52:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA00314 for ; Tue, 27 Jun 2000 17:52:52 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA05383 for ; Tue, 27 Jun 2000 18:52:52 -0600 (MDT) Received: (qmail 23336 invoked from network); 28 Jun 2000 00:55:09 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 28 Jun 2000 00:55:09 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Tue, 27 Jun 2000 17:46:50 +4100 Date: Tue, 27 Jun 2000 17:46:50 -0700 From: Ben Black To: Jim Bound Cc: Jessica Yu , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000627174650.E12321@layer8.net> References: <20000627153255.2166.qmail@web3002.mail.yahoo.com> <200006272027.QAA0000558366@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006272027.QAA0000558366@anw.zk3.dec.com>; from bound@zk3.dec.com on Tue, Jun 27, 2000 at 04:27:40PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In all seriousness, would someone please explain the benefits of this approach in comparison tot he RFC2260 approach? I have *never* seen a single example and judging by the feedback the draft has gotten, most network operators see no value to it whatsoever. That alone should be a strong indication the proposal should be closely scrutinized before acceptance for any further circulation. Simply voting to have a draft moved to RFC without answering numerous, legitimate questions regarding its value would seem a very poor method for developing quality technical documents. Ben On Tue, Jun 27, 2000 at 04:27:40PM -0400, Jim Bound wrote: > Jessica, > > Your work should go thru as info RFC I see no reason at all to defend > your draft any further for that goal. You have done a good job to give > us a means to work with our ISP customers with IPv6 to set up some > pilots with IPv6 using BGP+w/v6 to begin testing this and I also will be > proposing that 3GPP look at your proposal very seriously for IMT2000. > > Chairs - again there is no compelling reason past or present to prevent > this work from moving to info rfc and begin using it as a tool for the > many IPv6 pilots springing up with our customers. > > I am not saying the discussion is 100% complete and I don't think it > ever will be as we evolve IPv6, but I do think the decision has been > made, and we should move on here. > > regards, > /jim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 18:50:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S1mQN15722 for ipng-dist; Tue, 27 Jun 2000 18:48:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S1mG615715 for ; Tue, 27 Jun 2000 18:48:16 -0700 (PDT) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e5S1mEa771260; Tue, 27 Jun 2000 18:48:14 -0700 (PDT) Date: Tue, 27 Jun 2000 18:48:13 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: rfc2553bis comments To: Dave Thaler Cc: Francis Dupont , Steve Deering , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <19398D273324D3118A2B0008C7E9A5690C6F7AA4@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My reasoning is that ifindices are a link-layer id (per their original > definition in MIB-II), whereas site ids are network-layer (and IPv6 > only) > ids with a very different meaning. It's a layer violation to ask for > uniqueness among them. Dave, You can have multiple logically separate name spaces of finite size and all fit them into a single 32 bit ID space. For instance, this can be done by making the 32 bit ID space identify the name space using some small number of high order bits, and leave the rest of the bits to each namespace. As long as you don't have to support 4 billion interface IDs or site IDs in a single box this shouldn't be a problem. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 20:10:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S398G15773 for ipng-dist; Tue, 27 Jun 2000 20:09:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S38x615766 for ; Tue, 27 Jun 2000 20:08:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA08481 for ; Tue, 27 Jun 2000 20:08:59 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA22296 for ; Tue, 27 Jun 2000 21:08:54 -0600 (MDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA21429; Wed, 28 Jun 2000 11:56:11 +0900 (JST) Date: Wed, 28 Jun 2000 12:05:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@enst-bretagne.fr Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-Reply-To: In your message of "Mon, 26 Jun 2000 09:57:26 +0200" <200006260757.JAA00781@givry.rennes.enst-bretagne.fr> References: <200006260757.JAA00781@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 26 Jun 2000 09:57:26 +0200, >>>>> Francis Dupont said: > I think it is not necessarily a better thing. A user might just > want to specify a multicast group (with some zone ID) and let the > kernel send packets to that group on an appropriate interface(s) > according to the kernel's routing table, etc. > => do you mean we should use the multicast routing table for > genuine packets (BSD IPv4 multicast is not very clear about this > for me, I have no concern but the specs need to be clear(er) about this). Sort of that. We could install a route for ff00::/8 to some interface as the multicast default route, or we could use a separate mechanism to implement the default outgoing interface for multicast packets. > This can make IPV6_MULTICAST_IF useless and/or things even more complex: > what semantics for sin6_scope_id on the sending side do you propose > (and is there a special case for the zero sin6_scope_id)? I don't think such a default route makes IPV6_MULTICAST_IF useless, but I admit it makes the situation complex. In any case, we should clarify relationship and/or precedence about all these interfaces. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 20:35:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S3Y3n15795 for ipng-dist; Tue, 27 Jun 2000 20:34:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S3Xs615788 for ; Tue, 27 Jun 2000 20:33:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA21405 for ; Tue, 27 Jun 2000 20:33:52 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA12773 for ; Tue, 27 Jun 2000 20:33:52 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 7FB57BAB; Tue, 27 Jun 2000 23:33:50 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2B40C809; Tue, 27 Jun 2000 23:33:50 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000921779; Tue, 27 Jun 2000 23:33:45 -0400 (EDT) From: Jim Bound Message-Id: <200006280333.XAA0000921779@anw.zk3.dec.com> To: Ben Black Cc: Jim Bound , Jessica Yu , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Tue, 27 Jun 2000 17:46:50 PDT." <20000627174650.E12321@layer8.net> Date: Tue, 27 Jun 2000 23:33:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We don't have to answer to you or anyone else. Obviously people don't care about your issue as I see no support for your proposed wall against the aggregation draft. I think its in the decision of the chairs now. As far as no network operators care I called two ISP network operators today and both will pilot jessica's proposal simply to see if implementors can make it work. They like I feel no duty to respond to "you". Got it!!!! regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 20:48:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S3ktp15816 for ipng-dist; Tue, 27 Jun 2000 20:46:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S3kj615809 for ; Tue, 27 Jun 2000 20:46:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA17753 for ; Tue, 27 Jun 2000 20:46:43 -0700 (PDT) Received: from mx1out.umbc.edu (mx1out.umbc.edu [130.85.253.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA16232 for ; Tue, 27 Jun 2000 20:46:43 -0700 (PDT) Received: from gl.umbc.edu (vijay@umbc8.umbc.edu [130.85.60.8]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id XAA27420; Tue, 27 Jun 2000 23:46:41 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id XAA11036625; Tue, 27 Jun 2000 23:46:40 -0400 (EDT) X-Authentication-Warning: umbc8.umbc.edu: vijay owned process doing -bs Date: Tue, 27 Jun 2000 23:46:39 -0400 From: Vijay Gill To: Jim Bound cc: Ben Black , Jessica Yu , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-Reply-To: <200006280333.XAA0000921779@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 27 Jun 2000, Jim Bound wrote: > We don't have to answer to you or anyone else. Obviously people don't > care about your issue as I see no support for your proposed wall against > the aggregation draft. I think its in the decision of the chairs now. Incorrect. There has bave been questions about the proposed value of this I-D. > As far as no network operators care I called two ISP network operators > today and both will pilot jessica's proposal simply to see if > implementors can make it work. They like I feel no duty to respond to > "you". Got it!!!! A better metric would probably be asking some CUSTOMERS. Speaking as a customer, I'd just get two separate lines with two address blocks from each provider to ensure against _autonomous system wide isp failure_, before I'd trust an bit of data to this scheme. This is much more common than people seem to realize, having been in midst of several on a global scale. Including some interesting area wide failures TODAY (see thread on nanog). Wearing my provider hat, I _assure_ you we can barely get standard point to point circuits up amongst ourselves, much less co-ordinate setup of selective routing. Special casing does not scale. MBONE and 6BONE are set up as special cases with engineers working on them, but trying to get something on this scale for several thousand customers just isn't going to work. /vijay > > regards, > /jim > Vijay Gill |The (paying) customer is always right. wrath@cs.umbc.edu, vijay@umbc.edu | - Piercarlo Grandi http://umbc.edu/~vijay | Eagles may soar, but weasels don't get These are my opinions only. | sucked into jet engines. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 27 20:59:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S3vRN15837 for ipng-dist; Tue, 27 Jun 2000 20:57:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S3vG615830 for ; Tue, 27 Jun 2000 20:57:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA22838 for ; Tue, 27 Jun 2000 20:57:15 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA06579 for ; Tue, 27 Jun 2000 21:57:14 -0600 (MDT) Received: (qmail 23518 invoked from network); 28 Jun 2000 03:59:33 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 28 Jun 2000 03:59:33 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Tue, 27 Jun 2000 20:51:13 +4100 Date: Tue, 27 Jun 2000 20:51:13 -0700 From: Ben Black To: Jessica Yu Cc: Vijay Gill , Jim Bound , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000627205113.A12344@layer8.net> References: <20000627153255.2166.qmail@web3002.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000627153255.2166.qmail@web3002.mail.yahoo.com>; from jyy_99@yahoo.com on Tue, Jun 27, 2000 at 08:32:55AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jun 27, 2000 at 08:32:55AM -0700, Jessica Yu wrote: > I found it very trouble-some that you make assertions > without compelling (sometimes inaccurate) technical > arguments neither knowledge of current practice. This > is showing in the message below (see my response > inline) and the thread of discussion last year on the > same topic. > I witnessed a lot of contention, but certainly no resolution. I also saw no evidence of any inaccuracies on my assertions. Given that I am in fact a network operator quite familiar with current practice and other network operators in similar positions have been agreeing with my concerns, I don't see how you reached this conclusion. > Also, please go back and read the thread on this topic > on this list. What you pointed out about my proposal > had been either dismissed and/or answered/addressed. > It was based on that the WG decided to move forward. > Oh, it was definitely dismissed, but I would say not addressed or answered. > Inline comments below ... > > --- Ben Black wrote: > > On Mon, Jun 26, 2000 at 02:19:27PM -0700, Jessica Yu > > wrote: > > > So now, we changed topic to multihoming to two > > ISPs > > > with hole-punching, right? This is what we do > > today > > > with two issues: > > > > > > a) increase the size of the global routing table > > since > > > it can not be aggregated, and > > > > > > > This issue verges on irrelevant given current > > hardware > > (even completely ignoring improvements in hardware > > over > > time). > > Are you saying that reducing the routes in the global > routing table to improve routing scalability is > irrelevant? You are deadly wrong on this. Go ask the No, I am not saying that. What I *am* saying is that the terror of a few years ago that the routing table would grow beyond hardware limits and cause some sort of meltdown has proven quite false. Moore's law is still alive and well and giving us continuing increases in hardware capacity in excess of the increase in routing table size. Expending significant effort on *decreasing* the table size would seem counter to all trends in router development. > ISP community. Go read I-Ds including IAB's routing > workshop report on routing scalability and stability. > You may still think that memory on router is the issue > but that's not the only issue, as well known in the > operation community. > > In fact, rfc2260's main motivation is to reduce > prefixes in the global routing table. > Indeed. That's why I have been vocally supporting simply updating RFC2260 rather than introducing a new and questionable approach. > > > > > b) The longer prefixes (the hole) could be blocked > > by > > > certain providers resulting in no access to that > > part > > > of the Internet. > > > > > > > No access to certain parts of the net during > > failure. > > This would seem to be a feature superior to your > > proposal > > in that you can access parts of the net beyond > > simply > > your direct peers. > > Obviously, you do not understand this. What I am > talking about is that the second connection can not be > a backup since the longer prefix will be filtered. > Your assertion of this is better than the mechanism > described in my I-D raised the question if you > understand the proposal. > I understand that completely and that was exactly my point. Your proposal gives extremely limited benefit, if any. If we are to assume that more specific prefixes will be filtered, then the RFC2260 system offers the better alternative. > > > > > I think this mechanism works today in IPv4 and > > there > > > is no reason why can not be used for Ipv6. > > However, it > > > does not hurt to have other mechanism which allow > > > better aggregation available if there are concerns > > > about the scaling and routability issues listed > > above. > > > > > > > Agreed, and I would add that those mechanisms should > > be > > as consistent as possible with the approaches in > > IPv4 unless > > there is a compelling technical reason for a > > previously > > unused mechanism. The Itojun proposal, based on the > > > > existing RFC2260 approach, meets those requirements. > > Your > > proposal introduces a new mechanism which lacks a > > compelling > > technical case. It is for these reasons that I am > > arguing it > > not be moved further along the track. > > > > You seem to indicate that the current v4 multihoming > practice is using rfc2260. That is just simply untrue. Correct, current practice indicates little concern for table growth beyond what is convenient. What does this tell us about the amount of effort we are expending on a "solution" to this alleged problem? > The majority multihoming sites just simply advertise > one prefix. Some of those prefix are PI and some from > one of providers CIDR block with no tunnels or other > involved whatsoever. By making this assertion, it > really shows that either you do not understand what > the current practice is; or you do not understand > rfc2260 or Itojun proposal; or neither. > There is a third possibility which is that you simply are not understanding the points I have made. Judging by the comments from other operators, I would assert it is not due to a lack of clarity on my part. Let me state my points again: 1) Fears of routing table growth are greatly exaggerated. 2) Even assuming routing table growth is the horror some seem to think, proposals to address the problem should be similar to those put forth (and never used) for IPv4 and should offer definite benefits over existing approaches. 3) Your draft is not similar to any for IPv4 and, once again, does not show any benefit whatsoever over the RFC2260-based approach. 4) There has not been a scenario presented in which your approach is a clear benefit. Ben > > > > Ben > > --jessica > > > > > Speaking as a person who had worked for ISPs and > > dealt > > > with operations for many many years, I submit > > there > > > are entities who would like to have the > > arrangement as > > > described in the ID. > > > > > > Thanks! > > > > > > --Jessica > > > > > > --- Vijay Gill wrote: > > > > On Mon, 26 Jun 2000, Jessica Yu wrote: > > > > > > > > Jessica, > > > > > > > > > > > > > The tail circuits to the customer have the > > > > opportunity to go through > > > > > diverse infrastructure (e.g. fiber) which > > would > > > > increase reliability. > > > > > > > > So would they if I just went to two different > > ISP's > > > > and got them to punch > > > > a hole in their aggregate for the netblock > > assigned > > > > to me from the first > > > > ISP. [paragragh X] > > > > > > > > > Instead of going to different POPs from the > > same > > > > ISP, > > > > > the customer will be able to go to the close > > POPs > > > > of > > > > > two ISPs. Therefore, the distance for the 2nd > > tail > > > > > circuit can be shorter resulting money saving. > > > > > > > > See Paragraph X. > > > > > > > > > The customer can reach part of the Internet > > (at > > > > least > > > > > customers of ISP2) without relying on ISP1. > > > > > > > > See Paragraph X. > > > > > > > > This also buys me the additional safety of being > > > > shielded from complete > > > > failure of one of the upstream ISPs. With > > network > > > > connectivity now > > > > becoming fundamental to doing business, I submit > > > > that there isn't a single > > > > sensible company who would rely upon this draft > > > > under discussion for a > > > > critical need. Instead most of them would > > > > immediately try and go for > > > > Paragraph X. Speaking as an operator, when > > clients > > > > are throwing $n > > > > million contracts at you, there is a powerful > > > > incentive to accomodate > > > > them. > > > > > > > > /vijay > > > > > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get Yahoo! Mail - Free email you can access from > > anywhere! > > > http://mail.yahoo.com/ > > > > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 21:01:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S404R15858 for ipng-dist; Tue, 27 Jun 2000 21:00:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S3xn615848 for ; Tue, 27 Jun 2000 20:59:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA11664 for ; Tue, 27 Jun 2000 20:59:48 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA07216 for ; Tue, 27 Jun 2000 21:59:47 -0600 (MDT) Received: (qmail 23527 invoked from network); 28 Jun 2000 04:02:06 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 28 Jun 2000 04:02:06 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Tue, 27 Jun 2000 20:53:46 +4100 Date: Tue, 27 Jun 2000 20:53:46 -0700 From: Ben Black To: Jim Bound Cc: Jessica Yu , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000627205346.B12344@layer8.net> References: <20000627174650.E12321@layer8.net> <200006280333.XAA0000921779@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006280333.XAA0000921779@anw.zk3.dec.com>; from bound@zk3.dec.com on Tue, Jun 27, 2000 at 11:33:43PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is this to be a "my network operators are bigger than yours" exchange? I believe those in support of this proposal are actually obligated to respond if they wish the draft to move forward. If those in support of this proposal never speak up with the details of their support, how is this a working group at all? Ben On Tue, Jun 27, 2000 at 11:33:43PM -0400, Jim Bound wrote: > We don't have to answer to you or anyone else. Obviously people don't > care about your issue as I see no support for your proposed wall against > the aggregation draft. I think its in the decision of the chairs now. > As far as no network operators care I called two ISP network operators > today and both will pilot jessica's proposal simply to see if > implementors can make it work. They like I feel no duty to respond to > "you". Got it!!!! > > regards, > /jim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 27 21:16:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5S4E6M15886 for ipng-dist; Tue, 27 Jun 2000 21:14:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S4Dv615879 for ; Tue, 27 Jun 2000 21:13:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA23977 for ; Tue, 27 Jun 2000 21:13:56 -0700 (PDT) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA23944 for ; Tue, 27 Jun 2000 21:13:56 -0700 (PDT) Received: from ix.netcom.com (user-33qscpa.dialup.mindspring.com [199.174.51.42]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id AAA19543; Wed, 28 Jun 2000 00:06:02 -0400 (EDT) Message-ID: <39599A86.DE85F643@ix.netcom.com> Date: Tue, 27 Jun 2000 23:26:14 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Vijay Gill CC: Jim Bound , Ben Black , Jessica Yu , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vijay and all, I agree Vijay. It seems obvious that Jim Bound here seems th have a personal dispute with Ben and seems to be touting the ICANN line here. Nothing unusual there though.... Vijay Gill wrote: > On Tue, 27 Jun 2000, Jim Bound wrote: > > > We don't have to answer to you or anyone else. Obviously people don't > > care about your issue as I see no support for your proposed wall against > > the aggregation draft. I think its in the decision of the chairs now. > > Incorrect. There has bave been questions about the proposed value of this > I-D. > > > As far as no network operators care I called two ISP network operators > > today and both will pilot jessica's proposal simply to see if > > implementors can make it work. They like I feel no duty to respond to > > "you". Got it!!!! > > A better metric would probably be asking some CUSTOMERS. Speaking as a > customer, I'd just get two separate lines with two address blocks from > each provider to ensure against _autonomous system wide isp failure_, > before I'd trust an bit of data to this scheme. This is much more common > than people seem to realize, having been in midst of several on a global > scale. Including some interesting area wide failures TODAY (see thread on > nanog). > > Wearing my provider hat, I _assure_ you we can barely get standard point > to point circuits up amongst ourselves, much less co-ordinate setup of > selective routing. Special casing does not scale. > > MBONE and 6BONE are set up as special cases with engineers working on > them, but trying to get something on this scale for several thousand > customers just isn't going to work. > > /vijay > > > > > regards, > > /jim > > > > Vijay Gill |The (paying) customer is always right. > wrath@cs.umbc.edu, vijay@umbc.edu | - Piercarlo Grandi > http://umbc.edu/~vijay | Eagles may soar, but weasels don't get > These are my opinions only. | sucked into jet engines. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 112k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1800 x1894 or 9236 fwd's to home ph# Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 03:51:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SAn2b16104 for ipng-dist; Wed, 28 Jun 2000 03:49:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SAmp616097 for ; Wed, 28 Jun 2000 03:48:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA22334 for ; Wed, 28 Jun 2000 03:48:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24567 for ; Wed, 28 Jun 2000 04:48:50 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17872; Wed, 28 Jun 2000 06:48:49 -0400 (EDT) Message-Id: <200006281048.GAA17872@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt Date: Wed, 28 Jun 2000 06:48:49 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Scoped Address Architecture Author(s) : S. Deering, B. Haberman, B. Zill Filename : draft-ietf-ipngwg-scoping-arch-01.txt Pages : 12 Date : 27-Jun-00 This document specifies the architectural characteristics, expected behavior, and usage of IPv6 addresses of different scopes A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-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-scoping-arch-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-scoping-arch-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: <20000627114906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoping-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoping-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000627114906.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 Jun 28 06:16:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SDDWW16177 for ipng-dist; Wed, 28 Jun 2000 06:13:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SDDN616170 for ; Wed, 28 Jun 2000 06:13:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA26399 for ; Wed, 28 Jun 2000 06:13:23 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03363 for ; Wed, 28 Jun 2000 06:13:23 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 6EAE74094; Wed, 28 Jun 2000 09:13:22 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3EF2E420C; Wed, 28 Jun 2000 09:13:22 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000544581; Wed, 28 Jun 2000 09:13:20 -0400 (EDT) From: Jim Bound Message-Id: <200006281313.JAA0000544581@anw.zk3.dec.com> To: Vijay Gill Cc: Jim Bound , Ben Black , Jessica Yu , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Tue, 27 Jun 2000 23:46:39 EDT." Date: Wed, 28 Jun 2000 09:13:15 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> We don't have to answer to you or anyone else. Obviously people don't >> care about your issue as I see no support for your proposed wall against >> the aggregation draft. I think its in the decision of the chairs now. > >Incorrect. There has bave been questions about the proposed value of this >I-D. No it is correct. True the "Chairs" and authors have to respond and I should have made that distinction, I or other WG members do NOT HAVE to respond to you or anyone else. Again Got It!!!! regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 06:22:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SDKYU16211 for ipng-dist; Wed, 28 Jun 2000 06:20:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SDKP616204 for ; Wed, 28 Jun 2000 06:20:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA22852 for ; Wed, 28 Jun 2000 06:20:25 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07452 for ; Wed, 28 Jun 2000 06:20:20 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id ECE0D975; Wed, 28 Jun 2000 09:20:19 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 88B1BB3F; Wed, 28 Jun 2000 09:20:18 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000545168; Wed, 28 Jun 2000 09:20:18 -0400 (EDT) From: Jim Bound Message-Id: <200006281320.JAA0000545168@anw.zk3.dec.com> To: Ben Black Cc: Jim Bound , Jessica Yu , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Tue, 27 Jun 2000 20:53:46 PDT." <20000627205346.B12344@layer8.net> Date: Wed, 28 Jun 2000 09:20:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Don't blame the working group blame me. I have heard your arguments and I have heard Jessica's responses. There is nothing to add. I think Jessica's proposal should be moved forward and be left to the market to make determination if it is useful. If rfc2260 can be informational so can this. Its that simple. But my point is I don't "have" to respond to you but CAN TELL the chairs I support this being moved forward. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 06:25:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SDNfE16234 for ipng-dist; Wed, 28 Jun 2000 06:23:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SDNW616227 for ; Wed, 28 Jun 2000 06:23:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA16541 for ; Wed, 28 Jun 2000 06:23:33 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01454 for ; Wed, 28 Jun 2000 07:23:32 -0600 (MDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 930D44A1; Wed, 28 Jun 2000 08:23:31 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id B18DB5C4; Wed, 28 Jun 2000 08:23:30 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000545818; Wed, 28 Jun 2000 09:23:29 -0400 (EDT) From: Jim Bound Message-Id: <200006281323.JAA0000545818@anw.zk3.dec.com> To: Jeff Williams Cc: Vijay Gill , Jim Bound , Ben Black , Jessica Yu , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-reply-to: Your message of "Tue, 27 Jun 2000 23:26:14 PDT." <39599A86.DE85F643@ix.netcom.com> Date: Wed, 28 Jun 2000 09:23:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am touting nothing about ICANN and have no personal issues with anyone or Ben. Do not make another assumption about me again on a public mail list or I will have one of my family attorneys call you, as you are in the U.S. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 06:50:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SDm2K16265 for ipng-dist; Wed, 28 Jun 2000 06:48:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SDlr616258; Wed, 28 Jun 2000 06:47:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA25885; Wed, 28 Jun 2000 06:47:53 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17346; Wed, 28 Jun 2000 07:47:53 -0600 (MDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 945E9436A; Wed, 28 Jun 2000 09:47:52 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3DF9441C5; Wed, 28 Jun 2000 09:47:52 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000548831; Wed, 28 Jun 2000 09:47:51 -0400 (EDT) From: Jim Bound Message-Id: <200006281347.JAA0000548831@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Cc: Reinhard.Scholl@etsi.fr, whl@unh.edu, bound@zk3.dec.com Subject: IPv6 Bake-Off and Testing at ETSI Date: Wed, 28 Jun 2000 09:47:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IPv6-ers, Sorry for the Interrupt. Please only respond to Reinhard Scholl, Bill Lenharth (both in cc list) and me and not the Working Group mail lists if you have input per the questions below. Please find below the invitation to an IPv6 Bake-off on ETSI premises. regards and thanks, /jim == Invitation == GOAL: test IPv6 and IPv6-related protocols, with feedback to the IETF, the IPv6 Forum, and 3GPP (3rd generation mobile). DATE: 2-6 October 2000 LOCATION: ETSI in Sophia Antipolis, France, located between Nice and Cannes in the French Silicon Valley. PARTICIPATION: Only engineers with implementations to test are invited to participate. This is neither a marketing event nor a conference. REGISTRATION: A web site for registration is under construction and will be online shortly. PROTOCOLS TO BE TESTED: - - IPv6 core protocols (base, neighbor discovery, stateless address configuration, path MTU discovery, basic transition mechanisms) - - Mobile IPv6 - - BGP4+ - - RIPng We'd also like to get your feedback if other protocols are ready to be tested (checkboxes on the website). Depending on the number of those implementations we will decide whether to include them as well in the event: - - IPv6 extended protocols (RSVP for v6, DHCPv6, translation mechanisms with v6, dual stack transition mechanisms) - - IPSec v6 - - PPPv6 - - diffserv v6 - - OSPF v6 - - IPv6 MIBs - - DIAMETER SERVICES OFFERED: * Conformance Testing: - - The University of New Hampshire has an extensive set of conformance test suites for IPv6 and mobile IPv6 (www.iol.unh.edu/testsuites/iprouting/index.html). Staff of UNH will be on site and run your implementations through their test suites. - - Ericsson has conformance test suites for IPv6 and mobile IPv6, written in TTCN, a formal testing language. Participants have a chance to have their implementations checked against those test suites as well and learn about TTCN. * "One-on-one" Interoperability Testing: Participants test against each other under controlled network conditions. PARTICIPATION FEE: There will be a participation fee of 800 Euros/company and 500 Euros/participant. Universities can participate for free. We are actively looking for sponsors. mailto:Reinhard.Scholl@etsi.fr ETSI Bake-off Service -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 07:10:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SE8ij16342 for ipng-dist; Wed, 28 Jun 2000 07:08:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SE8Z616335 for ; Wed, 28 Jun 2000 07:08:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA09553 for ; Wed, 28 Jun 2000 07:08:35 -0700 (PDT) Received: from web3004.mail.yahoo.com (web3004.mail.yahoo.com [204.71.202.167]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA05522 for ; Wed, 28 Jun 2000 07:08:35 -0700 (PDT) Received: (qmail 20477 invoked by uid 60001); 28 Jun 2000 14:08:34 -0000 Message-ID: <20000628140834.20476.qmail@web3004.mail.yahoo.com> Received: from [141.212.130.253] by web3004.mail.yahoo.com; Wed, 28 Jun 2000 07:08:34 PDT Date: Wed, 28 Jun 2000 07:08:34 -0700 (PDT) From: Jessica Yu Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" To: Ben Black , Jim Bound Cc: Jessica Yu , Vijay Gill , hinden@iprg.nokia.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 This has already been answered in the thread of discussion on this topic a while back. Please go back to read the thread before you make any more inaccurate and irresponsible assertions. You said most network operators see no value. Where did you get this? Who are the most operators? Please be more responsible when you make assertions. --Jessica --- Ben Black wrote: > In all seriousness, would someone please explain the > benefits of > this approach in comparison tot he RFC2260 approach? > > I have *never* seen a single example and judging by > the feedback > the draft has gotten, most network operators see no > value to it > whatsoever. That alone should be a strong > indication the proposal > should be closely scrutinized before acceptance for > any further > circulation. > > Simply voting to have a draft moved to RFC without > answering > numerous, legitimate questions regarding its value > would seem a > very poor method for developing quality technical > documents. > > > Ben > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, Jim Bound > wrote: > > Jessica, > > > > Your work should go thru as info RFC I see no > reason at all to defend > > your draft any further for that goal. You have > done a good job to give > > us a means to work with our ISP customers with > IPv6 to set up some > > pilots with IPv6 using BGP+w/v6 to begin testing > this and I also will be > > proposing that 3GPP look at your proposal very > seriously for IMT2000. > > > > Chairs - again there is no compelling reason past > or present to prevent > > this work from moving to info rfc and begin using > it as a tool for the > > many IPv6 pilots springing up with our customers. > > > > I am not saying the discussion is 100% complete > and I don't think it > > ever will be as we evolve IPv6, but I do think the > decision has been > > made, and we should move on here. > > > > regards, > > /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 > -------------------------------------------------------------------- __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 07:15:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SEDhH16368 for ipng-dist; Wed, 28 Jun 2000 07:13:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SEDY616361 for ; Wed, 28 Jun 2000 07:13:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA08971 for ; Wed, 28 Jun 2000 07:13:35 -0700 (PDT) Received: from web3004.mail.yahoo.com (web3004.mail.yahoo.com [204.71.202.167]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA04332 for ; Wed, 28 Jun 2000 08:13:34 -0600 (MDT) Received: (qmail 21105 invoked by uid 60001); 28 Jun 2000 14:13:33 -0000 Message-ID: <20000628141333.21104.qmail@web3004.mail.yahoo.com> Received: from [141.212.130.253] by web3004.mail.yahoo.com; Wed, 28 Jun 2000 07:13:33 PDT Date: Wed, 28 Jun 2000 07:13:33 -0700 (PDT) From: Jessica Yu Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" To: Ben Black , Jim Bound Cc: Jessica Yu , Vijay Gill , hinden@iprg.nokia.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 By the way, unless there are technical arguments and credible facts in your responses, I am not going to send more messages. --Jessica --- Jessica Yu wrote: > > This has already been answered in the thread of > discussion on this topic a while back. Please go > back > to read the thread before you make any more > inaccurate > and irresponsible assertions. > > You said most network operators see no value. Where > did you get this? Who are the most operators? Please > be more responsible when you make assertions. > > > --Jessica > > --- Ben Black wrote: > > In all seriousness, would someone please explain > the > > benefits of > > this approach in comparison tot he RFC2260 > approach? > > > > I have *never* seen a single example and judging > by > > the feedback > > the draft has gotten, most network operators see > no > > value to it > > whatsoever. That alone should be a strong > > indication the proposal > > should be closely scrutinized before acceptance > for > > any further > > circulation. > > > > Simply voting to have a draft moved to RFC without > > answering > > numerous, legitimate questions regarding its value > > would seem a > > very poor method for developing quality technical > > documents. > > > > > > Ben > > > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, Jim > Bound > > wrote: > > > Jessica, > > > > > > Your work should go thru as info RFC I see no > > reason at all to defend > > > your draft any further for that goal. You have > > done a good job to give > > > us a means to work with our ISP customers with > > IPv6 to set up some > > > pilots with IPv6 using BGP+w/v6 to begin testing > > this and I also will be > > > proposing that 3GPP look at your proposal very > > seriously for IMT2000. > > > > > > Chairs - again there is no compelling reason > past > > or present to prevent > > > this work from moving to info rfc and begin > using > > it as a tool for the > > > many IPv6 pilots springing up with our > customers. > > > > > > I am not saying the discussion is 100% complete > > and I don't think it > > > ever will be as we evolve IPv6, but I do think > the > > decision has been > > > made, and we should move on here. > > > > > > regards, > > > /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 > > > -------------------------------------------------------------------- > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from > anywhere! > http://mail.yahoo.com/ __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 07:52:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SEnxk16497 for ipng-dist; Wed, 28 Jun 2000 07:49:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SEno616490 for ; Wed, 28 Jun 2000 07:49:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA26843 for ; Wed, 28 Jun 2000 07:49:51 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01820 for ; Wed, 28 Jun 2000 07:49:46 -0700 (PDT) Received: from localhost (shuttle.wide.toshiba.co.jp [202.249.10.124]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA23653; Wed, 28 Jun 2000 23:37:18 +0900 (JST) Date: Wed, 28 Jun 2000 23:10:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com Subject: RE: sin6_flowinfo and sendto/recvfrom In-Reply-To: In your message of "Wed, 21 Jun 2000 17:13:48 -0700 (PDT)" <200006220013.RAA02649@feller.mentat.com> References: <200006220013.RAA02649@feller.mentat.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 21 Jun 2000 17:13:48 -0700 (PDT), >>>>> Tim Hartrick said: >> My assumption was that recvfrom() and accept() should return sin6_flowinfo >> from the received packet, and connect() and sendto() should take >> sin6_flowinfo and put it into sent packets. >> >> For bind(), I'd say either error if sin6_flowinfo is non-zero, or ignore >> sin6_flowinfo. > Not surprisingly this is the exact opposite of what I thought.:-) Since > the flow ID is source oriented it seems to make the most sense to me to > specify it on the bind() call and return it in calls which return a source > address (recvfrom, recvmsg, accept). It should be silently ignored on > connect, sendto and sendmsg. It's true that flow IDs are source oriented, but if sin6_scope_id is ignored in (e.g.) connect(), how can we call connect() without binding beforehand and with specifying the flow ID? (I'm not sure which is the best way to specify flow IDs for outgoing packets, or even whether such an API is necessary at all. It's just a question from curiosity) > Needless to say it needs to be written down. Agreed. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 09:01:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SFxPu16542 for ipng-dist; Wed, 28 Jun 2000 08:59:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SFxG616535 for ; Wed, 28 Jun 2000 08:59:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA09115 for ; Wed, 28 Jun 2000 08:59:17 -0700 (PDT) Received: from gwsmtp.thomson-csf.com (gwsmtp.thomson-csf.com [195.101.39.226]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24073 for ; Wed, 28 Jun 2000 09:59:14 -0600 (MDT) Received: from thomplex.thomson-csf.com (200.3.2.2) by gwsmtp.thomson-csf.com (NPlex 5.0.034) id 392D5A93001A6B31 for ipng@sunroof.eng.sun.com; Wed, 28 Jun 2000 17:55:00 +0200 Received: from thomplex.thomson-csf.com (200.3.2.2) by thomplex.thomson-csf.com (NPlex 5.0.046) id 3959CF4B00009C2D for ipng@sunroof.eng.sun.com; Wed, 28 Jun 2000 17:53:27 +0200 Received: from 194.151.12.2 by thomplex.thomson-csf.com (InterScan E-Mail VirusWall NT); Wed, 28 Jun 2000 17:53:27 +0200 (Paris, Madrid (heure d'été)) X-Internal-ID: 394897A900020CB9 Received: from mes1.ela.detexis.thomson-csf.com (61.14.31.2) by dexplex.detexis.thomson-csf.com (NPlex 2.0.124) for ipng@sunroof.eng.sun.com; Wed, 28 Jun 2000 17:58:48 +0200 X-Internal-ID: 38D1314300062509 Received: from mes1.ela.detexis.thomson-csf.com (61.14.31.2) by mes1.ela.detexis.thomson-csf.com (NPlex 2.0.124); Wed, 28 Jun 2000 17:54:35 +0200 Received: from 61.25.85.136 by mes1.ela.detexis.thomson-csf.com (InterScan E-Mail VirusWall NT); Wed, 28 Jun 2000 17:54:35 +0200 (Paris, Madrid (heure d'été)) Message-ID: <395A204E.BC033329@detexis.thomson-csf.com> Date: Wed, 28 Jun 2000 17:57:02 +0200 From: Alain RITOUX Organization: Thomson-CSF DETEXIS X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: Erik.Nordmark@eng.sun.com, deering@cisco.com CC: ipng@sunroof.eng.sun.com Subject: scoped-arch comments Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e5SFxH616536 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have some comments about the scoped @ arch, about the scope_id. - I definitly agree with E. Nordmark about storing all space names in a single 32 bit box! This could be done using a quartet with same signification as for multicast. Scope id could look like something as 0x 00 0S zone_id with 16 bits for zone id, and S being set to 2 for link-id, 5 for site-id ... zone_id might be set to nul to let the default zone ot be taken. hence 0x00020000 being the default link. - If we want to use litteral form of zone_id (assuming uniquiness of names among all zone id of all scopes), conversion fct should be provided in the API, such as scop2name and name2scope. if we want to have links with multiple interface, link_scope_id should not be obtained from an if_nametoindex. - About using scope_id with a smaller scope than the @ : isn't it in sometimes dangerous ? I mean the @ are unique in à zone, what if the sub-zone provided isn't the good one ? for example a station with two links (l#1 and l#2) belonging to the same site (s#1). The destination is on link#1 and the application choses l#2 as scope_id because of its source @!!! Best regards. Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 10:06:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SH4lY16664 for ipng-dist; Wed, 28 Jun 2000 10:04:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SH4a616657 for ; Wed, 28 Jun 2000 10:04:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA16101 for ; Wed, 28 Jun 2000 10:04:36 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA07291 for ; Wed, 28 Jun 2000 10:04:32 -0700 (PDT) Received: (qmail 23976 invoked from network); 28 Jun 2000 17:06:50 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 28 Jun 2000 17:06:50 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Wed, 28 Jun 2000 09:58:27 -0700 Date: Wed, 28 Jun 2000 09:58:27 -0700 From: Ben Black To: Jessica Yu Cc: Jim Bound , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000628095827.F12344@layer8.net> References: <20000628141333.21104.qmail@web3004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000628141333.21104.qmail@web3004.mail.yahoo.com>; from jyy_99@yahoo.com on Wed, Jun 28, 2000 at 07:13:33AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, here are detailed technical arguments which have not been addressed: >From Section 4 (Concerns): - The primary ISP is the sole interface for the multihomed customer to the Internet other than the ISPs the customer has directly connection with. Outages such as one between ISP-1 and ISP-4 would impact the reachability from customers of ISP-4 to Customer-A even though ISP-2 still has good connection to ISP-4. However, if the primary ISP is a good quality ISP, this sort of situation should happen rarely. The reason is that it's common practice that an ISP, especially good quality ISP, has multiple connections to other big ISPs at different geographical locations. Good quality ISPs also have robust network design to prevent any failure to impact the whole network. Choosing a good quality and robust ISP as primary ISP is a good practice. This is really the crux of the problem with the solution put forth in the document. The assumption that a given ISP will never have failures, or that rare failures are acceptable to customers who multihomed for redundancy, is simply not valid from an engineering perspective. If the primary goal of multihoming were load sharing, this solution would provide one, potentially very complicated, answer. However, the issue of multihoming for redundancy is totally ignored, drawing into question the need for a second ISP in the equation at all. Why not simply purchase additional bandwidth from the same ISP? >From Section 4 (Concerns): It is desirable to have solution which provides perfect redundancy and, at the same time, simplicity to scale management and operation. In the absence of a perfect solution, the trade-off needs to be made. The author believes that it is very important that the solution has to be simple and manageable. Manageability should be the top consideration. If managability of the solution is to be the top consideration, the response put forward does not measure up. In the name of avoiding routing table growth the author has suggested adding significant complexity to the configuration and management of multihomed customers without showing any benefit for the effort. An area not addressed at all in the document is that of multihoming for access to networks attached to a given ISP, rather than access to that ISP. For example, using the diagram above, if Customer-A purchased connectivity to ISP-2 because ISP-2 had better connectivity to ISP-4, then the offered multihoming solution is of no use. ISP-4 will never see reachability to Customer-A via ISP-2. Now, if everyone is done threatening legal action, perhaps we could return to the business of network engineering. Ben On Wed, Jun 28, 2000 at 07:13:33AM -0700, Jessica Yu wrote: > By the way, unless there are technical arguments and > credible facts in your responses, I am not going to > send more messages. > > --Jessica > > --- Jessica Yu wrote: > > > > This has already been answered in the thread of > > discussion on this topic a while back. Please go > > back > > to read the thread before you make any more > > inaccurate > > and irresponsible assertions. > > > > You said most network operators see no value. Where > > did you get this? Who are the most operators? Please > > be more responsible when you make assertions. > > > > > > --Jessica > > > > --- Ben Black wrote: > > > In all seriousness, would someone please explain > > the > > > benefits of > > > this approach in comparison tot he RFC2260 > > approach? > > > > > > I have *never* seen a single example and judging > > by > > > the feedback > > > the draft has gotten, most network operators see > > no > > > value to it > > > whatsoever. That alone should be a strong > > > indication the proposal > > > should be closely scrutinized before acceptance > > for > > > any further > > > circulation. > > > > > > Simply voting to have a draft moved to RFC without > > > answering > > > numerous, legitimate questions regarding its value > > > would seem a > > > very poor method for developing quality technical > > > documents. > > > > > > > > > Ben > > > > > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, Jim > > Bound > > > wrote: > > > > Jessica, > > > > > > > > Your work should go thru as info RFC I see no > > > reason at all to defend > > > > your draft any further for that goal. You have > > > done a good job to give > > > > us a means to work with our ISP customers with > > > IPv6 to set up some > > > > pilots with IPv6 using BGP+w/v6 to begin testing > > > this and I also will be > > > > proposing that 3GPP look at your proposal very > > > seriously for IMT2000. > > > > > > > > Chairs - again there is no compelling reason > > past > > > or present to prevent > > > > this work from moving to info rfc and begin > > using > > > it as a tool for the > > > > many IPv6 pilots springing up with our > > customers. > > > > > > > > I am not saying the discussion is 100% complete > > > and I don't think it > > > > ever will be as we evolve IPv6, but I do think > > the > > > decision has been > > > > made, and we should move on here. > > > > > > > > regards, > > > > /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 > > > > > > -------------------------------------------------------------------- > > > > > > __________________________________________________ > > Do You Yahoo!? > > Get Yahoo! Mail - Free email you can access from > > anywhere! > > http://mail.yahoo.com/ > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 10:14:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SHCOj16693 for ipng-dist; Wed, 28 Jun 2000 10:12:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SHCD616686 for ; Wed, 28 Jun 2000 10:12:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA07263 for ; Wed, 28 Jun 2000 10:12:13 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12943 for ; Wed, 28 Jun 2000 10:12:13 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA11629; Wed, 28 Jun 2000 10:11:18 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA17405; Wed, 28 Jun 2000 10:11:16 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA09432; Wed, 28 Jun 2000 10:15:08 -0700 (PDT) Date: Wed, 28 Jun 2000 10:15:08 -0700 (PDT) From: Tim Hartrick Message-Id: <200006281715.KAA09432@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp Subject: RE: sin6_flowinfo and sendto/recvfrom Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > It's true that flow IDs are source oriented, but if sin6_scope_id is > ignored in (e.g.) connect(), how can we call connect() without binding > beforehand and with specifying the flow ID? > I assume you intended to say sin6_flowinfo above. The answer is, you couldn't. If you wanted to use a flow ID you would need to assign it to the socket before connecting. To me this makes perfect sense since it is analogous to binding to a specific port or letting the stack choose the local port for the you. If you want a specific port or flow ID you must bind. If you don't care what value is chosen then don't bind. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 10:27:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SHNeQ16713 for ipng-dist; Wed, 28 Jun 2000 10:23:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SHNU616706 for ; Wed, 28 Jun 2000 10:23:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA29571 for ; Wed, 28 Jun 2000 10:23:29 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20588 for ; Wed, 28 Jun 2000 10:23:23 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA24081; Thu, 29 Jun 2000 02:10:52 +0900 (JST) Date: Thu, 29 Jun 2000 02:19:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: ipng@sunroof.eng.sun.com Subject: RE: sin6_flowinfo and sendto/recvfrom In-Reply-To: In your message of "Wed, 28 Jun 2000 10:15:08 -0700 (PDT)" <200006281715.KAA09432@feller.mentat.com> References: <200006281715.KAA09432@feller.mentat.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 28 Jun 2000 10:15:08 -0700 (PDT), >>>>> Tim Hartrick said: >> It's true that flow IDs are source oriented, but if sin6_scope_id is >> ignored in (e.g.) connect(), how can we call connect() without binding >> beforehand and with specifying the flow ID? > I assume you intended to say sin6_flowinfo above. Oops, that's right. I've made this type of mistakes several times...sorry. > The answer is, you couldn't. If you wanted to use a flow ID you would > need to assign it to the socket before connecting. To me this makes > perfect sense since it is analogous to binding to a specific port or > letting the stack choose the local port for the you. Hmm, I see. Thanks for the clarification. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 10:46:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SHiCI16747 for ipng-dist; Wed, 28 Jun 2000 10:44:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SHi4616740 for ; Wed, 28 Jun 2000 10:44:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA15418 for ; Wed, 28 Jun 2000 10:44:03 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05323 for ; Wed, 28 Jun 2000 10:44:02 -0700 (PDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 798125D4; Wed, 28 Jun 2000 12:43:59 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 346F1693 for ; Wed, 28 Jun 2000 12:43:59 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0000583107; Wed, 28 Jun 2000 13:43:58 -0400 (EDT) From: Jim Bound Message-Id: <200006281743.NAA0000583107@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: draft-ipngwg-scoping-arch-01.txt In-reply-to: Your message of "Tue, 27 Jun 2000 16:43:52 EDT." <200006272043.QAA0000878009@anw.zk3.dec.com> Date: Wed, 28 Jun 2000 13:43:58 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, I withdraw my thoughts on having to embedd uniqueness in the sitelocal addresses. After reviewing this draft I can only come up with limited cases where the app servers I mentioned cannot be made to work using the work in draft-ipngwg-scoping-arch-01.txt. I think each implementor can figure it out as I have so I won't go into the details (or I don't think I should to be accurate), but the Basic API sin6_scope_id will resolve the multisited database problems. The one area that does seem to make it problematic in the spec is: Just before section 10 Routing: Addresses of a given (non-global) scope may be re-used in different zones of that scope. The zone to which a particular non-global address pertains is not encoded in the address itself, but rather is determined by context, such as the interface from which it is sent Routing Header with more than zero Segments Left [RFC 2460, section 4.4] swaps the original destination address with the next address in the Routing Header. Then the above forwarding rules are applied, using the new destination address. An implementation MUST NOT examine additional addresses in the Routing header to determine whether they are crossing boundaries for their scopes. Thus, it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary. I believe this is very inadvisable. The other option is for customers that really want to use multisited servers is to use global addresses, which will not be a scarce resource in IPv6. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 10:55:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SHrho16793 for ipng-dist; Wed, 28 Jun 2000 10:53:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SHrX616786 for ; Wed, 28 Jun 2000 10:53:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA07945 for ; Wed, 28 Jun 2000 10:53:33 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27584 for ; Wed, 28 Jun 2000 11:53:30 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA25702; Wed, 28 Jun 2000 10:53:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA21784; Wed, 28 Jun 2000 10:53:22 -0700 X-Virus-Scanned: Wed, 28 Jun 2000 10:53:22 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma019872; Wed, 28 Jun 00 10:52:35 -0700 Message-Id: <4.3.2.7.2.20000628103133.02481960@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Jun 2000 10:50:30 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Multi-Link Subnet support in IPv6 In-Reply-To: <3958D41D.41DF7CEB@iprg.nokia.com> References: <200006271447.KAA0000020601@yquarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [was Re: Global Prefixes in IPv6] IPv6 includes some elements of support for multi-link subnets (i.e., a subnet that spans multiple independent links] but, like IPv4, does not currently specify a complete solution for multi-link subnet support. I do not believe that adding multi-link subnet support to IPv6 is an important topic for the IPng working group. We have a number of more important topics on our plate (e.g., completing multihoming support, scoped address architecture, etc.) that have higher priority. There are other approaches to this (e.g., level 2 bridge/switches, mobile IPv6, etc.) and we shouldn't have any shortage of addresses to assign subnet prefixes to individual links. I also do not think that the lack of multi-link subnet support in other IETF protocols (e.g., DHCPv6) should hold up progress on those protocols. 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 Jun 28 11:05:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SI3Ae16840 for ipng-dist; Wed, 28 Jun 2000 11:03:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SI31616833 for ; Wed, 28 Jun 2000 11:03:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA20707 for ; Wed, 28 Jun 2000 11:03:00 -0700 (PDT) Received: from mx2out.umbc.edu (mx2out.umbc.edu [130.85.253.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18368 for ; Wed, 28 Jun 2000 11:02:58 -0700 (PDT) Received: from gl.umbc.edu (vijay@umbc8.umbc.edu [130.85.60.8]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id OAA00764; Wed, 28 Jun 2000 14:02:55 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id OAA10128962; Wed, 28 Jun 2000 14:02:53 -0400 (EDT) X-Authentication-Warning: umbc8.umbc.edu: vijay owned process doing -bs Date: Wed, 28 Jun 2000 14:02:52 -0400 From: Vijay Gill To: Jim Bound cc: Ben Black , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-Reply-To: <200006281313.JAA0000544581@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 28 Jun 2000, Jim Bound wrote: > No it is correct. True the "Chairs" and authors have to respond and > I should have made that distinction, I or other WG members do NOT HAVE to > respond to you or anyone else. Again Got It!!!! Relax Jim. Don't take it so personally. /vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 11:40:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SIbsO17015 for ipng-dist; Wed, 28 Jun 2000 11:37:54 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SIbn617008 for ; Wed, 28 Jun 2000 11:37:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA20935 for ipng@sunroof.eng.sun.com; Wed, 28 Jun 2000 11:36:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5S8O8616021 for ; Wed, 28 Jun 2000 01:24:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA09481 for ; Wed, 28 Jun 2000 01:24:07 -0700 (PDT) Received: from mailhostnew.tbit.dk (mailhostnew.tbit.dk [194.182.135.150]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14675 for ; Wed, 28 Jun 2000 01:24:06 -0700 (PDT) Received: from mhr.tbit.dk (mhr.tbit.dk [194.182.135.76]) by mailhostnew.tbit.dk (8.9.3+Sun/8.9.3) with ESMTP id KAA08783; Wed, 28 Jun 2000 10:23:51 +0200 (MET DST) Received: (from mhr@localhost) by mhr.tbit.dk (8.9.3/8.9.3) id KAA07525; Wed, 28 Jun 2000 10:23:49 +0200 To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: Re: Stateless autoconf and dial-on-demand References: <200006261943.OAA24273@gungnir.fnal.gov> From: Morten Heiberg Rasmussen Date: 28 Jun 2000 10:23:48 +0200 In-Reply-To: "Matt Crawford"'s message of "Mon, 26 Jun 2000 14:43:21 -0500" Message-ID: Lines: 37 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: > If your dialup router is in command of the whole process, what > happens if it holds the first outbound packet for a while, then > advertises the new global prefix, *then* sends the initiator an ICMP > "beyond scope of source address"? Will the initiator's stack then > retry with the new global-scope address? Matt, I guess what we are worried about is the source address selection in the host implementations on the network. If a host needs to send a packet to a global scope destination address and only has a link local address to supply as the source, are we guaranteed that the packet will be put on the wire in the first place? It not, the dialup router will never know that a host wants to open the connection. If the packet _is_ sent with a link local source address at first I believe the initiator will have to retry with the new global-scope address when the ICMP message is sent. Provided, of course, that any duplicate address detection algorithms have completed and so on. A dumb question: Where is the "beyond scope of source address" ICMPv6 message defined? I see it mentioned in RFC2765 (SIIT) as "host unreachable, code 2", but the location of the definition eludes me. Thanks! /Morten -- Morten Heiberg Rasmussen System Developer, M. Sc. Ericsson Telebit A/S Tel: +45 86 28 81 76 Fabrikvej 11 Fax: +45 86 28 81 86 DK-8260 Viby J, Denmark E-mail: mhr@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 Wed Jun 28 12:01:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SIwik17079 for ipng-dist; Wed, 28 Jun 2000 11:58:44 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SIwe617072 for ; Wed, 28 Jun 2000 11:58:40 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA21007 for ipng@sunroof.eng.sun.com; Wed, 28 Jun 2000 11:57:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SHZb616727 for ; Wed, 28 Jun 2000 10:35:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA20780 for ; Wed, 28 Jun 2000 10:35:36 -0700 (PDT) Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12943 for ; Wed, 28 Jun 2000 11:35:32 -0600 (MDT) Received: from raspberry.epilogue.com ([128.224.132.107]:64772 "EHLO kenawang" ident: "IDENT-NOT-QUERIED [port 64772]") by newquern.epilogue.com with ESMTP id <240-176>; Wed, 28 Jun 2000 13:35:21 -0400 Message-Id: <4.2.2.20000628125350.01bd86e0@pop.epilogue.com> X-Sender: mrfpop@pop.epilogue.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt In-Reply-To: <200006281048.GAA17872@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Jun 2000 13:35:21 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have comments/questions on the scoping architecture draft. First, I'd like to compliment the authors on writing such a straightforward explanation of a complex topic. > Each interface belongs to one node-local zone, one link-local zone, > one site-local zone, and the global zone. Each link belongs to one > link-local zone, one site-local zone, and the global zone. An > interface or link only belongs to additional (i.e., multicast) zones > if it falls within the configured boundaries of such additional > zones. Is this a (relatively) new restriction? I know that, in the past, we had discussed the concept of overlapping sites. Does this draft intentionally invalidate the possibility of overlapping sites (where a single interface could be in more than one site)? > Thus, the upper layer requires the > ability, when sending a packet, to specify any zone of scope less > than or equal to the scope of the destination address, including the > case in which the destination address is of global scope. For this > reason, an implementation might find it useful to assign a distinct > value for each zone index, so that they are unique across all zones, > regardless of scope. Why not require a unique value in the architecture? I'm also interested to know if anyone has considered the implications of this specification on routing table management... If I understand correctly, this specification adds a "key" (the outbound zone ID) that is used for routing table lookups on both hosts and routers (conceptually, to choose between routing tables). The zone ID may identify a single interface or a group of interfaces. The IPv6 routing table MIB should probably be updated to include this new field. If I understand correctly, this specification also requires that all zone-boundary routers maintain information in each learned route entry to indicate the zone in which the information was learned. Should this also be reflected in a MIB? I also have a question regarding zone-boundary routers... Is there a distinction between zone-boundary and non-zone-boundary routers? Or can any router that is attached to more than one link dynamically become a zone boundary router due to reconfiguration or topology changes? If the latter, then all routers should maintain zone information associated with their learned routes, in case they become a zone- boundary router later on. Right? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 12:59:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SJuaJ17161 for ipng-dist; Wed, 28 Jun 2000 12:56:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SJuR617154 for ; Wed, 28 Jun 2000 12:56:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA09808 for ; Wed, 28 Jun 2000 12:56:26 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07112 for ; Wed, 28 Jun 2000 12:56:25 -0700 (PDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Wed, 28 Jun 2000 14:20:19 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NX0RQQ19; Wed, 28 Jun 2000 15:21:59 -0400 Received: from nortelnetworks.com (clemson.corpeast.baynetworks.com [132.245.252.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LSZ6RKA5; Wed, 28 Jun 2000 15:21:52 -0400 Message-ID: <395A4F61.74622A3F@nortelnetworks.com> Date: Wed, 28 Jun 2000 15:17:53 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt References: <4.2.2.20000628125350.01bd86e0@pop.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, I will take a crack at answering these questions. See below. Margaret Wasserman wrote: > > > Each interface belongs to one node-local zone, one link-local zone, > > one site-local zone, and the global zone. Each link belongs to one > > link-local zone, one site-local zone, and the global zone. An > > interface or link only belongs to additional (i.e., multicast) zones > > if it falls within the configured boundaries of such additional > > zones. > > Is this a (relatively) new restriction? I know that, in the past, > we had discussed the concept of overlapping sites. Does this draft > intentionally invalidate the possibility of overlapping sites (where > a single interface could be in more than one site)? It is not THAT new. The problem with overlapping sites is that there is no way to determine which site the address belongs to. Part of the past confusion was that all these definitions had been talked about, but never documented together. > > > Thus, the upper layer requires the > > ability, when sending a packet, to specify any zone of scope less > > than or equal to the scope of the destination address, including the > > case in which the destination address is of global scope. For this > > reason, an implementation might find it useful to assign a distinct > > value for each zone index, so that they are unique across all zones, > > regardless of scope. > > Why not require a unique value in the architecture? > > I'm also interested to know if anyone has considered the implications > of this specification on routing table management... Well, actually I have. Part of this draft is from my routing of scoped addresses draft I wrote a year ago. The idea is that each zone has a routing table. The tables are differentiated by the zone ids. We called it a conceptual table in the draft so that people could implement the function as they see fit. > > If I understand correctly, this specification adds a "key" (the > outbound zone ID) that is used for routing table lookups on both > hosts and routers (conceptually, to choose between routing tables). > The zone ID may identify a single interface or a group of interfaces. That is correct. > > The IPv6 routing table MIB should probably be updated to include this > new field. Good point. > > If I understand correctly, this specification also requires that all > zone-boundary routers maintain information in each learned route entry > to indicate the zone in which the information was learned. Yes. > > Should this also be reflected in a MIB? Yes. > > I also have a question regarding zone-boundary routers... Is there > a distinction between zone-boundary and non-zone-boundary routers? > Or can any router that is attached to more than one link dynamically > become a zone boundary router due to reconfiguration or topology > changes? Yes, a router could move between those two "states". > > If the latter, then all routers should maintain zone information > associated with their learned routes, in case they become a zone- > boundary router later on. Right? Yes. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 13:07:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SK4Nl17185 for ipng-dist; Wed, 28 Jun 2000 13:04:23 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SK4I617178 for ; Wed, 28 Jun 2000 13:04:19 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA21053 for ipng@sunroof.eng.sun.com; Wed, 28 Jun 2000 13:03:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SJT1617130 for ; Wed, 28 Jun 2000 12:29:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03218 for ; Wed, 28 Jun 2000 12:29:01 -0700 (PDT) Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16282 for ; Wed, 28 Jun 2000 13:28:58 -0600 (MDT) Received: from raspberry.epilogue.com ([128.224.132.107]:21765 "EHLO kenawang" ident: "IDENT-NOT-QUERIED [port 21765]") by newquern.epilogue.com with ESMTP id <240-176>; Wed, 28 Jun 2000 15:28:28 -0400 Message-Id: <4.2.2.20000628152657.01d4da40@pop.epilogue.com> X-Sender: mrfpop@pop.epilogue.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Morten Heiberg Rasmussen From: Margaret Wasserman Subject: Re: Stateless autoconf and dial-on-demand Cc: Matt Crawford , ipng@sunroof.eng.sun.com In-Reply-To: References: <"Matt Crawford"'s message of "Mon, 26 Jun 2000 14:43:21 -0500"> <200006261943.OAA24273@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Jun 2000 15:28:28 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Matt, >Matt Crawford writes: > >If your dialup router is in command of the whole process, what >happens if it holds the first outbound packet for a while, then >advertises the new global prefix, *then* sends the initiator an ICMP >"beyond scope of source address"? Will the initiator's stack then >retry with the new global-scope address? I don't think that this would work well for many application and/or transport layer protocols. Once the remote host has been identified as having a particular address, it may not be possible to change that address in mid-session. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 13:08:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SK6hS17197 for ipng-dist; Wed, 28 Jun 2000 13:06:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SK6R617190 for ; Wed, 28 Jun 2000 13:06:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA28582 for ; Wed, 28 Jun 2000 13:06:24 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA13194 for ; Wed, 28 Jun 2000 14:06:14 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Jun 2000 13:06:06 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Jun 2000 13:06:05 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024BCEFE6@RED-MSG-50> From: Richard Draves To: Morten Heiberg Rasmussen , Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: RE: Stateless autoconf and dial-on-demand Date: Wed, 28 Jun 2000 13:06:00 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If your dialup router is in command of the whole process, what > > happens if it holds the first outbound packet for a while, then > > advertises the new global prefix, *then* sends the initiator an ICMP > > "beyond scope of source address"? Will the initiator's stack then > > retry with the new global-scope address? > > Matt, > > I guess what we are worried about is the source address > selection in the > host implementations on the network. If a host needs to send > a packet to a > global scope destination address and only has a link local address to > supply as the source, are we guaranteed that the packet will > be put on the > wire in the first place? According to the draft source address selection rules, yes the packet will be sent with a global destination and link-local source if there is no better choice. But then there's Matt's question of whether the initiator's stack would retry with a new global source address after getting the ICMP error. The MSR stack would *not* do this when establishing a TCP connection. Backing up, I don't understand the approach. In this dial-on-demand scenario, why not "permanently" allocate a global prefix to the dial-up site? So router with the modem advertises this global prefix. And when the router gets a packet that it wants to send over the modem, then it dials. > A dumb question: Where is the "beyond scope of source address" ICMPv6 > message defined? I see it mentioned in RFC2765 (SIIT) as > "host unreachable, > code 2", but the location of the definition eludes me. draft-ietf-ipngwg-icmp-v3-00.txt, which seems to have expired. 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 Jun 28 14:16:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SLCZ017262 for ipng-dist; Wed, 28 Jun 2000 14:12:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SLCQ617255 for ; Wed, 28 Jun 2000 14:12:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06300 for ; Wed, 28 Jun 2000 14:12:25 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23452 for ; Wed, 28 Jun 2000 14:12:23 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA32754; Wed, 28 Jun 2000 22:12:20 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA23398; Wed, 28 Jun 2000 22:12:17 +0100 (BST) Message-ID: <395A69BF.3D402B21@hursley.ibm.com> Date: Wed, 28 Jun 2000 16:10:23 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ben Black CC: Jessica Yu , Jim Bound , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" References: <20000628141333.21104.qmail@web3004.mail.yahoo.com> <20000628095827.F12344@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben, You observe that Jessica's proposal does not resolve all cases of failover. True. This was obvious from the first draft. We all agree. Why does this make it inappropriate to publish the document, as a solution for certain types of failover? Brian Ben Black wrote: > > OK, here are detailed technical arguments which have not been > addressed: > > >From Section 4 (Concerns): > > - The primary ISP is the sole interface for the multihomed > customer to the Internet other than the ISPs the customer has > directly connection with. Outages such as one between ISP-1 and > ISP-4 would impact the reachability from customers of ISP-4 to > Customer-A even though ISP-2 still has good connection to ISP-4. > However, if the primary ISP is a good quality ISP, this sort of > situation should happen rarely. The reason is that it's common > practice that an ISP, especially good quality ISP, has multiple > connections to other big ISPs at different geographical locations. > Good quality ISPs also have robust network design to prevent any > failure to impact the whole network. Choosing a good quality and > robust ISP as primary ISP is a good practice. > > This is really the crux of the problem with the solution put forth in > the document. The assumption that a given ISP will never have > failures, or that rare failures are acceptable to customers who > multihomed for redundancy, is simply not valid from an engineering > perspective. If the primary goal of multihoming were load sharing, > this solution would provide one, potentially very complicated, > answer. However, the issue of multihoming for redundancy is totally > ignored, drawing into question the need for a second ISP in the > equation at all. Why not simply purchase additional bandwidth from > the same ISP? > > >From Section 4 (Concerns): > > It is desirable to have solution which provides perfect redundancy > and, at the same time, simplicity to scale management and operation. > In the absence of a perfect solution, the trade-off needs to be made. > The author believes that it is very important that the solution has > to be simple and manageable. Manageability should be the top > consideration. > > If managability of the solution is to be the top consideration, the > response put forward does not measure up. In the name of avoiding > routing table growth the author has suggested adding significant > complexity to the configuration and management of multihomed customers > without showing any benefit for the effort. > > An area not addressed at all in the document is that of multihoming > for access to networks attached to a given ISP, rather than access to > that ISP. For example, using the diagram above, if Customer-A > purchased connectivity to ISP-2 because ISP-2 had better connectivity > to ISP-4, then the offered multihoming solution is of no use. ISP-4 > will never see reachability to Customer-A via ISP-2. > > Now, if everyone is done threatening legal action, perhaps we could > return to the business of network engineering. > > Ben > > On Wed, Jun 28, 2000 at 07:13:33AM -0700, Jessica Yu wrote: > > By the way, unless there are technical arguments and > > credible facts in your responses, I am not going to > > send more messages. > > > > --Jessica > > > > --- Jessica Yu wrote: > > > > > > This has already been answered in the thread of > > > discussion on this topic a while back. Please go > > > back > > > to read the thread before you make any more > > > inaccurate > > > and irresponsible assertions. > > > > > > You said most network operators see no value. Where > > > did you get this? Who are the most operators? Please > > > be more responsible when you make assertions. > > > > > > > > > --Jessica > > > > > > --- Ben Black wrote: > > > > In all seriousness, would someone please explain > > > the > > > > benefits of > > > > this approach in comparison tot he RFC2260 > > > approach? > > > > > > > > I have *never* seen a single example and judging > > > by > > > > the feedback > > > > the draft has gotten, most network operators see > > > no > > > > value to it > > > > whatsoever. That alone should be a strong > > > > indication the proposal > > > > should be closely scrutinized before acceptance > > > for > > > > any further > > > > circulation. > > > > > > > > Simply voting to have a draft moved to RFC without > > > > answering > > > > numerous, legitimate questions regarding its value > > > > would seem a > > > > very poor method for developing quality technical > > > > documents. > > > > > > > > > > > > Ben > > > > > > > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, Jim > > > Bound > > > > wrote: > > > > > Jessica, > > > > > > > > > > Your work should go thru as info RFC I see no > > > > reason at all to defend > > > > > your draft any further for that goal. You have > > > > done a good job to give > > > > > us a means to work with our ISP customers with > > > > IPv6 to set up some > > > > > pilots with IPv6 using BGP+w/v6 to begin testing > > > > this and I also will be > > > > > proposing that 3GPP look at your proposal very > > > > seriously for IMT2000. > > > > > > > > > > Chairs - again there is no compelling reason > > > past > > > > or present to prevent > > > > > this work from moving to info rfc and begin > > > using > > > > it as a tool for the > > > > > many IPv6 pilots springing up with our > > > customers. > > > > > > > > > > I am not saying the discussion is 100% complete > > > > and I don't think it > > > > > ever will be as we evolve IPv6, but I do think > > > the > > > > decision has been > > > > > made, and we should move on here. > > > > > > > > > > regards, > > > > > /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 > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get Yahoo! Mail - Free email you can access from > > > anywhere! > > > http://mail.yahoo.com/ > > > > > > __________________________________________________ > > Do You Yahoo!? > > Get Yahoo! Mail - Free email you can access from anywhere! > > http://mail.yahoo.com/ > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 15:05:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SM3cJ17329 for ipng-dist; Wed, 28 Jun 2000 15:03:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SM3R617322 for ; Wed, 28 Jun 2000 15:03:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA20026 for ; Wed, 28 Jun 2000 15:03:27 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA27878 for ; Wed, 28 Jun 2000 15:03:22 -0700 (PDT) Received: (qmail 24325 invoked from network); 28 Jun 2000 22:05:40 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 28 Jun 2000 22:05:40 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Wed, 28 Jun 2000 14:57:17 -0700 Date: Wed, 28 Jun 2000 14:57:17 -0700 From: Ben Black To: Brian E Carpenter Cc: Jessica Yu , Jim Bound , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000628145717.C12380@layer8.net> References: <20000628141333.21104.qmail@web3004.mail.yahoo.com> <20000628095827.F12344@layer8.net> <395A69BF.3D402B21@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <395A69BF.3D402B21@hursley.ibm.com>; from brian@hursley.ibm.com on Wed, Jun 28, 2000 at 04:10:23PM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What makes it inappropriate at this time is the lack of a clear definition of *when* this solution is more appropriate than others. If it only provides a subset of the functionality, has minimal redundancy benefits, increases management overhead, and doesn't have a clearly met set of goals, why should it be put forth as an RFC giving people the impression it has somehow been blessed as a good idea? Ben On Wed, Jun 28, 2000 at 04:10:23PM -0500, Brian E Carpenter wrote: > Ben, > > You observe that Jessica's proposal does not resolve all cases > of failover. True. This was obvious from the first draft. We > all agree. > > Why does this make it inappropriate to publish the document, > as a solution for certain types of failover? > > Brian > > Ben Black wrote: > > > > OK, here are detailed technical arguments which have not been > > addressed: > > > > >From Section 4 (Concerns): > > > > - The primary ISP is the sole interface for the multihomed > > customer to the Internet other than the ISPs the customer has > > directly connection with. Outages such as one between ISP-1 and > > ISP-4 would impact the reachability from customers of ISP-4 to > > Customer-A even though ISP-2 still has good connection to ISP-4. > > However, if the primary ISP is a good quality ISP, this sort of > > situation should happen rarely. The reason is that it's common > > practice that an ISP, especially good quality ISP, has multiple > > connections to other big ISPs at different geographical locations. > > Good quality ISPs also have robust network design to prevent any > > failure to impact the whole network. Choosing a good quality and > > robust ISP as primary ISP is a good practice. > > > > This is really the crux of the problem with the solution put forth in > > the document. The assumption that a given ISP will never have > > failures, or that rare failures are acceptable to customers who > > multihomed for redundancy, is simply not valid from an engineering > > perspective. If the primary goal of multihoming were load sharing, > > this solution would provide one, potentially very complicated, > > answer. However, the issue of multihoming for redundancy is totally > > ignored, drawing into question the need for a second ISP in the > > equation at all. Why not simply purchase additional bandwidth from > > the same ISP? > > > > >From Section 4 (Concerns): > > > > It is desirable to have solution which provides perfect redundancy > > and, at the same time, simplicity to scale management and operation. > > In the absence of a perfect solution, the trade-off needs to be made. > > The author believes that it is very important that the solution has > > to be simple and manageable. Manageability should be the top > > consideration. > > > > If managability of the solution is to be the top consideration, the > > response put forward does not measure up. In the name of avoiding > > routing table growth the author has suggested adding significant > > complexity to the configuration and management of multihomed customers > > without showing any benefit for the effort. > > > > An area not addressed at all in the document is that of multihoming > > for access to networks attached to a given ISP, rather than access to > > that ISP. For example, using the diagram above, if Customer-A > > purchased connectivity to ISP-2 because ISP-2 had better connectivity > > to ISP-4, then the offered multihoming solution is of no use. ISP-4 > > will never see reachability to Customer-A via ISP-2. > > > > Now, if everyone is done threatening legal action, perhaps we could > > return to the business of network engineering. > > > > Ben > > > > On Wed, Jun 28, 2000 at 07:13:33AM -0700, Jessica Yu wrote: > > > By the way, unless there are technical arguments and > > > credible facts in your responses, I am not going to > > > send more messages. > > > > > > --Jessica > > > > > > --- Jessica Yu wrote: > > > > > > > > This has already been answered in the thread of > > > > discussion on this topic a while back. Please go > > > > back > > > > to read the thread before you make any more > > > > inaccurate > > > > and irresponsible assertions. > > > > > > > > You said most network operators see no value. Where > > > > did you get this? Who are the most operators? Please > > > > be more responsible when you make assertions. > > > > > > > > > > > > --Jessica > > > > > > > > --- Ben Black wrote: > > > > > In all seriousness, would someone please explain > > > > the > > > > > benefits of > > > > > this approach in comparison tot he RFC2260 > > > > approach? > > > > > > > > > > I have *never* seen a single example and judging > > > > by > > > > > the feedback > > > > > the draft has gotten, most network operators see > > > > no > > > > > value to it > > > > > whatsoever. That alone should be a strong > > > > > indication the proposal > > > > > should be closely scrutinized before acceptance > > > > for > > > > > any further > > > > > circulation. > > > > > > > > > > Simply voting to have a draft moved to RFC without > > > > > answering > > > > > numerous, legitimate questions regarding its value > > > > > would seem a > > > > > very poor method for developing quality technical > > > > > documents. > > > > > > > > > > > > > > > Ben > > > > > > > > > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, Jim > > > > Bound > > > > > wrote: > > > > > > Jessica, > > > > > > > > > > > > Your work should go thru as info RFC I see no > > > > > reason at all to defend > > > > > > your draft any further for that goal. You have > > > > > done a good job to give > > > > > > us a means to work with our ISP customers with > > > > > IPv6 to set up some > > > > > > pilots with IPv6 using BGP+w/v6 to begin testing > > > > > this and I also will be > > > > > > proposing that 3GPP look at your proposal very > > > > > seriously for IMT2000. > > > > > > > > > > > > Chairs - again there is no compelling reason > > > > past > > > > > or present to prevent > > > > > > this work from moving to info rfc and begin > > > > using > > > > > it as a tool for the > > > > > > many IPv6 pilots springing up with our > > > > customers. > > > > > > > > > > > > I am not saying the discussion is 100% complete > > > > > and I don't think it > > > > > > ever will be as we evolve IPv6, but I do think > > > > the > > > > > decision has been > > > > > > made, and we should move on here. > > > > > > > > > > > > regards, > > > > > > /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 > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Get Yahoo! Mail - Free email you can access from > > > > anywhere! > > > > http://mail.yahoo.com/ > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get Yahoo! Mail - Free email you can access from anywhere! > > > http://mail.yahoo.com/ > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 15:14:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5SMBdL17358 for ipng-dist; Wed, 28 Jun 2000 15:11:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5SMBU617349 for ; Wed, 28 Jun 2000 15:11:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA22084 for ; Wed, 28 Jun 2000 15:11:31 -0700 (PDT) Received: from mx2out.umbc.edu (mx2out.umbc.edu [130.85.253.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17419 for ; Wed, 28 Jun 2000 16:11:27 -0600 (MDT) Received: from gl.umbc.edu (vijay@umbc8.umbc.edu [130.85.60.8]) by mx2out.umbc.edu (8.9.3/8.9.3) with ESMTP id SAA05584; Wed, 28 Jun 2000 18:11:12 -0400 (EDT) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id SAA10762763; Wed, 28 Jun 2000 18:11:11 -0400 (EDT) X-Authentication-Warning: umbc8.umbc.edu: vijay owned process doing -bs Date: Wed, 28 Jun 2000 18:11:10 -0400 From: Vijay Gill To: Ben Black cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" In-Reply-To: <20000628145717.C12380@layer8.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 28 Jun 2000, Ben Black wrote: > have a clearly met set of goals, why should it be put forth as an > RFC giving people the impression it has somehow been blessed as > a good idea? I believe that this mail from Vernon S. pretty much sums it all up. /vijay From: Vernon Schryver Message-Id: <200006272043.OAA07814@calcite.rhyolite.com> To: ietf@ietf.org Subject: Re: The Non-IETF Informational RFC Publication Fiction X-Loop: ietf@ietf.org > From: Bill Manning > ... > I think things are headed in that general direction and I think it is a > sad state of affairs. Historically, RFCs were used to document ideas, > both good and bad. The series covered the range of idea generation > and expression and this was encouraged by the RFC editor. Now, many > "non-conformant" ideas are being released into the community as defacto > documents since it is too hard to get material documented in the RFC series > as either informational or experimental. This is in part due to the IESG/IAB > review cycle that is now part of the process. The alternative is many more and far worse circuses. What happens when someone writes something like draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-08.txt without what seems to be that author's non-confrontational nature but with the attitudes of D.J.Burnstein and Mohsen BANAN? In the old days, the IETF was in fact closed because no one knew about it, and the RFC editors did real editing. The barriers to outsiders in 1986 were informal but much higher than they are now. Even had he heard of RFC's and wanted to publish some ideas as one 1985, Mohsen BANAN could not have, at least not in the forms the modern IETF allowed. As the public discovered TCP/IP, the RFC printing press was in effect forced open. The relatively recent attempt to make the IETF a free vanity publisher is a growing, inevitable disaster that pleases no one. Things have changed in the last 15 or 20 years. The publishing services of the IETF and (and ISI) are no longer needed except for official products of working groups and perhaps except for open mailing lists. Each of us can trivially operate our own vanity publishing houses. Consider how very much better things would have been for everyone including Mohsen BANAN had the IETF said "those ideas are interesting, but until they have been implementated and tested, and thereby attracted an IETF Working Group to sponsoring them, all we can do is suggest that you mention a mailing list and URL for your documents in the IETF mailing lists." And similarly for TAP vs. Ident and whichever other excitements involving DJB that Mohsen BANAN is talking about. > This practice leads to > closed environments, documentation, code and operations. Not what I would > have hoped for in an evolved Internet. That is clearly wrong at least about code. Close vs. open code has nothing one way or another to do with the IETF's publishing polices, as demonstrated by the closed and open implementations of offical IETF protocols, not to mention the "individual submissions." Besides, there has been practically no code ever published by the IETF. I suspect one RFC contains most of the code in all existing RFC's. It's also not clear that open publishing leads to open protocols or anything else besides open (esp. vanity) publishing. Contrast the protocols that Microsoft has described with RFC's with the availability of source implementing them and the chance of anyone outside Redmod fixing or convincing anyone to fix even their most egregious and obvious bugs. What made sense as a semi-formal way to slightly polish items discussed in mailing lists has nothing to do with the polices, procedures and even goals of a competitor or co-equal of the ANSI and IEEE and member of the ITU. The IETF should keep the best parts of the RFC process, including free access to RFC text. However, for better or worse, the IETF doesn't have the organization, policies, procedures, people, or billing systems to operate a major vanity press catering to the under appreciated computer geniuses of the world. Vernon Schryver vjs@rhyolite.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 28 22:29:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5T5S5R17563 for ipng-dist; Wed, 28 Jun 2000 22:28:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5T5Rs617556 for ; Wed, 28 Jun 2000 22:27:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA21549 for ; Wed, 28 Jun 2000 22:27:53 -0700 (PDT) Received: from kryptonmail.spacenet.com ([12.1.237.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA22566 for ; Wed, 28 Jun 2000 23:27:52 -0600 (MDT) Received: by kryptonmail.spacenet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 01:26:20 -0400 Received: from mimesw.gilat.com (MIMESW [10.101.0.128]) by kryptonmail.spacenet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NWNMBZ7Y; Thu, 29 Jun 2000 01:26:17 -0400 Received: from mail.gilat.com (unverified) by mimesw.gilat.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 29 Jun 2000 08:14:45 +0200 Received: by mail.gvtele.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 08:14:43 +0200 Message-ID: <1ED1DEFB051AD311AEA20008C70D2F7E01B9C2BA@mail.gvtele.com> From: Eyal Levy - Israel To: ipng@sunroof.eng.sun.com Subject: Ip ver 6 membership Date: Thu, 29 Jun 2000 08:14:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-8" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello ; I would like to stop my membership with the "Ip ver 6 group". Thanks a lot to all the members. Eyal. -------------------------------------------------------------- Eyal Levy Gilat Satellite Networks Ltd. - www.gilat.com Tel: 972 - 3 - 929 3182 Fax: 972 - 3 - 929 3131 Mail: eyall@gilat.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 Jun 29 00:38:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5T7ad717613 for ipng-dist; Thu, 29 Jun 2000 00:36:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5T7aU617606 for ; Thu, 29 Jun 2000 00:36:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA21271 for ; Thu, 29 Jun 2000 00:36:32 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA04570 for ; Thu, 29 Jun 2000 01:36:30 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5T7aHK05409; Thu, 29 Jun 2000 09:36:18 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA06789; Thu, 29 Jun 2000 09:36:16 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA14945; Thu, 29 Jun 2000 09:37:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006290737.JAA14945@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dave Thaler" cc: "Steve Deering" , ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Tue, 27 Jun 2000 09:52:37 PDT. <19398D273324D3118A2B0008C7E9A5690C6F7AA4@SIT.platinum.corp.microsoft.com> Date: Thu, 29 Jun 2000 09:37:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I really don't like the idea of sharing the same numbering space between interface ids and scope ids of higher levels, and requiring uniqueness among them. => if link-local scope IDs are named link IDs and have in general the same value set than interface IDs per accident have you still an objection? if_nametoindex() and related functions wouldn't be helpful for an app wanting to choosing a link. => I agree the confusion between interface indexes and link IDs is confusing but with two sets of functions (one for interface indexes, one for scope IDs) to have the same name is only user convenience. This argument can be used for IPV6_MULTICAST_IF, PKTINFO, ..., too. I believe the reception interface (for both unicast and multicast) can already be obtained if you use recvmsg. => my purpose was just to recall how recvfrom() and co should fill the sin6_scope_id field. I think there already is an agreement about that (and I'd like to show no change is needed for this). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 01:19:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5T8H4p17685 for ipng-dist; Thu, 29 Jun 2000 01:17:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5T8Gn617678 for ; Thu, 29 Jun 2000 01:16:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA24238 for ; Thu, 29 Jun 2000 01:16:39 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23462 for ; Thu, 29 Jun 2000 01:16:37 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5T8E0K16869; Thu, 29 Jun 2000 10:14:00 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA07306; Thu, 29 Jun 2000 10:13:58 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA15100; Thu, 29 Jun 2000 10:14:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006290814.KAA15100@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Tue, 27 Jun 2000 10:08:16 EDT. <200006271408.KAA0000012829@yquarry.zk3.dec.com> Date: Thu, 29 Jun 2000 10:14:38 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: That would mean having to differentiate sin6_scope_id for each address which is not well defined today for anyone. Also with my thought of a fix this all becomes uncessary if we use the rsvd bits in site-local to provide uniqueness. => I don't believe this (reserved bits) idea will work because even if we shout they should be random in order to avoid collisions the human laziness will make only small values (1, 2, .., and don't forget many will stay with zero because it is the current mandatory value) to be used then they will collide. All the problems of some well known IPv6 implementations using embedded interface indexes in link-local addresses from place to place in the code make me even less confident... The sin6_scope_id is there in order to solve this issue, let it do its job! Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 01:19:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5T8IH917709 for ipng-dist; Thu, 29 Jun 2000 01:18:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5T8I3617697 for ; Thu, 29 Jun 2000 01:18:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA03475 for ; Thu, 29 Jun 2000 01:18:01 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20586 for ; Thu, 29 Jun 2000 02:18:01 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5T8GoK11534; Thu, 29 Jun 2000 10:16:53 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA07334; Thu, 29 Jun 2000 10:16:49 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA15127; Thu, 29 Jun 2000 10:17:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006290817.KAA15127@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: tim@mentat.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Wed, 28 Jun 2000 02:28:52 +0900. Date: Thu, 29 Jun 2000 10:17:46 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: We could implement Steve's proposal if we invented unique space of identifiers that covers all scopes. And I admit it would be useful if we can specify the outgoing interface by the sin6_scope_id field without any other APIs (such as socket options), but it would be too complecated for application programmers, especially on properly using different type of sin6_scope_id values (i.e. sometimes use it as an interface identifier, and sometimes use it as a zone identifier of a larger scope). => do you believe we should use conditional? In fact the sin6_scope_id space is not yet specified then in theory it is not too late. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 01:40:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5T8d3g17764 for ipng-dist; Thu, 29 Jun 2000 01:39:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5T8cs617757 for ; Thu, 29 Jun 2000 01:38:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA09637 for ; Thu, 29 Jun 2000 01:38:54 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28459 for ; Thu, 29 Jun 2000 02:38:52 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5T8ZqK16159; Thu, 29 Jun 2000 10:35:52 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA07637; Thu, 29 Jun 2000 10:35:51 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA15241; Thu, 29 Jun 2000 10:36:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006290836.KAA15241@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Alex Conta , Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: Global Prefixes in IPv6 In-reply-to: Your message of Tue, 27 Jun 2000 15:24:27 EDT. <200006271924.PAA0000867684@anw.zk3.dec.com> Date: Thu, 29 Jun 2000 10:36:51 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Francis was misguided on the issue. DHCPv6 has no problem. When it gets executed DHCPv6 will work. => I still disagree. DHCPv6 recognizes links using prefixes (an address and prefix length pair). This doesn't work with multi-link subnets then I propose to add a line saying DHCPv6 doesn't support multi-link subnets in the DHCPv6 I-D "non-goals" section (multi-link subnets don't exist today and we need DHCPv6 for two years ago). Regards Francis.Dupont@enst-bretagne.fr PS: but I agree with Jim that to find a full solution for this issue is not the job of the DHCPv6 team but the job of multi-link subnets researchers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 02:19:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5T9HKn17801 for ipng-dist; Thu, 29 Jun 2000 02:17:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5T9HB617794 for ; Thu, 29 Jun 2000 02:17:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA18617 for ; Thu, 29 Jun 2000 02:17:10 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13288 for ; Thu, 29 Jun 2000 03:17:06 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA26998; Thu, 29 Jun 2000 18:04:22 +0900 (JST) Date: Thu, 29 Jun 2000 18:12:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@enst-bretagne.fr Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-Reply-To: In your message of "Thu, 29 Jun 2000 10:17:46 +0200" <200006290817.KAA15127@givry.rennes.enst-bretagne.fr> References: <200006290817.KAA15127@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 29 Jun 2000 10:17:46 +0200, >>>>> Francis Dupont said: > We could implement Steve's proposal if we invented unique space of > identifiers that covers all scopes. And I admit it would be useful if > we can specify the outgoing interface by the sin6_scope_id field > without any other APIs (such as socket options), but it would be too > complecated for application programmers, especially on properly using > different type of sin6_scope_id values (i.e. sometimes use it as an > interface identifier, and sometimes use it as a zone identifier of a > larger scope). > => do you believe we should use conditional? In fact the sin6_scope_id > space is not yet specified then in theory it is not too late. I can't understand what you meant by "conditional" (sorry), but it is correct that the semantics of sin6_scope_id is not yet defined. My concern is possible confusion due to the complexity of the semantics in the future. By the way, do you intend to use the same approach for unicast addresses? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 03:10:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TA89m17903 for ipng-dist; Thu, 29 Jun 2000 03:08:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TA80617896 for ; Thu, 29 Jun 2000 03:08:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA10399 for ; Thu, 29 Jun 2000 03:07:58 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA03479 for ; Thu, 29 Jun 2000 04:07:56 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5TA6qK55906; Thu, 29 Jun 2000 12:06:52 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA08891; Thu, 29 Jun 2000 12:06:45 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA16159; Thu, 29 Jun 2000 12:07:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006291007.MAA16159@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Thu, 29 Jun 2000 18:12:32 +0900. Date: Thu, 29 Jun 2000 12:07:45 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> On Thu, 29 Jun 2000 10:17:46 +0200, >>>>> Francis Dupont said: > We could implement Steve's proposal if we invented unique space of > identifiers that covers all scopes. And I admit it would be useful if > we can specify the outgoing interface by the sin6_scope_id field > without any other APIs (such as socket options), but it would be too > complecated for application programmers, especially on properly using > different type of sin6_scope_id values (i.e. sometimes use it as an > interface identifier, and sometimes use it as a zone identifier of a > larger scope). > => do you believe we should use conditional? In fact the sin6_scope_id > space is not yet specified then in theory it is not too late. I can't understand what you meant by "conditional" (sorry), => could in place of can, invented in place of invent, ... For me this usage of past show you wouldn't like to support to Steve's proposal... but it is correct that the semantics of sin6_scope_id is not yet defined. My concern is possible confusion due to the complexity of the semantics in the future. => I understand your concern but powerful things are usually complex. I'd like to get both a powerful and uniform thing, ie. something which can be made simple to explain. Another question is do we need a very powerful thing or should we stay with the current solution (sin6_scope_ids are used only for link-locals). By the way, do you intend to use the same approach for unicast addresses? => I don't see any good reason to have different approaches for unicast and multicast addresses. In IPv4 they are very different for historical reasons and it is very hard for a beginner to program a multicast application for this reason (the lack of documentation doesn't help too). IMHO we should try to complete Steve's proposal and see if it works reasonnably (look at the scope I-D thread about potential issues). Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 03:48:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TAkTt17989 for ipng-dist; Thu, 29 Jun 2000 03:46:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TAkJ617982 for ; Thu, 29 Jun 2000 03:46:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA02781 for ; Thu, 29 Jun 2000 03:46:19 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA17032 for ; Thu, 29 Jun 2000 04:46:18 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25163; Thu, 29 Jun 2000 06:46:16 -0400 (EDT) Message-Id: <200006291046.GAA25163@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-scopedaddr-format-02.txt Date: Thu, 29 Jun 2000 06:46:16 -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 : An Extension of Format for IPv6 Scoped Addresses Author(s) : T. Jinmei, A. Onoe Filename : draft-ietf-ipngwg-scopedaddr-format-02.txt Pages : 11 Date : 28-Jun-00 This document defines an extension of the format for IPv6 scoped addresses. In the format, a scope identifier is attached to a scoped address in order to supplement the ambiguity of the semantics of the address. Using the format with some library routines will make scope-aware applications simpler. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scopedaddr-format-02.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-scopedaddr-format-02.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-scopedaddr-format-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000628101047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scopedaddr-format-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scopedaddr-format-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000628101047.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 Jun 29 07:34:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TEV8W18109 for ipng-dist; Thu, 29 Jun 2000 07:31:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TEUe618102 for ; Thu, 29 Jun 2000 07:30:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA03195 for ; Thu, 29 Jun 2000 07:30:41 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24725 for ; Thu, 29 Jun 2000 07:30:39 -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 PAA102010; Thu, 29 Jun 2000 15:30:28 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA17446; Thu, 29 Jun 2000 15:30:20 +0100 (BST) Message-ID: <395B5D26.AFFDFC1A@hursley.ibm.com> Date: Thu, 29 Jun 2000 09:28:54 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ben Black CC: Jessica Yu , Jim Bound , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" References: <20000628141333.21104.qmail@web3004.mail.yahoo.com> <20000628095827.F12344@layer8.net> <395A69BF.3D402B21@hursley.ibm.com> <20000628145717.C12380@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Publishing an informational RFC does not "bless" an idea. Brian Ben Black wrote: > > What makes it inappropriate at this time is the lack of a clear > definition of *when* this solution is more appropriate than others. > If it only provides a subset of the functionality, has minimal > redundancy benefits, increases management overhead, and doesn't > have a clearly met set of goals, why should it be put forth as an > RFC giving people the impression it has somehow been blessed as > a good idea? > > Ben > > On Wed, Jun 28, 2000 at 04:10:23PM -0500, Brian E Carpenter wrote: > > Ben, > > > > You observe that Jessica's proposal does not resolve all cases > > of failover. True. This was obvious from the first draft. We > > all agree. > > > > Why does this make it inappropriate to publish the document, > > as a solution for certain types of failover? > > > > Brian > > > > Ben Black wrote: > > > > > > OK, here are detailed technical arguments which have not been > > > addressed: > > > > > > >From Section 4 (Concerns): > > > > > > - The primary ISP is the sole interface for the multihomed > > > customer to the Internet other than the ISPs the customer has > > > directly connection with. Outages such as one between ISP-1 and > > > ISP-4 would impact the reachability from customers of ISP-4 to > > > Customer-A even though ISP-2 still has good connection to ISP-4. > > > However, if the primary ISP is a good quality ISP, this sort of > > > situation should happen rarely. The reason is that it's common > > > practice that an ISP, especially good quality ISP, has multiple > > > connections to other big ISPs at different geographical locations. > > > Good quality ISPs also have robust network design to prevent any > > > failure to impact the whole network. Choosing a good quality and > > > robust ISP as primary ISP is a good practice. > > > > > > This is really the crux of the problem with the solution put forth in > > > the document. The assumption that a given ISP will never have > > > failures, or that rare failures are acceptable to customers who > > > multihomed for redundancy, is simply not valid from an engineering > > > perspective. If the primary goal of multihoming were load sharing, > > > this solution would provide one, potentially very complicated, > > > answer. However, the issue of multihoming for redundancy is totally > > > ignored, drawing into question the need for a second ISP in the > > > equation at all. Why not simply purchase additional bandwidth from > > > the same ISP? > > > > > > >From Section 4 (Concerns): > > > > > > It is desirable to have solution which provides perfect redundancy > > > and, at the same time, simplicity to scale management and operation. > > > In the absence of a perfect solution, the trade-off needs to be made. > > > The author believes that it is very important that the solution has > > > to be simple and manageable. Manageability should be the top > > > consideration. > > > > > > If managability of the solution is to be the top consideration, the > > > response put forward does not measure up. In the name of avoiding > > > routing table growth the author has suggested adding significant > > > complexity to the configuration and management of multihomed customers > > > without showing any benefit for the effort. > > > > > > An area not addressed at all in the document is that of multihoming > > > for access to networks attached to a given ISP, rather than access to > > > that ISP. For example, using the diagram above, if Customer-A > > > purchased connectivity to ISP-2 because ISP-2 had better connectivity > > > to ISP-4, then the offered multihoming solution is of no use. ISP-4 > > > will never see reachability to Customer-A via ISP-2. > > > > > > Now, if everyone is done threatening legal action, perhaps we could > > > return to the business of network engineering. > > > > > > Ben > > > > > > On Wed, Jun 28, 2000 at 07:13:33AM -0700, Jessica Yu wrote: > > > > By the way, unless there are technical arguments and > > > > credible facts in your responses, I am not going to > > > > send more messages. > > > > > > > > --Jessica > > > > > > > > --- Jessica Yu wrote: > > > > > > > > > > This has already been answered in the thread of > > > > > discussion on this topic a while back. Please go > > > > > back > > > > > to read the thread before you make any more > > > > > inaccurate > > > > > and irresponsible assertions. > > > > > > > > > > You said most network operators see no value. Where > > > > > did you get this? Who are the most operators? Please > > > > > be more responsible when you make assertions. > > > > > > > > > > > > > > > --Jessica > > > > > > > > > > --- Ben Black wrote: > > > > > > In all seriousness, would someone please explain > > > > > the > > > > > > benefits of > > > > > > this approach in comparison tot he RFC2260 > > > > > approach? > > > > > > > > > > > > I have *never* seen a single example and judging > > > > > by > > > > > > the feedback > > > > > > the draft has gotten, most network operators see > > > > > no > > > > > > value to it > > > > > > whatsoever. That alone should be a strong > > > > > > indication the proposal > > > > > > should be closely scrutinized before acceptance > > > > > for > > > > > > any further > > > > > > circulation. > > > > > > > > > > > > Simply voting to have a draft moved to RFC without > > > > > > answering > > > > > > numerous, legitimate questions regarding its value > > > > > > would seem a > > > > > > very poor method for developing quality technical > > > > > > documents. > > > > > > > > > > > > > > > > > > Ben > > > > > > > > > > > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, Jim > > > > > Bound > > > > > > wrote: > > > > > > > Jessica, > > > > > > > > > > > > > > Your work should go thru as info RFC I see no > > > > > > reason at all to defend > > > > > > > your draft any further for that goal. You have > > > > > > done a good job to give > > > > > > > us a means to work with our ISP customers with > > > > > > IPv6 to set up some > > > > > > > pilots with IPv6 using BGP+w/v6 to begin testing > > > > > > this and I also will be > > > > > > > proposing that 3GPP look at your proposal very > > > > > > seriously for IMT2000. > > > > > > > > > > > > > > Chairs - again there is no compelling reason > > > > > past > > > > > > or present to prevent > > > > > > > this work from moving to info rfc and begin > > > > > using > > > > > > it as a tool for the > > > > > > > many IPv6 pilots springing up with our > > > > > customers. > > > > > > > > > > > > > > I am not saying the discussion is 100% complete > > > > > > and I don't think it > > > > > > > ever will be as we evolve IPv6, but I do think > > > > > the > > > > > > decision has been > > > > > > > made, and we should move on here. > > > > > > > > > > > > > > regards, > > > > > > > /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 > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > > __________________________________________________ > > > > > Do You Yahoo!? > > > > > Get Yahoo! Mail - Free email you can access from > > > > > anywhere! > > > > > http://mail.yahoo.com/ > > > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Get Yahoo! Mail - Free email you can access from anywhere! > > > > http://mail.yahoo.com/ > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 07:34:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TEXX118118 for ipng-dist; Thu, 29 Jun 2000 07:33:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TEXM618111 for ; Thu, 29 Jun 2000 07:33:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA04556 for ; Thu, 29 Jun 2000 07:33:22 -0700 (PDT) Received: from web3004.mail.yahoo.com (web3004.mail.yahoo.com [204.71.202.167]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA00878 for ; Thu, 29 Jun 2000 08:33:21 -0600 (MDT) Received: (qmail 2040 invoked by uid 60001); 29 Jun 2000 14:33:20 -0000 Message-ID: <20000629143320.2039.qmail@web3004.mail.yahoo.com> Received: from [63.88.104.20] by web3004.mail.yahoo.com; Thu, 29 Jun 2000 07:33:20 PDT Date: Thu, 29 Jun 2000 07:33:20 -0700 (PDT) From: Jessica Yu Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" To: Ben Black , Brian E Carpenter Cc: Jessica Yu , Jim Bound , Vijay Gill , hinden@iprg.nokia.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 --- Ben Black wrote: > What makes it inappropriate at this time is the lack > of a clear > definition of *when* this solution is more > appropriate than others. This is again another inaccurate assertion. In section 4 of my I-D (attached below), it clearly documented in what situations this approach is more suitable. At this point, I am not even sure if you read my draft or not. You have been making so many inaccurate assertions and unfound claims that I do not think what you are saying is credible any more. --Jessica 4. Conclusions It wouldn't be hard to understand that even those enterprises desire multiple Internet connections may have different criterias and resource constrains for implementing such connection. Some may require absolute redundancy while most may only desire reasonable redundancy. This document offers a viable multihoming solution for an enterprise to choose based on its particular requirements and constrains. The multihoming mechanism described in this document is applicable to various multihoming scenarios, the most suitable environment for deploying it are: a. ISPs serving the multi-homed site have direct connection(s) to each other. Although such direct connection is not required, it would make arrangement simpler and will also improve aggregation by limiting specific routes visible only to ISPs serving the multi-homed site. b. Enterprises with requirements for good redundancy but not absolute redundancy. c. Enterprises with limited to resource for onsite sophisticated network administrators d. Enterprises able to choose a robust ISP as primary provider. Although not the main focus, the mechanism described in this document can also be used to improve routing scalability within networks shares one aggregation block or Top Level Aggregator (TLA). --- Ben Black wrote: > What makes it inappropriate at this time is the lack > of a clear > definition of *when* this solution is more > appropriate than others. > If it only provides a subset of the functionality, > has minimal > redundancy benefits, increases management overhead, > and doesn't > have a clearly met set of goals, why should it be > put forth as an > RFC giving people the impression it has somehow been > blessed as > a good idea? > > > Ben > > On Wed, Jun 28, 2000 at 04:10:23PM -0500, Brian E > Carpenter wrote: > > Ben, > > > > You observe that Jessica's proposal does not > resolve all cases > > of failover. True. This was obvious from the first > draft. We > > all agree. > > > > Why does this make it inappropriate to publish the > document, > > as a solution for certain types of failover? > > > > Brian > > > > Ben Black wrote: > > > > > > OK, here are detailed technical arguments which > have not been > > > addressed: > > > > > > >From Section 4 (Concerns): > > > > > > - The primary ISP is the sole interface > for the multihomed > > > customer to the Internet other than the > ISPs the customer has > > > directly connection with. Outages such as > one between ISP-1 and > > > ISP-4 would impact the reachability from > customers of ISP-4 to > > > Customer-A even though ISP-2 still has > good connection to ISP-4. > > > However, if the primary ISP is a good > quality ISP, this sort of > > > situation should happen rarely. The reason > is that it's common > > > practice that an ISP, especially good > quality ISP, has multiple > > > connections to other big ISPs at different > geographical locations. > > > Good quality ISPs also have robust network > design to prevent any > > > failure to impact the whole network. > Choosing a good quality and > > > robust ISP as primary ISP is a good > practice. > > > > > > This is really the crux of the problem with the > solution put forth in > > > the document. The assumption that a given ISP > will never have > > > failures, or that rare failures are acceptable > to customers who > > > multihomed for redundancy, is simply not valid > from an engineering > > > perspective. If the primary goal of multihoming > were load sharing, > > > this solution would provide one, potentially > very complicated, > > > answer. However, the issue of multihoming for > redundancy is totally > > > ignored, drawing into question the need for a > second ISP in the > > > equation at all. Why not simply purchase > additional bandwidth from > > > the same ISP? > > > > > > >From Section 4 (Concerns): > > > > > > It is desirable to have solution which > provides perfect redundancy > > > and, at the same time, simplicity to scale > management and operation. > > > In the absence of a perfect solution, the > trade-off needs to be made. > > > The author believes that it is very important > that the solution has > > > to be simple and manageable. Manageability > should be the top > > > consideration. > > > > > > If managability of the solution is to be the top > consideration, the > > > response put forward does not measure up. In > the name of avoiding > > > routing table growth the author has suggested > adding significant > > > complexity to the configuration and management > of multihomed customers > > > without showing any benefit for the effort. > > > > > > An area not addressed at all in the document is > that of multihoming > > > for access to networks attached to a given ISP, > rather than access to > > > that ISP. For example, using the diagram above, > if Customer-A > > > purchased connectivity to ISP-2 because ISP-2 > had better connectivity > > > to ISP-4, then the offered multihoming solution > is of no use. ISP-4 > > > will never see reachability to Customer-A via > ISP-2. > > > > > > Now, if everyone is done threatening legal > action, perhaps we could > > > return to the business of network engineering. > > > > > > Ben > > > > > > On Wed, Jun 28, 2000 at 07:13:33AM -0700, > Jessica Yu wrote: > > > > By the way, unless there are technical > arguments and > > > > credible facts in your responses, I am not > going to > > > > send more messages. > > > > > > > > --Jessica > > > > > > > > --- Jessica Yu wrote: > > > > > > > > > > This has already been answered in the thread > of > > > > > discussion on this topic a while back. > Please go > > > > > back > > > > > to read the thread before you make any more > > > > > inaccurate > > > > > and irresponsible assertions. > > > > > > > > > > You said most network operators see no > value. Where > > > > > did you get this? Who are the most > operators? Please > > > > > be more responsible when you make > assertions. > > > > > > > > > > > > > > > --Jessica > > > > > > > > > > --- Ben Black wrote: > > > > > > In all seriousness, would someone please > explain > > > > > the > > > > > > benefits of > > > > > > this approach in comparison tot he RFC2260 > > > > > approach? > > > > > > > > > > > > I have *never* seen a single example and > judging > > > > > by > > > > > > the feedback > > > > > > the draft has gotten, most network > operators see > > > > > no > > > > > > value to it > > > > > > whatsoever. That alone should be a strong > > > > > > indication the proposal > > > > > > should be closely scrutinized before > acceptance > > > > > for > > > > > > any further > > > > > > circulation. > > > > > > > > > > > > Simply voting to have a draft moved to RFC > without > > > > > > answering > > > > > > numerous, legitimate questions regarding > its value > > > > > > would seem a > > > > > > very poor method for developing quality > technical > > > > > > documents. > > > > > > > > > > > > > > > > > > Ben > > > > > > > > > > > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, > Jim > > > > > Bound > > > > > > wrote: > === message truncated === __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 08:13:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TFBdg18229 for ipng-dist; Thu, 29 Jun 2000 08:11:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TFBU618222 for ; Thu, 29 Jun 2000 08:11:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA11565 for ; Thu, 29 Jun 2000 08:11:30 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20537 for ; Thu, 29 Jun 2000 08:11:29 -0700 (PDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 137fyJ-000727-00; Thu, 29 Jun 2000 11:11:19 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA04283; Thu, 29 Jun 00 11:09:18 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA07046; Thu, 29 Jun 2000 11:14:26 -0400 Message-Id: <395B6796.3FB4ABB3@txc.com> Date: Thu, 29 Jun 2000 11:13:26 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Peter Tam Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Thank you for your comments, which are important for the improving of this specification. For the first comment, I need more clarification, but it is probably better if I take the comments and answer them one by one, so please see bellow: Peter Tam wrote: > > > Bob: > > This is the 1st time I read this draft. Apology if the following have > been discussed before: > > 1. Must the Target Address List option in the Inverse Neighbor > Discovery Advertisement (InvNDA) message not contain unicast IPv6 > addresses only? I think it must. Then it will affect section > 4.3.2 on the validation procedures. > Would you please elaborate? > 1. Should it not also support unsolicited InvNDA, when 1 or more of > an inteface's IP addresses have been changed? It should, and > should also enforce to re-advertise all the addresses on that > interface. Otherwise, it is not possible to cover the scenario > where an IP address on the interface was deleted. > The motivations to the present text in the specification were the following: 1. Minimizing and possibly eliminating unsolicited messages is a good thing. 2. The scenario in which one or more new IPv6 address are added to an existent VC can be solved by having the node adding such addresses send IND Solicitation(s). 3. The scenario in which one ore more IPv6 addresses associated with a VC are deleted while the VC and DLCI remain was envisaged to happen seldom - more often, the VC and DLCI would be torn down as well - and be resolved through the IPv6 address deprecation. > 1. Appendix A: Frame Relay (FR) as a link-layer address. But it > should have a note up front that the DLCI applies to the member > DLCI in the case of a Multi-link Frame Relay. > The appendix was intended to contain one simple example to illustrate the use of the protocol. Some particular details of the link in the example were considered out of scope. > 1. Why is there a preference of FR to ATM in Appendix A? Should also > include the case for ATM as a link-layer technology. > > As said previously, the appendix contains just one example, to illustrate simply and briefly the use of the protocol. Although it is mentioned that it may apply to other link technologies, it was not intended to cover more or all possible link technologies. > > > Regards... Peter Tam, > Nortel Networks, Ottawa Thank you, Alex Conta Transwitch Corporation, Shelton, CT > > > -----Original Message----- > From: Bob Hinden [SMTP:hinden@iprg.nokia.com] > Sent: Thursday, June 22, 2000 4:27 PM > To: ipng@sunroof.eng.sun.com > Subject: W.G. Last Call on "Extensions to IPv6 Neighbor > Discovery for Inverse Discovery Specification" > > This is a IPng working group last call for comments on advancing > the > following document as a Proposed Standard: > > Title : Extensions to IPv6 Neighbor Discovery > for Inverse > Discovery Specification > Author(s) : A. Conta > Filename : draft-ietf-ion-ipv6-ind-03.txt > Pages : 22 > Date : 27-Oct-99 > > Please send substantive comments to the ipng mailing list, and > minor > editorial comments to the author. This last call period will end > two > week from today on July 6, 2000. > > Bob Hinden / Steve Deering > > > ------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > ------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 08:30:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TFSHZ18267 for ipng-dist; Thu, 29 Jun 2000 08:28:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TFS5618258 for ; Thu, 29 Jun 2000 08:28:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA18639 for ; Thu, 29 Jun 2000 08:28:06 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00992 for ; Thu, 29 Jun 2000 08:28:05 -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 KAA11810; Thu, 29 Jun 2000 10:21:20 -0500 (CDT) Message-Id: <200006291521.KAA11810@gungnir.fnal.gov> To: Jim Bound Cc: Brian E Carpenter , Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com From: "Matt Crawford" Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of Tue, 27 Jun 2000 15:12:32 EDT. <200006271912.PAA0000866020@anw.zk3.dec.com> Date: Thu, 29 Jun 2000 10:21:20 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > flowlabel should be done here or in routing area. > those are the people who understand it and ramifications. I disagree. It should be in routing or transport, so they can shed the blood over whether it's end-to-end or hop-by-hop-mutable. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 09:55:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TGr3I18338 for ipng-dist; Thu, 29 Jun 2000 09:53:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TGqq618331 for ; Thu, 29 Jun 2000 09:52:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA03964 for ; Thu, 29 Jun 2000 09:52:51 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27506 for ; Thu, 29 Jun 2000 09:52:50 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 91855416B; Thu, 29 Jun 2000 12:52:49 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5AA794143; Thu, 29 Jun 2000 12:52:49 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000762364; Thu, 29 Jun 2000 12:52:48 -0400 (EDT) From: Jim Bound Message-Id: <200006291652.MAA0000762364@anw.zk3.dec.com> To: "Matt Crawford" Cc: Jim Bound , Brian E Carpenter , Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com, bound@zk3.dec.com Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of "Thu, 29 Jun 2000 10:21:20 CDT." <200006291521.KAA11810@gungnir.fnal.gov> Date: Thu, 29 Jun 2000 12:52:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi matt, I agree. brian showed me the error of my ways too :---) thx /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 09:56:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TGsus18347 for ipng-dist; Thu, 29 Jun 2000 09:54:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TGsg618340 for ; Thu, 29 Jun 2000 09:54:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07245 for ; Thu, 29 Jun 2000 09:54:41 -0700 (PDT) Received: from tristero.cryptocourier.com (black-3.dsl.speakeasy.net [216.231.56.189]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA28773 for ; Thu, 29 Jun 2000 09:54:41 -0700 (PDT) Received: (qmail 24993 invoked from network); 29 Jun 2000 16:57:00 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 29 Jun 2000 16:56:59 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Thu, 29 Jun 2000 09:48:34 -0700 Date: Thu, 29 Jun 2000 09:48:34 -0700 From: Ben Black To: Jessica Yu Cc: Brian E Carpenter , Jim Bound , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" Message-ID: <20000629094834.A12427@layer8.net> References: <20000629143320.2039.qmail@web3004.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000629143320.2039.qmail@web3004.mail.yahoo.com>; from jyy_99@yahoo.com on Thu, Jun 29, 2000 at 07:33:20AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please note that I specifically said "more appropriate", not just "at all appropriate". Your draft describes a set of scenarios where it is applicable, but does not explain how it is superior in any way to other approaches, such as RFC2260. Ben On Thu, Jun 29, 2000 at 07:33:20AM -0700, Jessica Yu wrote: > --- Ben Black wrote: > > What makes it inappropriate at this time is the lack > > of a clear > > definition of *when* this solution is more > > appropriate than others. > > This is again another inaccurate assertion. In section > 4 of my I-D (attached below), it clearly documented in > what situations this approach is more suitable. > > At this point, I am not even sure if you read my draft > or not. You have been making so many inaccurate > assertions and unfound claims that I do not think what > you are saying is credible any more. > > --Jessica > > 4. Conclusions > > It wouldn't be hard to understand that even those > enterprises desire > multiple Internet connections may have different > criterias and > resource constrains for implementing such > connection. Some may > require absolute redundancy while most may only > desire reasonable > redundancy. This document offers a viable > multihoming solution for an > enterprise to choose based on its particular > requirements and > constrains. The multihoming mechanism described in > this document is > applicable to various multihoming scenarios, the > most suitable > environment for deploying it are: > > a. ISPs serving the multi-homed site have direct > connection(s) to > each other. Although such direct connection is > not required, it > would make arrangement simpler and will also > improve aggregation > by limiting specific routes visible only to ISPs > serving the > multi-homed site. > > b. Enterprises with requirements for good > redundancy but not > absolute redundancy. > > c. Enterprises with limited to resource for > onsite sophisticated > network administrators > > d. Enterprises able to choose a robust ISP as > primary provider. > > Although not the main focus, the mechanism > described in this > document can also be used to improve routing > scalability within > networks shares one aggregation block or Top > Level Aggregator > (TLA). > > > --- Ben Black wrote: > > What makes it inappropriate at this time is the lack > > of a clear > > definition of *when* this solution is more > > appropriate than others. > > If it only provides a subset of the functionality, > > has minimal > > redundancy benefits, increases management overhead, > > and doesn't > > have a clearly met set of goals, why should it be > > put forth as an > > RFC giving people the impression it has somehow been > > blessed as > > a good idea? > > > > > > Ben > > > > On Wed, Jun 28, 2000 at 04:10:23PM -0500, Brian E > > Carpenter wrote: > > > Ben, > > > > > > You observe that Jessica's proposal does not > > resolve all cases > > > of failover. True. This was obvious from the first > > draft. We > > > all agree. > > > > > > Why does this make it inappropriate to publish the > > document, > > > as a solution for certain types of failover? > > > > > > Brian > > > > > > Ben Black wrote: > > > > > > > > OK, here are detailed technical arguments which > > have not been > > > > addressed: > > > > > > > > >From Section 4 (Concerns): > > > > > > > > - The primary ISP is the sole interface > > for the multihomed > > > > customer to the Internet other than the > > ISPs the customer has > > > > directly connection with. Outages such as > > one between ISP-1 and > > > > ISP-4 would impact the reachability from > > customers of ISP-4 to > > > > Customer-A even though ISP-2 still has > > good connection to ISP-4. > > > > However, if the primary ISP is a good > > quality ISP, this sort of > > > > situation should happen rarely. The reason > > is that it's common > > > > practice that an ISP, especially good > > quality ISP, has multiple > > > > connections to other big ISPs at different > > geographical locations. > > > > Good quality ISPs also have robust network > > design to prevent any > > > > failure to impact the whole network. > > Choosing a good quality and > > > > robust ISP as primary ISP is a good > > practice. > > > > > > > > This is really the crux of the problem with the > > solution put forth in > > > > the document. The assumption that a given ISP > > will never have > > > > failures, or that rare failures are acceptable > > to customers who > > > > multihomed for redundancy, is simply not valid > > from an engineering > > > > perspective. If the primary goal of multihoming > > were load sharing, > > > > this solution would provide one, potentially > > very complicated, > > > > answer. However, the issue of multihoming for > > redundancy is totally > > > > ignored, drawing into question the need for a > > second ISP in the > > > > equation at all. Why not simply purchase > > additional bandwidth from > > > > the same ISP? > > > > > > > > >From Section 4 (Concerns): > > > > > > > > It is desirable to have solution which > > provides perfect redundancy > > > > and, at the same time, simplicity to scale > > management and operation. > > > > In the absence of a perfect solution, the > > trade-off needs to be made. > > > > The author believes that it is very important > > that the solution has > > > > to be simple and manageable. Manageability > > should be the top > > > > consideration. > > > > > > > > If managability of the solution is to be the top > > consideration, the > > > > response put forward does not measure up. In > > the name of avoiding > > > > routing table growth the author has suggested > > adding significant > > > > complexity to the configuration and management > > of multihomed customers > > > > without showing any benefit for the effort. > > > > > > > > An area not addressed at all in the document is > > that of multihoming > > > > for access to networks attached to a given ISP, > > rather than access to > > > > that ISP. For example, using the diagram above, > > if Customer-A > > > > purchased connectivity to ISP-2 because ISP-2 > > had better connectivity > > > > to ISP-4, then the offered multihoming solution > > is of no use. ISP-4 > > > > will never see reachability to Customer-A via > > ISP-2. > > > > > > > > Now, if everyone is done threatening legal > > action, perhaps we could > > > > return to the business of network engineering. > > > > > > > > Ben > > > > > > > > On Wed, Jun 28, 2000 at 07:13:33AM -0700, > > Jessica Yu wrote: > > > > > By the way, unless there are technical > > arguments and > > > > > credible facts in your responses, I am not > > going to > > > > > send more messages. > > > > > > > > > > --Jessica > > > > > > > > > > --- Jessica Yu wrote: > > > > > > > > > > > > This has already been answered in the thread > > of > > > > > > discussion on this topic a while back. > > Please go > > > > > > back > > > > > > to read the thread before you make any more > > > > > > inaccurate > > > > > > and irresponsible assertions. > > > > > > > > > > > > You said most network operators see no > > value. Where > > > > > > did you get this? Who are the most > > operators? Please > > > > > > be more responsible when you make > > assertions. > > > > > > > > > > > > > > > > > > --Jessica > > > > > > > > > > > > --- Ben Black wrote: > > > > > > > In all seriousness, would someone please > > explain > > > > > > the > > > > > > > benefits of > > > > > > > this approach in comparison tot he RFC2260 > > > > > > approach? > > > > > > > > > > > > > > I have *never* seen a single example and > > judging > > > > > > by > > > > > > > the feedback > > > > > > > the draft has gotten, most network > > operators see > > > > > > no > > > > > > > value to it > > > > > > > whatsoever. That alone should be a strong > > > > > > > indication the proposal > > > > > > > should be closely scrutinized before > > acceptance > > > > > > for > > > > > > > any further > > > > > > > circulation. > > > > > > > > > > > > > > Simply voting to have a draft moved to RFC > > without > > > > > > > answering > > > > > > > numerous, legitimate questions regarding > > its value > > > > > > > would seem a > > > > > > > very poor method for developing quality > > technical > > > > > > > documents. > > > > > > > > > > > > > > > > > > > > > Ben > > > > > > > > > > > > > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, > > Jim > > > > > > Bound > > > > > > > wrote: > > > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 11:08:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TI6jx18543 for ipng-dist; Thu, 29 Jun 2000 11:06:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TI6a618536 for ; Thu, 29 Jun 2000 11:06:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA26076 for ; Thu, 29 Jun 2000 11:06:35 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17586 for ; Thu, 29 Jun 2000 12:06:32 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA41082; Thu, 29 Jun 2000 19:06:28 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA18200; Thu, 29 Jun 2000 19:06:27 +0100 (BST) Message-ID: <395B8FCC.946CC064@hursley.ibm.com> Date: Thu, 29 Jun 2000 13:05:00 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ben Black CC: Jessica Yu , Jim Bound , Vijay Gill , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation" References: <20000629143320.2039.qmail@web3004.mail.yahoo.com> <20000629094834.A12427@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ben, You are not listening. Nobody said it was superior. It is one choice among several. We like choice. Brian Ben Black wrote: > > Please note that I specifically said "more appropriate", not > just "at all appropriate". Your draft describes a set of > scenarios where it is applicable, but does not explain how it > is superior in any way to other approaches, such as RFC2260. > > Ben > > On Thu, Jun 29, 2000 at 07:33:20AM -0700, Jessica Yu wrote: > > --- Ben Black wrote: > > > What makes it inappropriate at this time is the lack > > > of a clear > > > definition of *when* this solution is more > > > appropriate than others. > > > > This is again another inaccurate assertion. In section > > 4 of my I-D (attached below), it clearly documented in > > what situations this approach is more suitable. > > > > At this point, I am not even sure if you read my draft > > or not. You have been making so many inaccurate > > assertions and unfound claims that I do not think what > > you are saying is credible any more. > > > > --Jessica > > > > 4. Conclusions > > > > It wouldn't be hard to understand that even those > > enterprises desire > > multiple Internet connections may have different > > criterias and > > resource constrains for implementing such > > connection. Some may > > require absolute redundancy while most may only > > desire reasonable > > redundancy. This document offers a viable > > multihoming solution for an > > enterprise to choose based on its particular > > requirements and > > constrains. The multihoming mechanism described in > > this document is > > applicable to various multihoming scenarios, the > > most suitable > > environment for deploying it are: > > > > a. ISPs serving the multi-homed site have direct > > connection(s) to > > each other. Although such direct connection is > > not required, it > > would make arrangement simpler and will also > > improve aggregation > > by limiting specific routes visible only to ISPs > > serving the > > multi-homed site. > > > > b. Enterprises with requirements for good > > redundancy but not > > absolute redundancy. > > > > c. Enterprises with limited to resource for > > onsite sophisticated > > network administrators > > > > d. Enterprises able to choose a robust ISP as > > primary provider. > > > > Although not the main focus, the mechanism > > described in this > > document can also be used to improve routing > > scalability within > > networks shares one aggregation block or Top > > Level Aggregator > > (TLA). > > > > > > --- Ben Black wrote: > > > What makes it inappropriate at this time is the lack > > > of a clear > > > definition of *when* this solution is more > > > appropriate than others. > > > If it only provides a subset of the functionality, > > > has minimal > > > redundancy benefits, increases management overhead, > > > and doesn't > > > have a clearly met set of goals, why should it be > > > put forth as an > > > RFC giving people the impression it has somehow been > > > blessed as > > > a good idea? > > > > > > > > > Ben > > > > > > On Wed, Jun 28, 2000 at 04:10:23PM -0500, Brian E > > > Carpenter wrote: > > > > Ben, > > > > > > > > You observe that Jessica's proposal does not > > > resolve all cases > > > > of failover. True. This was obvious from the first > > > draft. We > > > > all agree. > > > > > > > > Why does this make it inappropriate to publish the > > > document, > > > > as a solution for certain types of failover? > > > > > > > > Brian > > > > > > > > Ben Black wrote: > > > > > > > > > > OK, here are detailed technical arguments which > > > have not been > > > > > addressed: > > > > > > > > > > >From Section 4 (Concerns): > > > > > > > > > > - The primary ISP is the sole interface > > > for the multihomed > > > > > customer to the Internet other than the > > > ISPs the customer has > > > > > directly connection with. Outages such as > > > one between ISP-1 and > > > > > ISP-4 would impact the reachability from > > > customers of ISP-4 to > > > > > Customer-A even though ISP-2 still has > > > good connection to ISP-4. > > > > > However, if the primary ISP is a good > > > quality ISP, this sort of > > > > > situation should happen rarely. The reason > > > is that it's common > > > > > practice that an ISP, especially good > > > quality ISP, has multiple > > > > > connections to other big ISPs at different > > > geographical locations. > > > > > Good quality ISPs also have robust network > > > design to prevent any > > > > > failure to impact the whole network. > > > Choosing a good quality and > > > > > robust ISP as primary ISP is a good > > > practice. > > > > > > > > > > This is really the crux of the problem with the > > > solution put forth in > > > > > the document. The assumption that a given ISP > > > will never have > > > > > failures, or that rare failures are acceptable > > > to customers who > > > > > multihomed for redundancy, is simply not valid > > > from an engineering > > > > > perspective. If the primary goal of multihoming > > > were load sharing, > > > > > this solution would provide one, potentially > > > very complicated, > > > > > answer. However, the issue of multihoming for > > > redundancy is totally > > > > > ignored, drawing into question the need for a > > > second ISP in the > > > > > equation at all. Why not simply purchase > > > additional bandwidth from > > > > > the same ISP? > > > > > > > > > > >From Section 4 (Concerns): > > > > > > > > > > It is desirable to have solution which > > > provides perfect redundancy > > > > > and, at the same time, simplicity to scale > > > management and operation. > > > > > In the absence of a perfect solution, the > > > trade-off needs to be made. > > > > > The author believes that it is very important > > > that the solution has > > > > > to be simple and manageable. Manageability > > > should be the top > > > > > consideration. > > > > > > > > > > If managability of the solution is to be the top > > > consideration, the > > > > > response put forward does not measure up. In > > > the name of avoiding > > > > > routing table growth the author has suggested > > > adding significant > > > > > complexity to the configuration and management > > > of multihomed customers > > > > > without showing any benefit for the effort. > > > > > > > > > > An area not addressed at all in the document is > > > that of multihoming > > > > > for access to networks attached to a given ISP, > > > rather than access to > > > > > that ISP. For example, using the diagram above, > > > if Customer-A > > > > > purchased connectivity to ISP-2 because ISP-2 > > > had better connectivity > > > > > to ISP-4, then the offered multihoming solution > > > is of no use. ISP-4 > > > > > will never see reachability to Customer-A via > > > ISP-2. > > > > > > > > > > Now, if everyone is done threatening legal > > > action, perhaps we could > > > > > return to the business of network engineering. > > > > > > > > > > Ben > > > > > > > > > > On Wed, Jun 28, 2000 at 07:13:33AM -0700, > > > Jessica Yu wrote: > > > > > > By the way, unless there are technical > > > arguments and > > > > > > credible facts in your responses, I am not > > > going to > > > > > > send more messages. > > > > > > > > > > > > --Jessica > > > > > > > > > > > > --- Jessica Yu wrote: > > > > > > > > > > > > > > This has already been answered in the thread > > > of > > > > > > > discussion on this topic a while back. > > > Please go > > > > > > > back > > > > > > > to read the thread before you make any more > > > > > > > inaccurate > > > > > > > and irresponsible assertions. > > > > > > > > > > > > > > You said most network operators see no > > > value. Where > > > > > > > did you get this? Who are the most > > > operators? Please > > > > > > > be more responsible when you make > > > assertions. > > > > > > > > > > > > > > > > > > > > > --Jessica > > > > > > > > > > > > > > --- Ben Black wrote: > > > > > > > > In all seriousness, would someone please > > > explain > > > > > > > the > > > > > > > > benefits of > > > > > > > > this approach in comparison tot he RFC2260 > > > > > > > approach? > > > > > > > > > > > > > > > > I have *never* seen a single example and > > > judging > > > > > > > by > > > > > > > > the feedback > > > > > > > > the draft has gotten, most network > > > operators see > > > > > > > no > > > > > > > > value to it > > > > > > > > whatsoever. That alone should be a strong > > > > > > > > indication the proposal > > > > > > > > should be closely scrutinized before > > > acceptance > > > > > > > for > > > > > > > > any further > > > > > > > > circulation. > > > > > > > > > > > > > > > > Simply voting to have a draft moved to RFC > > > without > > > > > > > > answering > > > > > > > > numerous, legitimate questions regarding > > > its value > > > > > > > > would seem a > > > > > > > > very poor method for developing quality > > > technical > > > > > > > > documents. > > > > > > > > > > > > > > > > > > > > > > > > Ben > > > > > > > > > > > > > > > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, > > > Jim > > > > > > > Bound > > > > > > > > wrote: > > > > > === message truncated === > > > > > > __________________________________________________ > > Do You Yahoo!? > > Get Yahoo! Mail - Free email you can access from anywhere! > > http://mail.yahoo.com/ > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 11:43:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TIfVd18589 for ipng-dist; Thu, 29 Jun 2000 11:41:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TIfM618582 for ; Thu, 29 Jun 2000 11:41:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA01608 for ; Thu, 29 Jun 2000 11:41:21 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11332 for ; Thu, 29 Jun 2000 11:41:16 -0700 (PDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 137jFH-0000eX-00; Thu, 29 Jun 2000 14:41:04 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA06232; Thu, 29 Jun 00 14:39:00 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA12742; Thu, 29 Jun 2000 14:44:06 -0400 Message-Id: <395B98B9.DF61197D@txc.com> Date: Thu, 29 Jun 2000 14:43:06 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Brian E Carpenter Cc: Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter References: <4.3.2.7.2.20000623143215.01c42da8@mailhost.iprg.nokia.com> <3958D134.16F37FCD@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While I agree with the chairs and the WG that the flow ID work must be completed, and I agree with you that the expertise in other IETF areas can be very useful to get the flow label work going, I am concerned that the work has less of a chance to be completed without a specific WG to do it. The "TraffiC Class" field is an example where things worked well: the output from the Diff-Serv WG affects directly the field. Did you have in mind something similar when you made the suggestion? Alex Brian E Carpenter wrote: > I can't hekp wondering whether the flow label issue should be sent off > to the Transport area for consideration. > > Brian > > Bob Hinden wrote: > > > > Folks, > > > > Attached is a draft of a revised charter for the working group. Updating > > the charter was agreed to at the Grenoble and Minneapolis working group > > meetings, but it took the chairs and AD's a while to draft a new one. > > > > The charter includes changing the name of the working group to the "IP > > Version 6 Working Group", but will keep the acronym of "ipngwg". This will > > avoid having to rename all current internet drafts. > > > > Please send comments on the new charter to the mailing list. There will be > > a short session in Pittsburgh to discuss it as well. > > > > Bob Hinden / Steve Deering > > > > ----------------------------------------------------------------------------- > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > > ----------------------------------------------------------------------------- > > > > IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym > > > > Chair(s): > > > > Bob Hinden > > Steve Deering > > > > Document Editor > > > > Bob Hinden (hinden@iprg.nokia.com) > > > > Internet Area Director(s): > > > > Thomas Narten > > Erik Nordmark > > > > Internet Area Advisor: > > > > Thomas Narten > > > > Mailing Lists: > > > > General Discussion:ipng@sunroof.eng.sun.com > > To Subscribe: majordomo@sunroof.eng.sun.com > > In Body: in body: subscribe ipng > > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > > > Description of Working Group: > > > > IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) > > is intended to support the continued growth of the Internet, both in > > size and capabilities, by offering a greatly increased IP address space > > and other enhancements over IPv4. The working group was originally > > chartered to implement the recommendations of the IPng Area Directors > > as outlined at the July 1994 IETF meeting and in "The Recommendation > > for the IP Next Generation Protocol," RFC1752, January 1995. Most of > > the tasks in that original charter have been completed, and the core > > IPv6 protocol specifications are now on the IETF standards track. > > The working group's ongoing responsibilities are as follows: > > > > - Complete work from the original charter and follow-on work, as > > outlined below. > > > > - Keep all IPv6 working group documents moving along publication / > > standardization track. > > > > - Serve as a review board and body of competence and coordination for > > IPv6 architectural issues that span multiple IETF working groups. > > > > - Provide a home for IPv6-related work that doesn't fit in an existing > > IETF working group and doesn't merit a working group of its own. > > > > - Provide technical input to ICANN, Internet Address Registries, and > > IANA with regard to IPv6 address allocation policies and procedures. > > > > - Provide technical input and review to IANA with regard to IPv6 > > protocol and parameter assignments. > > > > The list of the working group's current work items is as follows: > > > > - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, > > editorial) > > - Revise Generic Tunneling spec (add bidirectional tunnels) > > - Update Basic and Advanced API specs > > - Complete Router Renumbering spec > > - Complete Scoped Address Architecture spec and any necessary revisions > > to other working group drafts required to properly implement support > > for IPv6 address scoping > > - Complete work on recommended address-selection algorithms > > - Work on new solutions to site-multihoming problems, possibly including > > both host-based and router-based solutions. > > - Complete work on local IPv6 networking as part of IPv6 plug-and-play > > - Complete work on privacy extensions to stateless address configuration > > - Document IPv6 renumbering model > > - Complete the GSE Analysis document > > - Complete the Inverse Neighbor Discovery spec > > - Complete the IPv6 Node Information Queries spec > > - Complete MIB specs as required by any working group protocol specs > > > > New work items not listed above require the approval of the working > > group and Internet Area directors before they will be taken on by the > > working group. > > > > The working group would welcome contributions on the following topics > > (this is not an exhaustive list): > > > > - Flow label standardization > > - Solutions to other multihoming issues, beyond those specific to > > site-multihoming > > - Integration of autoconfiguration, mobility, DNS, service discovery > > and other technologies to enhance IPv6 plug-and-play > > - IPv6 dial-up issues relating to address assignment, use of Neighbor > > Discovery, etc. (not including AAA work) > > - Specifications for IPv6 over additional media > > - Extending MLD to include functionality of IGMPv3 > > - Host use of anycast; TCP use of anycast > > - Support for multi-link subnets (single subnet spans multiple links) > > - Scope-name discovery > > - IPv6 protocol extensions to accommodate mobile wireless networks. > > > > Goals and Milestones: > > > > Aug 2000 Complete MLD MIB and submit for Proposed Standard > > > > Aug 2000 Complete privacy extensions specification and submit for > > Proposed Standard > > > > Aug 2000 Completed revision of GSE Analysis document and resubmit > > for Informational > > > > Aug 2000 Complete the Inverse Neighbor Discovery specification > > and submit for Proposed Standard > > > > Aug 2000 Complete IPv6 Multihoming with Route Aggregation and submit > > for Informational. > > > > Oct 2000 Update ICMP document and resubmit for Draft Standard > > > > Oct 2000 Update Generic Tunneling specification and resubmit for > > Proposed Standard > > > > Oct 2000 Complete updates to Basic and Advanced API specifications > > and submit for Informational > > > > Dec 2000 Complete Scoped Address Architecture and submit for Proposed > > Standard > > > > Dec 2000 Compete Address Selection specification and submit for Proposed > > Standard > > > > Dec 2000 Complete Local IPv6 Networking Specification and submit for > > Proposed Standard > > > > Dec 2000 Complete the IPv6 Node Information Queries specification > > and submit for Proposed Standard > > > > Mar 2001 Complete IPv6 renumbering model document and submit for > > Informational > > > > ----------------------------------------------------------------------------- > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > > ----------------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 13:39:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TKb2o18821 for ipng-dist; Thu, 29 Jun 2000 13:37:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TKaq618814 for ; Thu, 29 Jun 2000 13:36:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA01080 for ; Thu, 29 Jun 2000 13:36:51 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13874 for ; Thu, 29 Jun 2000 14:36:50 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA28148; Thu, 29 Jun 2000 21:36:42 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA23184; Thu, 29 Jun 2000 21:36:41 +0100 (BST) Message-ID: <395BB2FE.E29B26D7@hursley.ibm.com> Date: Thu, 29 Jun 2000 15:35:10 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta CC: Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter References: <4.3.2.7.2.20000623143215.01c42da8@mailhost.iprg.nokia.com> <3958D134.16F37FCD@hursley.ibm.com> <395B98B9.DF61197D@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, I don't think the issue is separable from other QOS issues. That means that DIFFSERV, INTSERV and ISSLL are all concerned at some level. So I think it needs to be raised first in the TSV Area meeting. I agree that once the topic has been clarified, a work item should be identified and then we can see which WG should handle it - it can't be left floating. (I'm much less clear about routing, I have to say. I suspect that flow-label based routing would prove to be a pure rathole.) Brian Alex Conta wrote: > > While I agree with the chairs and the WG that the flow ID work must be completed, > and I agree with you that the expertise in other IETF areas can be very useful to > get the flow label work going, I am concerned that the work > has less of a chance to be completed without a specific WG to do it. > > The "TraffiC Class" field is an example where things worked well: the output from > the Diff-Serv WG affects directly > the field. > > Did you have in mind something similar when you made the suggestion? > > Alex > > Brian E Carpenter wrote: > > > I can't hekp wondering whether the flow label issue should be sent off > > to the Transport area for consideration. > > > > Brian > > > > Bob Hinden wrote: > > > > > > Folks, > > > > > > Attached is a draft of a revised charter for the working group. Updating > > > the charter was agreed to at the Grenoble and Minneapolis working group > > > meetings, but it took the chairs and AD's a while to draft a new one. > > > > > > The charter includes changing the name of the working group to the "IP > > > Version 6 Working Group", but will keep the acronym of "ipngwg". This will > > > avoid having to rename all current internet drafts. > > > > > > Please send comments on the new charter to the mailing list. There will be > > > a short session in Pittsburgh to discuss it as well. > > > > > > Bob Hinden / Steve Deering > > > > > > ----------------------------------------------------------------------------- > > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > > > ----------------------------------------------------------------------------- > > > > > > IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym > > > > > > Chair(s): > > > > > > Bob Hinden > > > Steve Deering > > > > > > Document Editor > > > > > > Bob Hinden (hinden@iprg.nokia.com) > > > > > > Internet Area Director(s): > > > > > > Thomas Narten > > > Erik Nordmark > > > > > > Internet Area Advisor: > > > > > > Thomas Narten > > > > > > Mailing Lists: > > > > > > General Discussion:ipng@sunroof.eng.sun.com > > > To Subscribe: majordomo@sunroof.eng.sun.com > > > In Body: in body: subscribe ipng > > > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > > > > > Description of Working Group: > > > > > > IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) > > > is intended to support the continued growth of the Internet, both in > > > size and capabilities, by offering a greatly increased IP address space > > > and other enhancements over IPv4. The working group was originally > > > chartered to implement the recommendations of the IPng Area Directors > > > as outlined at the July 1994 IETF meeting and in "The Recommendation > > > for the IP Next Generation Protocol," RFC1752, January 1995. Most of > > > the tasks in that original charter have been completed, and the core > > > IPv6 protocol specifications are now on the IETF standards track. > > > The working group's ongoing responsibilities are as follows: > > > > > > - Complete work from the original charter and follow-on work, as > > > outlined below. > > > > > > - Keep all IPv6 working group documents moving along publication / > > > standardization track. > > > > > > - Serve as a review board and body of competence and coordination for > > > IPv6 architectural issues that span multiple IETF working groups. > > > > > > - Provide a home for IPv6-related work that doesn't fit in an existing > > > IETF working group and doesn't merit a working group of its own. > > > > > > - Provide technical input to ICANN, Internet Address Registries, and > > > IANA with regard to IPv6 address allocation policies and procedures. > > > > > > - Provide technical input and review to IANA with regard to IPv6 > > > protocol and parameter assignments. > > > > > > The list of the working group's current work items is as follows: > > > > > > - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, > > > editorial) > > > - Revise Generic Tunneling spec (add bidirectional tunnels) > > > - Update Basic and Advanced API specs > > > - Complete Router Renumbering spec > > > - Complete Scoped Address Architecture spec and any necessary revisions > > > to other working group drafts required to properly implement support > > > for IPv6 address scoping > > > - Complete work on recommended address-selection algorithms > > > - Work on new solutions to site-multihoming problems, possibly including > > > both host-based and router-based solutions. > > > - Complete work on local IPv6 networking as part of IPv6 plug-and-play > > > - Complete work on privacy extensions to stateless address configuration > > > - Document IPv6 renumbering model > > > - Complete the GSE Analysis document > > > - Complete the Inverse Neighbor Discovery spec > > > - Complete the IPv6 Node Information Queries spec > > > - Complete MIB specs as required by any working group protocol specs > > > > > > New work items not listed above require the approval of the working > > > group and Internet Area directors before they will be taken on by the > > > working group. > > > > > > The working group would welcome contributions on the following topics > > > (this is not an exhaustive list): > > > > > > - Flow label standardization > > > - Solutions to other multihoming issues, beyond those specific to > > > site-multihoming > > > - Integration of autoconfiguration, mobility, DNS, service discovery > > > and other technologies to enhance IPv6 plug-and-play > > > - IPv6 dial-up issues relating to address assignment, use of Neighbor > > > Discovery, etc. (not including AAA work) > > > - Specifications for IPv6 over additional media > > > - Extending MLD to include functionality of IGMPv3 > > > - Host use of anycast; TCP use of anycast > > > - Support for multi-link subnets (single subnet spans multiple links) > > > - Scope-name discovery > > > - IPv6 protocol extensions to accommodate mobile wireless networks. > > > > > > Goals and Milestones: > > > > > > Aug 2000 Complete MLD MIB and submit for Proposed Standard > > > > > > Aug 2000 Complete privacy extensions specification and submit for > > > Proposed Standard > > > > > > Aug 2000 Completed revision of GSE Analysis document and resubmit > > > for Informational > > > > > > Aug 2000 Complete the Inverse Neighbor Discovery specification > > > and submit for Proposed Standard > > > > > > Aug 2000 Complete IPv6 Multihoming with Route Aggregation and submit > > > for Informational. > > > > > > Oct 2000 Update ICMP document and resubmit for Draft Standard > > > > > > Oct 2000 Update Generic Tunneling specification and resubmit for > > > Proposed Standard > > > > > > Oct 2000 Complete updates to Basic and Advanced API specifications > > > and submit for Informational > > > > > > Dec 2000 Complete Scoped Address Architecture and submit for Proposed > > > Standard > > > > > > Dec 2000 Compete Address Selection specification and submit for Proposed > > > Standard > > > > > > Dec 2000 Complete Local IPv6 Networking Specification and submit for > > > Proposed Standard > > > > > > Dec 2000 Complete the IPv6 Node Information Queries specification > > > and submit for Proposed Standard > > > > > > Mar 2001 Complete IPv6 renumbering model document and submit for > > > Informational > > > > > > ----------------------------------------------------------------------------- > > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > > > ----------------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 15:03:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TM1Uk18949 for ipng-dist; Thu, 29 Jun 2000 15:01:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TM1L618942 for ; Thu, 29 Jun 2000 15:01:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA19492 for ; Thu, 29 Jun 2000 15:01:21 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17164 for ; Thu, 29 Jun 2000 16:01:19 -0600 (MDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 137mN0-0005oX-00; Thu, 29 Jun 2000 18:01:14 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA07621; Thu, 29 Jun 00 17:59:09 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA17871; Thu, 29 Jun 2000 18:04:16 -0400 Message-Id: <395BC7A1.D72CB7ED@txc.com> Date: Thu, 29 Jun 2000 18:03:13 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Brian E Carpenter Cc: Bob Hinden , ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Revised IPng Working Group Charter References: <4.3.2.7.2.20000623143215.01c42da8@mailhost.iprg.nokia.com> <3958D134.16F37FCD@hursley.ibm.com> <395B98B9.DF61197D@txc.com> <395BB2FE.E29B26D7@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I agree with you that the flow ID work should be focused on QoS specifics (flow identification and classification) rather than routing. IMHO any serious focus on flow ID routing would intersect sooner or later with MPLS, and the folks in the MPLS WG have done a lot of the the work on labeling flows and forwarding flows based on labels in such a way in which that work stands on its own, independent of IPv6, or the IPv6 header format. Which is to say that there is not too much to do in IPv6 for that purpose. Alex Brian E Carpenter wrote: > Alex, I don't think the issue is separable from other QOS issues. That > means that DIFFSERV, INTSERV and ISSLL are all concerned at some level. > So I think it needs to be raised first in the TSV Area meeting. > I agree that once the topic has been clarified, a work item should > be identified and then we can see which WG should handle it - it can't > be left floating. > > (I'm much less clear about routing, I have to say. I suspect that flow-label > based routing would prove to be a pure rathole.) > > Brian > > Alex Conta wrote: > > > > While I agree with the chairs and the WG that the flow ID work must be completed, > > and I agree with you that the expertise in other IETF areas can be very useful to > > get the flow label work going, I am concerned that the work > > has less of a chance to be completed without a specific WG to do it. > > > > The "TraffiC Class" field is an example where things worked well: the output from > > the Diff-Serv WG affects directly > > the field. > > > > Did you have in mind something similar when you made the suggestion? > > > > Alex > > > > Brian E Carpenter wrote: > > > > > I can't hekp wondering whether the flow label issue should be sent off > > > to the Transport area for consideration. > > > > > > Brian > > > > > > Bob Hinden wrote: > > > > > > > > Folks, > > > > > > > > Attached is a draft of a revised charter for the working group. Updating > > > > the charter was agreed to at the Grenoble and Minneapolis working group > > > > meetings, but it took the chairs and AD's a while to draft a new one. > > > > > > > > The charter includes changing the name of the working group to the "IP > > > > Version 6 Working Group", but will keep the acronym of "ipngwg". This will > > > > avoid having to rename all current internet drafts. > > > > > > > > Please send comments on the new charter to the mailing list. There will be > > > > a short session in Pittsburgh to discuss it as well. > > > > > > > > Bob Hinden / Steve Deering > > > > > > > > ----------------------------------------------------------------------------- > > > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > > > > ----------------------------------------------------------------------------- > > > > > > > > IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym > > > > > > > > Chair(s): > > > > > > > > Bob Hinden > > > > Steve Deering > > > > > > > > Document Editor > > > > > > > > Bob Hinden (hinden@iprg.nokia.com) > > > > > > > > Internet Area Director(s): > > > > > > > > Thomas Narten > > > > Erik Nordmark > > > > > > > > Internet Area Advisor: > > > > > > > > Thomas Narten > > > > > > > > Mailing Lists: > > > > > > > > General Discussion:ipng@sunroof.eng.sun.com > > > > To Subscribe: majordomo@sunroof.eng.sun.com > > > > In Body: in body: subscribe ipng > > > > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > > > > > > > Description of Working Group: > > > > > > > > IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) > > > > is intended to support the continued growth of the Internet, both in > > > > size and capabilities, by offering a greatly increased IP address space > > > > and other enhancements over IPv4. The working group was originally > > > > chartered to implement the recommendations of the IPng Area Directors > > > > as outlined at the July 1994 IETF meeting and in "The Recommendation > > > > for the IP Next Generation Protocol," RFC1752, January 1995. Most of > > > > the tasks in that original charter have been completed, and the core > > > > IPv6 protocol specifications are now on the IETF standards track. > > > > The working group's ongoing responsibilities are as follows: > > > > > > > > - Complete work from the original charter and follow-on work, as > > > > outlined below. > > > > > > > > - Keep all IPv6 working group documents moving along publication / > > > > standardization track. > > > > > > > > - Serve as a review board and body of competence and coordination for > > > > IPv6 architectural issues that span multiple IETF working groups. > > > > > > > > - Provide a home for IPv6-related work that doesn't fit in an existing > > > > IETF working group and doesn't merit a working group of its own. > > > > > > > > - Provide technical input to ICANN, Internet Address Registries, and > > > > IANA with regard to IPv6 address allocation policies and procedures. > > > > > > > > - Provide technical input and review to IANA with regard to IPv6 > > > > protocol and parameter assignments. > > > > > > > > The list of the working group's current work items is as follows: > > > > > > > > - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, > > > > editorial) > > > > - Revise Generic Tunneling spec (add bidirectional tunnels) > > > > - Update Basic and Advanced API specs > > > > - Complete Router Renumbering spec > > > > - Complete Scoped Address Architecture spec and any necessary revisions > > > > to other working group drafts required to properly implement support > > > > for IPv6 address scoping > > > > - Complete work on recommended address-selection algorithms > > > > - Work on new solutions to site-multihoming problems, possibly including > > > > both host-based and router-based solutions. > > > > - Complete work on local IPv6 networking as part of IPv6 plug-and-play > > > > - Complete work on privacy extensions to stateless address configuration > > > > - Document IPv6 renumbering model > > > > - Complete the GSE Analysis document > > > > - Complete the Inverse Neighbor Discovery spec > > > > - Complete the IPv6 Node Information Queries spec > > > > - Complete MIB specs as required by any working group protocol specs > > > > > > > > New work items not listed above require the approval of the working > > > > group and Internet Area directors before they will be taken on by the > > > > working group. > > > > > > > > The working group would welcome contributions on the following topics > > > > (this is not an exhaustive list): > > > > > > > > - Flow label standardization > > > > - Solutions to other multihoming issues, beyond those specific to > > > > site-multihoming > > > > - Integration of autoconfiguration, mobility, DNS, service discovery > > > > and other technologies to enhance IPv6 plug-and-play > > > > - IPv6 dial-up issues relating to address assignment, use of Neighbor > > > > Discovery, etc. (not including AAA work) > > > > - Specifications for IPv6 over additional media > > > > - Extending MLD to include functionality of IGMPv3 > > > > - Host use of anycast; TCP use of anycast > > > > - Support for multi-link subnets (single subnet spans multiple links) > > > > - Scope-name discovery > > > > - IPv6 protocol extensions to accommodate mobile wireless networks. > > > > > > > > Goals and Milestones: > > > > > > > > Aug 2000 Complete MLD MIB and submit for Proposed Standard > > > > > > > > Aug 2000 Complete privacy extensions specification and submit for > > > > Proposed Standard > > > > > > > > Aug 2000 Completed revision of GSE Analysis document and resubmit > > > > for Informational > > > > > > > > Aug 2000 Complete the Inverse Neighbor Discovery specification > > > > and submit for Proposed Standard > > > > > > > > Aug 2000 Complete IPv6 Multihoming with Route Aggregation and submit > > > > for Informational. > > > > > > > > Oct 2000 Update ICMP document and resubmit for Draft Standard > > > > > > > > Oct 2000 Update Generic Tunneling specification and resubmit for > > > > Proposed Standard > > > > > > > > Oct 2000 Complete updates to Basic and Advanced API specifications > > > > and submit for Informational > > > > > > > > Dec 2000 Complete Scoped Address Architecture and submit for Proposed > > > > Standard > > > > > > > > Dec 2000 Compete Address Selection specification and submit for Proposed > > > > Standard > > > > > > > > Dec 2000 Complete Local IPv6 Networking Specification and submit for > > > > Proposed Standard > > > > > > > > Dec 2000 Complete the IPv6 Node Information Queries specification > > > > and submit for Proposed Standard > > > > > > > > Mar 2001 Complete IPv6 renumbering model document and submit for > > > > Informational > > > > > > > > ----------------------------------------------------------------------------- > > > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > > > > ----------------------------------------------------------------------------- > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: http://playground.sun.com/ipng > > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 15:06:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TM5GY18971 for ipng-dist; Thu, 29 Jun 2000 15:05:16 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TM54618964 for ; Thu, 29 Jun 2000 15:05:04 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e5TM4ej499794; Thu, 29 Jun 2000 15:04:40 -0700 (PDT) Date: Thu, 29 Jun 2000 15:04:34 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: scoped-arch comments To: Alain RITOUX Cc: Erik.Nordmark@eng.sun.com, deering@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <395A204E.BC033329@detexis.thomson-csf.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have some comments about the scoped @ arch, about the scope_id. > - I definitly agree with E. Nordmark about storing all space names in a > single 32 bit box! This could be done using a quartet with same > signification as for multicast. Scope id could look like something as > 0x 00 0S zone_id > with 16 bits for zone id, and S being set to 2 for link-id, 5 for > site-id ... > zone_id might be set to nul to let the default zone ot be taken. hence > 0x00020000 being the default link. For compatibility with what we have in RFC 2553 I think you want to still handle just an ifindex i.e. the high order bits being zero should mean that the low order bits is an ifindex. But I still think your general approach with using the defined (multicast) scope values is a good idea. Of course, this can all be hidden in the if_nametoindex type APIs. Thus you'd get 0 Interface ID 1 - 2 Link ID 5 Site ID ... If we go this path (allowing different scope zones ids in sin6_scope_id) it might make sense to add parallels to the if_nametoindex() etc APIs. Either site_nametoindex(), site_indextoname(), site_nameindex() link_nametoindex(), ... or a more general set of routines sz_nametoindex(char *name, int scope_level) That way we can add protocol support (something like MZAP?) for advertising scope zone names in the future. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 16:33:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5TNUxR19158 for ipng-dist; Thu, 29 Jun 2000 16:30:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5TNUn619151 for ; Thu, 29 Jun 2000 16:30:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA02605 for ; Thu, 29 Jun 2000 16:30:49 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11367 for ; Thu, 29 Jun 2000 16:30:47 -0700 (PDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id QAA19541; Thu, 29 Jun 2000 16:28:54 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D810249B8E7A@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D810249B8E7A@RED-MSG-50> Date: Thu, 29 Jun 2000 16:29:00 -0700 To: Richard Draves From: Steve Deering Subject: RE: rfc2553bis comments Cc: Dave Thaler , Francis.Dupont@enst-bretagne.fr, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:45 PM -0700 6/26/00, Richard Draves wrote: >I'm warming up to Dave's proposal, but I would not invent new zone ids for >all the different multicast scope levels. (Or at least I'd leave this >optional for implementations.) I'd map the multicast scope levels into the >link-local/site-local/global unicast scopes. I don't think you have to create zone IDs for all multicast scope levels *nor* do I think you have to "map" those levels into the unicast levels. Rather, you only need zone IDs for those scopes for which you are a boundary (or in other words, only for those zones for which you are attached to more than one of the same scope). Whenever dealing with an address (multicast or unicast) of a scope for which you are not a boundary, the appropriate zone is unambiguous (all your interfaces belong to a single zone of that scope), so you can just use the "unspecified" (e.g., zero valued) zone id in the sin6_scope_id that accompanies that address. 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 Jun 29 17:12:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U0ADO19239 for ipng-dist; Thu, 29 Jun 2000 17:10:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U09r619232 for ; Thu, 29 Jun 2000 17:09:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA20609 for ; Thu, 29 Jun 2000 17:09:50 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA28834 for ; Thu, 29 Jun 2000 17:09:50 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Jun 2000 16:40:38 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 29 Jun 2000 16:48:33 -0700 content-class: urn:content-classes:message Subject: RE: rfc2553bis comments MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE223.9F48E2F0" x-mimeole: Produced By Microsoft Exchange V6.0.4408.0 Date: Thu, 29 Jun 2000 16:42:01 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690C6F7AB9@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc2553bis comments Thread-Index: Ab/iIjFBuSwKK1+lTJyYBT2R20vyEQAAUYGQ From: "Dave Thaler" To: "Steve Deering" , "Richard Draves" Cc: "Dave Thaler" , , , X-OriginalArrivalTime: 29 Jun 2000 23:48:33.0772 (UTC) FILETIME=[892BEAC0:01BFE224] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFE223.9F48E2F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think Steve is _almost_ right :-) and I was thinking along these same lines. I believe it should be that for a given scope level, all interfaces within the next higher well-known scope level are within the same scope of that level. For example scop 4, being smaller than site-local scope, should use the site-local scope ids. If you're in multiple sites, you can't assume all interfaces are in the same scop 4 zone. So by default scopes 6 and higher just use 0 (same as global), 3-5 use site ids, and 2 uses ifindex. So my proposed correction to Steve's rule is: "Whenever dealing with an address (multicast or unicast) of=20 a scope for which you are not a boundary, the appropriate zone is unambiguous, so the sin6_scope_id is the same zone id of the next larger scope for which you are a boundary (e.g., zero if you are not a boundary for any larger scope level)." -Dave > -----Original Message----- > From: Steve Deering [mailto:deering@cisco.com] > Sent: Thursday, June 29, 2000 4:29 PM > To: Richard Draves > Cc: Dave Thaler; Francis.Dupont@enst-bretagne.fr; > jinmei@isl.rdc.toshiba.co.jp; ipng@sunroof.eng.sun.com > Subject: RE: rfc2553bis comments >=20 >=20 > At 1:45 PM -0700 6/26/00, Richard Draves wrote: > >I'm warming up to Dave's proposal, but I would not invent=20 > new zone ids for > >all the different multicast scope levels. (Or at least I'd leave this > >optional for implementations.) I'd map the multicast scope=20 > levels into the > >link-local/site-local/global unicast scopes. >=20 > I don't think you have to create zone IDs for all multicast=20 > scope levels > *nor* do I think you have to "map" those levels into the=20 > unicast levels. > Rather, you only need zone IDs for those scopes for which you are a > boundary (or in other words, only for those zones for which you are > attached to more than one of the same scope). Whenever=20 > dealing with an > address (multicast or unicast) of a scope for which you are=20 > not a boundary, > the appropriate zone is unambiguous (all your interfaces=20 > belong to a single > zone of that scope), so you can just use the "unspecified" (e.g., zero > valued) zone id in the sin6_scope_id that accompanies that address. >=20 > Steve >=20 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- >=20 ------_=_NextPart_001_01BFE223.9F48E2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: rfc2553bis comments

I think Steve is _almost_ right :-)
and I was thinking along these same lines.

I believe it should be that for a given scope = level,
all interfaces within the next higher = well-known
scope level are within the same scope of that = level.

For example scop 4, being smaller than site-local = scope,
should use the site-local scope ids.  If = you're
in multiple sites, you can't assume all = interfaces
are in the same scop 4 zone.

So by default scopes 6 and higher just use 0 (same = as
global), 3-5 use site ids, and 2 uses ifindex.

So my proposed correction to Steve's rule is:
"Whenever dealing with an address (multicast or = unicast) of
a scope for which you are not a boundary, the = appropriate zone
is unambiguous, so the sin6_scope_id is the same zone = id of
the next larger scope for which you are a boundary = (e.g., zero
if you are not a boundary for any larger scope = level)."

-Dave

> -----Original Message-----
> From: Steve Deering [mailto:deering@cisco.com]
> Sent: Thursday, June 29, 2000 4:29 PM
> To: Richard Draves
> Cc: Dave Thaler; = Francis.Dupont@enst-bretagne.fr;
> jinmei@isl.rdc.toshiba.co.jp; = ipng@sunroof.eng.sun.com
> Subject: RE: rfc2553bis comments
>
>
> At 1:45 PM -0700 6/26/00, Richard Draves = wrote:
> >I'm warming up to Dave's proposal, but I = would not invent
> new zone ids for
> >all the different multicast scope levels. = (Or at least I'd leave this
> >optional for implementations.) I'd map the = multicast scope
> levels into the
> >link-local/site-local/global unicast = scopes.
>
> I don't think you have to create zone IDs for = all multicast
> scope levels
> *nor* do I think you have to "map" = those levels into the
> unicast levels.
> Rather, you only need zone IDs for those scopes = for which you are a
> boundary (or in other words, only for those = zones for which you are
> attached to more than one of the same = scope).  Whenever
> dealing with an
> address (multicast or unicast) of a scope for = which you are
> not a boundary,
> the appropriate zone is unambiguous (all your = interfaces
> belong to a single
> zone of that scope), so you can just use the = "unspecified" (e.g., zero
> valued) zone id in the sin6_scope_id that = accompanies that address.
>
> Steve
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &n= bsp;          http://playground.sun.com/ipng
> FTP = archive:           = ;           ftp://playground.sun.com/pub/i= png
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01BFE223.9F48E2F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 17:24:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U0MIL19266 for ipng-dist; Thu, 29 Jun 2000 17:22:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U0Ls619259 for ; Thu, 29 Jun 2000 17:21:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA13291 for ; Thu, 29 Jun 2000 17:21:51 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA03735 for ; Thu, 29 Jun 2000 17:21:50 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Jun 2000 17:21:31 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Thu, 29 Jun 2000 17:21:29 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024BCF595@RED-MSG-50> From: Richard Draves To: Steve Deering Cc: Dave Thaler , Francis.Dupont@enst-bretagne.fr, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments Date: Thu, 29 Jun 2000 17:21:25 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I'm warming up to Dave's proposal, but I would not invent > new zone ids for > >all the different multicast scope levels. (Or at least I'd leave this > >optional for implementations.) I'd map the multicast scope > levels into the > >link-local/site-local/global unicast scopes. > > I don't think you have to create zone IDs for all multicast > scope levels > *nor* do I think you have to "map" those levels into the > unicast levels. > Rather, you only need zone IDs for those scopes for which you are a > boundary (or in other words, only for those zones for which you are > attached to more than one of the same scope). Whenever > dealing with an > address (multicast or unicast) of a scope for which you are > not a boundary, > the appropriate zone is unambiguous (all your interfaces > belong to a single > zone of that scope), so you can just use the "unspecified" (e.g., zero > valued) zone id in the sin6_scope_id that accompanies that address. I'm (mildly) concerned about how much state an implementation has to maintain per interface. Right now in the interface structure we have fields for an interface id and a site id. If our implementation might be used in boundary situations for the different multicast scope levels, does that mean the interface structure must grow to accommodate ~16 zone ids at the different levels? Of course this isn't the biggest space hit for an interface by far. 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 Jun 29 17:43:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U0fmG19295 for ipng-dist; Thu, 29 Jun 2000 17:41:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U0fZ619288 for ; Thu, 29 Jun 2000 17:41:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA25897 for ; Thu, 29 Jun 2000 17:41:34 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA11322 for ; Thu, 29 Jun 2000 17:41:33 -0700 (PDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id RAA22834; Thu, 29 Jun 2000 17:39:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19398D273324D3118A2B0008C7E9A5690C6F7AB9@SIT.platinum.corp.microsoft.com> References: <19398D273324D3118A2B0008C7E9A5690C6F7AB9@SIT.platinum.corp.microsoft.com> Date: Thu, 29 Jun 2000 17:39:38 -0700 To: "Dave Thaler" From: Steve Deering Subject: RE: rfc2553bis comments Cc: "Richard Draves" , "Dave Thaler" , , , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:42 PM -0700 6/29/00, Dave Thaler wrote: >For example scop 4, being smaller than site-local scope, >should use the site-local scope ids. If you're >in multiple sites, you can't assume all interfaces >are in the same scop 4 zone. Hmm, yes, I can see how you can use that approach to avoid creating zone indices for scop 4 on site-boundary nodes. I was working from the assumption that you *would* have scop 4 zone ids on such a node, i.e., *if* scop 4 were configured to be used within a site, it would have to be configured on all site-boundary nodes. However, you still need the capability to explicitly configure scop 4 zone ids on site-boundary nodes, in case the node is attached (via different interfaces) to more than one scop 4 zone within the same site. And you also need the capability to configure scop 4 zone ids on nodes that are internal to a site, i.e., not site-boundary nodes. >So my proposed correction to Steve's rule is: >"Whenever dealing with an address (multicast or unicast) of >a scope for which you are not a boundary, the appropriate zone >is unambiguous, so the sin6_scope_id is the same zone id of >the next larger scope for which you are a boundary (e.g., zero >if you are not a boundary for any larger scope level)." That's still not quite right, because if you are a boundary for scope x, you are *necessarily* a boundary for all configured scopes less than x, since a smaller zone cannot span across boundaries of a larger zone. 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 Jun 29 18:26:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U1OHa19337 for ipng-dist; Thu, 29 Jun 2000 18:24:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U1O7619330 for ; Thu, 29 Jun 2000 18:24:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA22491 for ; Thu, 29 Jun 2000 18:24:08 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA26967 for ; Thu, 29 Jun 2000 18:24:06 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Jun 2000 17:58:23 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 29 Jun 2000 18:05:50 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: rfc2553bis comments Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE22E.6ACEB86E" x-mimeole: Produced By Microsoft Exchange V6.0.4408.0 Date: Thu, 29 Jun 2000 17:59:17 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690C6F7ABB@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc2553bis comments Thread-Index: Ab/iKtkwG/QxDfyXToWJTj+3mDrHHAAAdiqQ From: "Dave Thaler" To: "Steve Deering" Cc: "Richard Draves" , , , X-OriginalArrivalTime: 30 Jun 2000 01:05:50.0110 (UTC) FILETIME=[54A4F3E0:01BFE22F] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFE22E.6ACEB86E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve Deering replied: > At 4:42 PM -0700 6/29/00, Dave Thaler wrote: > >For example scop 4, being smaller than site-local scope, > >should use the site-local scope ids. If you're > >in multiple sites, you can't assume all interfaces > >are in the same scop 4 zone. >=20 > Hmm, yes, I can see how you can use that approach to avoid creating > zone indices for scop 4 on site-boundary nodes. I was working from > the assumption that you *would* have scop 4 zone ids on such a node, > i.e., *if* scop 4 were configured to be used within a site, it > would have to be configured on all site-boundary nodes. Re "if scop 4 were configured to be used within a site"... So if we have a host with interfaces in two sites, and there's no manual configuration related to scop 4, and if an app tried to send to or join a multicast group in scop 4 are you saying that the send/join would fail? I'd rather be liberal in what we accept here and have it succeed, which is what I was trying to allow. > However, you still need the capability to explicitly configure scop 4 > zone ids on site-boundary nodes, in case the node is attached (via > different interfaces) to more than one scop 4 zone within the=20 > same site. Agree. > And you also need the capability to configure scop 4 zone ids on nodes > that are internal to a site, i.e., not site-boundary nodes. I didn't follow this. I was suggesting that you don't need separate scop 4 zone ids in this config, you use the same ids as for scop 5 (and you use a disjoint numbering space as Erik suggested to disambiguate this). > >So my proposed correction to Steve's rule is: > >"Whenever dealing with an address (multicast or unicast) of > >a scope for which you are not a boundary, the appropriate zone > >is unambiguous, so the sin6_scope_id is the same zone id of > >the next larger scope for which you are a boundary (e.g., zero > >if you are not a boundary for any larger scope level)." >=20 > That's still not quite right, because if you are a boundary for > scope x, you are *necessarily* a boundary for all configured scopes > less than x, since a smaller zone cannot span across boundaries > of a larger zone. I agree the wording "are not a boundary" is problematic here. -Dave ------_=_NextPart_001_01BFE22E.6ACEB86E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: rfc2553bis comments

Steve Deering replied:
> At 4:42 PM -0700 6/29/00, Dave Thaler = wrote:
> >For example scop 4, being smaller than = site-local scope,
> >should use the site-local scope ids.  = If you're
> >in multiple sites, you can't assume all = interfaces
> >are in the same scop 4 zone.
>
> Hmm, yes, I can see how you can use that = approach to avoid creating
> zone indices for scop 4 on site-boundary = nodes.  I was working from
> the assumption that you *would* have scop 4 zone = ids on such a node,
> i.e., *if* scop 4 were configured to be used = within a site, it
> would have to be configured on all site-boundary = nodes.

Re "if scop 4 were configured to be used within a = site"...
So if we have a host with interfaces in two sites, = and
there's no manual configuration related to scop 4, = and
if an app tried to send to or join a multicast = group
in scop 4 are you saying that the send/join would = fail?
I'd rather be liberal in what we accept here and have = it
succeed, which is what I was trying to allow.

> However, you still need the capability to = explicitly configure scop 4
> zone ids on site-boundary nodes, in case the = node is attached (via
> different interfaces) to more than one scop 4 = zone within the
> same site.

Agree.

> And you also need the capability to configure = scop 4 zone ids on nodes
> that are internal to a site, i.e., not = site-boundary nodes.

I didn't follow this.  I was suggesting that you = don't need
separate scop 4 zone ids in this config, you use the = same ids
as for scop 5 (and you use a disjoint numbering space = as Erik
suggested to disambiguate this).

> >So my proposed correction to Steve's rule = is:
> >"Whenever dealing with an address = (multicast or unicast) of
> >a scope for which you are not a boundary, = the appropriate zone
> >is unambiguous, so the sin6_scope_id is the = same zone id of
> >the next larger scope for which you are a = boundary (e.g., zero
> >if you are not a boundary for any larger = scope level)."
>
> That's still not quite right, because if you are = a boundary for
> scope x, you are *necessarily* a boundary for = all configured scopes
> less than x, since a smaller zone cannot span = across boundaries
> of a larger zone.

I agree the wording "are not a boundary" is = problematic here.

-Dave

------_=_NextPart_001_01BFE22E.6ACEB86E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 18:39:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U1bHo19358 for ipng-dist; Thu, 29 Jun 2000 18:37:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U1b9619351 for ; Thu, 29 Jun 2000 18:37:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA04015 for ; Thu, 29 Jun 2000 18:37:09 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21551 for ; Thu, 29 Jun 2000 19:37:08 -0600 (MDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id SAA25168; Thu, 29 Jun 2000 18:36:23 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006270805.KAA05747@givry.rennes.enst-bretagne.fr> References: <200006270805.KAA05747@givry.rennes.enst-bretagne.fr> Date: Thu, 29 Jun 2000 18:36:29 -0700 To: Francis Dupont From: Steve Deering Subject: Re: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:05 AM +0200 6/27/00, Francis Dupont wrote: >For this reason (selection of a sub-zone), an implementation might >find it useful to assign a distinct value for each zone index, so that >they are unique across all zones, regardless of scope. Yes, I think that makes the most sense. Our current draft suggests, but does not require, that different scopes use different zone indices, but I'd be in favor of changing that in the next revision (just have to convince my co-authors). >If we have distinct values then we can implement any kind of outgoing >zone selection, ie. we can specify in the sin6_scope_id field the zone >of the outgoing interface, the only restriction is its scope must be >smaller or equal to the address scope. Then I have three questions >about this: > - a link zone can have more than one interface, is there practical > example where this can be a problem? I'm not sure what you are asking. Are you asking if there is a practical reason to support multiple interfaces to the same link? Or are you asking if we have all the machinery necessary to properly support multiple interfaces to the same link? > - should we extend this model to global addresses (this is a proposal > for the sin6_scope_id meaning)? Our draft does mention the use of smaller-scope zone indices when sending to a global destination address (section 7, last paragraph, penultimate sentence). > - should we extend this model to the reception side, ie. one matches > only when the incoming interface belongs to the right zone? Are you talking about using bind() to limit the zone of acceptance? > For IPv6, with its scoped addresses, the analogous capabilities would > be a choice among: > > - identifying a particular outgoing interface, or > >=> do you mean a particular outgoing link (someone has already corrected >me about the difference :-) or do you rely on IPV6_MULTICAST_IF? In the above-quoted text, I was referring to an outgoing interface, not an outgoing link. If you read the scoping architecture draft carefully, you'll see that we specify separate zone indices for interfaces and for links. For example, Figure 1 in the draft shows a node with zone indices for each of the following zones: intf1, intf2, intf3, intf4, intf5, link1, link2, link3, link4, site1, site2, site3 The zone indices for interfaces arise from the definition of the (multicast) node-local scope as spanning only a single interface. Then, by allowing any transmission to be constrained to a lesser-scope zone, we can use those node-local zone indices to specify a particular outgoing interface, even for sending unicasts. Now, that's a pretty sneaky way of unifying interface indices and zone indices, and it is pretty counterintuitive too: a packet whose transmission is constrained to a node-local zone ought not to be allowed to leave the node. And I think that if I were starting from scratch, I would eliminate the node-local multicast scope altogether (and use link-local multicast scope on the phantom loopback link to achieve the purposes for which node-local was intended). So I'm now more inclined towards explicitly distinguishing between interface indices and zone indices, but giving them distinct values so they can both be carried unambiguously within a single field, such as the interface field in the in6_pktinfo structure. > - identifying only the outgoing zone (for non-global destinations), > and leaving it to the IP layer to choose an outgoing interface > within that zone, or > >=> I don't know if the non-global restriction is really needed. It's not. In the above-quoted text, I was trying to avoid the diversionary issue of using of lesser-scope zones. > On reception, the upper-layer should be told the arrival interface, > >=> how? The sin6_scope_id should contains the index of the zone of the >address scope (this rule implies global addresses in any cases will get >the zero sin6_scope_id in recvfrom() because there is only one global zone). Yes, my thinking was muddled. I think we need to distinguish between two different uses of zone/interface indices: (1) to identify the zone of an address, in a node that is attached to more than one zone of that address's scope. This is the purpose of the sin6_scope_id field in the sockaddr_in6 structure, and of the "%" qualifier in the textual representation of IPv6 addresses. (2) to constrain the set of interfaces over which a packet may be transmitted -- or on which a multicast group is to be joined -- to a set *less than* that implied by the zone of the relevant address. This is the purpose of the interface index in the in6_pktinfo structure, and in the IPV6_MULTICAST_IF and IPV6_JOIN_GROUP setsockopts, and of a "-i " or "-z " command line option in, for example, a ping command. This leads to the following suggestions: - a non-zero sin6_scope_id value used when bind()ing a socket or sending a packet is used only to identify the relevant zone of the source or destination address, and *not* to identify a particular interface for sending or receiving, even if the sin6_scope_id happens to be an interface index. I.e., the use of an interface index would not be interpreted as (over) specifying the choice of outgoing interface. Of course, it would be cleaner to just use zone indices, not interface indices, for sin6_scope_id, but backwards compatibility with existing implementations might argue for allowing either. - the sin6_scope_id value returned in a sockaddr_in6 when receiving a packet is interpreted only as identifying the zone of the source address, not as the specific interface on which the packet arrived. Again, it would be cleanest if only zone indices were used, but interface indices could be "tolerated" for backwards-compatibility reasons. - to constrain an outgoing packet to a specific interface or a set of interfaces smaller than the set belonging to the destination address's zone, you would specify an interface index or a zone index in the in6_pktinfo structure of the advanced API. For multicast packets, you could alternatively use IPV6_MULTICAST_IF. - to determine the specific arrival interface of a packet, you would use the in6_pktinfo structure of the advanced API. - when joining a multicast group, you would use IPV6_JOIN_GROUP with either an interface index, a zone index, or zero (unspecified). (If the above is just a restatement of what some of you have been saying all along, please forgive me for spending more time talking than listening.) 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 Jun 29 19:01:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U1x6419394 for ipng-dist; Thu, 29 Jun 2000 18:59:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U1ws619387 for ; Thu, 29 Jun 2000 18:58:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA06176 for ; Thu, 29 Jun 2000 18:58:53 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA00569 for ; Thu, 29 Jun 2000 19:58:53 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA18264; Thu, 29 Jun 2000 18:58:50 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA23996; Thu, 29 Jun 2000 18:58:50 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id TAA10243; Thu, 29 Jun 2000 19:02:42 -0700 (PDT) Date: Thu, 29 Jun 2000 19:02:42 -0700 (PDT) From: Tim Hartrick Message-Id: <200006300202.TAA10243@feller.mentat.com> To: deering@cisco.com Subject: Re: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > - should we extend this model to the reception side, ie. one matches > > only when the incoming interface belongs to the right zone? > > Are you talking about using bind() to limit the zone of acceptance? > Good lord, if I had known what it was going to lead to I would never have suggested adding a scope (zone) identifier to the sockaddr_in6. Can anyone explain how being able to restrict the flow of globally addressed datagrams to some set of interfaces is going to be useful to Joe Average application writer? What is wrong with simply numbering an attached nodes interfaces starting at one and numbering a nodes attached sites starting at one? I am just not getting what we are gaining or likely to gain by attempting to number these zones from the same identifier space and then allowing all these degrees of freedom in how the sin6_scope_id is interpreted. I find it difficult to get most application writers to understand select(). Do we really believe that this level of complexity is going to be understood sufficiently by application writers to make use of it. I am dubious that it will. I will shut-up now and keep reading. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 29 19:20:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U2I3k19422 for ipng-dist; Thu, 29 Jun 2000 19:18:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U2Hs619415 for ; Thu, 29 Jun 2000 19:17:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA05718 for ; Thu, 29 Jun 2000 19:17:54 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13359 for ; Thu, 29 Jun 2000 19:17:53 -0700 (PDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id TAA26699; Thu, 29 Jun 2000 19:17:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006300202.TAA10243@feller.mentat.com> References: <200006300202.TAA10243@feller.mentat.com> Date: Thu, 29 Jun 2000 19:17:19 -0700 To: Tim Hartrick From: Steve Deering Subject: Re: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 7:02 PM -0700 6/29/00, Tim Hartrick wrote: >Good lord, if I had known what it was going to lead to I would never >have suggested adding a scope (zone) identifier to the sockaddr_in6. I was afraid I was going to trigger that reaction. :-) >Can anyone explain how being able to restrict the flow of globally >addressed datagrams to some set of interfaces is going to be useful to >Joe Average application writer? I doubt that it will. And if you can ignore all my words of justification and just notice that I was proposing keeping all of that cruft in the "Advanced API", you'll see that Joe Average application writer shouldn't be exposed to it. 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 Jun 29 20:55:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U3rSA19467 for ipng-dist; Thu, 29 Jun 2000 20:53:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U3rI619460 for ; Thu, 29 Jun 2000 20:53:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA15102 for ; Thu, 29 Jun 2000 20:53:17 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA13362 for ; Thu, 29 Jun 2000 21:53:17 -0600 (MDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Thu, 29 Jun 2000 21:53:08 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 29 Jun 2000 21:53:10 -0600 From: "Narsimharao Nagampalli" To: , Cc: , , Subject: Re: Revised IPng Working Group Charter Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e5U3rK619461 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Flow label is also important for other applications such as server load balancing solutions. Also this could be useful for parallelizing protocol stack workload in a connection level parallelism mechanism. -Narsi >>> Brian E Carpenter 06/30/00 02:05AM >>> Alex, I don't think the issue is separable from other QOS issues. That means that DIFFSERV, INTSERV and ISSLL are all concerned at some level. So I think it needs to be raised first in the TSV Area meeting. I agree that once the topic has been clarified, a work item should be identified and then we can see which WG should handle it - it can't be left floating. (I'm much less clear about routing, I have to say. I suspect that flow-label based routing would prove to be a pure rathole.) Brian Alex Conta wrote: > > While I agree with the chairs and the WG that the flow ID work must be completed, > and I agree with you that the expertise in other IETF areas can be very useful to > get the flow label work going, I am concerned that the work > has less of a chance to be completed without a specific WG to do it. > > The "TraffiC Class" field is an example where things worked well: the output from > the Diff-Serv WG affects directly > the field. > > Did you have in mind something similar when you made the suggestion? > > Alex > > Brian E Carpenter wrote: > > > I can't hekp wondering whether the flow label issue should be sent off > > to the Transport area for consideration. > > > > Brian > > > > Bob Hinden wrote: > > > > > > Folks, > > > > > > Attached is a draft of a revised charter for the working group. Updating > > > the charter was agreed to at the Grenoble and Minneapolis working group > > > meetings, but it took the chairs and AD's a while to draft a new one. > > > > > > The charter includes changing the name of the working group to the "IP > > > Version 6 Working Group", but will keep the acronym of "ipngwg". This will > > > avoid having to rename all current internet drafts. > > > > > > Please send comments on the new charter to the mailing list. There will be > > > a short session in Pittsburgh to discuss it as well. > > > > > > Bob Hinden / Steve Deering > > > > > > ----------------------------------------------------------------------------- > > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > > > ----------------------------------------------------------------------------- > > > > > > IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym > > > > > > Chair(s): > > > > > > Bob Hinden > > > Steve Deering > > > > > > Document Editor > > > > > > Bob Hinden (hinden@iprg.nokia.com) > > > > > > Internet Area Director(s): > > > > > > Thomas Narten > > > Erik Nordmark > > > > > > Internet Area Advisor: > > > > > > Thomas Narten > > > > > > Mailing Lists: > > > > > > General Discussion:ipng@sunroof.eng.sun.com > > > To Subscribe: majordomo@sunroof.eng.sun.com > > > In Body: in body: subscribe ipng > > > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > > > > > Description of Working Group: > > > > > > IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) > > > is intended to support the continued growth of the Internet, both in > > > size and capabilities, by offering a greatly increased IP address space > > > and other enhancements over IPv4. The working group was originally > > > chartered to implement the recommendations of the IPng Area Directors > > > as outlined at the July 1994 IETF meeting and in "The Recommendation > > > for the IP Next Generation Protocol," RFC1752, January 1995. Most of > > > the tasks in that original charter have been completed, and the core > > > IPv6 protocol specifications are now on the IETF standards track. > > > The working group's ongoing responsibilities are as follows: > > > > > > - Complete work from the original charter and follow-on work, as > > > outlined below. > > > > > > - Keep all IPv6 working group documents moving along publication / > > > standardization track. > > > > > > - Serve as a review board and body of competence and coordination for > > > IPv6 architectural issues that span multiple IETF working groups. > > > > > > - Provide a home for IPv6-related work that doesn't fit in an existing > > > IETF working group and doesn't merit a working group of its own. > > > > > > - Provide technical input to ICANN, Internet Address Registries, and > > > IANA with regard to IPv6 address allocation policies and procedures. > > > > > > - Provide technical input and review to IANA with regard to IPv6 > > > protocol and parameter assignments. > > > > > > The list of the working group's current work items is as follows: > > > > > > - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, > > > editorial) > > > - Revise Generic Tunneling spec (add bidirectional tunnels) > > > - Update Basic and Advanced API specs > > > - Complete Router Renumbering spec > > > - Complete Scoped Address Architecture spec and any necessary revisions > > > to other working group drafts required to properly implement support > > > for IPv6 address scoping > > > - Complete work on recommended address-selection algorithms > > > - Work on new solutions to site-multihoming problems, possibly including > > > both host-based and router-based solutions. > > > - Complete work on local IPv6 networking as part of IPv6 plug-and-play > > > - Complete work on privacy extensions to stateless address configuration > > > - Document IPv6 renumbering model > > > - Complete the GSE Analysis document > > > - Complete the Inverse Neighbor Discovery spec > > > - Complete the IPv6 Node Information Queries spec > > > - Complete MIB specs as required by any working group protocol specs > > > > > > New work items not listed above require the approval of the working > > > group and Internet Area directors before they will be taken on by the > > > working group. > > > > > > The working group would welcome contributions on the following topics > > > (this is not an exhaustive list): > > > > > > - Flow label standardization > > > - Solutions to other multihoming issues, beyond those specific to > > > site-multihoming > > > - Integration of autoconfiguration, mobility, DNS, service discovery > > > and other technologies to enhance IPv6 plug-and-play > > > - IPv6 dial-up issues relating to address assignment, use of Neighbor > > > Discovery, etc. (not including AAA work) > > > - Specifications for IPv6 over additional media > > > - Extending MLD to include functionality of IGMPv3 > > > - Host use of anycast; TCP use of anycast > > > - Support for multi-link subnets (single subnet spans multiple links) > > > - Scope-name discovery > > > - IPv6 protocol extensions to accommodate mobile wireless networks. > > > > > > Goals and Milestones: > > > > > > Aug 2000 Complete MLD MIB and submit for Proposed Standard > > > > > > Aug 2000 Complete privacy extensions specification and submit for > > > Proposed Standard > > > > > > Aug 2000 Completed revision of GSE Analysis document and resubmit > > > for Informational > > > > > > Aug 2000 Complete the Inverse Neighbor Discovery specification > > > and submit for Proposed Standard > > > > > > Aug 2000 Complete IPv6 Multihoming with Route Aggregation and submit > > > for Informational. > > > > > > Oct 2000 Update ICMP document and resubmit for Draft Standard > > > > > > Oct 2000 Update Generic Tunneling specification and resubmit for > > > Proposed Standard > > > > > > Oct 2000 Complete updates to Basic and Advanced API specifications > > > and submit for Informational > > > > > > Dec 2000 Complete Scoped Address Architecture and submit for Proposed > > > Standard > > > > > > Dec 2000 Compete Address Selection specification and submit for Proposed > > > Standard > > > > > > Dec 2000 Complete Local IPv6 Networking Specification and submit for > > > Proposed Standard > > > > > > Dec 2000 Complete the IPv6 Node Information Queries specification > > > and submit for Proposed Standard > > > > > > Mar 2001 Complete IPv6 renumbering model document and submit for > > > Informational > > > > > > ----------------------------------------------------------------------------- > > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft > > > ----------------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jun 29 21:29:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U4S5Z19494 for ipng-dist; Thu, 29 Jun 2000 21:28:05 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U4Ru619487 for ; Thu, 29 Jun 2000 21:27:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA16823 for ; Thu, 29 Jun 2000 21:27:55 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA26644 for ; Thu, 29 Jun 2000 22:27:55 -0600 (MDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id VAA00318; Thu, 29 Jun 2000 21:27:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19398D273324D3118A2B0008C7E9A5690C6F7AA4@SIT.platinum.corp.microsoft.com> References: <19398D273324D3118A2B0008C7E9A5690C6F7AA4@SIT.platinum.corp.microsoft.com> Date: Thu, 29 Jun 2000 21:27:27 -0700 To: "Dave Thaler" From: Steve Deering Subject: RE: rfc2553bis comments Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:52 AM -0700 6/27/00, Dave Thaler wrote: >I really don't like the idea of sharing the same numbering space >between interface ids and scope ids of higher levels, and requiring >uniqueness among them. > >My reasoning is that ifindices are a link-layer id (per their original >definition in MIB-II), whereas site ids are network-layer (and IPv6 only) >ids with a very different meaning. It's a layer violation to ask for >uniqueness among them. The interface ids used by IP apps are (supposed to be) IP-layer concepts, not link-layer concepts. For example, one link-layer ("physical") interface might underlie multiple IP-layer ("logical") interfaces, such as tunnel endpoints or the endpoints of multiple virtual circuits established over the same physical interface. Conversely, multiple physical interfaces, such as some point-to-point interfaces to a set of parallel trunks, might be presented to the IP layer as a single IP-layer interface (with the link-layer performing packet-striping across the trunks, invisible to IP). >If the implementation used interface ids that were not ifindices, that would >be a different thing, but then if_nametoindex() and related functions wouldn't >be helpful for an app wanting to choosing a link. Huh? 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 Jun 29 21:41:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U4cuu19518 for ipng-dist; Thu, 29 Jun 2000 21:38:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U4ck619511 for ; Thu, 29 Jun 2000 21:38:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA15602 for ; Thu, 29 Jun 2000 21:38:41 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA00982 for ; Thu, 29 Jun 2000 22:38:40 -0600 (MDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id VAA00562; Thu, 29 Jun 2000 21:37:24 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: <200006270330.UAA08422@feller.mentat.com> Date: Thu, 29 Jun 2000 21:37:33 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: RE: rfc2553bis comments Cc: tim@mentat.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:28 AM +0900 6/28/00, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >We could implement Steve's proposal if we invented unique space of >identifiers that covers all scopes. And I admit it would be useful if >we can specify the outgoing interface by the sin6_scope_id field >without any other APIs (such as socket options), but it would be too >complecated for application programmers, especially on properly using >different type of sin6_scope_id values (i.e. sometimes use it as an >interface identifier, and sometimes use it as a zone identifier of a >larger scope). Yes, I think I am coming to the same conclusion. 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 Jun 29 21:52:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U4oQa19543 for ipng-dist; Thu, 29 Jun 2000 21:50:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U4oI619536 for ; Thu, 29 Jun 2000 21:50:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA09056 for ; Thu, 29 Jun 2000 21:50:16 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29053 for ; Thu, 29 Jun 2000 21:50:15 -0700 (PDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id VAA00785; Thu, 29 Jun 2000 21:48:26 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81024BCF595@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81024BCF595@RED-MSG-50> Date: Thu, 29 Jun 2000 21:48:35 -0700 To: Richard Draves From: Steve Deering Subject: RE: rfc2553bis comments Cc: Dave Thaler , Francis.Dupont@enst-bretagne.fr, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:21 PM -0700 6/29/00, Richard Draves wrote: >I'm (mildly) concerned about how much state an implementation has to >maintain per interface. Right now in the interface structure we have fields >for an interface id and a site id. If our implementation might be used in >boundary situations for the different multicast scope levels, does that mean >the interface structure must grow to accommodate ~16 zone ids at the >different levels? In theory, yes, though there are probably a number of other, more space- efficient ways to implement it (e.g., a zone table that is a list of zones, each with a bitmap identifying the interfaces belonging to that zone). If you are worried about the size, but want to keep your current implementation, perhaps you can make each interface's zone list be a linked-list of dynamically-allocated elements, and in all but the rarest of cases would be very short lists. 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 Jun 29 21:56:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U4spx19561 for ipng-dist; Thu, 29 Jun 2000 21:54:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U4sg619554 for ; Thu, 29 Jun 2000 21:54:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA19572 for ; Thu, 29 Jun 2000 21:54:40 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA00274 for ; Thu, 29 Jun 2000 21:54:40 -0700 (PDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id VAA00878; Thu, 29 Jun 2000 21:53:16 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19398D273324D3118A2B0008C7E9A5690C6F7ABB@SIT.platinum.corp.microsoft.com> References: <19398D273324D3118A2B0008C7E9A5690C6F7ABB@SIT.platinum.corp.microsoft.com> Date: Thu, 29 Jun 2000 21:53:25 -0700 To: "Dave Thaler" From: Steve Deering Subject: RE: rfc2553bis comments Cc: "Richard Draves" , , , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:59 PM -0700 6/29/00, Dave Thaler wrote: >Re "if scop 4 were configured to be used within a site"... >So if we have a host with interfaces in two sites, and >there's no manual configuration related to scop 4, and >if an app tried to send to or join a multicast group >in scop 4 are you saying that the send/join would fail? I guess that is what I was saying (or, at least, an consequence of what I was saying). >I'd rather be liberal in what we accept here and have it >succeed, which is what I was trying to allow. I'm not sure how lax you want to be with zone-boundary configuration. Seems to me that, in the IPv4 admin multicast scope case, we were quite worried abou the hazards of "leaky" zone boundaries. > > And you also need the capability to configure scop 4 zone ids on nodes > > that are internal to a site, i.e., not site-boundary nodes. > >I didn't follow this. I was suggesting that you don't need >separate scop 4 zone ids in this config, you use the same ids >as for scop 5 (and you use a disjoint numbering space as Erik >suggested to disambiguate this). I meant for nodes that are scop 4 boundaries but not site boundaries. 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 Jun 29 22:50:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U5mNX19597 for ipng-dist; Thu, 29 Jun 2000 22:48:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U5mF619590 for ; Thu, 29 Jun 2000 22:48:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA13152 for ; Thu, 29 Jun 2000 22:48:15 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27443 for ; Thu, 29 Jun 2000 23:48:14 -0600 (MDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id WAA02060; Thu, 29 Jun 2000 22:47:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4.2.2.20000628125350.01bd86e0@pop.epilogue.com> References: <4.2.2.20000628125350.01bd86e0@pop.epilogue.com> Date: Thu, 29 Jun 2000 22:47:44 -0700 To: Margaret Wasserman From: Steve Deering Subject: Re: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:35 PM -0400 6/28/00, Margaret Wasserman wrote: >First, I'd like to compliment the authors on writing such a >straightforward explanation of a complex topic. On behalf of all the authors, thanks! >Does this draft intentionally invalidate the possibility of overlapping >sites (where a single interface could be in more than one site)? Yes. To add an example to Brian's early response, suppose you are connected to two sites via a single interface, and each of those sites has a node with site-local address X in the part of the site that does not overlap the other site. If you wanted to send a packet to X, there is no way for you to say, or for the routers in the overlap area to know, which of the two Xs you mean. 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 Jun 29 22:50:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U5mxd19609 for ipng-dist; Thu, 29 Jun 2000 22:48:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U5mk619599 for ; Thu, 29 Jun 2000 22:48:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA13178 for ; Thu, 29 Jun 2000 22:48:46 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA14794 for ; Thu, 29 Jun 2000 22:48:45 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Jun 2000 21:37:40 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 29 Jun 2000 21:42:53 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE24C.BD4C1E9C" Subject: RE: rfc2553bis comments x-mimeole: Produced By Microsoft Exchange V6.0.4408.0 Date: Thu, 29 Jun 2000 21:36:21 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690D8CEEC0@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc2553bis comments Thread-Index: Ab/iSqbU/Eld6ZIhRqyIEW2FK4S9PAAAsg2A From: "Dave Thaler" To: "Steve Deering" Cc: X-OriginalArrivalTime: 30 Jun 2000 04:42:53.0675 (UTC) FILETIME=[A74B43B0:01BFE24D] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFE24C.BD4C1E9C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All of the scenarios you describe are handled with link-layer ifindexes. Nothing says a link has to be a physical link. This is specified in RFC 2233 (Interfaces MIB), where there is an excellent=20 discussion of the interface layering model and the use of interface indices. -Dave=20 -----Original Message----- From: Steve Deering [mailto:deering@cisco.com] Sent: Thursday, June 29, 2000 9:27 PM To: Dave Thaler Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments At 9:52 AM -0700 6/27/00, Dave Thaler wrote: >I really don't like the idea of sharing the same numbering space >between interface ids and scope ids of higher levels, and requiring >uniqueness among them. > >My reasoning is that ifindices are a link-layer id (per their original >definition in MIB-II), whereas site ids are network-layer (and IPv6 only) >ids with a very different meaning. It's a layer violation to ask for >uniqueness among them. The interface ids used by IP apps are (supposed to be) IP-layer concepts, not link-layer concepts. For example, one link-layer ("physical") interface might underlie multiple IP-layer ("logical") interfaces, such as tunnel endpoints or the endpoints of multiple virtual circuits established over the same physical interface. Conversely, multiple physical interfaces, such as some point-to-point interfaces to a set of parallel trunks, might be presented to the IP layer as a single IP-layer interface (with the link-layer performing packet-striping across the trunks, invisible to IP). >If the implementation used interface ids that were not ifindices, that would >be a different thing, but then if_nametoindex() and related functions wouldn't >be helpful for an app wanting to choosing a link. Huh? Steve ------_=_NextPart_001_01BFE24C.BD4C1E9C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: rfc2553bis comments

All of the scenarios you describe are handled = with
link-layer ifindexes.  Nothing says a link has = to
be a physical link.  This is specified in RFC = 2233
(Interfaces MIB), where there is an excellent
discussion of the interface layering model and
the use of interface indices.

-Dave

-----Original Message-----
From: Steve Deering [mailto:deering@cisco.com]
Sent: Thursday, June 29, 2000 9:27 PM
To: Dave Thaler
Cc: ipng@sunroof.eng.sun.com
Subject: RE: rfc2553bis comments


At 9:52 AM -0700 6/27/00, Dave Thaler wrote:
>I really don't like the idea of sharing the same = numbering space
>between interface ids and scope ids of higher = levels, and requiring
>uniqueness among them.
>
>My reasoning is that ifindices are a link-layer = id (per their original
>definition in MIB-II), whereas site ids are = network-layer (and IPv6 only)
>ids with a very different meaning.  It's a = layer violation to ask for
>uniqueness among them.

The interface ids used by IP apps are (supposed to be) = IP-layer concepts,
not link-layer concepts.  For example, one = link-layer ("physical") interface
might underlie multiple IP-layer = ("logical") interfaces, such as tunnel
endpoints or the endpoints of multiple virtual = circuits established over
the same physical interface.  Conversely, = multiple physical interfaces,
such as some point-to-point interfaces to a set of = parallel trunks, might
be presented to the IP layer as a single IP-layer = interface (with the
link-layer performing packet-striping across the = trunks, invisible to IP).

>If the implementation used interface ids that were = not ifindices, that would
>be a different thing, but then if_nametoindex() = and related functions wouldn't
>be helpful for an app wanting to choosing a = link.

Huh?

Steve

------_=_NextPart_001_01BFE24C.BD4C1E9C-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 23:01:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U5wmm19701 for ipng-dist; Thu, 29 Jun 2000 22:58:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U5wa619682 for ; Thu, 29 Jun 2000 22:58:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA13760 for ; Thu, 29 Jun 2000 22:58:36 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA17514 for ; Thu, 29 Jun 2000 22:58:35 -0700 (PDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id WAA02153; Thu, 29 Jun 2000 22:51:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006272043.QAA0000878009@anw.zk3.dec.com> References: <200006272043.QAA0000878009@anw.zk3.dec.com> Date: Thu, 29 Jun 2000 22:51:31 -0700 To: Jim Bound From: Steve Deering Subject: Re: draft-ipngwg-scoping-arch-01.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:43 PM -0400 6/27/00, Jim Bound wrote: >I read the spec wearing my ietf spec reveiwer and architecture hat. I >like the clarification on zones. It is all clear to me. I have not one >issue with it at this point. Thanks, Jim. I hope the subsequent email discussion hasn't muddied it up again. 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 Jun 29 23:09:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U68Tj19733 for ipng-dist; Thu, 29 Jun 2000 23:08:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U68L619726 for ; Thu, 29 Jun 2000 23:08:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA24109 for ; Thu, 29 Jun 2000 23:08:21 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05196 for ; Fri, 30 Jun 2000 00:08:21 -0600 (MDT) Received: from [10.19.130.190] (deering-dsl5.cisco.com [10.19.130.190]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id XAA02588; Thu, 29 Jun 2000 23:01:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200006281743.NAA0000583107@anw.zk3.dec.com> References: <200006281743.NAA0000583107@anw.zk3.dec.com> Date: Thu, 29 Jun 2000 23:01:17 -0700 To: Jim Bound From: Steve Deering Subject: Re: draft-ipngwg-scoping-arch-01.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:43 PM -0400 6/28/00, Jim Bound wrote: > whether they are crossing boundaries for their scopes. Thus, it is > possible, though generally inadvisable, to use a Routing Header to > convey a non-global address across its associated zone boundary. > >I believe this is very inadvisable. Yeah, it's not likely to do anything useful. But I would not want to impose the cost on implementations of a relatively expensive check (a scan through all the addresses in a Routing header) for a such an unlikely event. >The other option is for customers that really want to use multisited >servers is to use global addresses, which will not be a scarce resource >in IPv6. Yes, that's always a choice. 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 Jun 30 01:06:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U84Jt19819 for ipng-dist; Fri, 30 Jun 2000 01:04:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U84A619812 for ; Fri, 30 Jun 2000 01:04:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA00177 for ; Fri, 30 Jun 2000 01:04:07 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01033 for ; Fri, 30 Jun 2000 01:04:06 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5U83KK01590; Fri, 30 Jun 2000 10:03:21 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA21563; Fri, 30 Jun 2000 10:03:20 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA21322; Fri, 30 Jun 2000 10:04:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006300804.KAA21322@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: Steve Deering , Dave Thaler , jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Thu, 29 Jun 2000 17:21:25 PDT. <4D0A23B3F74DD111ACCD00805F31D81024BCF595@RED-MSG-50> Date: Fri, 30 Jun 2000 10:04:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm (mildly) concerned about how much state an implementation has to maintain per interface. Right now in the interface structure we have fields for an interface id and a site id. If our implementation might be used in boundary situations for the different multicast scope levels, does that mean the interface structure must grow to accommodate ~16 zone ids at the different levels? => I think that you already need this if you'd like to implement scoped multicast forwarding (ie. in order to forward multicast packets only to interfaces which belong to the right zone, you need to know zones of each interfaces for each scope). Then I have a zone ID table per interface and KAME has a similar thing... Of course this isn't the biggest space hit for an interface by far. => note you need only 12 new zone IDs and 16 bits per ID are usually enough! Regards Francis.Dupont@enst-bretagne.fr PS: my concern is about the routing table (both size and organization). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 01:10:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U89QH19845 for ipng-dist; Fri, 30 Jun 2000 01:09:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U89H619838 for ; Fri, 30 Jun 2000 01:09:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA00528 for ; Fri, 30 Jun 2000 01:09:15 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA29651 for ; Fri, 30 Jun 2000 02:09:14 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5U87eK32984; Fri, 30 Jun 2000 10:07:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA21647; Fri, 30 Jun 2000 10:07:40 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA21357; Fri, 30 Jun 2000 10:08:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006300808.KAA21357@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: "Dave Thaler" , "Richard Draves" , "Dave Thaler" , jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Thu, 29 Jun 2000 17:39:38 PDT. Date: Fri, 30 Jun 2000 10:08:45 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: However, you still need the capability to explicitly configure scop 4 zone ids on site-boundary nodes, in case the node is attached (via different interfaces) to more than one scop 4 zone within the same site. And you also need the capability to configure scop 4 zone ids on nodes that are internal to a site, i.e., not site-boundary nodes. => then I believe we need to standardize the way to configure zone IDs (ie. to attach an interface to a zone). But this should be in the advanced API, not in the basic API (rationate: this will be done by an administrator, not by a common user). Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 01:29:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U8RrE19932 for ipng-dist; Fri, 30 Jun 2000 01:27:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U8Rh619925 for ; Fri, 30 Jun 2000 01:27:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA03484 for ; Fri, 30 Jun 2000 01:27:41 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA07890 for ; Fri, 30 Jun 2000 02:27:41 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5U8QsK14852; Fri, 30 Jun 2000 10:26:54 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA22006; Fri, 30 Jun 2000 10:26:53 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA21440; Fri, 30 Jun 2000 10:27:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006300827.KAA21440@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dave Thaler" cc: "Steve Deering" , "Richard Draves" , jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Thu, 29 Jun 2000 17:59:17 PDT. <19398D273324D3118A2B0008C7E9A5690C6F7ABB@SIT.platinum.corp.microsoft.com> Date: Fri, 30 Jun 2000 10:27:59 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Re "if scop 4 were configured to be used within a site"... So if we have a host with interfaces in two sites, and there's no manual configuration related to scop 4, and if an app tried to send to or join a multicast group in scop 4 are you saying that the send/join would fail? I'd rather be liberal in what we accept here and have it succeed, which is what I was trying to allow. => the unspecified zone (ie. zero sin6_scope_id) can give a default zone in scop 4 if a default rule has been configurated (the existence of a default rule should be optional). > And you also need the capability to configure scop 4 zone ids on nodes > that are internal to a site, i.e., not site-boundary nodes. I didn't follow this. I was suggesting that you don't need separate scop 4 zone ids in this config, you use the same ids as for scop 5 (and you use a disjoint numbering space as Erik suggested to disambiguate this). => we have not (yet) defined the meaning of a zone ID for a scope larger than the address. The only hairy case is where it is ambiguous, for instance in this context one specify a site when the node has interfaces in two zones of scope 4 in this site. Again we can introduce an optional default rule (a new one if this site is not the default site)... Content-Type: text/html; => I think this part has no more information (ie. its purpose is just to make the message far larger :-) ? Regards Francis.Dupont@enst-bretagne.fr PS: here my concern is still with the routing table... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 02:11:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U992J19971 for ipng-dist; Fri, 30 Jun 2000 02:09:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U98s619964 for ; Fri, 30 Jun 2000 02:08:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA26870 for ; Fri, 30 Jun 2000 02:08:53 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27205 for ; Fri, 30 Jun 2000 03:08:52 -0600 (MDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 303604DEB; Fri, 30 Jun 2000 05:08:52 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 03E924EB1; Fri, 30 Jun 2000 05:08:51 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id FAA0000900685; Fri, 30 Jun 2000 05:08:51 -0400 (EDT) From: Jim Bound Message-Id: <200006300908.FAA0000900685@anw.zk3.dec.com> To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: draft-ipngwg-scoping-arch-01.txt In-reply-to: Your message of "Thu, 29 Jun 2000 22:51:31 PDT." Date: Fri, 30 Jun 2000 05:08:50 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I read the spec wearing my ietf spec reveiwer and architecture hat. I >>like the clarification on zones. It is all clear to me. I have not one >>issue with it at this point. > >Thanks, Jim. I hope the subsequent email discussion hasn't muddied it >up again. Not at all. Great questions and great answers. Not a big fan of bit-maps fyi for datastructures anymore as we evolve to multithreaded multiprocessor implementations reason is that I don't want to search the darn thing if it gets huge but only where a datum has changed !!! regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 02:12:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U9BLY19982 for ipng-dist; Fri, 30 Jun 2000 02:11:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U9B5619973 for ; Fri, 30 Jun 2000 02:11:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA27029 for ; Fri, 30 Jun 2000 02:11:05 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27383 for ; Fri, 30 Jun 2000 02:11:04 -0700 (PDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id BA65F1A75; Fri, 30 Jun 2000 04:11:03 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 47F481B58; Fri, 30 Jun 2000 04:11:03 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id FAA0000900813; Fri, 30 Jun 2000 05:11:02 -0400 (EDT) From: Jim Bound Message-Id: <200006300911.FAA0000900813@anw.zk3.dec.com> To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: draft-ipngwg-scoping-arch-01.txt In-reply-to: Your message of "Thu, 29 Jun 2000 23:01:17 PDT." Date: Fri, 30 Jun 2000 05:11:02 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> whether they are crossing boundaries for their scopes. Thus, it is >> possible, though generally inadvisable, to use a Routing Header to >> convey a non-global address across its associated zone boundary. >> >>I believe this is very inadvisable. >Yeah, it's not likely to do anything useful. But I would not want to >impose the cost on implementations of a relatively expensive check (a >scan through all the addresses in a Routing header) for a such an >unlikely event. Agreed. ALso to early to limit functionality if that can be avoided. thanks and this spec is really good on my fourth read......... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 02:26:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U9OCP20022 for ipng-dist; Fri, 30 Jun 2000 02:24:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U9O3620015 for ; Fri, 30 Jun 2000 02:24:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA07347 for ; Fri, 30 Jun 2000 02:24:02 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04099 for ; Fri, 30 Jun 2000 03:24:01 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5U9NsK28102; Fri, 30 Jun 2000 11:23:54 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA23076; Fri, 30 Jun 2000 11:23:54 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA21635; Fri, 30 Jun 2000 11:24:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006300924.LAA21635@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Thu, 29 Jun 2000 18:36:29 PDT. Date: Fri, 30 Jun 2000 11:24:59 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Our current draft suggests, but does not require, that different scopes use different zone indices, but I'd be in favor of changing that in the next revision (just have to convince my co-authors). => I'd like to have a require for the numerical values. >If we have distinct values then we can implement any kind of outgoing >zone selection, ie. we can specify in the sin6_scope_id field the zone >of the outgoing interface, the only restriction is its scope must be >smaller or equal to the address scope. Then I have three questions >about this: > - a link zone can have more than one interface, is there practical > example where this can be a problem? I'm not sure what you are asking. Are you asking if there is a practical reason to support multiple interfaces to the same link? Or are you asking if we have all the machinery necessary to properly support multiple interfaces to the same link? => second but if we can convert node-local to interface-local the whole issue will be magically solved! > - should we extend this model to the reception side, ie. one matches > only when the incoming interface belongs to the right zone? Are you talking about using bind() to limit the zone of acceptance? => yes, I like symmetry. > For IPv6, with its scoped addresses, the analogous capabilities would > be a choice among: > > - identifying a particular outgoing interface, or > >=> do you mean a particular outgoing link (someone has already corrected >me about the difference :-) or do you rely on IPV6_MULTICAST_IF? In the above-quoted text, I was referring to an outgoing interface, not an outgoing link. If you read the scoping architecture draft carefully, you'll see that we specify separate zone indices for interfaces and for links. => I've missed the usage of node-local (*) zone IDs for denoting interfaces. (*) we *must* change the name to interface-local ASAP! Now, that's a pretty sneaky way of unifying interface indices and zone indices, and it is pretty counterintuitive too: a packet whose transmission is constrained to a node-local zone ought not to be allowed to leave the node. And I think that if I were starting from scratch, I would eliminate the node-local multicast scope altogether (and use link-local multicast scope on the phantom loopback link to achieve the purposes for which node-local was intended). So I'm now more inclined towards explicitly distinguishing between interface indices and zone indices, but giving them distinct values so they can both be carried unambiguously within a single field, such as the interface field in the in6_pktinfo structure. => I agree but can we do these necessary changes? > On reception, the upper-layer should be told the arrival interface, > >=> how? The sin6_scope_id should contains the index of the zone of the >address scope (this rule implies global addresses in any cases will get >the zero sin6_scope_id in recvfrom() because there is only one global zone). Yes, my thinking was muddled. I think we need to distinguish between two different uses of zone/interface indices: (1) to identify the zone of an address, in a node that is attached to more than one zone of that address's scope. This is the purpose of the sin6_scope_id field in the sockaddr_in6 structure, and of the "%" qualifier in the textual representation of IPv6 addresses. (2) to constrain the set of interfaces over which a packet may be transmitted -- or on which a multicast group is to be joined -- to a set *less than* that implied by the zone of the relevant address. This is the purpose of the interface index in the in6_pktinfo structure, and in the IPV6_MULTICAST_IF and IPV6_JOIN_GROUP setsockopts, and of a "-i " or "-z " command line option in, for example, a ping command. => don't forget that IPV6_JOIN_GROUP has a global effect then one can easily misunderstand what is really "a multicast group join"... I am not convinced that we need to distinguish between the two cases, in fact I'd like to not go backward to -i/-z extra parameters to all the applications... This leads to the following suggestions: - a non-zero sin6_scope_id value used when bind()ing a socket or sending a packet is used only to identify the relevant zone of the source or destination address, and *not* to identify a particular interface for sending or receiving, even if the sin6_scope_id happens to be an interface index. I.e., the use of an interface index would not be interpreted as (over) specifying the choice of outgoing interface. Of course, it would be cleaner to just use zone indices, not interface indices, for sin6_scope_id, but backwards compatibility with existing implementations might argue for allowing either. => I agree but what happens if we convert node-local to interface-local (I think that the whole restriction will vanish). - the sin6_scope_id value returned in a sockaddr_in6 when receiving a packet is interpreted only as identifying the zone of the source address, not as the specific interface on which the packet arrived. Again, it would be cleanest if only zone indices were used, but interface indices could be "tolerated" for backwards-compatibility reasons. => I agree and in this case there is no issue because all the addresses have a scope strictly greater than node-local with the exception of ::1 which is already very special. - to constrain an outgoing packet to a specific interface or a set of interfaces smaller than the set belonging to the destination address's zone, you would specify an interface index or a zone index in the in6_pktinfo structure of the advanced API. For multicast packets, you could alternatively use IPV6_MULTICAST_IF. => why is it not enough for zones to use sin6_scope_id as suggested in the scope arch I-D? I'd like to have both (extended) in6_pktinfo and sin6_scope_id, functions are not exactly the same (in6_pktinfo can specify the source address too) and there are a lot of old codes using in6_pktinfo, for instance all the RIPng implementations I know... - to determine the specific arrival interface of a packet, you would use the in6_pktinfo structure of the advanced API. => I agree. We have to extend in6_pktinfo to IPv4 too in order to have more regular codes. - when joining a multicast group, you would use IPV6_JOIN_GROUP with either an interface index, a zone index, or zero (unspecified). => fine. Thanks Francis.Dupont@enst-bretagne.fr PS: the two remaining questions are: - do we agree about this model? - do we convert node-local to interface-local or put interface indexes into another space than zone IDs (this will force by side effect all the interface index restrictions)? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 02:45:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U9gsG20048 for ipng-dist; Fri, 30 Jun 2000 02:42:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U9gi620041 for ; Fri, 30 Jun 2000 02:42:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA08340 for ; Fri, 30 Jun 2000 02:42:42 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09809 for ; Fri, 30 Jun 2000 02:42:41 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5U9gTK26914; Fri, 30 Jun 2000 11:42:29 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA23392; Fri, 30 Jun 2000 11:42:29 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA21689; Fri, 30 Jun 2000 11:43:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006300943.LAA21689@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Thu, 29 Jun 2000 19:02:42 PDT. <200006300202.TAA10243@feller.mentat.com> Date: Fri, 30 Jun 2000 11:43:34 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Good lord, if I had known what it was going to lead to I would never have suggested adding a scope (zone) identifier to the sockaddr_in6. => the can of worms was opened when we added scopes to the address architecture or if you prefer when we try to replace Fortran by Algol (:-). Can anyone explain how being able to restrict the flow of globally addressed datagrams to some set of interfaces is going to be useful to Joe Average application writer? => Joe Average will use the zero sin6_scope_id which will give the default and unique global zone. And if (s)he puts a random value (applying the original meaning of "average" :-) then (s)he should get an error. What is wrong with simply numbering an attached nodes interfaces starting at one and numbering a nodes attached sites starting at one? => nothing, I'd just believe you don't like the new model (and the last paragraph of section 7 of the scope arch I-D). I am just not getting what we are gaining or likely to gain by attempting to number these zones from the same identifier space and then allowing all these degrees of freedom in how the sin6_scope_id is interpreted. => read the section 7. I find it difficult to get most application writers to understand select(). => I don't understand the link for the select() system call? Do we really believe that this level of complexity is going to be understood sufficiently by application writers to make use of it. => this can be a problem but application writers can just put zero in sin6_scope_id... This will work without any trouble on a single interface host (more than 90% of the cases?). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 02:57:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5U9tJI20080 for ipng-dist; Fri, 30 Jun 2000 02:55:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5U9tA620073 for ; Fri, 30 Jun 2000 02:55:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA29412 for ; Fri, 30 Jun 2000 02:55:09 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA14315 for ; Fri, 30 Jun 2000 02:55:08 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5U9r7K28127; Fri, 30 Jun 2000 11:53:07 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA23579; Fri, 30 Jun 2000 11:53:07 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA21759; Fri, 30 Jun 2000 11:54:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006300954.LAA21759@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , tim@mentat.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Thu, 29 Jun 2000 21:37:33 PDT. Date: Fri, 30 Jun 2000 11:54:11 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >We could implement Steve's proposal if we invented unique space of >identifiers that covers all scopes. And I admit it would be useful if >we can specify the outgoing interface by the sin6_scope_id field >without any other APIs (such as socket options), but it would be too >complecated for application programmers, especially on properly using >different type of sin6_scope_id values (i.e. sometimes use it as an >interface identifier, and sometimes use it as a zone identifier of a >larger scope). Yes, I think I am coming to the same conclusion. => what about both: - put the zone different from the address of the zone stuff into the new advanced API document (I've already seen this idea in Steve's answer, we should get the opinion of the new advanced API author(s) and of course change the name of this thread) - introduce a flag which allows the extension to different zones (with the default value, an error should be returned when zones don't match, a per-user sysctl() should make the job on BSDs) By the way, I think the interface index confusion is the main problem, then we should find solutions to this issue, pick one and re-evaluate the model. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 03:49:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UAkxs20115 for ipng-dist; Fri, 30 Jun 2000 03:46:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UAko620108 for ; Fri, 30 Jun 2000 03:46:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA09841 for ; Fri, 30 Jun 2000 03:46:48 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00665 for ; Fri, 30 Jun 2000 03:46:48 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 2AC03891; Fri, 30 Jun 2000 06:46:48 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0336B9F4; Fri, 30 Jun 2000 06:46:47 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id GAA0000912725; Fri, 30 Jun 2000 06:46:47 -0400 (EDT) From: Jim Bound Message-Id: <200006301046.GAA0000912725@anw.zk3.dec.com> To: Francis Dupont Cc: Tim Hartrick , deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of "Fri, 30 Jun 2000 11:43:34 +0200." <200006300943.LAA21689@givry.rennes.enst-bretagne.fr> Date: Fri, 30 Jun 2000 06:46:47 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi francis, let me try a non-technical response to define the complexity. in this community folks like you, tim, carl, erik, jack, itojun, etc. are like the gods of network programming and even muck around in OS internals with network subsytems and some even change paradigms that have worked for 15 years on the internet in our code bases. these folks also understand the work of Dr. Richard Stevens and Turing machines, etc.... but there is a whole class of "programmer" that builds applications which the end user really sees and the real reason people buy computers that do networking. there job is to ship user space code that people will pay for to do a business function. They are usually called "application" programmers and we are the "systems programmers". the basic API was written for the "applications programmers". tim's comment on select() I agree with. the select() or poll() sys call is not intuitive to an application programmer that now has to re-write their application server for 10,000+ connections because of the Internet explosion when they wrote it for about 100 connections and might have not even used select or poll. part of our job here is to keep the "BASIC" API as simple as possible and now BACKWARDS compatible for the application programmer who will port their apps to IPv6. Its a human thing not just a technical thing. I am not saying not fix parts that need to be addressed like the issue of multicast IF. I will say that after this next release of the Basic API we are done. It will got to XNET/POSIX and then either some of the stuff I am hearing in here goes to the Advanced API or to another API we may need for QOS, IPSEC, whatever...But we must live with the next update for good. The basic API cannot be a moving target for developers porting to IPv6. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 04:17:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UBEiQ20147 for ipng-dist; Fri, 30 Jun 2000 04:14:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UBEX620140 for ; Fri, 30 Jun 2000 04:14:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA03750 for ; Fri, 30 Jun 2000 04:14:32 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18938 for ; Fri, 30 Jun 2000 05:14:31 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13286; Fri, 30 Jun 2000 07:14:28 -0400 (EDT) Message-Id: <200006301114.HAA13286@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Router Renumbering for IPv6 to Proposed Standard Date: Fri, 30 Jun 2000 07:14:28 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Router Renumbering for IPv6' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Hosts obtain routing prefixes from routers, and form addresses from those prefixes. This mechanism simplifies site renumbering by allowing routers to simultaneously phase in new prefixes and phase out old ones. This document defines a mechanism called Router Renumbering that allows the address prefixes routers advertise to be configured and reconfigured from a central place. That is, it allows a site administer to easily change the prefixes that all of its routers advertise. This mechanism may facilitate easier site renumbering. Working Group Summary The IPng WG originally asked to advance the document over a year ago, and the IESG returned it to the WG asking for a strengthening of the reliability aspects of the protocol. This version of the document includes those changes and no issues were raised during the Last Call. Protocol Quality This protocol has been reviewed for the IESG by Thomas Narten and Erik Nordmark. Note to RFC Editor: Please include the following as an IESG Note: This document defines mechanisms for informing a set of routers of renumbering operations they are to perform, including a mode of operation in environments in which the exact number of routers is unknown. Reliably informing all routers when the actual number of routers is unknown is a difficult problem. Implementation and operational experience will be needed to fully understand the applicabilty and scalability aspects of the mechanisms defined in this document when the number of routers is unknown. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 05:00:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UBwQG20226 for ipng-dist; Fri, 30 Jun 2000 04:58:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UBwH620219 for ; Fri, 30 Jun 2000 04:58:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA14157 for ; Fri, 30 Jun 2000 04:58:15 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA22931 for ; Fri, 30 Jun 2000 04:58:11 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5UBtUK31361; Fri, 30 Jun 2000 13:55:31 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA24877; Fri, 30 Jun 2000 13:55:29 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id NAA22444; Fri, 30 Jun 2000 13:56:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006301156.NAA22444@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jim Bound cc: Tim Hartrick , deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Fri, 30 Jun 2000 06:46:47 EDT. <200006301046.GAA0000912725@anw.zk3.dec.com> Date: Fri, 30 Jun 2000 13:56:36 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: let me try a non-technical response to define the complexity. => I agree and if you have seen by last mail you can find in it two ideas which address this concern. the basic API was written for the "applications programmers". tim's comment on select() I agree with. the select() or poll() sys call is not intuitive to an application programmer that now has to re-write their application server for 10,000+ connections because of the Internet explosion when they wrote it for about 100 connections and might have not even used select or poll. => unfortunately you can't give the programming of an application which have to support 10,000+ connections to Joe Average, and I am afraid that this applies to multicast applications too. Regards Francis.Dupont@enst-bretagne.fr PS: a part of my concern about the routing table is this cannot easily hiden to the administrator and unfortunately Joe Average as an administrator has a very low skill. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 05:58:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UCuAl20267 for ipng-dist; Fri, 30 Jun 2000 05:56:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UCu1620260 for ; Fri, 30 Jun 2000 05:56:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA17802 for ; Fri, 30 Jun 2000 05:56:01 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14682 for ; Fri, 30 Jun 2000 05:56:00 -0700 (PDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Fri, 30 Jun 2000 08:43:48 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N54ZNMN1; Fri, 30 Jun 2000 08:43:51 -0400 Received: from nortelnetworks.com (clemson.corpeast.baynetworks.com [132.245.252.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LSZ6RL49; Fri, 30 Jun 2000 08:43:40 -0400 Message-ID: <395C950E.D3A907B4@nortelnetworks.com> Date: Fri, 30 Jun 2000 08:39:42 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments References: <200006300804.KAA21322@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, Francis Dupont wrote: > > PS: my concern is about the routing table (both size and organization). The added complexity of scoped routing has been known for awhile now. My original scoped routing document pointed it out in all its messy details. We talk about a conceptual routing table in the scoped address arch. One way to implement it is to have a "separate" routing table per scope. The tables are indexed from the scope zone on the incoming interface to give you the correct table. Then the lookup can be done and the packet forwarded. 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 Jun 30 06:53:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UDntC20309 for ipng-dist; Fri, 30 Jun 2000 06:49:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UDnk620302 for ; Fri, 30 Jun 2000 06:49:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA24947 for ; Fri, 30 Jun 2000 06:49:46 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10145 for ; Fri, 30 Jun 2000 06:49:45 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 13234869; Fri, 30 Jun 2000 09:49:45 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D48C1848; Fri, 30 Jun 2000 09:49:44 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000935406; Fri, 30 Jun 2000 09:49:44 -0400 (EDT) From: Jim Bound Message-Id: <200006301349.JAA0000935406@anw.zk3.dec.com> To: Francis Dupont Cc: Jim Bound , Tim Hartrick , deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of "Fri, 30 Jun 2000 13:56:36 +0200." <200006301156.NAA22444@givry.rennes.enst-bretagne.fr> Date: Fri, 30 Jun 2000 09:49:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this is where the difference happens between product engineer and other engineers. I have no choice but to make joe or mary average work. and it has everything to do with my view of the basic api. take care, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 07:08:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UE5LF20371 for ipng-dist; Fri, 30 Jun 2000 07:05:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UE5A620364 for ; Fri, 30 Jun 2000 07:05:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA21575 for ; Fri, 30 Jun 2000 07:05:04 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17990 for ; Fri, 30 Jun 2000 07:05:03 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id JAA17249; Fri, 30 Jun 2000 09:55:19 -0400 (EDT) Date: Fri, 30 Jun 2000 09:55:19 -0400 (EDT) From: Scott Bradner Message-Id: <200006301355.JAA17249@newdev.harvard.edu> To: bound@zk3.dec.com, brian@hursley.ibm.com Subject: Re: Revised IPng Working Group Charter Cc: deering@cisco.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian sez: > But the people who understand QOS are in the transport area, and so far > they have ignored it. "ignored" is a bit strong (see RFC 1809) but it has not been a priority (so to speak) in light of the other QoS developments under way. in response to Jim: > flowlabel should be done here or in routing area. > those are the people who understand it and ramifications. the use of the flowlabel as a routing process optimizer or as a QoS enabler or both would be a useful discussion to have Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 07:09:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UE8ak20393 for ipng-dist; Fri, 30 Jun 2000 07:08:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UE8P620386 for ; Fri, 30 Jun 2000 07:08:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA26811 for ; Fri, 30 Jun 2000 07:08:25 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19642 for ; Fri, 30 Jun 2000 07:08:23 -0700 (PDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Fri, 30 Jun 2000 07:30:58 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N54ZNK8C; Fri, 30 Jun 2000 08:29:26 -0400 Received: from nortelnetworks.com (clemson.corpeast.baynetworks.com [132.245.252.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LSZ6RL4L; Fri, 30 Jun 2000 08:29:16 -0400 Message-ID: <395C91AD.FF2BF1DE@nortelnetworks.com> Date: Fri, 30 Jun 2000 08:25:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: IPng Mailing List Subject: Re: scoped-arch comments References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Erik Nordmark wrote: > ... major snip ... > > If we go this path (allowing different scope zones ids in sin6_scope_id) > it might make sense to add parallels to the if_nametoindex() etc APIs. > Either > site_nametoindex(), site_indextoname(), site_nameindex() > link_nametoindex(), ... > or a more general set of routines > sz_nametoindex(char *name, int scope_level) > > That way we can add protocol support (something like MZAP?) > for advertising scope zone names in the future. Dave Thaler and I are already looking into either an extension to MZAP or an MZAP-like protocol for the scope name discovery work item on the updated charter. 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 Jun 30 07:30:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UERdh20426 for ipng-dist; Fri, 30 Jun 2000 07:27:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UERU620419 for ; Fri, 30 Jun 2000 07:27:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA24030 for ; Fri, 30 Jun 2000 07:27:30 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25707 for ; Fri, 30 Jun 2000 08:27:29 -0600 (MDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 1D90A4058; Fri, 30 Jun 2000 10:27:29 -0400 (EDT) Received: from yquarry.zk3.dec.com (byquarry.zk3.dec.com [16.140.96.30]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D275C41F6; Fri, 30 Jun 2000 10:27:28 -0400 (EDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id KAA0000006258; Fri, 30 Jun 2000 10:27:28 -0400 (EDT) From: Jim Bound Message-Id: <200006301427.KAA0000006258@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Scott Bradner Cc: bound@zk3.dec.com, brian@hursley.ibm.com, deering@cisco.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of "Fri, 30 Jun 2000 09:55:19 EDT." <200006301355.JAA17249@newdev.harvard.edu> Date: Fri, 30 Jun 2000 10:27:28 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk scott et al... here is another one I heard at an internal wireless conference I was at for engineering "indirectly". it appears some server vendor ISVs like to put a black-network-box in front of a bunch of servers and load balance them based on IP addr+tcp/udp port number (sure lots of folks do this but...). (...Server 1) --------- (Server 2) ------- (Server 3) ---- BLACK BOX TO ABOVE NETWORK CONNECTONS Not important how the black-box talks to the servers (atm, ethernet, hippi, etc). So this server engineer says to me hey jim I am hosed with IPsec v4 or v6!!!!! Yep I sez..... So this server engineer says so how about using the flowlabel with the IPv6 addresses..... I sez this field is TBD ...(standard party line) , of course its your own trip :-----) Besides the input that this is another means to use the flowlabel when IPSec has encrypted everything as identifier, it also tells me that this field is sitting there in IPv6 and we need to do something with it soon. take care, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 07:45:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UEgqk20454 for ipng-dist; Fri, 30 Jun 2000 07:42:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UEgf620447 for ; Fri, 30 Jun 2000 07:42:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA00763 for ; Fri, 30 Jun 2000 07:42:41 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06405 for ; Fri, 30 Jun 2000 08:42:40 -0600 (MDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id KAA17514; Fri, 30 Jun 2000 10:33:19 -0400 (EDT) Date: Fri, 30 Jun 2000 10:33:19 -0400 (EDT) From: Scott Bradner Message-Id: <200006301433.KAA17514@newdev.harvard.edu> To: bound@zk3.dec.com, sob@harvard.edu Subject: Re: Revised IPng Working Group Charter Cc: brian@hursley.ibm.com, deering@cisco.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk humm - idle bits are the devil's playground Scott --- From bound@zk3.dec.com Fri Jun 30 10:28:04 2000 From: Jim Bound X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Scott Bradner Cc: bound@zk3.dec.com, brian@hursley.ibm.com, deering@cisco.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of "Fri, 30 Jun 2000 09:55:19 EDT." <200006301355.JAA17249@newdev.harvard.edu> Date: Fri, 30 Jun 2000 10:27:28 -0400 X-Mts: smtp scott et al... here is another one I heard at an internal wireless conference I was at for engineering "indirectly". it appears some server vendor ISVs like to put a black-network-box in front of a bunch of servers and load balance them based on IP addr+tcp/udp port number (sure lots of folks do this but...). (...Server 1) --------- (Server 2) ------- (Server 3) ---- BLACK BOX TO ABOVE NETWORK CONNECTONS Not important how the black-box talks to the servers (atm, ethernet, hippi, etc). So this server engineer says to me hey jim I am hosed with IPsec v4 or v6!!!!! Yep I sez..... So this server engineer says so how about using the flowlabel with the IPv6 addresses..... I sez this field is TBD ...(standard party line) , of course its your own trip :-----) Besides the input that this is another means to use the flowlabel when IPSec has encrypted everything as identifier, it also tells me that this field is sitting there in IPv6 and we need to do something with it soon. take care, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 07:50:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UEn0A20484 for ipng-dist; Fri, 30 Jun 2000 07:49:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UEmp620477 for ; Fri, 30 Jun 2000 07:48:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA01529 for ; Fri, 30 Jun 2000 07:48:50 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12046 for ; Fri, 30 Jun 2000 07:48:49 -0700 (PDT) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by ertpg14e1.nortelnetworks.com; Fri, 30 Jun 2000 10:39:29 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NZBMXNJ0; Fri, 30 Jun 2000 07:30:23 -0700 Received: from nortelnetworks.com (clemson.corpeast.baynetworks.com [132.245.252.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LSZ6RL5T; Fri, 30 Jun 2000 10:30:21 -0400 Message-ID: <395CAE0E.F60436D@nortelnetworks.com> Date: Fri, 30 Jun 2000 10:26:22 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt References: <4.2.2.20000628125350.01bd86e0@pop.epilogue.com> <4.2.2.20000629174645.01bec200@pop.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, Margaret Wasserman wrote: > > Hi Brian, > > Thanks for your quick and helpful response. Sure. Not a problem. > ... snip ... > I have another network management related question/issue... > > If I understand correctly, a zone-boundary router could use > the same site-local address within more than one site. It > would internally distinguish between these two addresses using > the zone ID of each site. Yes. > > I think it would be useful for an SNMP manager (or possibly > other applications) within a site-local zone to be able to > determine which zone ID a zone-boundary router is using to > identify the manager's local site. Do we currently have a way > to do this? Is anyone working on something like this? > Dave Thaler and I are planning on addressing the scope name discovery item on the revised charter. We are thinking that an MZAP-like mechanism will work. This will allow someone to determine what the "scope names" are on a given device. > A possible solution would be a new ICMP message that asks for > the remote host to return the zone ID indicated by the interface > on which the message was received. A message sent to a link-local > address would return a link-level zone ID; a message sent to a > site-local address would return the site-level zone ID. That may be a simple approach. Let me digest it a little more. 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 Jun 30 08:30:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UFRxf20543 for ipng-dist; Fri, 30 Jun 2000 08:27:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UFRm620536 for ; Fri, 30 Jun 2000 08:27:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA08247 for ; Fri, 30 Jun 2000 08:27:44 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04586 for ; Fri, 30 Jun 2000 08:27:42 -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 KAA25805; Fri, 30 Jun 2000 10:21:04 -0500 (CDT) Message-Id: <200006301521.KAA25805@gungnir.fnal.gov> To: Scott Bradner Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of Fri, 30 Jun 2000 10:33:19 EDT. <200006301433.KAA17514@newdev.harvard.edu> Date: Fri, 30 Jun 2000 10:21:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I haven't refreshed my ipsec wetware in some time, but can't the poor fellow peek at the SPI value to get his job done? Maybe this means that the load-shared servers have to divide up the SPI space among themselves, but that should be possible. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 08:36:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UFZ9820563 for ipng-dist; Fri, 30 Jun 2000 08:35:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UFYw620556 for ; Fri, 30 Jun 2000 08:34:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA16433 for ; Fri, 30 Jun 2000 08:34:57 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09129 for ; Fri, 30 Jun 2000 08:34:55 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id LAA17869; Fri, 30 Jun 2000 11:25:36 -0400 (EDT) Date: Fri, 30 Jun 2000 11:25:36 -0400 (EDT) From: Scott Bradner Message-Id: <200006301525.LAA17869@newdev.harvard.edu> To: bound@zk3.dec.com, crawdad@gungnir.fnal.gov, ipng@sunroof.eng.sun.com Subject: Re: Revised IPng Working Group Charter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk if the only thing the redirector does is forward out a special port to a particular server (or tunnel to the server) and all the servers are running as if they are using the same IP address this should work - but many redirectors operate as NAT boxes and fiddle with the IP addresses in the IP header which breaks IPSec scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 08:43:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UFfWO20587 for ipng-dist; Fri, 30 Jun 2000 08:41:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UFfN620579 for ; Fri, 30 Jun 2000 08:41:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA11632 for ; Fri, 30 Jun 2000 08:41:22 -0700 (PDT) Received: from audrey.enst-bretagne.fr (audrey.enst-bretagne.fr [192.108.115.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16862 for ; Fri, 30 Jun 2000 09:41:19 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e5UFf2l41836; Fri, 30 Jun 2000 17:41:09 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA28136; Fri, 30 Jun 2000 17:39:46 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA23672; Fri, 30 Jun 2000 17:40:53 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200006301540.RAA23672@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Brian Haberman" cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-reply-to: Your message of Fri, 30 Jun 2000 08:39:42 EDT. <395C950E.D3A907B4@nortelnetworks.com> Date: Fri, 30 Jun 2000 17:40:53 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > PS: my concern is about the routing table (both size and organization). The added complexity of scoped routing has been known for awhile now. My original scoped routing document pointed it out in all its messy details. => my concern is not how to do it but the price to pay to have it, ie. it is not a technical concern (as many concerns in this thread). Thanks Francis.Dupont@enst-bretagne.fr PS: is the scope routing table implemented by a router vendor? (I'd like to get opinion from router vendors) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 09:25:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UGN9Y20662 for ipng-dist; Fri, 30 Jun 2000 09:23:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UGN0620655 for ; Fri, 30 Jun 2000 09:23:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA20644 for ; Fri, 30 Jun 2000 09:22:58 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18361 for ; Fri, 30 Jun 2000 10:22:57 -0600 (MDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Fri, 30 Jun 2000 12:22:40 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N54Z33HS; Fri, 30 Jun 2000 12:22:40 -0400 Received: from nortelnetworks.com (clemson.corpeast.baynetworks.com [132.245.252.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LSZ6RL0X; Fri, 30 Jun 2000 12:22:29 -0400 Message-ID: <395CC856.CBFDA519@nortelnetworks.com> Date: Fri, 30 Jun 2000 12:18:30 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments References: <200006301540.RAA23672@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, I actually was implementing the scoped routing draft at my previous place of employment. But, since they no longer sell routers, the code is unavailable. The mechanism I used was to add an additional field to the forwarding table to indicate the scope id. The route lookups were done using the address and the id as the key to the lookup. Regards, Brian Francis Dupont wrote: > > In your previous mail you wrote: > > > PS: my concern is about the routing table (both size and organization). > > The added complexity of scoped routing has been known for awhile > now. My original scoped routing document pointed it out in all > its messy details. > > => my concern is not how to do it but the price to pay to have it, > ie. it is not a technical concern (as many concerns in this thread). > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: is the scope routing table implemented by a router vendor? > (I'd like to get opinion from router vendors) -- Brian Haberman Nortel Networks haberman@nortelnetworks.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 Jun 30 09:58:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UGuLn20719 for ipng-dist; Fri, 30 Jun 2000 09:56:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UGuC620712 for ; Fri, 30 Jun 2000 09:56:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA03570 for ; Fri, 30 Jun 2000 09:56:11 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA13226 for ; Fri, 30 Jun 2000 10:56:08 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jun 2000 09:55:14 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Fri, 30 Jun 2000 09:55:09 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024BCF700@RED-MSG-50> From: Richard Draves To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments Date: Fri, 30 Jun 2000 09:52:10 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My first reaction is I think your suggestions (reproduced below) are logical & consistent, but I do worry about one thing. If I understand correctly, you're saying that a user could say ping6 fec0::1%3 where 3 could be an interface index. On a multi-sited node, this would say "I mean fec0::1 in the site that interface 3 belongs to". But it would not constrain the packet to actually being sent out interface 3. It could be sent via any interface belonging to the same site as interface 3. My worry is that this would be rather confusing & nonintuitive for users. Rich > This leads to the following suggestions: > > - a non-zero sin6_scope_id value used when bind()ing a socket or > sending a packet is used only to identify the relevant zone of the > source or destination address, and *not* to identify a particular > interface for sending or receiving, even if the > sin6_scope_id happens > to be an interface index. I.e., the use of an interface > index would > not be interpreted as (over) specifying the choice of outgoing > interface. Of course, it would be cleaner to just use > zone indices, > not interface indices, for sin6_scope_id, but backwards > compatibility > with existing implementations might argue for allowing either. > > - the sin6_scope_id value returned in a sockaddr_in6 when receiving > a packet is interpreted only as identifying the zone of the source > address, not as the specific interface on which the > packet arrived. > Again, it would be cleanest if only zone indices were used, but > interface indices could be "tolerated" for backwards-compatibility > reasons. > > - to constrain an outgoing packet to a specific interface > or a set of > interfaces smaller than the set belonging to the destination > address's zone, you would specify an interface index or a > zone index > in the in6_pktinfo structure of the advanced API. For multicast > packets, you could alternatively use IPV6_MULTICAST_IF. > > - to determine the specific arrival interface of a packet, you would > use the in6_pktinfo structure of the advanced API. > > - when joining a multicast group, you would use IPV6_JOIN_GROUP with > either an interface index, a zone index, or zero (unspecified). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 10:46:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UHhbK20816 for ipng-dist; Fri, 30 Jun 2000 10:43:37 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UHhW620809 for ; Fri, 30 Jun 2000 10:43:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA23068 for ipng@sunroof.eng.sun.com; Fri, 30 Jun 2000 10:42:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UE4F620352 for ; Fri, 30 Jun 2000 07:04:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA26740 for ; Fri, 30 Jun 2000 07:04:15 -0700 (PDT) Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10791 for ; Fri, 30 Jun 2000 08:04:13 -0600 (MDT) Received: from dhcp-ep-6.epilogue.com ([128.224.1.106]:3588 "EHLO kenawang" ident: "IDENT-NOT-QUERIED [port 3588]") by newquern.epilogue.com with ESMTP id <227-176>; Fri, 30 Jun 2000 10:03:52 -0400 Message-Id: <4.2.2.20000629174645.01bec200@pop.epilogue.com> X-Sender: mrfpop@pop.epilogue.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: Brian Haberman From: Margaret Wasserman Subject: Re: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <395A4F61.74622A3F@nortelnetworks.com> References: <4.2.2.20000628125350.01bd86e0@pop.epilogue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 30 Jun 2000 10:03:52 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, Thanks for your quick and helpful response. >It is not THAT new. The problem with overlapping sites is that there is >no way to determine which site the address belongs to. Part of the past >confusion was that all these definitions had been talked about, but >never documented together. Well, it's new to me! :-). Actually, I fell out of the IPv6 discussions around the time that we began to uncover the issues with overlapping sites -- I pass my initial implementation and become more involved in management (corporate management, not network management). I'm just starting to catch back up on the IPv6 front. I agree with the restriction, I just wanted to make sure that is was intentional. I have another network management related question/issue... If I understand correctly, a zone-boundary router could use the same site-local address within more than one site. It would internally distinguish between these two addresses using the zone ID of each site. I think it would be useful for an SNMP manager (or possibly other applications) within a site-local zone to be able to determine which zone ID a zone-boundary router is using to identify the manager's local site. Do we currently have a way to do this? Is anyone working on something like this? A possible solution would be a new ICMP message that asks for the remote host to return the zone ID indicated by the interface on which the message was received. A message sent to a link-local address would return a link-level zone ID; a message sent to a site-local address would return the site-level zone ID. What do you think? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 11:11:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UI9D420849 for ipng-dist; Fri, 30 Jun 2000 11:09:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UI94620842 for ; Fri, 30 Jun 2000 11:09:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA22070 for ; Fri, 30 Jun 2000 11:09:03 -0700 (PDT) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15205 for ; Fri, 30 Jun 2000 11:08:59 -0700 (PDT) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Fri, 30 Jun 2000 13:02:30 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 13:05:33 -0500 Message-ID: From: "Peter Tam" To: Alex Conta Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" Date: Fri, 30 Jun 2000 13:05:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE2BD.C890F946" X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFE2BD.C890F946 Content-Type: text/plain; charset="ISO-8859-1" Alex: Please see inserts.... Peter -----Original Message----- From: Alex Conta [SMTP:aconta@txc.com] Sent: Thursday, June 29, 2000 11:13 AM To: Tam, Peter [NORSE:6L73:EXCH] Cc: Bob Hinden; ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" Peter, Thank you for your comments, which are important for the improving of this specification. For the first comment, I need more clarification, but it is probably better if I take the comments and answer them one by one, so please see bellow: Peter Tam wrote: > > > Bob: > > This is the 1st time I read this draft. Apology if the following have > been discussed before: > > 1. Must the Target Address List option in the Inverse Neighbor > Discovery Advertisement (InvNDA) message not contain unicast IPv6 > addresses only? I think it must. Then it will affect section > 4.3.2 on the validation procedures. > Would you please elaborate? >> Currently, the draft does not restrict the types of addresses within the Source/Target Address Lists in the IND Solicitation/Advertisement messages. Thus, it implies that both unicast and multicast addresses are legitimate. This address information is used to build the Neighbor cache, which I believe can contain only unicast addresses. If unicast-only addresses are imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should discard IND messages containing multicast addresses, so that they will not be entered into the cache. After all, resolution should be between link layer addresses and unicast network addresses. > 1. Should it not also support unsolicited InvNDA, when 1 or more of > an inteface's IP addresses have been changed? It should, and > should also enforce to re-advertise all the addresses on that > interface. Otherwise, it is not possible to cover the scenario > where an IP address on the interface was deleted. > The motivations to the present text in the specification were the following: 1. Minimizing and possibly eliminating unsolicited messages is a good thing. 2. The scenario in which one or more new IPv6 address are added to an existent VC can be solved by having the node adding such addresses send IND Solicitation(s). 3. The scenario in which one ore more IPv6 addresses associated with a VC are deleted while the VC and DLCI remain was envisaged to happen seldom - more often, the VC and DLCI would be torn down as well - and be resolved through the IPv6 address deprecation. >> There are 2 possible ways of providing changed IP address (added or deleted) information using IND. First way is for the node that changes its IP address(es) to use an unsolicited IND Advertisement message to identify all the source IP addresses on that interface. The 2nd is for that node to use an IND Solicitation message to identify all the source IP addresses. The IND advertisement approach would have to add an S-bit to the advertisement message, changing message format in the current draft. But it involves 1 message type, the Advertisement. Secondly, the IND solicitation approach does not change the current message formats, but will double the amount of IND traffic with an advertisement response. Need only 1 approach. > 1. Appendix A: Frame Relay (FR) as a link-layer address. But it > should have a note up front that the DLCI applies to the member > DLCI in the case of a Multi-link Frame Relay. > The appendix was intended to contain one simple example to illustrate the use of the protocol. Some particular details of the link in the example were considered out of scope. >> Out-of/in scope is an artificial line. In this case, all it takes is only 1 line of clarification. > 1. Why is there a preference of FR to ATM in Appendix A? Should also > include the case for ATM as a link-layer technology. > > As said previously, the appendix contains just one example, to illustrate simply and briefly the use of the protocol. Although it is mentioned that it may apply to other link technologies, it was not intended to cover more or all possible link technologies. >> Yes, I agree. 1 scenario is as good as 2 or 3 if they are similar. Moreover, you did indeed state the intent in the Abstract. Also, I am a FR supporter. > > > Regards... Peter Tam, > Nortel Networks, Ottawa Thank you, Alex Conta Transwitch Corporation, Shelton, CT > > > -----Original Message----- > From: Bob Hinden [SMTP:hinden@iprg.nokia.com] > Sent: Thursday, June 22, 2000 4:27 PM > To: ipng@sunroof.eng.sun.com > Subject: W.G. Last Call on "Extensions to IPv6 Neighbor > Discovery for Inverse Discovery Specification" > > This is a IPng working group last call for comments on advancing > the > following document as a Proposed Standard: > > Title : Extensions to IPv6 Neighbor Discovery > for Inverse > Discovery Specification > Author(s) : A. Conta > Filename : draft-ietf-ion-ipv6-ind-03.txt > Pages : 22 > Date : 27-Oct-99 > > Please send substantive comments to the ipng mailing list, and > minor > editorial comments to the author. This last call period will end > two > week from today on July 6, 2000. > > Bob Hinden / Steve Deering > > > ------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > ------------------------------------------------------------------- > ------_=_NextPart_001_01BFE2BD.C890F946 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: W.G. Last Call on "Extensions to IPv6 Neighbor = Discovery for Inverse Discovery Specification"

Alex: Please see inserts.... = Peter

    -----Original = Message-----
    From:   Alex Conta = [SMTP:aconta@txc.com]
    Sent:   Thursday, June 29, 2000 11:13 AM
    To:     Tam, Peter [NORSE:6L73:EXCH]
    Cc:     Bob Hinden; ipng@sunroof.eng.sun.com
    Subject:       = Re: W.G. Last Call on = "Extensions to IPv6 Neighbor Discovery for  Inverse Discovery = Specification"

    Peter,

    Thank you for your comments, which are = important for the improving of
    this specification.
    For the first comment, I need more = clarification, but it is probably
    better if I take the comments and = answer them one by one, so please see
    bellow:

    Peter Tam wrote:

    >
    >
    > Bob:
    >
    > This is the 1st time I read this = draft. Apology if the following have
    > been discussed before:
    >
    >   1. Must the Target = Address List option in the Inverse Neighbor
    >      = Discovery Advertisement (InvNDA) message not contain unicast = IPv6
    >      = addresses only? I think it must. Then it will affect section
    >      = 4.3.2 on the validation procedures.
    >

    Would you please = elaborate?
    >> Currently, the draft does = not = restrict the = types of = addresses within = the Source/Target Address Lists in the IND Solicitation/Advertisement messages. Thus, it implies that both unicast and multicast = addresses are legitimate. This address information is used to = build the Neighbor cache, which I believe can contain only unicast addresses. If unicast-only addresses are imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should discard IND messages containing multicast addresses, so that = they will not be entered = into the cache. After = all, = resolution = should be between link layer addresses and unicast network addresses.


    >   1. Should it not also = support unsolicited InvNDA, when 1 or more of
    >      an = inteface's IP addresses have been changed? It should, and
    >      = should also enforce to re-advertise all the addresses on that
    >      = interface. Otherwise, it is not possible to cover the scenario
    >      = where an IP address on the interface was deleted.
    >
    The motivations to the present text = in the specification were the
    following:

    1. Minimizing and possibly eliminating = unsolicited messages is a good
    thing.

    2. The scenario in which one or more = new IPv6 address are added to an
    existent VC can be solved by having = the node adding such addresses send
    IND Solicitation(s).

    3. The scenario in which one ore more = IPv6 addresses associated with a
    VC are deleted while the VC and DLCI = remain was envisaged to happen
    seldom - more often, the VC and DLCI = would be torn down as well   - and
    be resolved through the IPv6 address = deprecation.

    >> There are 2 possible = ways of providing = changed IP address (added or deleted) information using = IND. First way = is for the node that = changes its IP address(es) = to use = an unsolicited IND Advertisement message to identify all the = source IP addresses on that interface. The = 2nd is for that = node to use an = IND Solicitation = message to identify all the source IP addresses. The IND advertisement = approach would have = to add an S-bit = to the advertisement = message, = changing = message format in the current draft. But it = involves 1 message type, the Advertisement. Secondly, the IND solicitation approach does not change the current = message = formats, but = will double the amount of IND traffic = with an advertisement response. Need only = 1 approach.

    >   1. Appendix A: Frame = Relay (FR) as a link-layer address. But it
    >      = should have a note up front that the DLCI applies to the member
    >      = DLCI in the case of a Multi-link Frame Relay.
    >

    The appendix was intended to contain = one simple example to illustrate
    the use of the protocol. Some = particular details of the link in the
    example were considered out of = scope.
    >> Out-of/in scope is an = artificial line. In this case, all it takes = is only 1 line of = clarification.


    >   1. Why is there a = preference of FR to ATM in Appendix A? Should also
    >      = include the case for ATM as a link-layer technology.
    >
    >

    As said previously, the appendix = contains just one example, to
    illustrate simply and briefly the use = of the protocol. Although it is
    mentioned that it may apply to other = link technologies, it was not
    intended to cover more or all = possible link technologies.
    >> Yes, I agree. 1 scenario = is as good as 2 or 3 if they are similar. Moreover, you did indeed = state the = intent in the Abstract. Also, I am a FR supporter.

    >
    >
    > Regards... Peter Tam,
    > Nortel Networks, Ottawa

    Thank you,
    Alex Conta
    Transwitch Corporation, Shelton, = CT


    >
    >
    >      = -----Original Message-----
    >      = From:   Bob Hinden [SMTP:hinden@iprg.nokia.com]
    >      = Sent:   Thursday, June 22, 2000 4:27 PM
    >      = To:     ipng@sunroof.eng.sun.com
    >      = Subject:        W.G. Last Call on = "Extensions to IPv6 Neighbor
    >      = Discovery for Inverse  Discovery Specification"
    >
    >      = This is a IPng working group last call for comments on advancing
    >      = the
    >      = following document as a Proposed Standard:
    >
    >         = ;     = Title           : = Extensions to IPv6 Neighbor Discovery
    >      = for Inverse
    >         = ;            = ;           Discovery = Specification
    >         = ;     Author(s)       = : A. Conta
    >         = ;     = Filename        : = draft-ietf-ion-ipv6-ind-03.txt
    >         = ;     = Pages           : = 22
    >         = ;     = Date            = : 27-Oct-99
    >
    >      = Please send substantive comments to the ipng mailing list, and
    >      = minor
    >      = editorial comments to the author.  This last call period will = end
    >      = two
    >      = week from today on July 6, 2000.
    >
    >      = Bob Hinden / Steve Deering
    >
    >
    >      = -------------------------------------------------------------------
    >
    >      = IETF IPng Working Group Mailing List
    >      = IPng Home Page:
    >      http://playground.sun.com/ipng
    >      = FTP archive:
    >      ftp://playground.sun.com/pub/ipng
    >      = Direct all administrative requests to
    >      = majordomo@sunroof.eng.sun.com
    >
    >      = -------------------------------------------------------------------
    >

------_=_NextPart_001_01BFE2BD.C890F946-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 11:27:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UIQ9Z20905 for ipng-dist; Fri, 30 Jun 2000 11:26:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UIPw620898 for ; Fri, 30 Jun 2000 11:25:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA20114 for ; Fri, 30 Jun 2000 11:25:56 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17792 for ; Fri, 30 Jun 2000 12:25:38 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA02898; Sat, 1 Jul 2000 03:13:16 +0900 (JST) Date: Sat, 01 Jul 2000 03:18:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com Subject: Resend: icmp-name-lookups-05 User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Sat_Jul__1_03:18:06_2000-1" X-Dispatcher: imput version 980905(IM100) Lines: 256 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Sat_Jul__1_03:18:06_2000-1 Content-Type: text/plain; charset=US-ASCII Hello, Matt, Sorry for disturbing you so often, but if I remember correctly, I've never seen any responses to the attached mail. As an earlier implementer (and also a user/lover) of icmp-name-lookups, I really want to know your opinion, too. If you have already sent a reply to itojun or to the list, could you kindly resend it to the list, please? Again, I apologize if I miss a previous response. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Sat_Jul__1_03:18:06_2000-1 Content-Type: message/rfc822 To: crawdad@fnal.gov cc: ipng@sunroof.eng.sun.com Subject: icmp-name-lookups-05 X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Tue, 27 Jun 2000 16:05:51 +0900 Message-ID: <10312.962089551@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, I really need your input on this. Note that we really are implementing code based on the document, and in a serious need for clarification. itojun ------- Forwarded Messages Return-Path: Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id AAA17608 for ; Wed, 10 May 2000 00:57:51 +0900 (JST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24425; Tue, 9 May 2000 09:57:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29117; Tue, 9 May 2000 08:53:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e49FVIp27307 for ipng-dist; Tue, 9 May 2000 08:31:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e49FV4727300 for ; Tue, 9 May 2000 08:31:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12781 for ; Tue, 9 May 2000 08:31:00 -0700 (PDT) Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04072 for ; Tue, 9 May 2000 09:30:49 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e49FUQE05019; Wed, 10 May 2000 00:30:26 +0900 (JST) To: crawdad@fnal.gov cc: ipng@sunroof.eng.sun.com Subject: icmp-name-lookups-05.txt>: NOOP 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: Wed, 10 May 2000 00:30:26 +0900 Message-ID: <5017.957886226@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org icmp-name-lookups-05 says the following. >5.1. NOOP > > This NI type has no defined flags and never has a Data field. A > Reply to a NI NOOP Query tells the Querier that a node with the > Queried Address is up and reachable, implements the Node Information > protocol, and incidentally happens to reveal whether the Queried > Address was an anycast address. However, since these seem to be no Code defined for empty Data field, it is not possible for a Querier to transmit NOOP packet with empty Data field. Definition of NOOP and Code seems, at least, contradictory. Or is the evaluation of Code field dependent to Qtype field? (i.e. we should ignore Code field if Qtype equals to NOOP or Qtype equals to Supported Qtypes) 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 - -------------------------------------------------------------------- ------- Message 2 Return-Path: Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA06859 for ; Thu, 18 May 2000 01:36:13 +0900 (JST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28739; Wed, 17 May 2000 10:34:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA03043; Wed, 17 May 2000 07:30:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HE2aH03546 for ipng-dist; Wed, 17 May 2000 07:02:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HE2L703539 for ; Wed, 17 May 2000 07:02:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA02818 for ; Wed, 17 May 2000 07:02:20 -0700 (PDT) Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12895 for ; Wed, 17 May 2000 08:02:18 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e4HDX8f04271; Wed, 17 May 2000 22:33:08 +0900 (JST) cc: ipng@sunroof.eng.sun.com to: crawdad@fnal.gov 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: ipngwg-icmp-name-lookups-05: dns compression From: Jun-ichiro itojun Hagino Date: Wed, 17 May 2000 22:33:08 +0900 Message-ID: <4269.958570388@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-Filter: mailagent [version 3.0 PL68] for itojun@itojun.org Hello, again I have couple of questions about name-lookups-05. if we (as ipngwg) are more likely to go to multicast DNS than icmp name lookup, please tell us so - we at KAME are very interested in zeroconf-oriented configurations and love to provide/test common local name lookup mechanisms without config twists. itojun 1. DNS compression the draft uses DNS wire format (as defined in RFC1035) in two places; subject DNS name in queries (very last paragraph in section 3), and DNS names in replies (5.3). My question is: if we are to use DNS message compression (RFC1035 4.1.4), where should we count offset from? Will it be the beginning of ICMPv6 message, or beginning of the part formatted by DNS wire format? or is DNS message compression is not permitted at all? 2. restriction on IPv6 destination address for validation on receiving side, section 4 says like the folloing: > Upon receiving a NI Query, the Responder must check the Query's IPv6 > destination address and discard the Query without further processing > unless it is one of the Responder's unicast or anycast addresses, a > NI Group Address for a name belonging to the Responder, or a NI > Group Address for a name for which the Responder is providing proxy > service. considering that ICMPv6 specification recommends a node to reply to ICMPv6 echo request toward multicast destination, I'm not sure if the above restriction buys us much protection. I can query hostnames for all nodes in the site, by the following steps: - ping6 ff05::1 - for all nodes answered, send node information query, with subject address (equal to IPv6 destination) I agree that icmp6 to wide-area multicast would be insecure, however, at least name-lookup draft is not very consistent with ICMPv6 RFC. Also, we find name lookup queries to ff02::1 very useful as debugging tool. How about permitting these? - unicast address - anycast address - link-local multicast addresses the node joins the last item is less strict than 05 draft. sender rule needs to be changed too if we take this route. 4. Subject address validation for validation on receiving side, section 4 says like the folloing: > A Responder must also silently discard a Query whose > Subject Address or Name (in the Data field) does not belong to that > node, unless it is providing proxy service for that Subject. A > single-component Subject Name matches any fully-qualified name whose > first label matches the Subject. All name matching is done in a > case-independent manner. What defines "address belongs to node"? for example, is "::1" valid as subject address? all IPv6 nodes supposed to have ::1 on loopback interface, so ::1 is valid for all nodes. Is a query packet with empty Subject valid? what should the code field be? also, we may have scope issue here. What should happen in the following cases: - if you got node information query from/to global IPv6 address, with link-local subject address for your node - if we got query from/to link-local address on interface A, with link-local subject address for interface B - if your (receiving) node node offers proxy service, and you've got scoped subject address in a query packet, how should we interpret the subject address? what is the suggested behavior? 5. code field on queries again, I don't understand how should a responding node must validate code field and subject field in the query message. (this is a recap) I'm not sure about the following: - what should be put into code field when subject part needs to be empty (NOOP, supported qtypes) - if it is legal to leave Subject portion of query empty, what should be put into code field? Basically, I think we'd need a table of valid combinations. the text leaves many cases unanswered. - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Messages -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --Multipart_Sat_Jul__1_03:18:06_2000-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 11:27:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UIPgZ20896 for ipng-dist; Fri, 30 Jun 2000 11:25:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UIPX620889 for ; Fri, 30 Jun 2000 11:25:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA19332 for ; Fri, 30 Jun 2000 11:25:32 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26628 for ; Fri, 30 Jun 2000 11:25:25 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA02885; Sat, 1 Jul 2000 03:13:04 +0900 (JST) Date: Sat, 01 Jul 2000 02:52:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-Reply-To: In your message of "Thu, 29 Jun 2000 18:36:29 -0700" References: <200006270805.KAA05747@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 73 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 29 Jun 2000 18:36:29 -0700, >>>>> Steve Deering said: > This leads to the following suggestions: > - a non-zero sin6_scope_id value used when bind()ing a socket or > sending a packet is used only to identify the relevant zone of the > source or destination address, and *not* to identify a particular > interface for sending or receiving, even if the sin6_scope_id happens > to be an interface index. I.e., the use of an interface index would > not be interpreted as (over) specifying the choice of outgoing > interface. Of course, it would be cleaner to just use zone indices, > not interface indices, for sin6_scope_id, but backwards compatibility > with existing implementations might argue for allowing either. > - the sin6_scope_id value returned in a sockaddr_in6 when receiving > a packet is interpreted only as identifying the zone of the source > address, not as the specific interface on which the packet arrived. > Again, it would be cleanest if only zone indices were used, but > interface indices could be "tolerated" for backwards-compatibility > reasons. > - to constrain an outgoing packet to a specific interface or a set of > interfaces smaller than the set belonging to the destination > address's zone, you would specify an interface index or a zone index > in the in6_pktinfo structure of the advanced API. For multicast > packets, you could alternatively use IPV6_MULTICAST_IF. > - to determine the specific arrival interface of a packet, you would > use the in6_pktinfo structure of the advanced API. > - when joining a multicast group, you would use IPV6_JOIN_GROUP with > either an interface index, a zone index, or zero (unspecified). > (If the above is just a restatement of what some of you have been > saying all along, please forgive me for spending more time talking > than listening.) Hmm...this is surely a candidate that we can compromise, but please let me ask you some questions about this model: - In this model, we still interpret sin6_scope_id as a single space (over all scopes), right? - Are we tring to allow users to specify broader scopes than interfaces in in6_pktinfo? (Note that the in6_pktinfo structure specifies an *interface* index according to RFC2292: struct in6_pktinfo { struct in6_addr ipi6_addr; /* src/dst IPv6 address */ unsigned int ipi6_ifindex; /* send/recv interface index */ }; There's no ambiguity in this point, so if the answer is yes, then we are trying to make an extension to the advanced API.) - If the answer to the previous question is yes, the interpretation of in6_pktinfo.ipi6_ifindex can be differrent between the sending side and the receiving side; for the sending side, we allow all type of zone identifier (as far as it is valid according to the corresponding address). For the receiving side, it is always interpreted as an interface index. Is this understanding correct? - What if we specify a zone ID of a broader scope than interface for IPV6_JOIN_GROUP? Does this mean we're listening to the multicast group on all the interfaces of the zone? Regardless of the answers to the questions, I think I have to consider the model more carefully...personally, I still think we should go with a simpler way (i.e the traditional way), but I may be wrong. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 11:38:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UIap220953 for ipng-dist; Fri, 30 Jun 2000 11:36:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UIag620946 for ; Fri, 30 Jun 2000 11:36:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA16542 for ; Fri, 30 Jun 2000 11:36:41 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA24913 for ; Fri, 30 Jun 2000 12:36:36 -0600 (MDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jun 2000 11:35:51 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 30 Jun 2000 11:35:38 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024BCF7D3@RED-MSG-50> From: Richard Draves To: "Thomas Narten (E-mail)" , "IPng List (E-mail)" Subject: quick autoconf question Date: Fri, 30 Jun 2000 11:35:30 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm reviewing the latest TAHI test results. They've added some new tests for autoconfiguration, and one of them raises a question. If I receive a Neighbor Advertisement and the Destination Address in the IPv6 header is a tentative address and the Target Address in the NA is the same tentative address, should I process the NA (therefore concluding that the address is a duplicate) or should I silently discard the NA? In RFC 2462 it says: An address on which the duplicate Address Detection Procedure is applied is said to be tentative until the procedure has completed successfully. A tentative address is not considered "assigned to an interface" in the traditional sense. That is, the interface must accept Neighbor Solicitation and Advertisement messages containing the tentative address in the Target Address field, but processes such packets differently from those whose Target Address matches an address assigned to the interface. Other packets addressed to the tentative address should be silently discarded. The TAHI test says the NA should be silently discarded, and reading the quoted paragraph closely it's not quite clear. It hinges on the word "Other" in the last sentence. Note that normally when when the Target Address is a tentative address, the destination address is multicast (ff02::1 for NAs and solicited-node multicast for NSs) so the answer only affects clever tests, not normal operation. 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 Jun 30 12:31:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UJUEB21032 for ipng-dist; Fri, 30 Jun 2000 12:30:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UJU5621025 for ; Fri, 30 Jun 2000 12:30:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA04304 for ; Fri, 30 Jun 2000 12:30:04 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07039 for ; Fri, 30 Jun 2000 12:30:03 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA35854; Fri, 30 Jun 2000 15:29:57 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA40198; Fri, 30 Jun 2000 15:29:20 -0400 Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA12271; Fri, 30 Jun 2000 15:28:47 -0400 Message-Id: <200006301928.PAA12271@ludwigia.raleigh.ibm.com> To: Richard Draves cc: "IPng List (E-mail)" Subject: Re: quick autoconf question In-Reply-To: Message from Richard Draves of "Fri, 30 Jun 2000 11:35:30 PDT." <4D0A23B3F74DD111ACCD00805F31D81024BCF7D3@RED-MSG-50> Date: Fri, 30 Jun 2000 15:28:46 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, Maybe I misunderstand the issue, but it seems obvious that a node MUST accept the NA. If it doesn't accept the NA, DAD won't work. I.e., you rely on someone else returning an NA to indicate that the tentative address is in use. If you discard it without processing it, the DAD code won't see it either. What am I missing? I think you do point out that the wording isn't perfect though. I.e., it should say, something like "accept packets whose IP destination address is a tentative address". I.e., the idea is that you accept/process NA/ND packets addressed to tentative addresses, but silently discard all other packets addressed to the tentative address. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 12:53:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UJodR21071 for ipng-dist; Fri, 30 Jun 2000 12:50:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UJoT621064 for ; Fri, 30 Jun 2000 12:50:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA02845 for ; Fri, 30 Jun 2000 12:50:17 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA13095 for ; Fri, 30 Jun 2000 13:50:15 -0600 (MDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jun 2000 12:49:38 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 30 Jun 2000 12:49:36 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024BCF801@RED-MSG-50> From: Richard Draves To: Thomas Narten Cc: "IPng List (E-mail)" Subject: RE: quick autoconf question Date: Fri, 30 Jun 2000 12:47:52 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Maybe I misunderstand the issue, but it seems obvious that a node MUST > accept the NA. If it doesn't accept the NA, DAD won't work. I.e., you > rely on someone else returning an NA to indicate that the tentative > address is in use. If you discard it without processing it, the DAD > code won't see it either. What am I missing? This interpretation question does not affect normal DAD operation because the DAD packets are multicast - the NS is sent to a solicited-node multicast address and the NA is sent to the all-nodes-on-link multicast address. The question has to do with NA & NS where the destination address (== the target address) is tentative. 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 Jun 30 13:12:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UKAnu21105 for ipng-dist; Fri, 30 Jun 2000 13:10:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UKAc621098 for ; Fri, 30 Jun 2000 13:10:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA11927 for ; Fri, 30 Jun 2000 13:10:36 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27167 for ; Fri, 30 Jun 2000 13:10:35 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA27228; Fri, 30 Jun 2000 16:10:33 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA07016; Fri, 30 Jun 2000 16:10:33 -0400 Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA12548; Fri, 30 Jun 2000 16:10:00 -0400 Message-Id: <200006302010.QAA12548@ludwigia.raleigh.ibm.com> To: Richard Draves cc: "IPng List (E-mail)" Subject: Re: quick autoconf question In-Reply-To: Message from Richard Draves of "Fri, 30 Jun 2000 12:47:52 PDT." <4D0A23B3F74DD111ACCD00805F31D81024BCF801@RED-MSG-50> Date: Fri, 30 Jun 2000 16:10:00 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This interpretation question does not affect normal DAD operation because > the DAD packets are multicast - the NS is sent to a solicited-node multicast > address and the NA is sent to the all-nodes-on-link multicast > address. Oh, right. The sender of the DAD NS uses an unspecified source address, so the response can't be unicast. > The question has to do with NA & NS where the destination address (== the > target address) is tentative. Seems like that shouldn't be happening normally. So the TAHI interpretation seems reasonable. Either way, the cited wording in 2462 could be better. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 13:12:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UKA2b21096 for ipng-dist; Fri, 30 Jun 2000 13:10:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UK9r621089 for ; Fri, 30 Jun 2000 13:09:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA11783 for ; Fri, 30 Jun 2000 13:09:51 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24603 for ; Fri, 30 Jun 2000 14:09:50 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA65996; Fri, 30 Jun 2000 21:09:45 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA15070; Fri, 30 Jun 2000 21:09:45 +0100 (BST) Message-ID: <395CFE32.19E24800@hursley.ibm.com> Date: Fri, 30 Jun 2000 15:08:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Scott Bradner CC: ipng@sunroof.eng.sun.com Subject: Re: Revised IPng Working Group Charter References: <200006301355.JAA17249@newdev.harvard.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So can it be given a few minutes in the TSV WG in Pittsburgh, at least to see if there is any interest/volunteers? Brian Scott Bradner wrote: > > Brian sez: > > But the people who understand QOS are in the transport area, and so far > > they have ignored it. > > "ignored" is a bit strong (see RFC 1809) but it has not been a priority > (so to speak) in light of the other QoS developments under way. > > in response to Jim: > > flowlabel should be done here or in routing area. > > those are the people who understand it and ramifications. > > the use of the flowlabel as a routing process optimizer or as a QoS enabler > or both would be a useful discussion to have > > Scott > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 13:51:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UKnZI21203 for ipng-dist; Fri, 30 Jun 2000 13:49:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UKnK621187 for ; Fri, 30 Jun 2000 13:49:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA19880 for ; Fri, 30 Jun 2000 13:49:18 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA18508 for ; Fri, 30 Jun 2000 14:49:13 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jun 2000 13:48:22 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Fri, 30 Jun 2000 13:48:13 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024BCF857@RED-MSG-50> From: Richard Draves To: Thomas Narten Cc: "IPng List (E-mail)" , "Powell, Ken" Subject: RE: quick autoconf question Date: Fri, 30 Jun 2000 13:46:54 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The question has to do with NA & NS where the destination > address (== the > > target address) is tentative. > > Seems like that shouldn't be happening normally. So the TAHI > interpretation seems reasonable. Either way, the cited wording in 2462 > could be better. Yes. I'm happy to go with the TAHI interpretation - it's simpler to implement. 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 Jun 30 15:27:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UMPbd21294 for ipng-dist; Fri, 30 Jun 2000 15:25:37 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UMPX621287 for ; Fri, 30 Jun 2000 15:25:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id PAA00503 for ipng@sunroof.eng.sun.com; Fri, 30 Jun 2000 15:24:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UJXG621049 for ; Fri, 30 Jun 2000 12:33:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA05275 for ; Fri, 30 Jun 2000 12:33:14 -0700 (PDT) Received: from shrimp.baynetworks.com (ns4.BayNetworks.COM [192.32.253.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02840 for ; Fri, 30 Jun 2000 13:33:13 -0600 (MDT) Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id PAA15777 for ; Fri, 30 Jun 2000 15:27:04 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id PAA00356 for ; Fri, 30 Jun 2000 15:33:08 -0400 (EDT) Received: from skibum.engeast (skibum [192.32.138.69]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA09126; Fri, 30 Jun 2000 15:33:07 -0400 for Received: from localhost by skibum.engeast (SMI-8.6/SMI-SVR4) id PAA08608; Fri, 30 Jun 2000 15:33:07 -0400 Date: Fri, 30 Jun 2000 15:33:07 -0400 (EDT) From: Hamayon Mujeeb X-Sender: hmujeeb@skibum To: ipng@sunroof.eng.sun.com Subject: Route Leaking ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Could anybody kindly point me to any RFC or Internet Draft etc. that discusses Route Leaking ? Thanks Hamayon Mujeeb Nortel Networks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 15:30:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UMTPT21330 for ipng-dist; Fri, 30 Jun 2000 15:29:25 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UMTK621323 for ; Fri, 30 Jun 2000 15:29:20 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id PAA00539 for ipng@sunroof.eng.sun.com; Fri, 30 Jun 2000 15:28:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UKVq621162 for ; Fri, 30 Jun 2000 13:31:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA16374 for ; Fri, 30 Jun 2000 13:31:49 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08897 for ; Fri, 30 Jun 2000 13:31:49 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 16041774; Fri, 30 Jun 2000 15:31:49 -0500 (CDT) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id C38D96CB; Fri, 30 Jun 2000 15:31:48 -0500 (CDT) Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 16:31:48 -0400 Message-ID: From: "Powell, Ken" To: "'Richard Draves'" , "Thomas Narten (E-mail)" , "IPng List (E-mail)" Subject: RE: quick autoconf question Date: Fri, 30 Jun 2000 16:31:47 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, I've been working my way through the TAHI tests as well and am running into similar questions. I think the following sections of RFC 2462 also apply. 5.4.1. Message Validation A node MUST silently discard any Neighbor Solicitation or Advertisement message that does not pass the validity checks specified in [DISCOVERY]. A solicitation that passes these validity checks is called a valid solicitation or valid advertisement. 5.4.4. Receiving Neighbor Advertisement Messages On receipt of a valid Neighbor Advertisement message on an interface, node behavior depends on whether the target address is tentative or matches a unicast or anycast address assigned to the interface. If the target address is assigned to the receiving interface, the solicitation is processed as described in [DISCOVERY]. If the target address is tentative, the tentative address is not unique. I couldn't find anything that specifically states you should silently discard the Neighbor Advertisement. On the other hand, a Neighbor Advertisement sent in response to your Neighbor Solicit under DAD MUST be addressed to the all nodes multicast address, so it is probably reasonable to silently ignore the Neighbor Advertisement in this test. I tend to prefer to leave it up to the implementation unless there is a clear reason to mandate one option over the other. Ken Powell Compaq Computer Corporation > -----Original Message----- > From: Richard Draves [mailto:richdr@microsoft.com] > Sent: Friday, June 30, 2000 2:36 PM > To: Thomas Narten (E-mail); IPng List (E-mail) > Subject: quick autoconf question > > > I'm reviewing the latest TAHI test results. They've added > some new tests for > autoconfiguration, and one of them raises a question. > > If I receive a Neighbor Advertisement and the Destination > Address in the > IPv6 header is a tentative address and the Target Address in > the NA is the > same tentative address, should I process the NA (therefore > concluding that > the address is a duplicate) or should I silently discard the NA? > > In RFC 2462 it says: > > An address on which the duplicate Address Detection Procedure is > applied is said to be tentative until the procedure has completed > successfully. A tentative address is not considered > "assigned to an > interface" in the traditional sense. That is, the interface must > accept Neighbor Solicitation and Advertisement messages containing > the tentative address in the Target Address field, but > processes such > packets differently from those whose Target Address matches an > address assigned to the interface. Other packets addressed to the > tentative address should be silently discarded. > > The TAHI test says the NA should be silently discarded, and > reading the > quoted paragraph closely it's not quite clear. It hinges on > the word "Other" > in the last sentence. > > Note that normally when when the Target Address is a > tentative address, the > destination address is multicast (ff02::1 for NAs and solicited-node > multicast for NSs) so the answer only affects clever tests, not normal > operation. > > 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 Fri Jun 30 16:49:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e5UNkoS21405 for ipng-dist; Fri, 30 Jun 2000 16:46:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e5UNkg621398 for ; Fri, 30 Jun 2000 16:46:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA23710 for ; Fri, 30 Jun 2000 16:46:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09794 for ; Fri, 30 Jun 2000 16:46:41 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA21708; Fri, 30 Jun 2000 16:46:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA09354; Fri, 30 Jun 2000 16:46:38 -0700 X-Virus-Scanned: Fri, 30 Jun 2000 16:46:38 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma009086; Fri, 30 Jun 00 16:46:29 -0700 Message-Id: <4.3.2.7.2.20000630164059.026665a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Jun 2000 16:44:19 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPv6 Flow Label Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Was "Re: Revised IPng Working Group Charter"] Thinking about the discussion on what to do with the IPv6 flow label field, I have couple of thoughts. The discussion about the best working group for this work is somewhat academic until there is a concrete proposal (i.e, an internet draft) for what do with it. The intent of the words in the draft charter was to say that if someone has a concrete proposal for how to use the IPv6 flow label field, they should present it to the IPng w.g. It will be easy once that happens to move it to a more appropriate w.g. if it makes sense. Just because we have the IPv6 flow label bits "available" it is not at all clear we want to do anything with them today. Our experience with IPv4 is that it would have been very nice to have had some open bits available for future use. The IP world will change in unexpected ways. These bits may become very useful 5-10 years from now. They may be needed for something that has not been thought of today. It might be much better to encourage experimentation with the flow label bits than to standardize something now. Lets use them wisely. 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 Jun 30 17:34:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e610X2F21432 for ipng-dist; Fri, 30 Jun 2000 17:33:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e610Wp621425 for ; Fri, 30 Jun 2000 17:32:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA24438 for ; Fri, 30 Jun 2000 17:32:51 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA25088 for ; Fri, 30 Jun 2000 17:32:50 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id UAA19721; Fri, 30 Jun 2000 20:32:40 -0400 (EDT) Date: Fri, 30 Jun 2000 20:32:40 -0400 (EDT) From: Scott Bradner Message-Id: <200007010032.UAA19721@newdev.harvard.edu> To: brian@hursley.ibm.com, sob@harvard.edu Subject: Re: Revised IPng Working Group Charter Cc: ipng@sunroof.eng.sun.com, mankin@isi.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So can it be given a few minutes in the TSV WG in Pittsburgh, at least to > see if there is any interest/volunteers? if someone wants to take a few min to talk about teh IPv6 flow label during the tsvwg session in Pittsburgh (assuming we hold one which depends on having things to talk about) please let Allison & me know Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 30 18:00:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e610wlL21483 for ipng-dist; Fri, 30 Jun 2000 17:58:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e610wb621476 for ; Fri, 30 Jun 2000 17:58:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA11724 for ; Fri, 30 Jun 2000 17:58:36 -0700 (PDT) From: mankin@ISI.EDU Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24663 for ; Fri, 30 Jun 2000 18:58:35 -0600 (MDT) Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14]) by east.isi.edu (8.9.2/8.9.2) with SMTP id UAA28532; Fri, 30 Jun 2000 20:59:00 -0400 (EDT) Date: Fri, 30 Jun 00 21:01:19 EDT Posted-Date: Fri, 30 Jun 00 21:01:19 EDT Message-Id: <10007010101.AA13547@maia.east.isi.edu> Received: by maia.east.isi.edu (4.1/4.0.3-6) id ; Fri, 30 Jun 00 21:01:19 EDT To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com, sob@harvard.edu Subject: re: Revised IPng Working Group Charter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > if someone wants to take a few min to talk about teh IPv6 flow label > during the tsvwg session in Pittsburgh I think this would be a good idea. > (assuming we hold one which depends on having things to talk about) Actually, we are definitely having one. We have one agenda item, and would have room in the same hour for a short flow label discussion. Allison -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 30 18:56:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e611rxv21535 for ipng-dist; Fri, 30 Jun 2000 18:53:59 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e611rn621528 for ; Fri, 30 Jun 2000 18:53:49 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e611rkj711748; Fri, 30 Jun 2000 18:53:46 -0700 (PDT) Date: Fri, 30 Jun 2000 18:53:37 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4.2.2.20000628125350.01bd86e0@pop.epilogue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I also have a question regarding zone-boundary routers... Is there > a distinction between zone-boundary and non-zone-boundary routers? > Or can any router that is attached to more than one link dynamically > become a zone boundary router due to reconfiguration or topology > changes? A router connected to more than one link always have to deal with multiple link-local scope zones. For site-local scope zones it can presumably change dynamically. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------