From owner-ipng@sunroof.eng.sun.com Sat Aug 1 03:08:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA19735 for ipng-dist; Sat, 1 Aug 1998 03:04:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA19728 for ; Sat, 1 Aug 1998 03:04:06 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA01846 for ; Sat, 1 Aug 1998 03:04:05 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA29432 for ; Sat, 1 Aug 1998 03:04:05 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id TAA28017; Sat, 1 Aug 1998 19:04:03 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (4.1) id xma028003; Sat, 1 Aug 98 19:03:29 +0900 Received: from localhost (localhost.iij.ad.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id TAA04839; Sat, 1 Aug 1998 19:03:42 +0900 (JST) To: ipng@sunroof.eng.sun.com, IPV6IMP@munnari.OZ.AU Subject: (IPng 6095) the second stable release of KAME IPv6/IPsec package Mime-Version: 1.0 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.93b51 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980801190342Y.kazu@iijlab.net> Date: Sat, 01 Aug 1998 19:03:42 +0900 X-Dispatcher: imput version 980702 Lines: 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is the second announcement of KAME stable release. KAME packages are provided hoping that they will be reference implementation for IPv6, IPsec and advanced internetworking features on BSD variants. They are freely available without warranty. As always, the stable packages are available from http://www.kame.net. Here attached RELNOTES to sum up the differences from the first stable release: <> - Tunnel mode IPsec is now ready (just for IPv4). - IPsec becames fairly stable, thanks to interoperability test held between 7/29-30 at Keio University. - Home-brew IKE daemon "racoon" appears. We need some work to make it actually usable. - Key management API is now PF_KEY version 2. <> Input: - Multiple prefixes are now properly handled. - Default router list handling became more sophisticated. - Timer handling became more sophisticated. - Both prefix list and default router list are visible by "ndp". Output: - "rtadvd" now can handle multiple prefixes on one link. - "rtadvd"'s timer handling became more sophisticated. - "rtadvd" checks RA consistency. - "rtadvd.conf" became easier-to-configure thanks to implicit default values. - RAs are now generated with the source link-layer address option. <> - ICMPv6 redirect became acceptable. - ICMPv6 error message is now generated against unknown header. <> - RAW IPv6 is now gained access from user space without IPv6 header to conform to Stevens's spec. - "struct sockaddr_in6" contains indexes to conform the upcoming draft. - "getaddrinfo" became more stable. - "getnodeinfo" has been provided. <> - IPv6 support for fetch, lpd, and others. - Enriched "port" collection including ALTQ, heimdal, IM, MRT, Perl5, SOCKS64, UCD SNMP, v6tun, and so forth. <> - For FreeBSD, ALTQ has been merged into the kernel. ATM driver is replaced to one that came with ALTQ. // KAME 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 Sun Aug 2 11:58:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA20327 for ipng-dist; Sun, 2 Aug 1998 11:49:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA20320 for ; Sun, 2 Aug 1998 11:49:05 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA06914 for ; Sun, 2 Aug 1998 11:49:02 -0700 Received: from hotmail.com (f252.hotmail.com [207.82.251.143]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA25353 for ; Sun, 2 Aug 1998 11:49:04 -0700 (PDT) Received: (qmail 2019 invoked by uid 0); 2 Aug 1998 18:49:04 -0000 Message-ID: <19980802184904.2018.qmail@hotmail.com> Received: from 202.188.24.193 by www.hotmail.com with HTTP; Sun, 02 Aug 1998 11:49:03 PDT X-Originating-IP: [202.188.24.193] From: "flowcontrol PDF" To: ipng@sunroof.eng.sun.com Subject: (IPng 6097) IPv6 over ATM Content-Type: text/plain Date: Sun, 02 Aug 1998 11:49:03 PDT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi everyone, I want to know whether RSVP can enhance the QoS of Internet applications in IPv6 over ATM? Does IPv6 over ATM still need the RSVP in order to provide acceptable QoS for all internet class of service ? Thanks Shuhaimi ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 2 14:15:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA20408 for ipng-dist; Sun, 2 Aug 1998 14:09:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA20401 for ; Sun, 2 Aug 1998 14:09:01 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14473 for ; Sun, 2 Aug 1998 14:09:00 -0700 Received: from send101.yahoomail.com (send101.yahoomail.com [205.180.60.87]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA16916 for ; Sun, 2 Aug 1998 14:09:00 -0700 (PDT) Message-ID: <19980802210818.23609.rocketmail@send101.yahoomail.com> Received: from [209.94.102.12] by send101.yahoomail.com; Sun, 02 Aug 1998 14:08:18 PDT Date: Sun, 2 Aug 1998 14:08:18 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6098) Re: IPv6 over ATM To: flowcontrol PDF , 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 Even if we use ATM PNNI for QoS support, I think we need RSVP for QoS support at the Network level. As ATM provides the QoS at data link layer. So IPV6 over ATM still needs RSVP for QoS support. -iprsvp. ---flowcontrol PDF wrote: > > Hi everyone, > I want to know whether RSVP can enhance the QoS of Internet applications > in IPv6 over ATM? > Does IPv6 over ATM still need the RSVP in order to provide acceptable > QoS for all internet class of service ? > > > Thanks > Shuhaimi > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 2 14:19:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA20421 for ipng-dist; Sun, 2 Aug 1998 14:13:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA20414 for ; Sun, 2 Aug 1998 14:13:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14865 for ; Sun, 2 Aug 1998 14:13:42 -0700 Received: from send1d.yahoomail.com (send1d.yahoomail.com [205.180.60.48]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA17679 for ; Sun, 2 Aug 1998 14:13:43 -0700 (PDT) Message-ID: <19980802210704.6113.rocketmail@send1d.yahoomail.com> Received: from [209.94.102.12] by send1d; Sun, 02 Aug 1998 14:07:04 PDT Date: Sun, 2 Aug 1998 14:07:04 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6099) Re: IPv6 over ATM To: ipng@sunroof.eng.sun.com, flowcontrol PDF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The solution IPv6 over ATM should not make any changes to routing layer. So routing layer is hidden from the fact that it is operating over ATM virtual links. So we need RSVP even if we are operating IPv6 over ATM. Let me know if there any mistakes. Thanks -iprsvp. ---flowcontrol PDF wrote: > > Hi everyone, > I want to know whether RSVP can enhance the QoS of Internet applications > in IPv6 over ATM? > Does IPv6 over ATM still need the RSVP in order to provide acceptable > QoS for all internet class of service ? > > > Thanks > Shuhaimi > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 2 14:26:06 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA20466 for ipng-dist; Sun, 2 Aug 1998 14:22:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA20459 for ; Sun, 2 Aug 1998 14:21:47 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA15362 for ; Sun, 2 Aug 1998 14:21:45 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA18846 for ; Sun, 2 Aug 1998 14:21:45 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA25722; Sun, 2 Aug 1998 16:23:46 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA19433; Sun, 2 Aug 98 16:21:42 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id QAA25722; Sun, 2 Aug 1998 16:21:41 -0500 Message-Id: <199808022121.QAA25722@cubbie.aud.alcatel.com> Date: Sun, 2 Aug 1998 16:21:41 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6100) Re: IPv6 over ATM To: ipng@sunroof.eng.sun.com, flowcontrol@hotmail.com, chirgi@cubbie.aud.alcatel.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: r41fyGxEl1cOUNepGDnVhQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If the question is flipped, it boils down to "do we need RSVP if underlying link-layer is QoS-active ?". The answer is: Yes. look at 4th para of the paper "RSVP and Integrated Services in the Internet: A tutorial" by Paul. P. White, in IEEE Communications magazine, may 1997, page 100. the phrase "enhance the QoS" in what sense is unclear. But certainly router RSVP reservations at the network management layer are essential for Internet datagram services However, RSVP router needs to map (negotiate with) to link-layer ATM QoS. Regards Girish > X-Originating-Ip: [202.188.24.193] > From: "flowcontrol PDF" > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6097) IPv6 over ATM > Mime-Version: 1.0 > X-BadHeader: plain > Date: Sun, 02 Aug 1998 11:49:03 PDT > > Hi everyone, > I want to know whether RSVP can enhance the QoS of Internet applications > in IPv6 over ATM? > Does IPv6 over ATM still need the RSVP in order to provide acceptable > QoS for all internet class of service ? > > > Thanks > Shuhaimi > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 3 14:30:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA21242 for ipng-dist; Mon, 3 Aug 1998 14:18:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA21235 for ; Mon, 3 Aug 1998 14:18:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14400 for ; Mon, 3 Aug 1998 14:18:03 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA20120 for ; Mon, 3 Aug 1998 14:17:03 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA06010; Mon, 3 Aug 1998 16:19:01 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA20137; Mon, 3 Aug 98 16:16:55 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id QAA27680; Mon, 3 Aug 1998 16:16:54 -0500 Message-Id: <199808032116.QAA27680@cubbie.aud.alcatel.com> Date: Mon, 3 Aug 1998 16:16:54 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6101) [Q] address allocation... To: ipng@sunroof.eng.sun.com Cc: chirgi@cubbie.aud.alcatel.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: 4AF3rmRD9+igzpNnHLZuug== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, a dumb question from me :-) As I see, from the initial allocation of IPv6 address pool there is no such thing as "Mobile IP address" pool. To be clear, for example FF prefix indicates multicast address pool and 010 prefix indicates Unicast addr pool. similarly, why not an address pool for mobile IP nodes? There should be some reason for not allocating such addr pool to mobile stuff. I would like to know... Thanks so much for your time... Regards Girish -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 3 14:57:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA21290 for ipng-dist; Mon, 3 Aug 1998 14:50:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA21283 for ; Mon, 3 Aug 1998 14:49:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA24947 for ; Mon, 3 Aug 1998 14:49:50 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA09598 for ; Mon, 3 Aug 1998 14:49:50 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA07608; Mon, 3 Aug 1998 16:51:48 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA21928; Mon, 3 Aug 98 16:49:40 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id QAA27725; Mon, 3 Aug 1998 16:49:40 -0500 Message-Id: <199808032149.QAA27725@cubbie.aud.alcatel.com> Date: Mon, 3 Aug 1998 16:49:40 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6102) Re: [Q] address allocation... To: ipng@sunroof.eng.sun.com, chirgi@aud.alcatel.com Cc: chirgi@cubbie.aud.alcatel.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: /V5sBvmNTpMUylxgo6JH5w== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, I just want to more cut-short the question.. In the unicast addr pool, after TLA + NLA + SLA (for hierarchical routing), why not a bit (MSB) allocated from the rest of 64 bits for distinguishing mobile addrs. (or even good if we steal a bit from either TLA or NLA or SLA feilds :-) sure, there should be some contra things to this allocations, any suggestions/hints Thanks a lot Regards Girish > Date: Mon, 3 Aug 1998 16:16:54 -0500 (CDT) > From: Girish Chiruvolu > Subject: (IPng 6101) [Q] address allocation... > To: ipng@sunroof.Eng.Sun.COM > Cc: chirgi@cubbie.aud.alcatel.com > Mime-Version: 1.0 > Content-Md5: 4AF3rmRD9+igzpNnHLZuug== > > > Hello all, > > a dumb question from me :-) > > As I see, from the initial allocation of IPv6 address pool > there is no such thing as "Mobile IP address" pool. > > To be clear, for example FF prefix indicates multicast > address pool and 010 prefix indicates Unicast addr pool. > similarly, why not an address pool for mobile IP nodes? > > There should be some reason for not allocating such addr pool > to mobile stuff. I would like to know... > > Thanks so much for your time... > > Regards -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 06:14:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA21849 for ipng-dist; Tue, 4 Aug 1998 06:09:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA21842 for ; Tue, 4 Aug 1998 06:09:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA10284 for ; Tue, 4 Aug 1998 06:09:47 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA11947 for ; Tue, 4 Aug 1998 06:09:45 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA26668; Tue, 4 Aug 1998 09:09:35 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id JAA25732; Tue, 4 Aug 1998 09:09:34 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id JAA20322; Tue, 4 Aug 1998 09:09:32 -0400 (EDT) Message-Id: <199808041309.JAA20322@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Girish Chiruvolu cc: ipng@sunroof.eng.sun.com, chirgi@cubbie.aud.alcatel.com Subject: (IPng 6104) Re: [Q] address allocation... In-reply-to: Your message of "Mon, 03 Aug 1998 16:16:54 CDT." <199808032116.QAA27680@cubbie.aud.alcatel.com> Date: Tue, 04 Aug 1998 09:09:32 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Girish, > To be clear, for example FF prefix indicates multicast > address pool and 010 prefix indicates Unicast addr pool. > similarly, why not an address pool for mobile IP nodes? > There should be some reason for not allocating such addr pool > to mobile stuff. I would like to know... Actually, I'd turn the question around and ask what the reason would be for allocating a bit in the address to indicate mobile vs. non-mobile. The implication of having such a bit is that addresses for mobile nodes would be syntactically different from addresses from non-mobile nodes, and more to the point, that nodes would process packets to/from mobile addresses *differently* from those to/from non-mobile nodes. What would the advantage of that be? Also, how do I decide whether I'm a mobile node or not? I become mobile by moving. It's very hard to predict in advance whether a node will ever be mobile. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 06:17:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA21858 for ipng-dist; Tue, 4 Aug 1998 06:14:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA21851 for ; Tue, 4 Aug 1998 06:14:17 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA10849 for ; Tue, 4 Aug 1998 06:14:14 -0700 Received: from send1b.yahoomail.com (send1b.yahoomail.com [205.180.60.23]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA13906 for ; Tue, 4 Aug 1998 06:14:16 -0700 (PDT) Message-ID: <19980804131340.21038.rocketmail@send1b.yahoomail.com> Received: from [138.111.39.131] by send1b; Tue, 04 Aug 1998 06:13:40 PDT Date: Tue, 4 Aug 1998 06:13:40 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6105) Re: [Q] address allocation... To: ipng@sunroof.eng.sun.com, Girish Chiruvolu Cc: chirgi@cubbie.aud.alcatel.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mobile IP address is like any other IP address. That can be one of the reasons. I think there should be some pool of address for 1. care of address 2. co located address. So each foreign agent should be given some pool of addresses for this reason. I don't see any reason for the mobile IP nodes to have a pool of addresses. Hope I am correct. Bcos I am still in learning phase. Let me know if there are any mistakes. -iprsvp. ---Girish Chiruvolu wrote: > > > Hello all, > > a dumb question from me :-) > > As I see, from the initial allocation of IPv6 address pool > there is no such thing as "Mobile IP address" pool. > > To be clear, for example FF prefix indicates multicast > address pool and 010 prefix indicates Unicast addr pool. > similarly, why not an address pool for mobile IP nodes? > > There should be some reason for not allocating such addr pool > to mobile stuff. I would like to know... > > Thanks so much for your time... > > Regards > Girish > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 06:43:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA21940 for ipng-dist; Tue, 4 Aug 1998 06:38:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA21933 for ; Tue, 4 Aug 1998 06:38:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA15480 for ; Tue, 4 Aug 1998 06:38:33 -0700 Received: from send1d.yahoomail.com (send1d.yahoomail.com [205.180.60.48]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA25316 for ; Tue, 4 Aug 1998 06:38:34 -0700 (PDT) Message-ID: <19980804133147.20024.rocketmail@send1d.yahoomail.com> Received: from [138.111.39.131] by send1d; Tue, 04 Aug 1998 06:31:47 PDT Date: Tue, 4 Aug 1998 06:31:47 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6106) Re: [Q] address allocation... To: Thomas Narten , Girish Chiruvolu Cc: ipng@sunroof.eng.sun.com, chirgi@cubbie.aud.alcatel.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agent adver. helps the mobile node to identify the whether it is home N/W or foreign N/W. Only the home agent with which it is going to register once it moves to foriegn N/W is aware of the fact that it is a mobile node. All the other nodes will process the packets destined for mobile nodes in NORMAL (based on dest. address) way. Even the registration request and replies are ICMP router adve. extensions. So only the home agents will process the these requests. Other nodes are not concerned about. Only the HOME &FOREIGN AGENTS are aware of the fact that the packets are destined for a mobile node. So there need not to be any special pool of addresses for mobile nodes. Hope I am clear. -iprsvp ---Thomas Narten wrote: > > Girish, > > > To be clear, for example FF prefix indicates multicast > > address pool and 010 prefix indicates Unicast addr pool. > > similarly, why not an address pool for mobile IP nodes? > > > There should be some reason for not allocating such addr pool > > to mobile stuff. I would like to know... > > Actually, I'd turn the question around and ask what the reason would > be for allocating a bit in the address to indicate mobile > vs. non-mobile. > > The implication of having such a bit is that addresses for mobile > nodes would be syntactically different from addresses from non-mobile > nodes, and more to the point, that nodes would process packets to/from > mobile addresses *differently* from those to/from non-mobile > nodes. What would the advantage of that be? > > Also, how do I decide whether I'm a mobile node or not? I become > mobile by moving. It's very hard to predict in advance whether a node > will ever be mobile. > > 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 > -------------------------------------------------------------------- > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 06:58:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA22003 for ipng-dist; Tue, 4 Aug 1998 06:50:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA21996 for ; Tue, 4 Aug 1998 06:50:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA19648 for ; Tue, 4 Aug 1998 06:50:18 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA00812 for ; Tue, 4 Aug 1998 06:50:19 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16422; Tue, 4 Aug 1998 09:50:16 -0400 (EDT) Message-Id: <199808041350.JAA16422@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6107) I-D ACTION:draft-ietf-ipngwg-trans-tokenring-05.txt Date: Tue, 04 Aug 1998 09:50:15 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over Token Ring Networks Author(s) : T. Narten, M. Crawford, S. Thomas Filename : draft-ietf-ipngwg-trans-tokenring-05.txt Pages : 10 Date : 03-Aug-98 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-trans-tokenring-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-trans-tokenring-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980803151116.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-tokenring-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980803151116.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 Aug 4 06:58:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA22023 for ipng-dist; Tue, 4 Aug 1998 06:54:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA22016 for ; Tue, 4 Aug 1998 06:53:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA20743 for ; Tue, 4 Aug 1998 06:53:45 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA02292 for ; Tue, 4 Aug 1998 06:53:38 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA27764; Tue, 4 Aug 1998 08:55:37 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA23873; Tue, 4 Aug 98 08:53:28 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id IAA28891; Tue, 4 Aug 1998 08:53:27 -0500 Message-Id: <199808041353.IAA28891@cubbie.aud.alcatel.com> Date: Tue, 4 Aug 1998 08:53:27 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6109) Re: [Q] address allocation... To: ipng@sunroof.eng.sun.com, chirgi@aud.alcatel.com, iprsvp@yahoo.com, narten@raleigh.ibm.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: TbDwNaqEyZhCKHoVrWDORQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all, thanks a lot for your feedback... > Mobile IP address is like any other IP address. agreed, because they were designed that way :-) >Actually, I'd turn the question around and ask what the reason would >be for allocating a bit in the address to indicate mobile >vs. non-mobile. yes, as you mentioned the datagrams intended for mobile nodes can be treated/routed differently by just looking at the IP address bit itself. May be some optimal algorithms in those aspects can be designed if we knew in advance that those datagrams are for (wireless) mobile nodes. not sure at this point, although! Also, I am not sure if such a (allocation) will make a big difference in syntax of the addresses. For, we need to get to 64 bit interface ID (right most 64 bits of IPv6 addr) from the current 48 bit IEEE-802 addr thereby getting the EUI-64 bit format. and 2^63 is a big number I guess for unique host identification (??) Just trying to justify the bit :-)) Regarding the definition of mobile, sure if you move you become mobile ! However, I am thinking of wireless mobile which have *probably* (or atleast capable of having) handoffs and different locations frequently (yes, the word 'frequent' used loosely (broader sense)). Finally, to clear-up my doubts, may I request a technical reason besides compatibility, of the IPX and NSAP addr pool allocation... (no, I am not questioning the allocation, but just trying to think of motivation for that) Thanks a lot, it is an interesting learning experience for me.. Regards Girish -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 06:58:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA22010 for ipng-dist; Tue, 4 Aug 1998 06:50:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA21994 for ; Tue, 4 Aug 1998 06:50:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA19640 for ; Tue, 4 Aug 1998 06:50:17 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA00795 for ; Tue, 4 Aug 1998 06:50:19 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA16409; Tue, 4 Aug 1998 09:50:14 -0400 (EDT) Message-Id: <199808041350.JAA16409@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6108) I-D ACTION:draft-ietf-ipngwg-discovery-v2-03.txt Date: Tue, 04 Aug 1998 09:50:09 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : W. Simpson, T. Narten, E. Nordmark Filename : draft-ietf-ipngwg-discovery-v2-03.txt Pages : 92 Date : 03-Aug-98 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-discovery-v2-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-discovery-v2-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-v2-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: <19980803150706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980803150706.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 Aug 4 07:21:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA22198 for ipng-dist; Tue, 4 Aug 1998 07:16:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA22191 for ; Tue, 4 Aug 1998 07:16:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA28762 for ; Tue, 4 Aug 1998 07:16:18 -0700 Received: from send1d.yahoomail.com (send1d.yahoomail.com [205.180.60.48]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA12503 for ; Tue, 4 Aug 1998 07:16:11 -0700 (PDT) Message-ID: <19980804140928.18298.rocketmail@send1d.yahoomail.com> Received: from [138.111.39.131] by send1d; Tue, 04 Aug 1998 07:09:28 PDT Date: Tue, 4 Aug 1998 07:09:28 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6110) Re: [Q] address allocation... To: narten@raleigh.ibm.com, chirgi@aud.alcatel.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 > > Regarding the definition of mobile, sure if you move you become mobile ! > However, I am thinking of wireless mobile which have *probably* (or atleast > capable of having) handoffs and different locations frequently (yes, the word > 'frequent' used loosely (broader sense)). >>>>>> IT IS CLERALY MENTIONED IN MOBILE IP SPECIFICATION THAT MOBILE IP PROTOCOL CAN'T BE (I REPEAT CAN'T ) be used for FREQUENT HANDOFFS. -iprsvp. > Finally, to clear-up my doubts, may I request a technical reason besides > compatibility, of the IPX and NSAP addr pool allocation... > > (no, I am not questioning the allocation, but just trying to think of motivation for that) > > Thanks a lot, it is an interesting learning experience for me.. > > Regards > Girish > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 07:23:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA22215 for ipng-dist; Tue, 4 Aug 1998 07:21:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA22208 for ; Tue, 4 Aug 1998 07:21:12 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA00574 for ; Tue, 4 Aug 1998 07:21:08 -0700 Received: from bagira.fsz.bme.hu (bagira.fsz.bme.hu [152.66.76.5]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA14868 for ; Tue, 4 Aug 1998 07:20:50 -0700 (PDT) Received: from localhost (mohacsi@localhost) by bagira.fsz.bme.hu (8.9.0.Beta5/8.9.0.Beta3+BME-IIT) with SMTP id QAA00951; Tue, 4 Aug 1998 16:20:53 +0200 (MET DST) Date: Tue, 4 Aug 1998 16:20:47 +0200 (MET DST) From: Janos Mohacsi To: Girish Chiruvolu cc: ipng@sunroof.eng.sun.com, iprsvp@yahoo.com, narten@raleigh.ibm.com Subject: (IPng 6111) Re: [Q] address allocation... In-Reply-To: <199808041353.IAA28891@cubbie.aud.alcatel.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, 4 Aug 1998, Girish Chiruvolu wrote: > Date: Tue, 4 Aug 1998 08:53:27 -0500 (CDT) > From: Girish Chiruvolu > To: ipng@sunroof.Eng.Sun.COM, chirgi@aud.alcatel.com, iprsvp@yahoo.com, > narten@raleigh.ibm.com > Subject: (IPng 6109) Re: [Q] address allocation... > > > Dear all, > > thanks a lot for your feedback... > > > > Mobile IP address is like any other IP address. > > agreed, because they were designed that way :-) > > >Actually, I'd turn the question around and ask what the reason would > >be for allocating a bit in the address to indicate mobile > >vs. non-mobile. > > yes, as you mentioned the datagrams intended for mobile nodes > can be treated/routed differently by just looking at the IP address > bit itself. May be some optimal algorithms in those aspects can be > designed if we knew in advance that those datagrams are for (wireless) > mobile nodes. not sure at this point, although! > > Also, I am not sure if such a (allocation) will make a big > difference in syntax of the addresses. > For, we need to get to 64 bit interface ID > (right most 64 bits of IPv6 addr) from the current 48 bit IEEE-802 > addr thereby getting the EUI-64 bit format. and 2^63 is a big number I guess > for unique host identification (??) Just trying to justify the bit :-)) Not necessarily globally unique. EUI-64 address allows locally unique addresses. Janos Mohacsi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 07:49:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA22341 for ipng-dist; Tue, 4 Aug 1998 07:44:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA22334 for ; Tue, 4 Aug 1998 07:44:20 -0700 (PDT) From: akephart@austin.ibm.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA10006 for ; Tue, 4 Aug 1998 07:44:19 -0700 Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA26912 for ; Tue, 4 Aug 1998 07:44:18 -0700 (PDT) Received: from netmail3.austin.ibm.com (netmail3.austin.ibm.com [9.53.250.99]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id JAA21310; Tue, 4 Aug 1998 09:44:02 -0500 Received: from aguila.austin.ibm.com (aguila.austin.ibm.com [9.53.150.192]) by netmail3.austin.ibm.com (8.8.5/8.8.5) with ESMTP id JAA15882; Tue, 4 Aug 1998 09:44:01 -0500 Received: (from akephart@localhost) by aguila.austin.ibm.com (AIX4.3/UCB 8.7/8.7-client1.01) id JAA37394; Tue, 4 Aug 1998 09:44:01 -0500 (CDT) Message-Id: <199808041444.JAA37394@aguila.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Girish Chiruvolu cc: ipng@sunroof.eng.sun.com Reply-To: akephart@austin.ibm.com Subject: (IPng 6112) Re: [Q] address allocation... In-reply-to: (Your message of Tue, 04 Aug 98 08:53:27 -0500.)<199808041353.IAA28891@cubbie.aud.alcatel.com> Date: Tue, 04 Aug 98 09:44:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Girish, It's easy to say that 63 bits is enough for reasonable uniqueness, but that's a slippery slope that we don't want to start down; if it's justified for mobile nodes, whose to say that it's not justified for some other set of properties? Unless there's an overriding reason (other than "I don't think it'll hurt anything), I'd be against munging the bits any more... -andrew [much deleted] > > Also, I am not sure if such a (allocation) will make a big > difference in syntax of the addresses. > For, we need to get to 64 bit interface ID > (right most 64 bits of IPv6 addr) from the current 48 bit IEEE-802 > addr thereby getting the EUI-64 bit format. and 2^63 is a big number I guess > for unique host identification (??) Just trying to justify the bit :-)) > > Regarding the definition of mobile, sure if you move you become mobile ! > However, I am thinking of wireless mobile which have *probably* (or atleast > capable of having) handoffs and different locations frequently (yes, the word > 'frequent' used loosely (broader sense)). > > Finally, to clear-up my doubts, may I request a technical reason besides > compatibility, of the IPX and NSAP addr pool allocation... > > (no, I am not questioning the allocation, but just trying to think of motivation for that) > > Thanks a lot, it is an interesting learning experience for me.. > > Regards > Girish > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- +---------------------------------------------------------------------------+ | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +---------------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 08:15:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA22417 for ipng-dist; Tue, 4 Aug 1998 08:08:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA22410 for ; Tue, 4 Aug 1998 08:08:28 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA16358 for ; Tue, 4 Aug 1998 08:08:26 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA10156 for ; Tue, 4 Aug 1998 08:08:26 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA29976; Tue, 4 Aug 1998 11:08:08 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA29468; Tue, 4 Aug 1998 11:08:08 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id LAA07970; Tue, 4 Aug 1998 11:08:06 -0400 (EDT) Message-Id: <199808041508.LAA07970@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Girish Chiruvolu cc: ipng@sunroof.eng.sun.com, iprsvp@yahoo.com Subject: (IPng 6114) Re: [Q] address allocation... In-reply-to: Your message of "Tue, 04 Aug 1998 08:53:27 CDT." <199808041353.IAA28891@cubbie.aud.alcatel.com> Date: Tue, 04 Aug 1998 11:08:06 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > May be some optimal algorithms in those aspects can be designed if > we knew in advance that those datagrams are for (wireless) mobile > nodes. not sure at this point, although! If you have a concrete proposal for how those bits would be used, then it becomes possible to have an engineering discussion about the benefits of such a bit vs. the negatives of having one. In the absence of a concrete proposal, allocating a bit is pretty much out of the question. I'll also note that the Mobile IPv6 work has not requested such a bit. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 08:21:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA22449 for ipng-dist; Tue, 4 Aug 1998 08:17:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA22438 for ; Tue, 4 Aug 1998 08:17:00 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA18457 for ; Tue, 4 Aug 1998 08:16:59 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA14540 for ; Tue, 4 Aug 1998 08:16:53 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA03732; Tue, 4 Aug 1998 10:18:56 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA28516; Tue, 4 Aug 98 10:16:49 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id KAA29060; Tue, 4 Aug 1998 10:16:49 -0500 Message-Id: <199808041516.KAA29060@cubbie.aud.alcatel.com> Date: Tue, 4 Aug 1998 10:16:49 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6115) Re: [Q] address allocation... To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: lS6SOezU+J70rzGK+OZReA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Tue, 4 Aug 1998 07:09:28 -0700 (PDT) > From: "Raghu V.V.J Vadapalli" > Subject: Re: (IPng 6101) [Q] address allocation... > To: narten@raleigh.ibm.com, chirgi@aud.alcatel.com, ipng@sunroof.Eng.Sun.COM > Mime-Version: 1.0 > > > > > Regarding the definition of mobile, sure if you move you become > mobile ! > > However, I am thinking of wireless mobile which have *probably* (or > atleast > > capable of having) handoffs and different locations frequently (yes, > the word > > 'frequent' used loosely (broader sense)). > > >>>>>> IT IS CLERALY MENTIONED IN MOBILE IP > SPECIFICATION THAT MOBILE IP PROTOCOL CAN'T BE > (I REPEAT CAN'T ) be used for FREQUENT HANDOFFS. > I am not sure again by your frequency, However, Paper by Charles E. Perkins and David B. Johnson, "Mobility support in IPv6" under section 3.1, (Requirements, Goals and Applicability, last para of that section) they talk about a frequency of 1 per sec. sorry, I dont have page numbers, but it appeared in MOBICOM, 1996. (?) I am also talking the same. Certainly, today evening I will have a closer look at Mobile IP spec. Thanks a lot Girish -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 09:08:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA22545 for ipng-dist; Tue, 4 Aug 1998 09:03:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA22538 for ; Tue, 4 Aug 1998 09:03:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA28515 for ; Tue, 4 Aug 1998 09:03:05 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA10471 for ; Tue, 4 Aug 1998 09:03:05 -0700 (PDT) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA28324; Tue, 4 Aug 1998 17:02:51 +0100 Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA23446; Tue, 4 Aug 1998 17:02:50 +0100 (BST) Message-Id: <35C730A3.D26043E3@hursley.ibm.com> Date: Tue, 04 Aug 1998 17:02:43 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: Girish Chiruvolu Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6116) Re: [Q] address allocation... References: <199808041444.JAA37394@aguila.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Girish, > Finally, to clear-up my doubts, may I request a technical reason besides > compatibility, of the IPX and NSAP addr pool allocation... I don't think the IPX allocation has ever been explored; I think we put it there in case Novell wanted to work on it. For the NSAP allocation see RFC 1888 but note that it is "experimental" and I am not aware of any implementations. Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 10:40:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA22706 for ipng-dist; Tue, 4 Aug 1998 10:34:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA22699 for ; Tue, 4 Aug 1998 10:33:53 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA00611 for ; Tue, 4 Aug 1998 10:33:47 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA06588 for ; Tue, 4 Aug 1998 10:33:39 -0700 (PDT) Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id NAA01059 for ; Tue, 4 Aug 1998 13:33:39 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00059; Tue, 4 Aug 1998 13:33:35 -0400 Message-Id: <199808041733.AA00059@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6117) Basic API Update Date: Tue, 04 Aug 1998 13:33:34 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I will have completed all edits to the Basic API update and will have preliminary draft to all by Aug 10th.. This will not be part of the IPng WG discussions at Chicago and once we review the preliminary draft we will submit as ID and as Info RFC update to RFC 2133. I believe all issues have been resolved and I was waiting on two implementations we were to get private input on.. The only oustanding issue was whether we add an interface index in addition to the site index in the socket structure.. I take consensus to be that we should only supply a site identifier and for applications that want to specify an exact interface they must use the Advanced API via send/recv[msg]. It was a split consensus (I want the interface index for all comm apis as note), but the complication and change in code base, and strong feelings for not doing this should sway our decision on not supporting the interface index. This too means the mreq structure stays in tact. My co-authors and I apologize for this taking so long but we needed to wrap this issue up and it took lots of discussion with implementers offline. THere will also be no RESERVED field in the new socket structure too. So here is the plan: Aug 10th - Preliminary draft to our list. Aug 10-19 - Discussion via Email and consensus. Aug 24-27 - IETF meeting.. We can meet with key principles if there are any major issues which I do not perceive now. Aug 31-Sept 4: Co-Authors review of Final Update. Sept 7th - Submit to Chairs as update Info RFC for Basic API Sept - Get new Info RFC Published via IETF processes. At this point we are done and many implementors have asked and the co-authors will support that any future changes to the Basic API must not break binary compatibility, or any other standards organization that extend this API. I will work with Chris Harding to get this into the processes of the Open Group for standardization in that forum. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 4 15:48:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA23147 for ipng-dist; Tue, 4 Aug 1998 15:37:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA23139 for ; Tue, 4 Aug 1998 15:37:22 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA03320 for ; Tue, 4 Aug 1998 15:37:21 -0700 Received: from escape.com (escape.com [198.6.71.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA01018 for ; Tue, 4 Aug 1998 15:37:22 -0700 (PDT) Received: from escape.com (slip-ppp-5-115.escape.com [205.160.47.115]) by escape.com (8.8.5/8.6.9) with ESMTP id SAA26749; Tue, 4 Aug 1998 18:30:53 -0400 (EDT) Message-ID: <35996FAE.DD06086D@escape.com> Date: Tue, 30 Jun 1998 19:07:27 -0400 From: Quool Reply-To: Quool@escape.com X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, 6bone@isi.edu Subject: (IPng 6119) IPv6 Security - Encryption, Authenticity, Trust, anything! Content-Type: multipart/alternative; boundary="------------DAD600B1FD34A2B8DC34C17C" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------DAD600B1FD34A2B8DC34C17C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey everyone, I am currently working on a research project based mainly on the security of IPv6. Anyone have any tips, ideas, concepts, or just anything relating to the subject! Researching how secure the IPv6 protocol is, compared to IPv4, and what will the effects of its transition be on the Internet, (ie: packet sniffing, tcp attacks, compatabilities, vulnerabilities). Comments are appreciated, Thanx in advance... QuooL -- ICQ: UIN #7432177 E-Mail: QuooL@Escape.Com IRC: EFnet Only: _Guest_ (or) QuooL Snail Mail: (Available Upon Request and Verification) PGP Sig./Fingerprint: {Not yet set} AOL Instant Messenger: Default IP _____________________________________________________ | Knowledge Without Wisdom / Wisdom Without Knowledge | | Dangerous / Frustrating - Unknown | | Free Kevin | |__________"Summa Sedes Capit Non Duos"_-M.O.D. _______| --------------DAD600B1FD34A2B8DC34C17C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hey everyone,
    I am currently working on a research project based mainly on the security of IPv6.  Anyone have any tips, ideas, concepts, or just anything relating to the subject!
    Researching how secure the IPv6 protocol is, compared to IPv4, and what will the effects of its transition be on the Internet, (ie: packet sniffing, tcp attacks, compatabilities, vulnerabilities).

                Comments are appreciated,
                                                            Thanx in advance...
                                                                                           QuooL
 
 
 

--
ICQ:                                     UIN #7432177
E-Mail:                                  QuooL@Escape.Com
IRC:                                      EFnet Only:   _Guest_   (or)   QuooL
Snail Mail:                             (Available Upon Request and Verification)
PGP Sig./Fingerprint:             {Not yet set}
AOL Instant Messenger:        Default IP
                     _____________________________________________________
                    |        Knowledge Without Wisdom / Wisdom Without Knowledge       |
                     |                                 Dangerous / Frustrating  - Unknown                 |
                      |                                            Free Kevin                                          |
                       |__________"Summa Sedes Capit Non Duos"_-M.O.D. _______|
  --------------DAD600B1FD34A2B8DC34C17C-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 5 03:12:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA23494 for ipng-dist; Wed, 5 Aug 1998 03:06:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA23487 for ; Wed, 5 Aug 1998 03:06:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA04310 for ; Wed, 5 Aug 1998 03:06:19 -0700 Received: from arthur.axion.bt.co.uk (arthur.axion.bt.co.uk [132.146.5.4]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA12386 for ; Wed, 5 Aug 1998 03:06:19 -0700 (PDT) Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by arthur.axion.bt.co.uk (PP) with SMTP; Wed, 5 Aug 1998 10:57:30 +0100 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA14097; Wed, 5 Aug 1998 09:55:32 GMT Date: Wed, 5 Aug 1998 09:55:32 +0000 (GMT) From: George Tsirtsis X-Sender: george@gideon To: ipng@sunroof.eng.sun.com Subject: (IPng 6122) Re: [Q] address allocation... (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This was sent yesterday but I have not seen it yet. Sorry if you get a duplicat. George ---------- Forwarded message ---------- Date: Tue, 4 Aug 1998 17:33:24 +0000 (GMT) From: George Tsirtsis To: akephart@austin.ibm.com Cc: Girish Chiruvolu , ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng 6112) Re: [Q] address allocation... On Tue, 4 Aug 1998 akephart@austin.ibm.com wrote: > Girish, > > It's easy to say that 63 bits is enough for reasonable > uniqueness, but that's a slippery slope that we don't want to start > down; if it's justified for mobile nodes, whose to say that it's not > justified for some other set of properties? Girish, If I may second what Andrew says, this is a very common mistake to make. You are thinking MobileIP and forget everything else. Addresses gives you the ability to identify and locate a node, they do not say anything (nor they should do) about what the node is/represents or what its capabilities are. If we start allocating addresses to Mobile IP nodes (either end-points or agents) then we should also do so for (and these are only examples) Tunnel End-points, conferencing units, NAT boxes, Firewalls, Bandwidth Brokers, DHCP Servers, ServLoc Servers, you get my drift ... and many many others. I am sure that there are a lot of people (to be honest including myself :) who would like to have separate address space for their favorit service. The fact is that you will end-up with a segmented address space that can not be agreegated and cannot be utilised. Best Regards George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 5 10:41:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA23986 for ipng-dist; Wed, 5 Aug 1998 10:34:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA23979 for ; Wed, 5 Aug 1998 10:34:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA22329 for ; Wed, 5 Aug 1998 10:33:59 -0700 Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA24679 for ; Wed, 5 Aug 1998 10:33:53 -0700 (PDT) Received: from localhost by ux6.sp.cs.cmu.edu id aa01644; 5 Aug 98 13:31 EDT To: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com From: Dave Johnson Reply-To: Dave Johnson Subject: (IPng 6125) New version of Mobile IPv6 draft submitted Date: Wed, 05 Aug 1998 13:31:55 -0400 Message-ID: <1642.902338315@ux6.sp.cs.cmu.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yesterday, I submitted a new version of the Internet-Draft "Mobility Support in IPv6" documenting Mobile IP for IPv6. This version is now basically the final version and is expected to go to "Last Call" soon. This draft will be discussed at the Mobile IP working group meeting in Chicago, Monday morning, 9:30-11:30. The official announcement for the draft is working its way through the system, but for those who would like a copy of the draft now, it is available from my ftp server at ftp://ftp.monarch.cs.cmu.edu/pub/internet-drafts/ draft-ietf-mobileip-ipv6-06.txt I have also appended below a summary of the major changes in the draft relative to the previous version of it. We would particularly like to get comments on the draft from those in both the Mobile IP working group and the IPng working group, either by email and/or at the meeting. See you all in Chicago... Dave -- David B. Johnson dbj@cs.cmu.edu Assistant Professor http://www.cs.cmu.edu/~dbj/ Computer Science Department http://www.monarch.cs.cmu.edu/ Carnegie Mellon University Phone: (412) 268-7399 5000 Forbes Avenue Fax: (412) 268-5576 Pittsburgh, PA 15213-3891 --------------------------------------------------------------------------- - Clarified that the Advertisement Interval option in Section 6.3 MAY be included in Router Advertisements by any router, not just by home agents. - Modified Section 6.5 to document a required change to the MaxRtrAdvInterval limit, in addition to the change to the MinRtrAdvInterval limit, and clarified that these new limits MAY be used by any router, not just by home agents. - Added Section 6.6 to document new limits on sending Router Solicitations by a mobile node while away from home. These changes are related to the MAX_RTR_SOLICITATIONS and RTR_SOLICITATION_INTERVAL Neighbor Discovery constants. - Added Section 6.2 documenting a modification to the format of a Prefix Information option for use in Router Advertisement messages. This modification allows a router to easily and efficiently advertise its own global unicast address. - Defined a new Home Agent Information Option for Router Advertisements (Section 6.4). This option allows those routers functioning as a home agent to optionally specify a preference (relative to other home agents on this link) and a lifetime for this advertisement for providing home agent service. Use of this option by home agents is optional. - Added Section 10.2, defining the general procedures to be used by a mobile node in receiving packets while away from home. In particular, for packets received with a Routing header, this section defines an exception for any use of a Routing header automatically derived by "reversing" the received Routing header, for any response packets sent by upper-layer protocols. - Changed the treatment of packets addressed to a mobile node's site-local address while the mobile node is away from home. The current consensus of the Mobile IP Working Group is that such packets SHOULD be tunneled to the mobile node by default, but this behavior MUST be configurable to disable it; currently, the exact definition and semantics of a "site" and a site-local address are undefined in IPv6, and this default behavior might change at some point in the future. - Added a definition of the treatment of multicast packets addressed to a multicast group to which a mobile node is subscribed, for which the multicast scope is link-local, site-local, organization-local, etc. As with packets sent to a mobile node's link-local and site-local addresses, link-local multicast packets MUST NOT be tunneled to the mobile node, and multicast packets addressed to a multicast address with scope larger than link-local but smaller than global (e.g., site-local and organization-local) SHOULD be tunneled to the mobile node by default, but this behavior MUST be configurable to disable it. - Added Section 7.2, detailing Mobile IP requirements on all IPv6 routers. They SHOULD be able to send an Advertisement Interval option in their Router Advertisements, and SHOULD be able to support sending unsolicited multicast Router Advertisements at the faster rate described in Section 6.5. - Added Section 10.14 describing the mobile node side of renumbering the home network, matching the home agent processing described in Section 9.7. - Simplified the sequence of tests in Section 9.4 performed by a home agent being requested to no longer serve as the sending mobile node's home agent. - Clarified in Section 10.5 that if a mobile node has multiple home addresses using different interface identifiers, then it SHOULD send a separate Binding Update to its home agent for each. - Finally filled in Section 2, giving a comparison of Mobile IPv6 with Mobile IP for IPv4. --------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 6 01:07:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA24665 for ipng-dist; Thu, 6 Aug 1998 01:02:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA24658 for ; Thu, 6 Aug 1998 01:02:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA23647 for ; Thu, 6 Aug 1998 01:02:37 -0700 Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA16310 for ; Thu, 6 Aug 1998 01:02:28 -0700 (PDT) Received: from ambryn.inrialpes.fr (ambryn.inrialpes.fr [194.199.20.183]) by ebene.inrialpes.fr (8.8.5/8.8.5) with ESMTP id KAA29699; Thu, 6 Aug 1998 10:02:25 +0200 (MET DST) Received: from ambryn (localhost [127.0.0.1]) by ambryn.inrialpes.fr (8.8.5/8.8.5) with SMTP id KAA18539; Thu, 6 Aug 1998 10:02:24 +0200 (MET DST) Message-ID: <35C96310.2B2D@inrialpes.fr> Date: Thu, 06 Aug 1998 10:02:24 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: Claude Castelluccia Subject: (IPng 6128) [Fwd: [Fwd: Re: Re: [Q] address allocation...]] Content-Type: multipart/mixed; boundary="------------5EF947523517" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------5EF947523517 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I forward this message on the behalf of Claude Castelluccia who already posted it twice to this mailing list apparently without any success. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet SIRAC (fax 52 52) --------------5EF947523517 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by pop-serv.inrialpes.fr (8.8.5/8.8.5) with ESMTP id JAA28101 for ; Thu, 6 Aug 1998 09:56:03 +0200 (MET DST) Received: from ambryn.inrialpes.fr (ambryn.inrialpes.fr [194.199.20.183]) by ebene.inrialpes.fr (8.8.5/8.8.5) with ESMTP id JAA29652 for ; Thu, 6 Aug 1998 09:56:01 +0200 (MET DST) Received: from ambryn (localhost [127.0.0.1]) by ambryn.inrialpes.fr (8.8.5/8.8.5) with SMTP id JAA18511 for ; Thu, 6 Aug 1998 09:56:01 +0200 (MET DST) Sender: Claude.Castelluccia@imag.fr Message-ID: <35C96190.5476@inrialpes.fr> Date: Thu, 06 Aug 1998 09:56:00 +0200 From: Claude Castelluccia X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: thierry.ernst@inrialpes.fr Subject: [Fwd: Re: (IPng 6104) Re: [Q] address allocation...] Content-Type: multipart/mixed; boundary="------------5D114C713F85" This is a multi-part message in MIME format. --------------5D114C713F85 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) ------- http://sirac.inrialpes.fr/------ --------------5D114C713F85 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by palmier.inrialpes.fr (8.8.5/8.8.5) with ESMTP id RAA29543 for ; Tue, 4 Aug 1998 17:06:02 +0200 (MET DST) Received: from ambryn.inrialpes.fr (ambryn.inrialpes.fr [194.199.20.183]) by ebene.inrialpes.fr (8.8.5/8.8.5) with ESMTP id RAA15488; Tue, 4 Aug 1998 17:05:41 +0200 (MET DST) Received: from ambryn (localhost [127.0.0.1]) by ambryn.inrialpes.fr (8.8.5/8.8.5) with SMTP id RAA05481; Tue, 4 Aug 1998 17:05:41 +0200 (MET DST) Sender: Claude.Castelluccia@imag.fr Message-ID: <35C72344.74B4@inrialpes.fr> Date: Tue, 04 Aug 1998 17:05:40 +0200 From: Claude Castelluccia X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: Thomas Narten CC: Girish Chiruvolu , claude.castelluccia@inrialpes.fr, ipng@sunroof.Eng.Sun.COM, chirgi@cubbie.aud.alcatel.com Subject: Re: (IPng 6104) Re: [Q] address allocation... References: <199808041309.JAA20322@cichlid.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thomas Narten wrote: > > Girish, > > > To be clear, for example FF prefix indicates multicast > > address pool and 010 prefix indicates Unicast addr pool. > > similarly, why not an address pool for mobile IP nodes? > > > There should be some reason for not allocating such addr pool > > to mobile stuff. I would like to know... > > Actually, I'd turn the question around and ask what the reason would > be for allocating a bit in the address to indicate mobile > vs. non-mobile. > I think that it would actually be very useful in order to provide a hierarchical mobility management scheme.... In the paper "toward a hierarchical Mobile IPv6" (to be presented at HPN98 in Sept. in Vienna), we present a hierarchical mobility management scheme for IPv6 based on the IETF Mobile IPv6. In this scheme, the Border routers of a site act as mobility agents. When a mobile host is roaming locally (ie within a site), it sends binding updates to the site's border routers instead of its CHs. As a result, since mobility is mostly local, the signaling load on the backbone is significantly reduced and handoffs are performed faster. Whenever a border router receives a packet it should then find out whether this packet is addressed to a fixed host or to a mobile host. In the former case, the packet is routed normally. If the packet is addressed for a MH, the router looks into its binding cache if it has a entry for this mobile host. If yes, it forwards it to the mobile host current CoA otherwise the packet is routed normally. If we use the current IP addressing scheme, the router should find out for each incoming packet whether it has a entry in its Binding cache for the destination specified in the destination field of the packet. This lookup phase is certainly not free performance-wise.... To solve this performance problem, we propose the definition of a mobility bit (the MSB of the SLA). If this bit is set to 0, then the border router knows that the destination host is a fixed host and routes the packet normally. If this bit is set to 1, the border router looks in its binding cache if it has a entry for the destination host.... As a result, the packets addressed to fixed hosts don't not suffer from the extra performance cost introduced by the mobility management protocol in the border routers. Only packets addressed to MHs will have to go through the lookup phase (BTW this cost also exist in Mobile IPv6 but it is introduced by the CH instead of the border router..). >Also, how do I decide whether I'm a mobile node or not? I become >mobile by moving. It's very hard to predict in advance whether a node >will ever be mobile. In our scheme, this does not really matter. A host could be identified by a fixed host IP address (as it is done today) and gets Mobile Addresses only when it moves ..(in order words, only the CoAs have to the Mobility bit set to 1). Claude. ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) ------- http://sirac.inrialpes.fr/------ --------------5D114C713F85-- --------------5EF947523517-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 6 04:50:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA24862 for ipng-dist; Thu, 6 Aug 1998 04:44:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA24855 for ; Thu, 6 Aug 1998 04:44:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA09474 for ; Thu, 6 Aug 1998 04:44:33 -0700 Received: from send1d.yahoomail.com (send1d.yahoomail.com [205.180.60.48]) by earth.sun.com (8.9.1/8.9.1) with SMTP id EAA10616 for ; Thu, 6 Aug 1998 04:44:34 -0700 (PDT) Message-ID: <19980806113751.14494.rocketmail@send1d.yahoomail.com> Received: from [209.94.102.1] by send1d; Thu, 06 Aug 1998 04:37:51 PDT Date: Thu, 6 Aug 1998 04:37:51 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6129) Re: [Fwd: [Fwd: Re: [Q] address allocation...]] To: Thierry Ernst , ipng@sunroof.eng.sun.com Cc: Claude Castelluccia MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi all!!! 1.Can we use MSB of FLOW LABEL field for identification of mobile packets. 2. Then we can use the MSB of site local adress for CoA. One quick Q: 1.Are the binding updates are sent in ICMP messages. Thanks -iprsvp ---Thierry Ernst wrote: > > Hi, > > I forward this message on the behalf of Claude Castelluccia > who already posted it twice to this mailing list apparently > without any success. > > > Thierry. > > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet SIRAC (fax 52 52) > > ATTACHMENT part 2 message/rfc822 > > -- > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > ------- http://sirac.inrialpes.fr/------ > > ATTACHMENT part 2.2 message/rfc822 > > Thomas Narten wrote: > > > > Girish, > > > > > To be clear, for example FF prefix indicates multicast > > > address pool and 010 prefix indicates Unicast addr pool. > > > similarly, why not an address pool for mobile IP nodes? > > > > > There should be some reason for not allocating such addr pool > > > to mobile stuff. I would like to know... > > > > Actually, I'd turn the question around and ask what the reason would > > be for allocating a bit in the address to indicate mobile > > vs. non-mobile. > > > > I think that it would actually be very useful in order > to provide a hierarchical mobility management scheme.... > > In the paper "toward a hierarchical Mobile IPv6" (to be presented > at HPN98 in Sept. in Vienna), we present a hierarchical mobility > management scheme for IPv6 based on the IETF Mobile IPv6. > In this scheme, the Border routers of a site act as mobility agents. > When a mobile host is roaming locally (ie within a site), it sends > binding updates to the site's border routers instead of its CHs. > > As a result, since mobility is mostly local, the signaling > load on the backbone is significantly reduced and handoffs are performed > faster. > Whenever a border router receives a packet it should then find out > whether this packet is addressed to a fixed host or to a mobile host. > In the former case, the packet is routed normally. If the > packet is addressed for a MH, the router looks into its binding > cache if it has a entry for this mobile host. If yes, it forwards it to > the mobile host current CoA otherwise the packet is routed normally. > > If we use the current IP addressing scheme, the router should find out > for each incoming packet whether it has a entry in its Binding cache for > the destination specified in the destination field of the packet. This > lookup phase is certainly not free performance-wise.... > To solve this performance problem, we propose the definition of a > mobility bit (the MSB of the SLA). If this bit is set to 0, then > the border router knows that the destination host is a fixed host > and routes the packet normally. If this bit is set to 1, the border > router looks in its binding cache if it has a entry for the destination > host.... > As a result, the packets addressed to fixed hosts don't not suffer from > the extra performance cost introduced by the mobility management > protocol in the border routers. Only packets addressed to MHs will > have to go through the lookup phase (BTW this cost also exist in Mobile > IPv6 but it is introduced by the CH instead of the border router..). > > >Also, how do I decide whether I'm a mobile node or not? I become > >mobile by moving. It's very hard to predict in advance whether a node > >will ever be mobile. > > In our scheme, this does not really matter. A host could be > identified by > a fixed host IP address (as it is done today) and gets Mobile > Addresses only when it moves ..(in order words, only the CoAs > have to the Mobility bit set to 1). > > > Claude. > > > > > > > > > > > ---------------------------------------- > Claude CASTELLUCCIA, INRIA Rhone-Alpes > ph: +33 4.76.61.52.15 (fax: 52.52) > ------- http://sirac.inrialpes.fr/------ > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 6 07:11:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA25087 for ipng-dist; Thu, 6 Aug 1998 07:00:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA25080 for ; Thu, 6 Aug 1998 07:00:22 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA06313 for ; Thu, 6 Aug 1998 07:00:18 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA28504 for ; Thu, 6 Aug 1998 07:00:18 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA18080; Thu, 6 Aug 1998 09:02:19 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA25421; Thu, 6 Aug 98 09:00:08 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id JAA02900; Thu, 6 Aug 1998 09:00:09 -0500 Message-Id: <199808061400.JAA02900@cubbie.aud.alcatel.com> Date: Thu, 6 Aug 1998 09:00:08 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6130) Re: [Fwd: [Fwd: Re: [Q] address allocation...]] To: Thierry.Ernst@inrialpes.fr, ipng@sunroof.eng.sun.com, iprsvp@yahoo.com, chirgi@cubbie.aud.alcatel.com Cc: Claude.Castelluccia@inrialpes.fr Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: +8CVYXj8HxSgixBEmH1J0g== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Thu, 6 Aug 1998 04:37:51 -0700 (PDT) > From: "Raghu V.V.J Vadapalli" > Subject: (IPng 6129) Re: [Fwd: [Fwd: Re: [Q] address allocation...]] > To: Thierry Ernst , ipng@sunroof.Eng.Sun.COM > Cc: Claude Castelluccia > Mime-Version: 1.0 > > hi all!!! > 1.Can we use MSB of FLOW LABEL field for identification > of mobile packets. At this point from what I understand, the flow-label is randomly generated (using all the bits allocated to this field). I guess you have to change that first :-) > 2. Then we can use the MSB of site local adress for > CoA. >From my understanding there is a big "Nay" to that :-) (mainly due to the seggregation of addr pool, I proposed a similar thing with host-id rather...). In my personal view tunnels are inefficient ('yep its a blanket stmt). But anyways, if some things work that way, thats fine also... If a bit can be allocated, then my question, anybody thinks of the wierd (fanciful) "Mobile ARP". Ofcourse, there's no ARP in IPv6 (as a part of ICMPv6), but the equivalent messages. > One quick Q: > 1.Are the binding updates are sent in ICMP messages. > nopes, they sent using extension header options.. With best regards, Girish Note: All of these are my personal views only, std disclaimers apply. > Thanks > -iprsvp > > > > ---Thierry Ernst wrote: > > > > Hi, > > > > I forward this message on the behalf of Claude Castelluccia > > who already posted it twice to this mailing list apparently > > without any success. > > > > > > Thierry. > > > > > > -- > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > * INRIA Rhone-Alpes Projet SIRAC (fax 52 52) > > > > ATTACHMENT part 2 message/rfc822 > > > > -- > > > > ---------------------------------------- > > Claude CASTELLUCCIA, INRIA Rhone-Alpes > > ph: +33 4.76.61.52.15 (fax: 52.52) > > ------- http://sirac.inrialpes.fr/------ > > > > ATTACHMENT part 2.2 message/rfc822 > > > > Thomas Narten wrote: > > > > > > Girish, > > > > > > > To be clear, for example FF prefix indicates multicast > > > > address pool and 010 prefix indicates Unicast addr pool. > > > > similarly, why not an address pool for mobile IP nodes? > > > > > > > There should be some reason for not allocating such addr pool > > > > to mobile stuff. I would like to know... > > > > > > Actually, I'd turn the question around and ask what the reason would > > > be for allocating a bit in the address to indicate mobile > > > vs. non-mobile. > > > > > > > I think that it would actually be very useful in order > > to provide a hierarchical mobility management scheme.... > > > > In the paper "toward a hierarchical Mobile IPv6" (to be presented > > at HPN98 in Sept. in Vienna), we present a hierarchical mobility > > management scheme for IPv6 based on the IETF Mobile IPv6. > > In this scheme, the Border routers of a site act as mobility agents. > > When a mobile host is roaming locally (ie within a site), it sends > > binding updates to the site's border routers instead of its CHs. > > > > As a result, since mobility is mostly local, the signaling > > load on the backbone is significantly reduced and handoffs are > performed > > faster. > > Whenever a border router receives a packet it should then find out > > whether this packet is addressed to a fixed host or to a mobile host. > > In the former case, the packet is routed normally. If the > > packet is addressed for a MH, the router looks into its binding > > cache if it has a entry for this mobile host. If yes, it forwards it > to > > the mobile host current CoA otherwise the packet is routed normally. > > > > If we use the current IP addressing scheme, the router should find out > > for each incoming packet whether it has a entry in its Binding cache > for > > the destination specified in the destination field of the packet. This > > lookup phase is certainly not free performance-wise.... > > To solve this performance problem, we propose the definition of a > > mobility bit (the MSB of the SLA). If this bit is set to 0, then > > the border router knows that the destination host is a fixed host > > and routes the packet normally. If this bit is set to 1, the border > > router looks in its binding cache if it has a entry for the > destination > > host.... > > As a result, the packets addressed to fixed hosts don't not suffer > from > > the extra performance cost introduced by the mobility management > > protocol in the border routers. Only packets addressed to MHs will > > have to go through the lookup phase (BTW this cost also exist in > Mobile > > IPv6 but it is introduced by the CH instead of the border router..). > > > > >Also, how do I decide whether I'm a mobile node or not? I become > > >mobile by moving. It's very hard to predict in advance whether a node > > >will ever be mobile. > > > > In our scheme, this does not really matter. A host could be > > identified by > > a fixed host IP address (as it is done today) and gets Mobile > > Addresses only when it moves ..(in order words, only the CoAs > > have to the Mobility bit set to 1). > > > > > > Claude. > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------- > > Claude CASTELLUCCIA, INRIA Rhone-Alpes > > ph: +33 4.76.61.52.15 (fax: 52.52) > > ------- http://sirac.inrialpes.fr/------ > > > > > > _________________________________________________________ > DO YOU YAHOO!? > Get your free @yahoo.com address at http://mail.yahoo.com > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 6 07:34:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA25189 for ipng-dist; Thu, 6 Aug 1998 07:30:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA25182 for ; Thu, 6 Aug 1998 07:30:45 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA17585 for ; Thu, 6 Aug 1998 07:30:44 -0700 Received: from send1b.yahoomail.com (send1b.yahoomail.com [205.180.60.23]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA12704 for ; Thu, 6 Aug 1998 07:30:44 -0700 (PDT) Message-ID: <19980806143008.29367.rocketmail@send1b.yahoomail.com> Received: from [138.111.39.131] by send1b; Thu, 06 Aug 1998 07:30:08 PDT Date: Thu, 6 Aug 1998 07:30:08 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6132) Re: [Fwd: [Fwd: Re: [Q] address allocation...]] To: chirgi@cubbie.aud.alcatel.com, Girish Chiruvolu , Thierry.Ernst@inrialpes.fr, ipng@sunroof.eng.sun.com Cc: Claude.Castelluccia@inrialpes.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > hi all!!! > > 1.Can we use MSB of FLOW LABEL field for identification > > of mobile packets. > >>>> Ya!!! Flow label is randomly generated. Initially the IPv6 flow label field is 24 bits ( Hope I am correct ) But people are trying to allocate 4 bits from this field to indicate class of service. So one more bit. Right!!! The mail which proposed MSB bit for mobile agents as border router is some thing like ATM pnni allocation. ( In this case it's mobile PNNI ). In that case u can choose a FORMAT PREFIX for the MOBILE PNNI ( sim. to ATM PNNI ) to devlop the heirarchies. !!!! Which may help in mobile RSVP as in ATM pnni.!!! The SITE LOCAL address is local to a site.!!! It's upto u to choose the format of the SITE LOCAL address. So it's possible.!!! If u allocate a MSB for the CoA then u will have enough CoA. Dear Girish!! Hope u got the diff. between the bit change in SITE LOCAL address and HOST ID. If there are any mistake please clarify!!! Thanks in advance. -iprsvp. > At this point from what I understand, the flow-label is > randomly generated (using all the bits allocated to this field). > I guess you have to change that first :-) > > > > In my personal view > tunnels are inefficient ('yep its a blanket stmt). But anyways, > if some things work that way, thats fine also... > > If a bit can be allocated, then my question, > > anybody thinks of the wierd (fanciful) "Mobile ARP". Ofcourse, > there's no ARP in IPv6 (as a part of ICMPv6), but the equivalent messages. >>> Sorry!! there is arp in IPv6. refer "neigh. discovery in IPv6". All the nodes need not to support stateless address configuration. > > > One quick Q: > > 1.Are the binding updates are sent in ICMP messages. > > > > nopes, they sent using extension header options.. > >>>> Thanks for the info!!! > With best regards, > Girish > > > Note: All of these are my personal views only, std disclaimers apply. > > > > > > > Thanks > > -iprsvp > > > > > > > > ---Thierry Ernst wrote: > > > > > > Hi, > > > > > > I forward this message on the behalf of Claude Castelluccia > > > who already posted it twice to this mailing list apparently > > > without any success. > > > > > > > > > Thierry. > > > > > > > > > -- > > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > > * INRIA Rhone-Alpes Projet SIRAC (fax 52 52) > > > > > > ATTACHMENT part 2 message/rfc822 > > > > > > -- > > > > > > ---------------------------------------- > > > Claude CASTELLUCCIA, INRIA Rhone-Alpes > > > ph: +33 4.76.61.52.15 (fax: 52.52) > > > ------- http://sirac.inrialpes.fr/------ > > > > > > ATTACHMENT part 2.2 message/rfc822 > > > > > > Thomas Narten wrote: > > > > > > > > Girish, > > > > > > > > > To be clear, for example FF prefix indicates multicast > > > > > address pool and 010 prefix indicates Unicast addr pool. > > > > > similarly, why not an address pool for mobile IP nodes? > > > > > > > > > There should be some reason for not allocating such addr pool > > > > > to mobile stuff. I would like to know... > > > > > > > > Actually, I'd turn the question around and ask what the reason would > > > > be for allocating a bit in the address to indicate mobile > > > > vs. non-mobile. > > > > > > > > > > I think that it would actually be very useful in order > > > to provide a hierarchical mobility management scheme.... > > > > > > In the paper "toward a hierarchical Mobile IPv6" (to be presented > > > at HPN98 in Sept. in Vienna), we present a hierarchical mobility > > > management scheme for IPv6 based on the IETF Mobile IPv6. > > > In this scheme, the Border routers of a site act as mobility agents. > > > When a mobile host is roaming locally (ie within a site), it sends > > > binding updates to the site's border routers instead of its CHs. > > > > > > As a result, since mobility is mostly local, the signaling > > > load on the backbone is significantly reduced and handoffs are > > performed > > > faster. > > > Whenever a border router receives a packet it should then find out > > > whether this packet is addressed to a fixed host or to a mobile host. > > > In the former case, the packet is routed normally. If the > > > packet is addressed for a MH, the router looks into its binding > > > cache if it has a entry for this mobile host. If yes, it forwards it > > to > > > the mobile host current CoA otherwise the packet is routed normally. > > > > > > If we use the current IP addressing scheme, the router should find out > > > for each incoming packet whether it has a entry in its Binding cache > > for > > > the destination specified in the destination field of the packet. This > > > lookup phase is certainly not free performance-wise.... > > > To solve this performance problem, we propose the definition of a > > > mobility bit (the MSB of the SLA). If this bit is set to 0, then > > > the border router knows that the destination host is a fixed host > > > and routes the packet normally. If this bit is set to 1, the border > > > router looks in its binding cache if it has a entry for the > > destination > > > host.... > > > As a result, the packets addressed to fixed hosts don't not suffer > > from > > > the extra performance cost introduced by the mobility management > > > protocol in the border routers. Only packets addressed to MHs will > > > have to go through the lookup phase (BTW this cost also exist in > > Mobile > > > IPv6 but it is introduced by the CH instead of the border router..). > > > > > > >Also, how do I decide whether I'm a mobile node or not? I become > > > >mobile by moving. It's very hard to predict in advance whether a node > > > >will ever be mobile. > > > > > > In our scheme, this does not really matter. A host could be > > > identified by > > > a fixed host IP address (as it is done today) and gets Mobile > > > Addresses only when it moves ..(in order words, only the CoAs > > > have to the Mobility bit set to 1). > > > > > > > > > Claude. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------- > > > Claude CASTELLUCCIA, INRIA Rhone-Alpes > > > ph: +33 4.76.61.52.15 (fax: 52.52) > > > ------- http://sirac.inrialpes.fr/------ > > > > > > > > > > _________________________________________________________ > > DO YOU YAHOO!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 6 07:40:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA25225 for ipng-dist; Thu, 6 Aug 1998 07:39:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA25218 for ; Thu, 6 Aug 1998 07:38:55 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA20755 for ; Thu, 6 Aug 1998 07:38:53 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA17184 for ; Thu, 6 Aug 1998 07:38:53 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA20711; Thu, 6 Aug 1998 09:40:57 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA27424; Thu, 6 Aug 98 09:38:36 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id JAA02963; Thu, 6 Aug 1998 09:38:36 -0500 Message-Id: <199808061438.JAA02963@cubbie.aud.alcatel.com> Date: Thu, 6 Aug 1998 09:38:36 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6133) Re: [Fwd: [Fwd: Re: [Q] address allocation...]] To: iprsvp@yahoo.com, ipng@sunroof.eng.sun.com, Thierry.Ernst@inrialpes.fr Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: GvS5DJ35ezGxGZ92XKslqg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, yep, thats correct. I just wanted to draw an analogy (may be bad one :-) Thats all from me for a while, adios.. Regards Girish > Hope u got the diff. between the bit change in > SITE LOCAL address and HOST ID. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 7 04:43:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA26184 for ipng-dist; Fri, 7 Aug 1998 04:37:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA26177; Fri, 7 Aug 1998 04:37:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA14859; Fri, 7 Aug 1998 04:37:34 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by earth.sun.com (8.9.1/8.9.1) with SMTP id EAA26355; Fri, 7 Aug 1998 04:37:34 -0700 (PDT) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA51951; Fri, 7 Aug 1998 12:37:32 +0100 Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA34322; Fri, 7 Aug 1998 12:37:30 +0100 (BST) Message-Id: <35CAE6E7.50CF8B5D@hursley.ibm.com> Date: Fri, 07 Aug 1998 12:37:11 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: (IPng 6134) draft-carpenter-ipng-6over4-04.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We've just submitted the above draft, a revision of "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels" (a.k.a. virtual Ethernet). It's been discussed a few times in NGTRANS, but as there are now 3 implementations, at least two of which have interworked, we've asked for agenda time in IPNG to see whether the document is ready for advancement. Brian Carpenter Cyndi Jung -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 7 06:04:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA26281 for ipng-dist; Fri, 7 Aug 1998 05:59:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA26265 for ; Fri, 7 Aug 1998 05:58:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA20869 for ; Fri, 7 Aug 1998 05:58:41 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA17933 for ; Fri, 7 Aug 1998 05:58:42 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA10301; Fri, 7 Aug 1998 08:58:39 -0400 (EDT) Message-Id: <199808071258.IAA10301@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6136) I-D ACTION:draft-ietf-ipngwg-tla-assignment-05.txt Date: Fri, 07 Aug 1998 08:58:39 -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 : Proposed TLA and NLA Assignment Rules Author(s) : B. Hinden Filename : draft-ietf-ipngwg-tla-assignment-05.txt Pages : 10 Date : 06-Aug-98 This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These proposed rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. This proposal is intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. Its content represents the result of extensive discussion between the IPng working group, IANA, and Registries. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-tla-assignment-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-tla-assignment-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980806113608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tla-assignment-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980806113608.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 7 06:05:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA26280 for ipng-dist; Fri, 7 Aug 1998 05:58:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA26267 for ; Fri, 7 Aug 1998 05:58:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA20873 for ; Fri, 7 Aug 1998 05:58:41 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA17910 for ; Fri, 7 Aug 1998 05:58:38 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA10287; Fri, 7 Aug 1998 08:58:35 -0400 (EDT) Message-Id: <199808071258.IAA10287@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6135) I-D ACTION:draft-ietf-ipngwg-icmp-v2-01.txt Date: Fri, 07 Aug 1998 08:58:34 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v2-01.txt Pages : 20 Date : 06-Aug-98 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-v2-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v2-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-v2-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: <19980806113047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980806113047.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 7 06:40:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA26503 for ipng-dist; Fri, 7 Aug 1998 06:29:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA26492 for ; Fri, 7 Aug 1998 06:29:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA24038 for ; Fri, 7 Aug 1998 06:29:27 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA28490 for ; Fri, 7 Aug 1998 06:29:29 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA11759; Fri, 7 Aug 1998 09:29:25 -0400 (EDT) Message-Id: <199808071329.JAA11759@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6137) I-D ACTION:draft-ietf-ipngwg-ipv6-spec-v2-02.txt Date: Fri, 07 Aug 1998 09:29:25 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart Note: This revision reflects comments received during the last call period. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Internet Protocol, Version 6 (IPv6) Specification Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-ipv6-spec-v2-02.txt Pages : 39 Date : 06-Aug-98 This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-spec-v2-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-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: <19980806165157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-spec-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980806165157.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 7 09:52:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA26798 for ipng-dist; Fri, 7 Aug 1998 09:43:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA26791 for ; Fri, 7 Aug 1998 09:43:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA19173 for ; Fri, 7 Aug 1998 09:43:16 -0700 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA03487 for ; Fri, 7 Aug 1998 09:43:17 -0700 (PDT) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA03626 for ; Fri, 7 Aug 1998 09:43:16 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Aug 1998 09:43:49 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 6138) revised IPv6 specs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk New versions of the IPv6 spec and the ICMPv6 spec have been published, as part of the process of advancing these documents from Proposed Standard to Draft Standard. In the IPv6 spec, the IESG identified two parts of the protocol -- Flow Labels and the Jumbo Payload option -- as having insufficient interoperability experience to advance to Draft Standard. Therefore, in order not to hold up the rest of the protocol, the following changes were made: - Most of the Flow Label section was moved to an appendix of the IPv6 spec, with a pointer to the appendix remaining in the main body of the spec. - The Jumbo Payload option was removed from the spec and placed in a separate draft, which was submitted for publication yesterday afternoon. The other changes to the IPv6 spec were (a) revision of the language in the Security Considerations section (to break a standards dependency loop) and (b) in the Flow Label description, changing the constant FFFFF hex to FFFFF (to take account of the previous change of field width from 24 to 20 bits). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 7 10:51:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA26904 for ipng-dist; Fri, 7 Aug 1998 10:45:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA26894 for ; Fri, 7 Aug 1998 10:45:13 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA10302 for ; Fri, 7 Aug 1998 10:44:55 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA10761 for ; Fri, 7 Aug 1998 10:44:47 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id KAA12924; Fri, 7 Aug 1998 10:43:32 -0700 (PDT) Message-Id: <3.0.5.32.19980807104209.008a2bb0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 07 Aug 1998 10:42:09 -0700 To: Thomas Narten , burgan@corp.home.net (Jeffrey Burgan) From: Bob Hinden Subject: (IPng 6139) Request that "Proposed TLA and NLA Assignment Rules" be published as Informational Cc: ipng@sunroof.eng.sun.com, scoya@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Jeff, This is a second request that the following document be published as an Informational RFC: Title : Proposed TLA and NLA Assignment Rules Author(s) : R. Hinden Filename : draft-ietf-ipngwg-tla-assignment-05.txt Pages : 10 Date : 06-Aug-98 This document is intended as input from the IPng working group to the IANA and Registries. It is not intended for any official IETF status. Its content represents the result of extensive discussion between the IPng working group, IANA, and Registries. Bob Hinden / Steve Deering IPng 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 Fri Aug 7 12:49:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA27089 for ipng-dist; Fri, 7 Aug 1998 12:37:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA27082 for ; Fri, 7 Aug 1998 12:37:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16274 for ; Fri, 7 Aug 1998 12:37:05 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA13313 for ; Fri, 7 Aug 1998 12:37:00 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA31644 for ; Fri, 7 Aug 1998 15:36:55 -0400 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA30002 for ; Fri, 7 Aug 1998 15:36:54 -0400 Received: by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17706; Fri, 7 Aug 1998 15:36:47 -0400 From: haberman@raleigh.ibm.com (Brian K. Haberman) Message-Id: <9808071936.AA17706@clemson.raleigh.ibm.com> Subject: (IPng 6140) PIM for IPv6 draft To: ipng@sunroof.eng.sun.com Date: Fri, 7 Aug 1998 15:36:46 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For those who may not have seen it, we posted a draft to the PIM mailing list describing modifications to PIM to support IPv6. A copy is attached below for all who are interested. Thanks, Brian Haberman Garry Kump Hal Sandick INTERNET DRAFT Brian Haberman Garry Kump (IBM) Hal Sandick (Bay) Augest 1998 Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6) Status of This Memo This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document outlines recommendations in the use of Protocol Independent Multicast routing protocol to support Internet Protocol Version 6. It describes the changes needed in order to handle the differences between IPv6 and IPv4 and conform to the logic introduced by other routing protocols enabled for IPv6. Haberman, Kump, Sandick Expires February 1998 [Page i] Internet Draft PIM Multicast Routing for IPv6 Augest 1998 Contents 1. Definitions 1 2. Introduction 1 3. Definitions and Assumptions 1 4. Protocol Impact 1 4.1. Hello Message . . . . . . . . . . . . . . . . . . . . . . 1 4.2. Register Message . . . . . . . . . . . . . . . . . . . . 2 4.3. Register-Stop Message . . . . . . . . . . . . . . . . . . 2 4.4. Join/Prune, Graft, and Graft-Ack Messages . . . . . . . 2 4.5. Bootstrap Message . . . . . . . . . . . . . . . . . . . . 2 4.6. Assert Message . . . . . . . . . . . . . . . . . . . . . 2 4.7. Candidate-RP-Advertisement Message . . . . . . . . . . . 3 5. IPv6 Address Scoping 3 6. Additional Areas of Work 3 Haberman, Kump, Sandick Expires February 1998 [Page ii] Internet Draft PIM Multicast Routing for IPv6 Augest 1998 1. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. 2. Introduction This document describes a protocol for efficiently routing to multicast groups communicating with the Internet Protocol Version 6 (IPv6). This document will only describe recommendations for making PIM conform to practices implemented by other IPv6 routing protocols. The existing PIM drafts should be referenced for actual protocol operation. 3. Definitions and Assumptions - Link Local Address - A local-use, non-routable unicast IPv6 address [RFC 2373]. - All-PIM-Routers multicast address - A permanently assigned link-scoped IPv6 multicast address for the PIM protocol [RFC 2375]. It is assumed that a router running PIM for IPv6 will have a network unique, globally routable IPv6 address that will serve as the router's Router-ID. 4. Protocol Impact The following will outline suggested values for the PIM protocol messages in order to support IPv6. For most messages, the changes involve the addresses used in the IPv6 header. 4.1. Hello Message When sending a Hello Message, a PIM router must use a different set of IPv6 addresses in the IPv6 header. The IPv6 destination address must be the All-PIM-Routers multicast address. The IPv6 source address must be the IPv6 link local address of the interface on which this message is being forwarded. The link local address in the source address field will be used to determine Haberman, Kump, Sandick Expires February 1998 [Page 1] Internet Draft PIM Multicast Routing for IPv6 Augest 1998 neighbor adjacency and for DR election. It should be noted, that the DR will identify itself using its Router-ID. 4.2. Register Message The Register Message is addressed to the Router-ID of the RP. The source address of the message is the Router-ID of the DR. The DR sending the Register Message obtains the Router-ID of the RP from the local RP-set information. 4.3. Register-Stop Message The Register-Stop Message is addressed in the same manner as the Register Message. The RP addresses the message to the Router-ID of the DR. The source address is the Router-ID of the RP. The RP obtains the Router-ID of the DR from the source address field of the Register Message received from the DR. 4.4. Join/Prune, Graft, and Graft-Ack Messages In the transmission of a Join/Prune Message, a router sets the IPv6 destination address to the All-PIM-Routers multicast address. The IPv6 source address is set to the link local address of the interface on which the message is forwarded. The Upstream Neighbor Address field is set to the link local address of the next hop router, which is obtained from the RPF lookup. 4.5. Bootstrap Message When sending a Bootstrap Message, a PIM router sets the IPv6 destination address to the All-PIM-Routers multicast address. The source address is the link local address of the interface on which the message is forwarded. The BSR Address is set to the Router-ID of the BSR. 4.6. Assert Message The Assert Message has an IPv6 destination address of the All-PIM-Routers multicast address and an IPv6 source address of the link local address of the interface forwarding the message. The link local address in the IPv6 source field is used to resolve ties in the Haberman, Kump, Sandick Expires February 1998 [Page 2] Internet Draft PIM Multicast Routing for IPv6 Augest 1998 assert process. Downstream routers save the winning assert router's link local address to resolve any future RPF requirements. 4.7. Candidate-RP-Advertisement Message The Candidate-RP-Advertisement Message uses the Router-ID of the BSR as the IPv6 destination address. The source address is the Router-ID of the candidate RP. The RP Address field is set to the Router-ID of the candidate RP. Each candidate RP router creates this message and unicasts it to the BSR. 5. IPv6 Address Scoping With the introduction of scoped addresses in IPv6, new issues arise in the distribution of scoped routes and the forwarding of scoped packets. Currently, work in the area of scoping has been limited. An Internet draft does exist that outlines the changes needed to routing protocols in order to support the IPv6 scoped addresses [SCOPE]. Currently, this work only addresses PIM running within a single site or organization. 6. Additional Areas of Work The main area of additional work is in the support of site- and organization-scoped IPv6 multicast addresses. If a PIM domain is to cross an IPv6 scope domain, then guidelines for supporting the following will have to be developed : - Scoped RP addresses - Scoped DR addresses - Scoped BSR addresses Haberman, Kump, Sandick Expires February 1998 [Page 3] Internet Draft PIM Multicast Routing for IPv6 Augest 1998 References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1997. [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC 2375] R. Hinden and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998. [SCOPE] B. Haberman, "Routing of Site-Scoped Addresses in the Internet Protocol Version 6 (IPv6)", currently draft-haberman-ipv6-site-route-00.txt. Security Considerations This document does introduce any protocol changes that require any additional security considerations above and beyond those described in the original protocol specification documents. Author's Address Brian Haberman IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA +1-919-254-2673 haberman@raleigh.ibm.com Garry Kump IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA +1-919-254-2395 kump@us.ibm.com Hal Sandick Bay Networks, Inc. 1009 Slater Rd., Suite 220 Durham, NC 27703 USA Haberman, Kump, Sandick Expires February 1998 [Page 4] Internet Draft PIM Multicast Routing for IPv6 Augest 1998 +1-919-941-1739 hsandick@baynetworks.com Haberman, Kump, Sandick Expires February 1998 [Page 5] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 7 18:29:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA27442 for ipng-dist; Fri, 7 Aug 1998 18:24:57 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id SAA27432 for ; Fri, 7 Aug 1998 18:24:34 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA02213; Fri, 7 Aug 1998 18:24:35 -0700 (PDT) Date: Fri, 7 Aug 1998 18:24:34 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6141) Updated site-prefixes draft To: ipng@sunroof.eng.sun.com Cc: nordmark@jurassic.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 I've submitted an updated site-prefixes draft today but it appears to have missed the 5PM cutoff. It is in: ftp://playground.sun.com/pub/nordmark/draft-ietf-ipngwg-site-prefixes-02.txt The following changes have been made since version 01 of the draft. o Stated the assumptions on what a "site" is and how it is configured. o Changed the document to store site-local addresses in the DNS and use filtering do ignore site-local addresses unless the sender and receiver can be determined to belong to the same site. o Added text describing interaction with mobile IP. o Added rules for ignoring site-local entries from the DNS o Make "turn off at site boundary" implementation dependent. o Changed 'S' bit in prefix option not to conflict with [MOBILE-IPv6]. 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 Sat Aug 8 05:13:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA28074 for ipng-dist; Sat, 8 Aug 1998 05:07:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA28067 for ; Sat, 8 Aug 1998 05:06:55 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA10797 for ; Sat, 8 Aug 1998 05:06:53 -0700 Received: from dee.inr.ac.ru (dee.inr.ac.ru [193.233.7.82]) by earth.sun.com (8.9.1/8.9.1) with SMTP id FAA06629 for ; Sat, 8 Aug 1998 05:06:48 -0700 (PDT) Received: (from root@localhost) by dee.inr.ac.ru (8.6.13/ANK+IPv6) id QAA23690; Sat, 8 Aug 1998 16:06:10 +0400 Message-Id: <199808081206.QAA23690@dee.inr.ac.ru> Subject: (IPng 6145) Re: I-D ACTION:draft-ietf-ipngwg-icmp-v2-01.txt To: deering@parc.xerox.com Date: Sat, 8 Aug 1998 16:06:09 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808071258.IAA10287@ietf.org> from "Internet-Drafts@ietf.org" at Aug 7, 98 08:58:34 am From: "Alexey N. Kuznetsov" X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > Note: This revision reflects comments received during the last call period. Three questions. First, I read in Appendix A: - Removed rate control from informational messages OK. 2.4(f): (f) Finally, to each sender of erroneous data packets, an IPv6 node MUST limit the rate of ICMPv6 error messages sent in order to Now 2.4(f.2): (f.2) Bandwidth-based - for example, limiting the rate at which informational reply or error messages are sent from a And 5.2.5: 5. ICMP messages may be used as attempts to perform denial of service attacks by sending back to back ICMP "echo" messages that cause the generation of back to back ICMP "echo reply" messages. An implementation that correctly followed section 2.4, paragraph (f) of this specifications, would be protected by the ICMP rate limiting mechanism. Did you not find, that all these statements completely obscure situation? 8)8) It looks like at least some of them are forgotten remnants of previous drafts. The second. What is supposed to do with error replies to fragments? Namely, to fragments with non-sero offset. From one hand, they are completely useless for original sender, because it will fail to identify them and, hence, will have to drop them and they will only eat resources uselessly. >From the other hand, draft-ietf-ipngwg-ipv6-spec-v2-02 says: If the length of a fragment, as derived from the fragment packet's Payload Length field, is not a multiple of 8 octets and the M flag of that fragment is 1, then that fragment must be discarded and an ICMP Parameter Problem, Code 0, message should be sent to the source of the fragment, pointing to the Payload Length field of the fragment packet. It looks like not only the first fragment is meant here. And the third. (e) An ICMPv6 error message MUST NOT be sent as a result of receiving: (e.1) an ICMPv6 error message, or OK. But what should we make, if icmp header is hidden behind dozen of another headers? Should we try to parse all the headers before trying to send an icmp error message? Or only messages, which to the moment of detecting error are known to be icmp error are meaned? If we should parse, this procedure must be described in details, because there are lots of marginal/exceptional cases. If we should not, impossibility of error loops MUST be proven. Dangerous situations are f.e. when errors are authenticated, or even worse, encrypted. Even simpler situation is when a router does not implement some new header type, which stands before icmp header. Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 03:53:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA28764 for ipng-dist; Mon, 10 Aug 1998 03:50:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA28757 for ; Mon, 10 Aug 1998 03:49:58 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA16806 for ; Mon, 10 Aug 1998 03:49:57 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA07404 for ; Mon, 10 Aug 1998 03:49:57 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA17442; Mon, 10 Aug 1998 06:49:21 -0400 (EDT) Message-Id: <199808101049.GAA17442@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6147) Protocol Action: Internet Protocol, Version 6 (IPv6) Specifications to Draft Standard Date: Mon, 10 Aug 1998 06:49:21 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved publication of the following Internet-Draft as Draft Standards: o Internet Protocol, Version 6 (IPv6) Specification replacing RFC 1883, currently a Proposed Standard. o Neighbor Discovery for IP Version 6 (IPv6) , replacing RFC1970, currently a Proposed Standard o IPv6 Stateless Address Autoconfiguration , replacing RFC1971, currently a Proposed Standard o Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification replacing RFC 1885, currently a Proposed Standard The IESG also approved Path MTU Discovery for IP version 6 as a Draft Standard. These documents are the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary These documents represent the base protocols for IPv6. The IPv6 Specification defines the base IPv6 packet format and processing rules. The Neighbor Discovery specification defines how to do address resolution for neighboring nodes, as well as to how to locate neighboring routers. The Stateless Address Autoconfiguration document defines how a booting node can generate its own IP addresses without the need to maintain configuration information across machine restarts. The ICMPv6 specification defines the packet formats and processing rules for ICMP for IPv6. The Path MTU Discovery document defines how to perform Path MTU in IPv6. All nodes are required to implement Path MTU in IPv6; routers do not fragment packets they forward. Working Group Summary There is Working Group consensus for the protocols defined in these documents. There were two objections raised during Last Call, but the objections did not have support of the Working Group. However, a small clarification was made to the ICMPv6 spec to make it easier to deploy a new ICMP "Packet Too Big" message, should such a message become defined. Protocol Quality There are numerous implementations of these protocols, and extensive interoperability tests have been done via the UNH consortium and on the 6bone. The documents have been reviewed for the IESG by Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 04:30:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA28844 for ipng-dist; Mon, 10 Aug 1998 04:24:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA28837 for ; Mon, 10 Aug 1998 04:24:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA19391 for ; Mon, 10 Aug 1998 04:24:45 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA14087 for ; Mon, 10 Aug 1998 04:24:46 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA17897; Mon, 10 Aug 1998 07:24:11 -0400 (EDT) Message-Id: <199808101124.HAA17897@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6148) Protocol Action: Generic Packet Tunneling in IPv6 Specification to Proposed Standard Date: Mon, 10 Aug 1998 07:24:11 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Generic Packet Tunneling in IPv6 Specification' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document specifies a method and generic mechanisms by which a packet is encapsulated and carried as payload within an IPv6 packet. The resulting packet is called an IPv6 tunnel packet. The forwarding path between the source and destination of the tunnel packet is called an IPv6 tunnel. The technique is called IPv6 tunneling. The document also discusses specific mechanisms for tunneling IPv6 and IPv4 packets. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 05:21:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA28934 for ipng-dist; Mon, 10 Aug 1998 05:17:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA28927 for ; Mon, 10 Aug 1998 05:17:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA24324 for ; Mon, 10 Aug 1998 05:17:33 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA25756 for ; Mon, 10 Aug 1998 05:17:33 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA18620; Mon, 10 Aug 1998 08:15:41 -0400 (EDT) Message-Id: <199808101215.IAA18620@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6149) Protocol Action: IP Version 6 Management Information Base for the Transmission Control Protocol to Proposed Standard Date: Mon, 10 Aug 1998 08:15:40 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IP Version 6 Management Information Base for the Transmission Control Protocol' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of which IP versions underlie TCP, and only the TCP connection information is IP version-specific. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed for the IESG by Juergen Schoenwaelder. It has also been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 05:40:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA29002 for ipng-dist; Mon, 10 Aug 1998 05:30:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA28995 for ; Mon, 10 Aug 1998 05:29:57 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA25958 for ; Mon, 10 Aug 1998 05:29:55 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA29304 for ; Mon, 10 Aug 1998 05:29:55 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA18863; Mon, 10 Aug 1998 08:29:16 -0400 (EDT) Message-Id: <199808101229.IAA18863@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6150) Protocol Action: IP Version 6 Management Information Base for the User Datagram Protocol to Proposed Standard Date: Mon, 10 Aug 1998 08:29:16 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IP Version 6 Management Information Base for the User Datagram Protocol' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of which IP versions underlie UDP, and only the UDP listener information is IP version-specific. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed for the IESG by Juergen Schoenwaelder. It has also been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 06:08:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA29114 for ipng-dist; Mon, 10 Aug 1998 06:04:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA29107 for ; Mon, 10 Aug 1998 06:04:00 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA00506 for ; Mon, 10 Aug 1998 06:03:58 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA09490 for ; Mon, 10 Aug 1998 06:03:54 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA19695; Mon, 10 Aug 1998 09:03:19 -0400 (EDT) Message-Id: <199808101303.JAA19695@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6151) Document Action: Proposed TLA and NLA Assignment Rules to Informational Date: Mon, 10 Aug 1998 09:03:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Deja vu! This protocol action announcement is being resent with the correct subject line. Sorry for any confusion, but it IS Monday morning! The IESG has approved the Internet-Draft Proposed TLA and NLA Assignment Rules as an Informational RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 06:45:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA29247 for ipng-dist; Mon, 10 Aug 1998 06:34:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA29240 for ; Mon, 10 Aug 1998 06:33:58 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA05369 for ; Mon, 10 Aug 1998 06:33:56 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA20893 for ; Mon, 10 Aug 1998 06:33:57 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA20497; Mon, 10 Aug 1998 09:33:21 -0400 (EDT) Message-Id: <199808101333.JAA20497@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: IESG Secretary Subject: (IPng 6152) Document Action: IPv6 Testing Address Allocation to Experimental Date: Mon, 10 Aug 1998 09:33:21 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I HATE Mondays... I am sorry, but the Document Action: Proposed TLA and NLA Assignment Rules to Informational was sent in ERROR. This document is currently being evaluated by the IESG, but no decision has been reached at this time. What follows is (I HOPE) THE announcement that is being retransmitted with the corrected Subject line. ===================================================== The IESG has approved the Internet-Draft IPv6 Testing Address Allocation for publication as an Experimental RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Thomas Narten and Jeffrey Burgan. Note to RFC Editor: The references: [DHCP6] Bound, J., "Host Configuration Protocol for IPv6", Internet Draft, , July 1995. [TLAASN] Hinden, R., "TLA and NLA Assignment Rules", Internet Draft, , July 1997. should be changed to "work in progress". I.e., they shouldn't be considered normative). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 08:26:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA29450 for ipng-dist; Mon, 10 Aug 1998 08:22:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA29443 for ; Mon, 10 Aug 1998 08:21:43 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA09764 for ; Mon, 10 Aug 1998 08:21:42 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA12985 for ; Mon, 10 Aug 1998 08:21:42 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA23996; Mon, 10 Aug 1998 11:21:37 -0400 (EDT) Message-Id: <199808101521.LAA23996@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6153) I-D ACTION:draft-ietf-ipngwg-jumbo-00.txt Date: Mon, 10 Aug 1998 11:21:36 -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 : The IPv6 Jumbo Payload Option Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-jumbo-00.txt Pages : 5 Date : 07-Aug-98 This document describes the Jumbo Payload option for IPv6, which is used to send IPv6 packets with payloads longer than 65,535 octets. This option is relevant only for IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-jumbo-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-jumbo-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-jumbo-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: <19980807105845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-jumbo-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-jumbo-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980807105845.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 08:56:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA29591 for ipng-dist; Mon, 10 Aug 1998 08:52:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA29584 for ; Mon, 10 Aug 1998 08:51:41 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA18276 for ; Mon, 10 Aug 1998 08:51:40 -0700 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA00249 for ; Mon, 10 Aug 1998 08:51:41 -0700 (PDT) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id IAA23800 for ; Mon, 10 Aug 1998 08:51:39 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Aug 1998 08:52:01 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 6154) I-D ACTION:draft-ietf-iab-case-for-ipv6-02.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If any of you aren't on the general ietf or ietf-announce list, you probably missed the following ID announcement. This is a draft IAB document, and the IAB would very much appreciate technical review by folks here in the IPNGWG before publishing it as an RFC. Steve > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Internet Architecture > Board (IAB). > > Title : The Case for IPv6 > Author(s) : B. Fink, D. Haskin, C. Perkins, R. Fax, > W. Ling, T. Meehan, S. King > Filename : draft-ietf-iab-case-for-ipv6-02.txt > Pages : 50 > Date : 07-Aug-98 > > This document outlines the business and technical case for IPv6. It > is intended to acquaint both the existing IPv4 community with IPv6, > to encourage its support for change, and to attract potential future > users of Internet technology. > > Internet-Drafts are available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-iab-case-for-ipv6-02.txt". > A URL for the Internet-Draft is: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-iab-case-for-ipv6-02.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 10:25:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA29896 for ipng-dist; Mon, 10 Aug 1998 10:12:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA29888 for ; Mon, 10 Aug 1998 10:12:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA18573 for ; Mon, 10 Aug 1998 10:12:18 -0700 Received: from cecom6.monmouth.army.mil (cecom6.monmouth.army.mil [134.80.0.9]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA24715 for ; Mon, 10 Aug 1998 10:12:17 -0700 (PDT) Received: from doim6.monmouth.army.mil (doim6 [134.80.0.30]) by cecom6.monmouth.army.mil (8.8.8/8.8.8) with SMTP id NAA04731; Mon, 10 Aug 1998 13:11:24 -0400 (EDT) Received: from ccMail by doim6.monmouth.army.mil (IMA Internet Exchange 2.1 (Gold Candidate) Enterprise) id 0007329D; Mon, 10 Aug 98 13:10:31 -0400 Mime-Version: 1.0 Date: Mon, 10 Aug 1998 13:15:32 -0400 Message-ID: <0007329D.@doim6.monmouth.army.mil> From: patel@doim6.monmouth.army.mil (Kamlesh Patel) To: The IESG Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com Subject: (IPng 6155) Re: Protocol Action: Internet Protocol, Version Content-Type: multipart/mixed; boundary="IMA.Boundary.130967209" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --IMA.Boundary.130967209 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Will there be new RFC numbers for the Internet Drafts on IPv6 that just have been approved as the draft standards? If the new RFC numbers will be handed out, when will that happen? Kamlesh Patel ______________________________ Reply Separator _________________________________ Subject: (IPng 6147) Protocol Action: Internet Protocol, Version 6 (I Author: The IESG at Internet_Gateway Date: 8/10/98 6:49 AM The IESG has approved publication of the following Internet-Draft as Draft Standards: o Internet Protocol, Version 6 (IPv6) Specification replacing RFC 1883, currently a Proposed Standard. o Neighbor Discovery for IP Version 6 (IPv6) , replacing RFC1970, currently a Proposed Standard o IPv6 Stateless Address Autoconfiguration , replacing RFC1971, currently a Proposed Standard o Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification replacing RFC 1885, currently a Proposed Standard The IESG also approved Path MTU Discovery for IP version 6 as a Draft Standard. These documents are the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary These documents represent the base protocols for IPv6. The IPv6 Specification defines the base IPv6 packet format and processing rules. The Neighbor Discovery specification defines how to do address resolution for neighboring nodes, as well as to how to locate neighboring routers. The Stateless Address Autoconfiguration document defines how a booting node can generate its own IP addresses without the need to maintain configuration information across machine restarts. The ICMPv6 specification defines the packet formats and processing rules for ICMP for IPv6. The Path MTU Discovery document defines how to perform Path MTU in IPv6. All nodes are required to implement Path MTU in IPv6; routers do not fragment packets they forward. Working Group Summary There is Working Group consensus for the protocols defined in these documents. There were two objections raised during Last Call, but the objections did not have support of the Working Group. However, a small clarification was made to the ICMPv6 spec to make it easier to deploy a new ICMP "Packet Too Big" message, should such a message become defined. Protocol Quality There are numerous implementations of these protocols, and extensive interoperability tests have been done via the UNH consortium and on the 6bone. The documents have been reviewed for the IESG by Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --IMA.Boundary.130967209 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Received: from cecom10.monmouth.army.mil (134.80.0.10) by doim6.monmouth.army.mil with SMTP (IMA Internet Exchange 2.1 (Gold Candidate) Enterprise) id 00071411; Mon, 10 Aug 98 06:57:29 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by cecom10.monmouth.army.mil (8.8.6/8.8.6) with SMTP id GAA22072 for ; Mon, 10 Aug 1998 06:57:28 -0400 (EDT) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA24511; Mon, 10 Aug 1998 03:54:16 -0700 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id DAA29638; Mon, 10 Aug 1998 03:54:14 -0700 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA28764 for ipng-dist; Mon, 10 Aug 1998 03:50:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA28757 for ; Mon, 10 Aug 1998 03:49:58 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA16806 for ; Mon, 10 Aug 1998 03:49:57 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA07404 for ; Mon, 10 Aug 1998 03:49:57 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA17442; Mon, 10 Aug 1998 06:49:21 -0400 (EDT) Message-Id: <199808101049.GAA17442@ietf.org> To: IETF-Announce:;;;;@ns.cnri.reston.va.us;@Eng.Sun.COM;;; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.Eng.Sun.COM From: The IESG Subject: (IPng 6147) Protocol Action: Internet Protocol, Version 6 (IPv6) Specifications to Draft Standard Date: Mon, 10 Aug 1998 06:49:21 -0400 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --IMA.Boundary.130967209-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 10 10:39:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA29966 for ipng-dist; Mon, 10 Aug 1998 10:29:42 -0700 (PDT) Received: from hsmpka.eng.sun.com (hsmpka [129.146.101.47] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA29959 for ; Mon, 10 Aug 1998 10:29:31 -0700 (PDT) Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01409; Mon, 10 Aug 1998 10:29:27 -0700 Message-Id: <199808101729.KAA01409@hsmpka.eng.sun.com> Date: Mon, 10 Aug 1998 10:27:16 -0700 (PDT) From: Charles Perkins Reply-To: Charles Perkins Subject: (IPng 6156) Re: [Q] address allocation... To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yMVgk9R8mCQbKuGWCUQ8uA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu, Girish, I am reposting this message to the list, because I don't think it made it the first time. If either of you see it again, please send me private mail to indicate that you got it. This way I get to test out my posting to the list, without asking the unconcerned other people to verify its reception. Regards, Charlie P. PS. To everyone else: please excuse the apparent lateness of this reply. ------------- Begin Forwarded Message ------------- Date: Tue, 4 Aug 1998 21:36:35 -0700 (PDT) From: Charles Perkins Subject: Re: (IPng 6115) Re: [Q] address allocation... To: ipng@sunroof.eng.sun.com Cc: "Raghu V.V.J Vadapalli" , Girish Chiruvolu MIME-Version: 1.0 Content-MD5: 7k66Kw0toTgcm+iJ3dN86A== Raghu, > > >>>>>> IT IS CLERALY MENTIONED IN MOBILE IP > > SPECIFICATION THAT MOBILE IP PROTOCOL CAN'T BE > > (I REPEAT CAN'T ) be used for FREQUENT HANDOFFS. A lot of people would say that entering a new cell every second counts for fairly frequent handoffs. Girish, > I am not sure again by your frequency, However, > Paper by Charles E. Perkins and David B. Johnson, > "Mobility support in IPv6" under section 3.1, > (Requirements, Goals and Applicability, > last para of that section) > they talk about a frequency of 1 per sec. Yes, but this was just inherited from RFC 2002. The real constraint is, of course, somewhat more complicated, especially in IPv6 mobility. It depends on how fast you can supply binding updates to the home agent -- and, to a lesser extent, to correspondent nodes -- and, probably, on how fast you can set up security associations with the routers that you might depend upon to help with the smooth handoffs. Unless you don't mind dropping some packets. My guess is that you can move with a frequency a lot faster than once per second, depending on how far away the mobile node is from its home agent and correspondent nodes, and how congested the relevant parts of the network happen to be. ============================================================= I don't think this part of the discussion is particularly relevant to setting particular bits of the address to indicate mobility. In fact, one of the reasons for trying to get Mobile IPv6 done, is the supposition that before too long almost the whole population of the Internet will be capable of mobility. So, it should be done in a way that is efficient and friendly to the network. That has a lot of implications. One implication is that setting aside some part of the address space doesn't make sense when the allocation applies to the majority of the addressable nodes of the Internet. Moreover, if in the future there are other schemes for allocating IPv6 addresses (e.g., geographical addressing), would we need to subdivide every new addressing architecture for mobile nodes vs. stationary nodes? Regards, Charlie P. ------------- 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 Tue Aug 11 08:00:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA01042 for ipng-dist; Tue, 11 Aug 1998 07:55:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA01035 for ; Tue, 11 Aug 1998 07:55:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29397 for ; Tue, 11 Aug 1998 07:55:22 -0700 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA22253 for ; Tue, 11 Aug 1998 07:55:22 -0700 (PDT) Message-ID: <19980811145342.14827.rocketmail@send1e.yahoomail.com> Received: from [138.111.39.131] by send1e; Tue, 11 Aug 1998 07:53:42 PDT Date: Tue, 11 Aug 1998 07:53:42 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6159) Reg: Jumbo Payload Length. 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 Dear All.. I was going through IPng Jumbo Payload option new draft. I have one quick question. Let me understand first !!! Jumbo Payload is meant for packets whost pay load length is greater that 65,535. Right !!! So the packet length becomes 65,535+40 octets when sending across a link!! Right!! Then why it is written in the description of Jumbo Payload length of Hop-By-Hop options header that the Length should be greater than 65,535 octets. I think it should be 65,575 octets. Where I am wrong!! Thanks in advance -iprsvp. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 11 08:19:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA01120 for ipng-dist; Tue, 11 Aug 1998 08:15:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA01113 for ; Tue, 11 Aug 1998 08:15:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA03887 for ; Tue, 11 Aug 1998 08:15:07 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA02685 for ; Tue, 11 Aug 1998 08:15:07 -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 LAA11780; Tue, 11 Aug 1998 11:15:01 -0400 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA27994; Tue, 11 Aug 1998 11:15:01 -0400 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23918; Tue, 11 Aug 1998 11:14:59 -0400 Message-Id: <35D05FF3.B90E2CD7@raleigh.ibm.com> Date: Tue, 11 Aug 1998 11:14:59 -0400 From: Brian Haberman Organization: Remote Access Products X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: "Raghu V.V.J Vadapalli" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6160) Re: Reg: Jumbo Payload Length. References: <19980811145342.14827.rocketmail@send1e.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu V.V.J Vadapalli wrote: > > Let me understand first !!! > Jumbo Payload is meant for packets whost pay load > length is greater that 65,535. Right !!! > > So the packet length becomes > 65,535+40 octets when sending across a link!! Right!! > No, the payload length field in the IPv6 header does not include the size of the header. So the Jumbo Payload is meant to handle packets with a data size greater than 65535. Brian Haberman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 11 10:05:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA01347 for ipng-dist; Tue, 11 Aug 1998 09:55:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA01338 for ; Tue, 11 Aug 1998 09:55:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA04330 for ; Tue, 11 Aug 1998 09:55:23 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA10821 for ; Tue, 11 Aug 1998 09:55:23 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA17681; Tue, 11 Aug 1998 12:55:21 -0400 (EDT) Message-Id: <199808111655.MAA17681@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6161) I-D ACTION:draft-ietf-ipngwg-dns-lookups-01.txt Date: Tue, 11 Aug 1998 12:55:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : DNS Extension to Support IP Version 6 Author(s) : C. Huitema, S. Thomson, M. Crawford Filename : draft-ietf-ipngwg-dns-lookups-01.txt Pages : 13 Date : 10-Aug-98 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new domain to hold the top-level delegation information and a zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-dns-lookups-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-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: <19980810143510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-lookups-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980810143510.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 Aug 11 12:48:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA01704 for ipng-dist; Tue, 11 Aug 1998 12:35:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA01697 for ; Tue, 11 Aug 1998 12:35:08 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA08561 for ; Tue, 11 Aug 1998 12:35:04 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA07446 for ; Tue, 11 Aug 1998 12:35:06 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA16870; Tue, 11 Aug 1998 14:35:03 -0500 Message-Id: <199808111935.OAA16870@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6162) Re: I-D ACTION:draft-ietf-ipngwg-dns-lookups-01.txt In-reply-to: Your message of Tue, 11 Aug 1998 12:55:20 EDT. <199808111655.MAA17681@ietf.org> Date: Tue, 11 Aug 1998 14:35:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft has now been published which combines the DNS forward-zone and reverse-zone renumbering-friendly features. (The revised supporting dnsind drafts came out a few weeks ago.) At the LA meeting, the working group expressed a desire to fast-track this. A straight presentation of the draft would consume valuable time in just working through the examples and so forth, so I would like to request that all interested parties read the draft beforehand. (Yes, that should always be assumed, but let's just give a nod to reality, shall we?) Discussion is open here on the list. 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 Aug 11 13:28:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA01783 for ipng-dist; Tue, 11 Aug 1998 13:12:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA01776 for ; Tue, 11 Aug 1998 13:12:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA20714 for ; Tue, 11 Aug 1998 13:12:05 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA04873 for ; Tue, 11 Aug 1998 13:12:00 -0700 (PDT) Received: from inner.net (stan.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.9.0/8.8.5) with ESMTP id UAA02524; Tue, 11 Aug 1998 20:11:49 GMT Message-Id: <199808112011.UAA02524@inner.net> To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com Subject: (IPng 6163) Re: I-D ACTION:draft-ietf-ipngwg-dns-lookups-01.txt In-reply-to: Your message of "Tue, 11 Aug 1998 14:35:03 CDT." <199808111935.OAA16870@gungnir.fnal.gov> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 11 Aug 1998 16:11:11 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808111935.OAA16870@gungnir.fnal.gov>, you write: >Discussion is open here on the list. In general, it looks like what this draft is trying to do is a good thing. If this is being proposed as "this is how you use these new DNS features to solve IPv6 DNS problems, when those features are available", then IMO it's good. These problems need to be solved, both in the IPv4 and IPv6 contexts. If this is being proposed as "this is how we're going to do IPv6 DNS now, and we're going to tie it to deployment of these new features", then it's a very bad thing. Obsoleting existing implementations and creating new IPv6 deployment barriers is not the way. In which of these forms is this being proposed? -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 11 13:53:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA01853 for ipng-dist; Tue, 11 Aug 1998 13:40:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA01846 for ; Tue, 11 Aug 1998 13:39:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA00357 for ; Tue, 11 Aug 1998 13:39:47 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA22299 for ; Tue, 11 Aug 1998 13:39:40 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id PAA17188; Tue, 11 Aug 1998 15:39:04 -0500 Message-Id: <199808112039.PAA17188@gungnir.fnal.gov> To: Craig Metz Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6164) Re: I-D ACTION:draft-ietf-ipngwg-dns-lookups-01.txt In-reply-to: Your message of Tue, 11 Aug 1998 16:11:11 -0300. <199808112011.UAA02524@inner.net> Date: Tue, 11 Aug 1998 15:39:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In general, it looks like what this draft is trying to do is a good thing. > > If this is being proposed as "this is how you use these new DNS features to > solve IPv6 DNS problems, when those features are available", then IMO it's > good. Let me defer for a moment your fundamental question by asking what it means for these new features to be generally available? Does it suffice for them to exist in a version of BIND which has passed a beta test? If there exists a time when code (servers & resolvers) supporting these new DNS features are deployed somewhat widely, but significantly less widely than IPv6 itself, then individual zone administrators will face a transition problem. Hence the fast track. Are we dreaming? 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 Aug 11 14:38:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA02093 for ipng-dist; Tue, 11 Aug 1998 14:28:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA02064 for ; Tue, 11 Aug 1998 14:28:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA17860 for ; Tue, 11 Aug 1998 14:27:59 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA28668 for ; Tue, 11 Aug 1998 14:27:59 -0700 (PDT) Received: from inner.net (stan.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.9.0/8.8.5) with ESMTP id VAA02612; Tue, 11 Aug 1998 21:27:49 GMT Message-Id: <199808112127.VAA02612@inner.net> To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com Subject: (IPng 6165) Re: I-D ACTION:draft-ietf-ipngwg-dns-lookups-01.txt In-reply-to: Your message of "Tue, 11 Aug 1998 15:39:04 CDT." <199808112039.PAA17188@gungnir.fnal.gov> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 11 Aug 1998 17:27:12 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808112039.PAA17188@gungnir.fnal.gov>, you write: >Let me defer for a moment your fundamental question by asking what it >means for these new features to be generally available? Does it >suffice for them to exist in a version of BIND which has passed a >beta test? > >If there exists a time when code (servers & resolvers) supporting >these new DNS features are deployed somewhat widely, but >significantly less widely than IPv6 itself, then individual zone >administrators will face a transition problem. > >Hence the fast track. Are we dreaming? The IPv6 user base is still small enough that new features could be rolled out quickly. If they work. I am not convinced that we will have an implementations of these features in a reasonable time frame that works reliably enough to tie all of the IPv6 DNS to it. These features aren't trivial to implement like AAAA was. Existence of features in a version of BIND that has "passed beta test" is not even remotely the same thing as those features being stable. I'm also not convinced that this can't be transitioned to with a reasonable amount of grace once it's stable. How are they planning to handle transition for IPv4? Why not reuse whatever solutions are found in that context? Creating new ways to impede IPv6 deployment just doesn't seem to be a good idea to me. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 12 00:12:17 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA02718 for ipng-dist; Tue, 11 Aug 1998 23:57:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA02711 for ; Tue, 11 Aug 1998 23:57:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA20020 for ; Tue, 11 Aug 1998 23:57:35 -0700 Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA02811; Tue, 11 Aug 1998 23:57:32 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:220:d8ff:fe00:6f2d]) by shuttle.wide.toshiba.co.jp (8.9.1+IPv6/8.9.0) with ESMTP id PAA10200; Wed, 12 Aug 1998 15:55:28 +0900 (JST) To: narten@raleigh.ibm.com, nordmark@sun.com, bsimpson@MorningStar.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6167) Re: I-D ACTION:draft-ietf-ipngwg-discovery-v2-03.txt In-Reply-To: Your message of "Tue, 04 Aug 1998 09:50:09 -0400" <199808041350.JAA16409@ietf.org> References: <199808041350.JAA16409@ietf.org> X-Mailer: Mew version 1.93b52 on Emacs 20.2 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980812155447Y.jinmei@isl.rdc.toshiba.co.jp> Date: Wed, 12 Aug 1998 15:54:47 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980522 Lines: 64 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 04 Aug 1998 09:50:09 -0400, >>>>> Internet-Drafts@ietf.org said: > This document specifies the Neighbor Discovery protocol for IP > Version 6. IPv6 nodes on the same link use Neighbor Discovery to > discover each other's presence, to determine each other's link-layer > addresses, to find routers and to maintain reachability information > about the paths to active neighbors. I have a question about state of the neighbor cache for routers. In the section 6.3.4, the draft requires a host to set router's reachability state to STALE when receiving a router advertisement; After extracting information from the fixed part of the Router Advertisement message, the advertisement is scanned for valid options. : : If a Neighbor Cache entry is created for the router its reachability state MUST be set to STALE as specified in Section 7.3.3. If a cache entry already exists and is updated with a different link-layer address the reachability state MUST also be set to STALE. In the section 7.3.3, the specification also says that a host should state the state to STALE; A Neighbor Cache entry enters the STALE state when created as a result of receiving packets other than solicited Neighbor Advertisements (i.e., Router Solicitations, Router Advertisements, Redirects, and Neighbor Solicitations). These packets contain the link-layer address of either the sender or, in the case of Redirect, the redirection target. It seems to me that the description assumes that a Source link-layer address option is always contained. But as the specification says in the section 4.2, a router MAY omit the option; Source link-layer address The link-layer address of the interface from which the Router Advertisement is sent. Only used on link layers that have addresses. A router MAY omit this option in order to enable inbound load sharing across multiple link-layer addresses. Now I have a question. What should we do if we receive a router advertisement that doesn't contain a Source Link-layer address option and we have no neighbor cache entry for the sender? Should we create a new entry and set its state to STALE? If so, what if we try to send a packet via the router? Should we wait until the state changes to PROBE or should we send neighbor solicitations to the router immediately? IMO, the specification is a little bit ambiguous on this point. If possible, I would like the specification to be more specific. Please let me know your opinion. Thanks in advance, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 12 11:41:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA03391 for ipng-dist; Wed, 12 Aug 1998 11:35:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA03384 for ; Wed, 12 Aug 1998 11:35:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA26124 for ; Wed, 12 Aug 1998 11:35:36 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA19566 for ; Wed, 12 Aug 1998 11:35:37 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01458; Wed, 12 Aug 1998 14:35:34 -0400 (EDT) Message-Id: <199808121835.OAA01458@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6169) I-D ACTION:draft-ietf-ipngwg-router-renum-04.txt Date: Wed, 12 Aug 1998 14:35:33 -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 : Router Renumbering for IPv6 Author(s) : B. Hinden, M. Crawford Filename : draft-ietf-ipngwg-router-renum-04.txt Pages : 22 Date : 11-Aug-98 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ('RR') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-router-renum-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-router-renum-04.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: <19980811163828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980811163828.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 12 12:15:02 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA03514 for ipng-dist; Wed, 12 Aug 1998 12:03:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA03507 for ; Wed, 12 Aug 1998 12:03:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA06928 for ; Wed, 12 Aug 1998 12:03:06 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA06999 for ; Wed, 12 Aug 1998 12:02:59 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA06723; Wed, 12 Aug 1998 15:02:51 -0400 (EDT) Message-Id: <199808121902.PAA06723@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 6170) I-D ACTION:draft-ietf-ipngwg-resv-anycast-00.txt Date: Wed, 12 Aug 1998 15:02:50 -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 : Reserved IPv6 Subnet Anycast Addresses Author(s) : S. Deering, D. Johnson Filename : draft-ietf-ipngwg-resv-anycast-00.txt Pages : 3 Date : 11-Aug-98 The IP Version 6 addressing architecture defines an 'anycast' address as an IPv6 address that is assigned to more than one network interface (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-resv-anycast-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-resv-anycast-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-resv-anycast-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: <19980811101545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-resv-anycast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-resv-anycast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980811101545.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 13 12:00:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA05654 for ipng-dist; Thu, 13 Aug 1998 11:53:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA05647 for ; Thu, 13 Aug 1998 11:53:41 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA12889 for ; Thu, 13 Aug 1998 11:53:38 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA16452 for ; Thu, 13 Aug 1998 11:53:39 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id OAA13388; Thu, 13 Aug 1998 14:53:37 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA01948; Thu, 13 Aug 1998 14:53:36 -0400 Message-Id: <199808131853.AA01948@wasted.zk3.dec.com> To: Craig Metz Cc: "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: (IPng 6171) Re: I-D ACTION:draft-ietf-ipngwg-dns-lookups-01.txt In-Reply-To: Your message of "Tue, 11 Aug 1998 17:27:12 -0300." <199808112127.VAA02612@inner.net> Date: Thu, 13 Aug 1998 14:53:36 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > The IPv6 user base is still small enough that new features could be rolled >out quickly. If they work. These DNS changes are not small. > I am not convinced that we will have an implementations of these features >in a reasonable time frame that works reliably enough to tie all of the IPv6 >DNS to it. These features aren't trivial to implement like AAAA was. Existence >of features in a version of BIND that has "passed beta test" is not even >remotely the same thing as those features being stable. Agreed. But you and others will see a press release soon that several of us vendors (Sun, Compaq, SGI, IBM, and HP) have defined a set of DNS Next Generation Reqs with the Internet Software Consortia (ISC) via Paul Vixie et al for a future set of releases for BIND. On the top of the list is IPv6 native protocol support and the new IPv6 DNS by Matt, Christian, Sue, et al. We are funding ISC to do this work over the next year and it will be in the public domain. Priorities are being set now and an project plan is in place. I don't see the changes for BIND for a year to support this effort from the work to be done. This is not an IETF function or any standards function if anything it is a group of vendors trying to get BIND features we need. (Note we also have SMP on top of the list and all of us are giving ISC SMP machines to get that done too). So there will be a transition issue. Using Compaq as an example I can't see shipping a product to customers other than AAAA records at least until mid 1999. This will be an issue for all vendors shipping IPv6 products assuming AAAA records. I also can't see developing a transition for DNS right out of the box for IPv6 so until the new DNS parts are done users will have to rekey their DNS entries and that is the way it is. Unless someone can develop a merge piece of code that will take the AAAA records and put them in the new format automatically when that part of IPv6 is working with the new DNS formats. Off the top of my head I would say this is a very doable piece of code but has a few quirks especially if the records have SIG records associated with them, and then it is not clear where and if the prefix boundaries will work so that will have to be user input to the merge code. > Creating new ways to impede IPv6 deployment just doesn't seem to be a good >idea to me. I agree and at the last IETF ipngwg meeting I voiced this quite loudly. But rather than slipping the ship dates of IPv6 products we just need to absorb this pain in some manner, the market cannot wait any longer for IPv6 products, they want them now. It would be good if the IETF did address moving to the new formats in more detail. But rigth now until more than just specs are supplied as vendors we have no choice but to ignore this work until all of this is better understood. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 08:53:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA06477 for ipng-dist; Fri, 14 Aug 1998 08:45:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA06470 for ; Fri, 14 Aug 1998 08:45:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA29003 for ; Fri, 14 Aug 1998 08:45:29 -0700 Received: from send103.yahoomail.com (send103.yahoomail.com [205.180.60.92]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA19297 for ; Fri, 14 Aug 1998 08:45:28 -0700 (PDT) Message-ID: <19980814154527.28174.rocketmail@send103.yahoomail.com> Received: from [138.111.39.131] by send103.yahoomail.com; Fri, 14 Aug 1998 08:45:27 PDT Date: Fri, 14 Aug 1998 08:45:27 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6172) Reg: PATH MTU discovery To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All.. I was going through IPv6 PATH MTU discovery. Path MTU discovery involves no. of iterations. Right!! Why don't we use some mechanism for MTU discovery as following. Whenever a node wants to find the PATH MTU for a path between A and B. Then A sends a packet which will collect the minimum of all the MTU. When the destination receives this DISCOVERY packet it sends it back to the source node A. What's wrong with this method. Just I want to clarify myself. Thanks in advance -Raghu. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 09:42:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA06569 for ipng-dist; Fri, 14 Aug 1998 09:33:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA06562 for ; Fri, 14 Aug 1998 09:33:41 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA15178 for ; Fri, 14 Aug 1998 09:33:37 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA17025 for ; Fri, 14 Aug 1998 09:33:35 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id MAA07415 for ; Fri, 14 Aug 1998 12:33:34 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03110; Fri, 14 Aug 1998 12:33:34 -0400 Message-Id: <199808141633.AA03110@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 6173) NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Date: Fri, 14 Aug 1998 12:33:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Sorry I am a few days late but I had to recheck over 250 mail messages. I have attached the draft for you to read first I list the changes from draft 01 per the latest round of discussions. I will format this better once we agree on these changes. Two things I did not change: - adding AI flags from getnodebyname to getaddrinfo. The reason is this is not our spec but POSIX's, if folks feel we can change it still I would like some discussion. - there was a request to permit getsockopt for multicast interfaces joined. but I think this will complicate the option greatly and still unclear if this has benefit and there was no consensus at this time to do this. The rest of the changes are based on mail from May thru July 1998. We will update the references too hopefully with new RFC #'s too. We won't submit this as ID until we go thru some review of what is here. Please lets nail this down now. thanks /jim ------------------------------------------------------- Changes made to updated RFC2133 draft -02. - Changed priority to traffic class in the spec. - Added the need for scope identification in section 2.1. - Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. - Changed 3.10 to use generic storage structure to support holding IPv6 addresses and removed the SA_LEN macro. - Distinguished between invalid input parameters and system failures for Interface Identification in Section 4.1 and 4.2. - Added defaults for multicast operations in section 5.2 and changed the names from ADD to JOIN and DROP to LEAVE to be consistent with IPv6 multicast terminology. - Changed getnodebyname to getipnodebyname, getnodebyaddr to getipnodebyaddr, and added MT safe error code to funtion parameters in section 6. - Moved freehostent to its own sub-section after getipnodebyaddr now 6.3 (so this bumps all remaining sections in section 6. - Clarified the use of AI_ALL and AI_V4MAPPED that these are dependent on the AF parameter and must be used as a conjuntion in section 6.1. - Removed the restriction that literal addresses cannot be used with a flags argument in section 6.1. ------------------- new draft 02 ------------------------------ Internet Engineering Task Force R. E. Gilligan (FreeGate) | INTERNET-DRAFT S. Thomson (Bellcore) J. Bound (Compaq) | W. R. Stevens (Consultant) August 14, 1998 | Basic Socket Interface Extensions for IPv6 | Abstract The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [6]. | Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. This Internet Draft expires on September 12, 1998. Internet Drafts | may be | updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. draft-ietf-ipngwg-bsd-api-new-02.txt [Page 1] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 Distribution of this memo is unlimited. draft-ietf-ipngwg-bsd-api-new-02.txt [Page 2] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 Table of Contents 1. Introduction .................................................... 5 2. Design Considerations ........................................... 5 2.1. What Needs to be Changed ................................... 5 2.2. Data Types ................................................. 7 2.3. Headers .................................................... 7 2.4. Structures ................................................. 7 3. Socket Interface ................................................ 7 3.1. IPv6 Address Family and Protocol Family .................... 8 3.2. IPv6 Address Structure ..................................... 8 3.3. Socket Address Structure for 4.3BSD-Based Systems .......... 8 3.4. Socket Address Structure for 4.4BSD-Based Systems .......... 10 3.5. The Socket Functions ....................................... 10 3.6. Compatibility with IPv4 Applications ....................... 11 3.7. Compatibility with IPv4 Nodes .............................. 12 3.8. IPv6 Wildcard Address ...................................... 12 3.9. IPv6 Loopback Address ...................................... 14 3.10. Portability Additions ..................................... 14 4. Interface Identification ........................................ 15 4.1. Name-to-Index .............................................. 15 4.2. Index-to-Name .............................................. 15 4.3. Return All Interface Names and Indexes ..................... 15 4.4. Free Memory ................................................ 15 5. Socket Options .................................................. 15 5.1. Unicast Hop Limit .......................................... 15 5.2. Sending and Receiving Multicast Packets .................... 15 6. Library Functions ............................................... 15 6.1. Nodename-to-Address Translation ............................ 15 6.2. Address-To-Nodename Translation ............................ 15 6.3. Freeing memory for getipnodebyname and getipnodebyaddr ..... 15 6.4. Protocol-Independent Nodename and Service Name Translation . 15 6.5. Socket Address Structure to Nodename and Service Name ...... 15 6.6. Address Conversion Functions ............................... 15 6.7. Address Testing Macros ..................................... 15 7. Summary of New Definitions ...................................... 15 8. Security Considerations ......................................... 15 9. Changes From RFC 2133 ........................................... 15 10. Acknowledgments ................................................. 15 draft-ietf-ipngwg-bsd-api-new-02.txt [Page 3] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 11. References ...................................................... 15 12. Authors' Addresses .............................................. 15 draft-ietf-ipngwg-bsd-api-new-02.txt [Page 4] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 1. Introduction While IPv4 addresses are 32 bits long, IPv6 interfaces are identified by 128-bit addresses. The socket interface make the size of an IP address quite visible to an application; virtually all TCP/IP applications for BSD-based systems have knowledge of the size of an IP address. Those parts of the API that expose the addresses must be changed to accommodate the larger IPv6 address size. IPv6 also introduces new features (e.g., traffic class and flowlabel). | some of which must be made visible to applications via the API. This memo defines a set of extensions to the socket interface to support the larger address size and new features of IPv6. 2. Design Considerations There are a number of important considerations in designing changes to this well-worn API: - The API changes should provide both source and binary compatibility for programs written to the original API. That is, existing program binaries should continue to operate when run on a system supporting the new API. In addition, existing applications that are re-compiled and run on a system supporting the new API should continue to operate. Simply put, the API changes for IPv6 should not break existing programs. - The changes to the API should be as small as possible in order to simplify the task of converting existing IPv4 applications to IPv6. - Where possible, applications should be able to use this API to interoperate with both IPv6 and IPv4 hosts. Applications should not need to know which type of host they are communicating with. - IPv6 addresses carried in data structures should be 64-bit aligned. This is necessary in order to obtain optimum performance on 64-bit machine architectures. Because of the importance of providing IPv4 compatibility in the API, these extensions are explicitly designed to operate on machines that provide complete support for both IPv4 and IPv6. A subset of this API could probably be designed for operation on systems that support only IPv6. However, this is not addressed in this memo. 2.1. What Needs to be Changed draft-ietf-ipngwg-bsd-api-new-02.txt [Page 5] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 The socket interface API consists of a few distinct components: - Core socket functions. - Address data structures. - Name-to-address translation functions. - Address conversion functions. The core socket functions -- those functions that deal with such things as setting up and tearing down TCP connections, and sending and receiving UDP packets -- were designed to be transport independent. Where protocol addresses are passed as function arguments, they are carried via opaque pointers. A protocol-specific address data structure is defined for each protocol that the socket functions support. Applications must cast pointers to these protocol-specific address structures into pointers to the generic "sockaddr" address structure when using the socket functions. These functions need not change for IPv6, but a new IPv6-specific address data structure is needed. The "sockaddr_in" structure is the protocol-specific data structure for IPv4. This data structure actually includes 8-octets of unused space, and it is tempting to try to use this space to adapt the sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in structure is not large enough to hold the 16-octet IPv6 address as well as the other information (address family and port number) that is needed. So a new address data structure must be defined for IPv6. IPv6 addresses are scoped [2] so they could be link-local, site, | organization, global, or other scopes at this time undefined. To | support applications that want to be able to identify a set of | interfaces for a specific scope, the IPv6 sockaddr_in structure must | support a field that can be used by an implementation to identify a | set of interfaces identifying the scope for an IPv6 address. | The name-to-address translation functions in the socket interface are gethostbyname() and gethostbyaddr(). These are left as is and new | functions are defined to support IPv4 and IPv6. Additionally, the | POSIX 1003.g draft [5] specifies a new nodename-to-address | translation function which | is protocol independent. This function can also be used with IPv4 and IPv6. | The address conversion functions -- inet_ntoa() and inet_addr() -- convert IPv4 addresses between binary and printable form. These functions are quite specific to 32-bit IPv4 addresses. We have draft-ietf-ipngwg-bsd-api-new-02.txt [Page 6] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 designed two analogous functions that convert both IPv4 and IPv6 addresses, and carry an address type parameter so that they can be extended to other protocol families as well. Finally, a few miscellaneous features are needed to support IPv6. New interfaces are needed to support the IPv6 traffic class, flow | label, | and hop limit header fields. New socket options are needed to control the sending and receiving of IPv6 multicast packets. The socket interface will be enhanced in the future to provide access to other IPv6 features. These extensions are described in [6]. | 2.2. Data Types The data types of the structure elements given in this memo are intended to be examples, not absolute requirements. Whenever possible, data types from Draft 6.6 (March 1997) of POSIX | 1003.1g are used: uintN_t means an unsigned integer of exactly N bits | (e.g., uint16_t). | We also assume the argument data types from 1003.1g when possible (e.g., the final argument to setsockopt() is a size_t value). Whenever buffer sizes are specified, the POSIX 1003.1 size_t data type is used (e.g., the two length arguments to getnameinfo()). 2.3. Headers When function prototypes and structures are shown we show the headers that must be #included to cause that item to be defined. 2.4. Structures When structures are described the members shown are the ones that must appear in an implementation. Additional, nonstandard members may also be defined by an implementation. The ordering shown for the members of a structure is the recommended ordering, given alignment considerations of multibyte members, but an implementation may order the members differently. 3. Socket Interface draft-ietf-ipngwg-bsd-api-new-02.txt [Page 7] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 This section specifies the socket interface changes for IPv6. 3.1. IPv6 Address Family and Protocol Family A new address family name, AF_INET6, is defined in . The AF_INET6 definition distinguishes between the original sockaddr_in address data structure, and the new sockaddr_in6 data structure. A new protocol family name, PF_INET6, is defined in . Like most of the other protocol family names, this will usually be defined to have the same value as the corresponding address family name: #define PF_INET6 AF_INET6 The PF_INET6 is used in the first argument to the socket() function to indicate that an IPv6 socket is being created. 3.2. IPv6 Address Structure A new in6_addr structure holds a single IPv6 address and is defined | as a result of including : | struct in6_addr { * uint8_t s6_addr[16]; /* IPv6 address */ | } This data structure contains an array of sixteen 8-bit elements, which make up one 128-bit IPv6 address. The IPv6 address is stored in network byte order. 3.3. Socket Address Structure for 4.3BSD-Based Systems In the socket interface, a different protocol-specific data structure is defined to carry the addresses for each protocol suite. Each protocol-specific data structure is designed so it can be cast into a protocol-independent data structure -- the "sockaddr" structure. Each has a "family" field that overlays the "sa_family" of the sockaddr data structure. This field identifies the type of the data structure. The sockaddr_in structure is the protocol-specific address data structure for IPv4. It is used to pass addresses between applications draft-ietf-ipngwg-bsd-api-new-02.txt [Page 8] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 and the system in the socket functions. The following sockaddr_in6 | structure holds IPv6 addresses and is defined as a result of | including the header: | struct sockaddr_in6 { * sa_family_t sin6_family; /* AF_INET6 */ | in_port_t sin6_port; /* transport layer port # */ | uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */| struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* set of interfaces for a scope */| }; This structure is designed to be compatible with the sockaddr data structure used in the 4.3BSD release. The sin6_family field identifies this as a sockaddr_in6 structure. This field overlays the sa_family field when the buffer is cast to a sockaddr data structure. The value of this field must be AF_INET6. The sin6_port field contains the 16-bit UDP or TCP port number. This field is used in the same way as the sin_port field of the sockaddr_in structure. The port number is stored in network byte order. The sin6_flowinfo field is a 32-bit field that contains two pieces of information: the traffic class and the flow label. | The contents and interpretation of this member is unspecified at this time. For exact field specifications see [1]. | The sin6_addr field is a single in6_addr structure (defined in the previous section). This field holds one 128-bit IPv6 address. The address is stored in network byte order. The ordering of elements in this structure is specifically designed so that the sin6_addr field will be aligned on a 64-bit boundary. This is done for optimum performance on 64-bit architectures. The sin6_scope_id field is a 32bit integer that identifies a set of | interfaces as appropriate for the scope of the address carried in the | sin6_addr field. For a link scope sin6_addr sin6_scope_id would be | an interface index. For a site scope sin6_addr, sin6_scope_id would | be a site identifier. The mapping of mapping of sin6_scope_id to an | interface or set of interfaces is left to implementation. | Notice that the sockaddr_in6 structure will normally be larger than the generic sockaddr structure. On many existing implementations the sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both draft-ietf-ipngwg-bsd-api-new-02.txt [Page 9] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 being 16 bytes. Any existing code that makes this assumption needs to be examined carefully when converting to IPv6. 3.4. Socket Address Structure for 4.4BSD-Based Systems The 4.4BSD release includes a small, but incompatible change to the socket interface. The "sa_family" field of the sockaddr data structure was changed from a 16-bit value to an 8-bit value, and the space saved used to hold a length field, named "sa_len". The sockaddr_in6 data structure given in the previous section cannot be correctly cast into the newer sockaddr data structure. For this reason, the following alternative IPv6 address data structure is provided to be used on systems based on 4.4BSD. It is defined as a result of including the | header. | struct sockaddr_in6 { * uint8_t sin6_len; /* length of this struct */ | sa_family_t sin6_family; /* AF_INET6 */ | in_port_t sin6_port; /* transport layer port # */ | uint32_t sin6_flowinfo; /* IPv6 flow information */ | struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* set of interfaces for a scope */| }; The only differences between this data structure and the 4.3BSD variant are the inclusion of the length field, and the change of the family field to a 8-bit data type. The definitions of all the other fields are identical to the structure defined in the previous section. Systems that provide this version of the sockaddr_in6 data structure must also declare SIN6_LEN as a result of including the header. This macro allows applications to determine whether they are being built on a system that supports the 4.3BSD or 4.4BSD variants of the data structure. 3.5. The Socket Functions Applications call the socket() function to create a socket descriptor that represents a communication endpoint. The arguments to the socket() function tell the system which protocol to use, and what format address structure will be used in subsequent functions. For example, to create an IPv4/TCP socket, applications make the call: s = socket(PF_INET, SOCK_STREAM, 0); draft-ietf-ipngwg-bsd-api-new-02.txt [Page 10] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 To create an IPv4/UDP socket, applications make the call: s = socket(PF_INET, SOCK_DGRAM, 0); Applications may create IPv6/TCP and IPv6/UDP sockets by simply using the constant PF_INET6 instead of PF_INET in the first argument. For example, to create an IPv6/TCP socket, applications make the call: s = socket(PF_INET6, SOCK_STREAM, 0); To create an IPv6/UDP socket, applications make the call: s = socket(PF_INET6, SOCK_DGRAM, 0); Once the application has created a PF_INET6 socket, it must use the sockaddr_in6 address structure when passing addresses in to the system. The functions that the application uses to pass addresses into the system are: bind() connect() sendmsg() sendto() The system will use the sockaddr_in6 address structure to return addresses to applications that are using PF_INET6 sockets. The functions that return an address from the system to an application are: accept() recvfrom() recvmsg() getpeername() getsockname() No changes to the syntax of the socket functions are needed to support IPv6, since all of the "address carrying" functions use an opaque address pointer, and carry an address length as a function argument. 3.6. Compatibility with IPv4 Applications In order to support the large base of applications using the original API, system implementations must provide complete source and binary compatibility with the original API. This means that systems must continue to support PF_INET sockets and the sockaddr_in address structure. Applications must be able to create IPv4/TCP and IPv4/UDP draft-ietf-ipngwg-bsd-api-new-02.txt [Page 11] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 sockets using the PF_INET constant in the socket() function, as described in the previous section. Applications should be able to hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets simultaneously within the same process. Applications using the original API should continue to operate as they did on systems supporting only IPv4. That is, they should continue to interoperate with IPv4 nodes. 3.7. Compatibility with IPv4 Nodes The API also provides a different type of compatibility: the ability for IPv6 applications to interoperate with IPv4 applications. This feature uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing architecture specification [2]. This address format allows the IPv4 address of an IPv4 node to be represented as an IPv6 address. The IPv4 address is encoded into the low-order 32 bits of the IPv6 address, and the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows: ::FFFF: These addresses are often generated automatically by the gethostbyname() function when the specified host has only IPv4 addresses (as described in Section 6.1). Applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect() or sendto() call. When applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way. Few applications will likely need to know which type of node they are interoperating with. However, for those applications that do need to know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is provided. 3.8. IPv6 Wildcard Address While the bind() function allows applications to select the source IP address of UDP packets and TCP connections, applications often want the system to select the source address for them. With IPv4, one draft-ietf-ipngwg-bsd-api-new-02.txt [Page 12] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 specifies the address as the symbolic constant INADDR_ANY (called the "wildcard" address) in the bind() call, or simply omits the bind() entirely. Since the IPv6 address type is a structure (struct in6_addr), a symbolic constant can be used to initialize an IPv6 address variable, but cannot be used in an assignment. Therefore systems provide the IPv6 wildcard address in two forms. The first version is a global variable named "in6addr_any" that is an in6_addr structure. The extern declaration for this variable is defined in : extern const struct in6_addr in6addr_any; Applications use in6addr_any similarly to the way they use INADDR_ANY in IPv4. For example, to bind a socket to port number 23, but let the system select the source address, an application could use the following code: struct sockaddr_in6 sin6; . . . sin6.sin6_family = AF_INET6; sin6.sin6_flowinfo = 0; sin6.sin6_port = htons(23); sin6.sin6_addr = in6addr_any; /* structure assignment */ . . . if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) . . . The other version is a symbolic constant named IN6ADDR_ANY_INIT and is defined in . This constant can be used to initialize an in6_addr structure: struct in6_addr anyaddr = IN6ADDR_ANY_INIT; Note that this constant can be used ONLY at declaration time. It can not be used to assign a previously declared in6_addr structure. For example, the following code will not work: /* This is the WRONG way to assign an unspecified address */ struct sockaddr_in6 sin6; . . . sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ Be aware that the IPv4 INADDR_xxx constants are all defined in host byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 draft-ietf-ipngwg-bsd-api-new-02.txt [Page 13] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 in6addr_xxx externals are defined in network byte order. 3.9. IPv6 Loopback Address Applications may need to send UDP packets to, or originate TCP connections to, services residing on the local node. In IPv4, they can do this by using the constant IPv4 address INADDR_LOOPBACK in their connect(), sendto(), or sendmsg() call. IPv6 also provides a loopback address to contact local TCP and UDP services. Like the unspecified address, the IPv6 loopback address is provided in two forms -- a global variable and a symbolic constant. The global variable is an in6_addr structure named "in6addr_loopback." The extern declaration for this variable is defined in : extern const struct in6_addr in6addr_loopback; Applications use in6addr_loopback as they would use INADDR_LOOPBACK in IPv4 applications (but beware of the byte ordering difference mentioned at the end of the previous section). For example, to open a TCP connection to the local telnet server, an application could use the following code: struct sockaddr_in6 sin6; . . . sin6.sin6_family = AF_INET6; sin6.sin6_flowinfo = 0; sin6.sin6_port = htons(23); sin6.sin6_addr = in6addr_loopback; /* structure assignment */ . . . if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) . . . The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined in . It can be used at declaration time ONLY; for example: struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to a previously declared IPv6 address variable. 3.10. Portability Additions | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 14] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 One simple additions to the sockets API can help application writers. | struct sockaddr_storage { char _ss_maxsize[128]; /* Implementation Specific */ /* * Plus implementation specific fields to ensure sufficient * alignment. * */ }; This structure solves the problem that you don't know how big the | retrieve buffer for a socket address structure needs to be until you | have received that structure (e.g., getpeername()). Also, much | existing code assumes that any socket address structure can fit in a | generic sockaddr structure. While this has been true for IPv4 socket | address structures, it has always been false for Unix domain socket | address structures (but in practice this has not been a problem) and | it is also false for IPv6 socket address structures (which can be a | problem). | So now an application can to the following: | struct sockaddr_storage ss; .... struct sockaddr_in6 *sin6; sin6 = (struct sockaddr_in6 *) &ss; Each implementation can add whatever fields it needs to get appropriate | aligment. | 4. Interface Identification This API uses an interface index (a small positive integer) to identify the local interface on which a multicast group is joined (Section 5.3). Additionally, the advanced API [6] uses these same interface indexes | to identify the interface on which a datagram is received, or to specify the interface on which a datagram is to be sent. Interfaces are normally known by names such as "le0", "sl1", "ppp2", and the like. On Berkeley-derived implementations, when an interface is made known to the system, the kernel assigns a unique positive integer value (called the interface index) to that interface. These draft-ietf-ipngwg-bsd-api-new-02.txt [Page 15] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 are small positive integers that start at 1. (Note that 0 is never used for an interface index.) There may be gaps so that there is no current interface for a particular positive interface index. This API defines two functions that map between an interface name and index, a third function that returns all the interface names and indexes, and a fourth function to return the dynamic memory allocated by the previous function. How these functions are implemented is left up to the implementation. 4.4BSD implementations can implement these functions using the existing sysctl() function with the NET_RT_IFLIST command. | Other implementations may wish to use ioctl() for this purpose. 4.1. Name-to-Index The first function maps an interface name into its corresponding index. #include unsigned int if_nametoindex(const char *ifname); If the specified interface does not exist, the return value is 0. 4.2. Index-to-Name The second function maps an interface index into its corresponding name. #include char *if_indextoname(unsigned int ifindex, char *ifname); The ifname argument must point to a buffer of at least IFNAMSIZ bytes into which the interface name corresponding to the specified index is returned. (IFNAMSIZ is also defined in and its value includes a terminating null byte at the end of the interface name.) This pointer is also the return value of the function. If there is no interface corresponding to the specified index, NULL is returned, and errno is set to ENXIO, if there was a system | error (such as running out of memory), ifindextoname returns NULL and | errno would be set to the proper value (e.g., ENOMEM). | 4.3. Return All Interface Names and Indexes draft-ietf-ipngwg-bsd-api-new-02.txt [Page 16] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 The if_nameindex structure holds the information about a single | interface and is defined as a result of including the | header. | struct if_nameindex { *| unsigned int if_index; /* 1, 2, ... */ | char *if_name; /* null terminated name: "le0", ... */ | }; | The final function returns an array of if_nameindex structures, one structure per interface. struct if_nameindex *if_nameindex(void); The end of the array of structures is indicated by a structure with an if_index of 0 and an if_name of NULL. The function returns a NULL pointer upon an error, and would set | errno to the approriate value. | The memory used for this array of structures along with the interface names pointed to by the if_name members is obtained dynamically. This memory is freed by the next function. 4.4. Free Memory The following function frees the dynamic memory that was allocated by if_nameindex(). #include void if_freenameindex(struct if_nameindex *ptr); The argument to this function must be a pointer that was returned by if_nameindex(). Currently net/if.h doesn't have prototype definitions for functions | and it is recommended that these definitions be defined in | arpa/inet.h as well and the struct if_nameindex{}. | 5. Socket Options A number of new socket options are defined for IPv6. All of these new options are at the IPPROTO_IPV6 level. That is, the "level" parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using these options. The constant name prefix IPV6_ is used in draft-ietf-ipngwg-bsd-api-new-02.txt [Page 17] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 all of the new socket options. This serves to clearly identify these options as applying to IPv6. The declaration for IPPROTO_IPV6, the new IPv6 socket options, and related constants defined in this section are obtained by including the header . 5.1. Unicast Hop Limit * A new setsockopt() option controls the hop limit used in outgoing unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and it is used at the IPPROTO_IPV6 layer. The following example illustrates how it is used: int hoplimit = 10; if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, (char *) &hoplimit, sizeof(hoplimit)) == -1) perror("setsockopt IPV6_UNICAST_HOPS"); When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option value given is used as the hop limit for all subsequent unicast packets sent via that socket. If the option is not set, the system selects a default value. The integer hop limit value (called x) is interpreted as follows: x < -1: return an error of EINVAL x == -1: use kernel default 0 <= x <= 255: use x x >= 256: return an error of EINVAL The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine the hop limit value that the system will use for subsequent unicast packets sent via that socket. For example: int hoplimit; size_t len = sizeof(hoplimit); if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, (char *) &hoplimit, &len) == -1) perror("getsockopt IPV6_UNICAST_HOPS"); else printf("Using %d for hop limit.\n", hoplimit); draft-ietf-ipngwg-bsd-api-new-02.txt [Page 18] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 5.2. Sending and Receiving Multicast Packets IPv6 applications may send UDP multicast packets by simply specifying an IPv6 multicast address in the address argument of the sendto() function. Three socket options at the IPPROTO_IPV6 layer control some of the parameters for sending multicast packets. Setting these options is not required: applications may send multicast packets without using these options. The setsockopt() options for controlling the sending of multicast packets are summarized below. These three options can also | be used with getsockopt(). | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 19] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 IPV6_MULTICAST_IF Set the interface to use for outgoing multicast packets. The argument is the index of the interface to use. Argument type: unsigned int IPV6_MULTICAST_HOPS Set the hop limit to use for outgoing multicast packets. (Note a separate option - IPV6_UNICAST_HOPS - is provided to set the hop limit to use for outgoing unicast packets.) The interpretation of the argument is the same as for the IPV6_UNICAST_HOPS option: x < -1: return an error of EINVAL x == -1: use kernel default 0 <= x <= 255: use x x >= 256: return an error of EINVAL If IPV6_MULTICAST_HOPS is not set, the default is 1 (same as IPv4 today)| Argument type: int IPV6_MULTICAST_LOOP If a multicast datagram is sent to a group to which the send- | ing host itself belongs (on the outgoing interface), a copy | of the datagram is looped back by the IP layer for local | delivery if this option is set to 1. If this option is set | to 0 a copy is not looped back. Other option values return | an error of EINVAL. | If IPV6_MULTICAST_LOOP is not set, the default is 1 (loop- | back; same as IPv4 today). | Argument type: unsigned int The reception of multicast packets is controlled by the two setsockopt() options summarized below. An error of EOPNOTSUPP is returned if | these two options are used with getsockopt(). | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 20] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 IPV6_JOIN_MEMBERSHIP | Join a multicast group on a specified local interface. If the interface index is specified as 0, the kernel chooses the local interface. For example, some kernels look up the multicast group in the normal IPv6 routing table and using the resulting interface. Argument type: struct ipv6_mreq IPV6_LEAVE_MEMBERSHIP | Leave a multicast group on a specified interface. Argument type: struct ipv6_mreq The argument type of both of these options is the ipv6_mreq structure, defined as as a result of including the header; | struct ipv6_mreq { * struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ unsigned int ipv6mr_interface; /* interface index */ }; Note that to receive multicast datagrams a process must join the multicast group and bind the UDP port to which datagrams will be sent. Some processes also bind the multicast group address to the socket, in addition to the port, to prevent other datagrams destined to that same port from being delivered to the socket. 6. Library Functions New library functions are needed to perform a variety of operations with IPv6 addresses. Functions are needed to lookup IPv6 addresses in the Domain Name System (DNS). Both forward lookup (nodename-to-address translation) and reverse | lookup (address-to-nodename translation) need to be supported. | Functions are also needed to convert IPv6 addresses between their binary and textual form. We note that the two existing functions, gethostbyname() and | gethostbyaddr(), are left as-is. New functions are defined to handle | both IPv4 and IPv6 addresses. | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 21] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 6.1. Nodename-to-Address Translation | The commonly used function gethostbyname() is inadequate for many | applications, first because it provides no way for the caller to | specify anything about the types of addresses desired (IPv4 only, | IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second many | implementations of this function are not thread safe. RFC 2133 | defined a function named gethostbyname2() but this function was also | inadequate, first because its use required setting a global option | (RES_USE_INET6) when IPv6 addresses were required, and second because | a flag argument is needed to provide the caller with additional | control over the types of addresses required. | The following function is new and must be thread safe: | #include #include struct hostent *getipnodebyname(const char *name, int af, int flags| int error_num); | The name argument can be either a node name or a numeric address | string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). | The af argument specifies the address family, either AF_INET or | AF_INET6. The error_num value is returned to the caller with the | appropriate error code, to support thread safe error code returns. | The flags argument specifies the types of addresses that are searched | for, and the types of addresses that are returned. We note that a | special flags value of AI_DEFAULT (defined below) should handle most | applications. That is, porting simple applications to use IPv6 | replaces the call | hptr = gethostbyname(name); | with | hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT); Applications desiring finer control over the types of addresses | searched for and returned, can specify other combinations of the | flags argument. | A flags of 0 implies a strict interpretation of the af argument: | - If flags is 0 and af is AF_INET, then the caller wants only IPv4 | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 22] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 addresses. A query is made for A records. If successful, the IPv4 | addresses are returned and the h_length member of the hostent | structure will be 4, else the function returns a NULL pointer. | - If flags is 0 and if af is AF_INET6, then the caller wants only | IPv6 addresses. A query is made for AAAA records. If | successful, the IPv6 addresses are returned and the h_length | member of the hostent structure will be 16, else the function | returns a NULL pointer. | Other constants can be logically-ORed into the flags argument, to | modify the behavior of the function. | - If the AI_V4MAPPED flag is specified along with an af of | AF_INET6, then the caller will accept IPv4-mapped IPv6 addresses. | That is, if no AAAA records are found then a query is made for A | records and any found are returned as IPv4-mapped IPv6 addresses | (h_length will be 16). The AI_V4MAPPED flag is ignored unless af | equals AF_INET6. | - The AI_ALL flag is used in conjunction with the AI_V4MAPPED flag, | and is only used with the IPv6 address family. When AI_ALL is | logically or'd with AI_V4MAPPED flag then the caller wants all | addresses: IPv6 and IPv4-mapped IPv6. A query is first made for | AAAA records and if successful, the IPv6 addresses are returned. | Another query is then made for A records and any found are | returned as IPv4-mapped IPv6 addresses. h_length will be 16. | Only if both queries fail does the function return a NULL | pointer. This flag is ignored unless af equals AF_INET6. | - The AI_ADDRCONFIG flag specifies that a query for AAAA records | should occur only if the node has at least one IPv6 source | address configured and a query for A records should occur only if | the node has at least one IPv4 source address configured. | For example, if the node has no IPv6 source addresses configured, | and af equals AF_INET6, and the node name being looked up has | both AAAA and A records, then: (a) if only AI_ADDRCONFIG is | specified, the function returns a NULL pointer; (b) if | AI_ADDRCONFIG | AI_V4MAPPED is specified, the A records are | returned as IPv4-mapped IPv6 addresses; | The special flags value of AI_DEFAULT is defined as | #define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG) draft-ietf-ipngwg-bsd-api-new-02.txt [Page 23] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 We noted that the getipnodebyname() function must allow the name | argument to be either a node name or a literal address string (i.e., | a dotted-decimal IPv4 address or an IPv6 hex address). This saves | applications from having to call inet_pton() to handle literal | address strings. | There are four scenarios based on the type of literal address string | and the value of the af argument. The two simple cases are when name | is a dotted-decimal IPv4 address and af equals AF_INET, or when name | is an IPv6 hex address and af equals AF_INET6. The members of the | returned hostent structure are: h_name points to a copy of the name | argument, h_aliases is a NULL pointer, h_addrtype is a copy of the af | argument, h_length is either 4 (for AF_INET) or 16 (for AF_INET6), | h_addr_list[0] is a pointer to the 4-byte or 16-byte binary address, | and h_addr_list[1] is a NULL pointer. | It is an error when name is an IPv6 hex address and af equals | AF_INET. The function's return value is a NULL pointer and error_num | equals HOST_NOT_FOUND. | 6.2. Address-To-Nodename Translation | The following function has the same arguments as the existing | gethostbyaddr() function, but adds an error number. | #include #include struct hostent *getipnodebyaddr(const void *src, size_t len, int af);| int error_num); | As with getipnodebyname(), getipnodebyaddr() must be thread safe. | The error_num value is returned to the caller with the appropriate | error code, to support thread safe error code returns. | One possible source of confusion is the handling of IPv4-mapped IPv6 addresses and IPv4-compatible IPv6 addresses. This is addressed in [7] and involves the following logic: | 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, then skip over the first 12 bytes of the IPv6 address, set af to AF_INET, and set len to 4. 2. If af is AF_INET, lookup the name for the given IPv4 address | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 24] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 (e.g., query for a PTR record in the in-addr.arpa domain). | 3. If af is AF_INET6, lookup the name for the given IPv6 address | (e.g., query for a PTR record in the ip6.int domain). | 4. If the function is returning success, then the single address | that is returned in the hostent structure is a copy of the first | argument to the function with with the same address family that | was passed as an argument to this function. | All four steps listed are performed, in order. 6.3. Freeing memory for getipnodebyname and getipnodebyaddr | The hostent structure does not change from its existing definition. | This structure, and the information pointed to by this structure, are | dynamically allocated by getipnodebyname and getipnodebyaddr. The | following function frees this memory: | #include #include void freehostent(struct hostent *ptr); 6.4. Protocol-Independent Nodename and Service Name Translation | Nodename-to-address translation is done in a protocol-independent | fashion using the getaddrinfo() function that is taken from the Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g (Protocol Independent Interfaces) draft specification | [5]. | The official specification for this function will be the final POSIX standard, with the following additional requirements: | - getaddrinfo() (along with the getnameinfo() function described in | the next section) must be thread safe. | - The AI_NUMERICHOST is new with this document. | - All fields in socket address structures returned by getaddrinfo() | that are not filled in through an explicit argument (e.g., | sin6_flowinfo and sin_zero) must be set to 0. (This makes it | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 25] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 easier to compare socket address structures.) | - getaddrinfo() must fill in the length field of a socket address | structure (e.g., sin6_len) on systems that support this field. | We are providing this independent description of the function because POSIX standards are not freely available (as are IETF documents). #include #include int getaddrinfo(const char *nodename, const char *servname, | const struct addrinfo *hints, struct addrinfo **res); The addrinfo structure is defined as a result of including the | header. | struct addrinfo { * int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */| int ai_family; /* PF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ size_t ai_addrlen; /* length of ai_addr */ char *ai_canonname; /* canonical name for nodename */ | struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ }; The return value from the function is 0 upon success or a nonzero error code. The following names are the nonzero error codes from getaddrinfo(), and are defined in : EAI_ADDRFAMILY address family for nodename not supported | EAI_AGAIN temporary failure in name resolution EAI_BADFLAGS invalid value for ai_flags EAI_FAIL non-recoverable failure in name resolution EAI_FAMILY ai_family not supported EAI_MEMORY memory allocation failure EAI_NODATA no address associated with nodename | EAI_NONAME nodename nor servname provided, or not known | EAI_SERVICE servname not supported for ai_socktype EAI_SOCKTYPE ai_socktype not supported EAI_SYSTEM system error returned in errno The nodename and servname arguments are pointers to null- | terminated | strings or NULL. One or both of these two arguments must be a non- draft-ietf-ipngwg-bsd-api-new-02.txt [Page 26] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 NULL pointer. In the normal client scenario, both the nodename and servname | are specified. In the normal server scenario, only the servname is specified. A non-NULL nodename string can be either a node name or a | numeric host address string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). A non-NULL servname string can be either a service name or a decimal port number. The caller can optionally pass an addrinfo structure, pointed to by the third argument, to provide hints concerning the type of socket that the caller supports. In this hints structure all members other than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL pointer. A value of PF_UNSPEC for ai_family means the caller will accept any protocol family. A value of 0 for ai_socktype means the caller will accept any socket type. A value of 0 for ai_protocol means the caller will accept any protocol. For example, if the caller handles only TCP and not UDP, then the ai_socktype member of the hints structure should be set to SOCK_STREAM when getaddrinfo() is called. If the caller handles only IPv4 and not IPv6, then the ai_family member of the hints structure should be set to PF_INET when getaddrinfo() is called. If the third argument to getaddrinfo() is a NULL pointer, this is the same as if the caller had filled in an addrinfo structure initialized to zero with ai_family set to PF_UNSPEC. Upon successful return a pointer to a linked list of one or more addrinfo structures is returned through the final argument. The caller can process each addrinfo structure in this list by following the ai_next pointer, until a NULL pointer is encountered. In each returned addrinfo structure the three members ai_family, ai_socktype, and ai_protocol are the corresponding arguments for a call to the socket() function. In each addrinfo structure the ai_addr member points to a filled-in socket address structure whose length is specified by the ai_addrlen member. If the AI_PASSIVE bit is set in the ai_flags member of the hints structure, then the caller plans to use the returned socket address structure in a call to bind(). In this case, if the nodename argument is a NULL pointer, | then the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the AI_PASSIVE bit is not set in the ai_flags member of the hints structure, then the returned socket address structure will be ready for a call to connect() (for a connection-oriented protocol) or either connect(), sendto(), or sendmsg() (for a connectionless draft-ietf-ipngwg-bsd-api-new-02.txt [Page 27] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 protocol). In this case, if the nodename argument is a NULL pointer, | then the IP address portion of the socket address structure will be set to the loopback address. If the AI_CANONNAME bit is set in the ai_flags member of the hints structure, then upon successful return the ai_canonname member of the first addrinfo structure in the linked list will point to a null- terminated string containing the canonical name of the specified nodename. | If the AI_NUMERICHOST bit is set in the ai_flags member of the hints | structure, then a non-NULL nodename string must be a numeric host | address string. Otherwise an error of EAI_NONAME is returned. This | flag prevents any type of name resolution service (e.g., the DNS) | from being called. | All of the information returned by getaddrinfo() is dynamically allocated: the addrinfo structures, and the socket address structures and canonical node name strings pointed to by the addrinfo | structures. | To return this information to the system the function freeaddrinfo() is called: #include #include void freeaddrinfo(struct addrinfo *ai); The addrinfo structure pointed to by the ai argument is freed, along with any dynamic storage pointed to by the structure. This operation is repeated until a NULL ai_next pointer is encountered. To aid applications in printing error messages based on the EAI_xxx codes returned by getaddrinfo(), the following function is defined. #include #include char *gai_strerror(int ecode); The argument is one of the EAI_xxx values defined earlier and the return value points to a string describing the error. If the argument is not one of the EAI_xxx values, the function still returns a pointer to a string whose contents indicate an unknown error. draft-ietf-ipngwg-bsd-api-new-02.txt [Page 28] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 6.5. Socket Address Structure to Nodename and Service Name | The POSIX 1003.1g specification includes no function to perform the reverse conversion from getaddrinfo(): to look up a nodename and service name, given the binary address and | port. | Therefore, we define the following function: #include #include int getnameinfo(const struct sockaddr *sa, socklen_t salen, | char *host, size_t hostlen, char *serv, size_t servlen, int flags); This function looks up an IP address and port number provided by the caller in the DNS and system-specific database, and returns text strings for both in buffers provided by the caller. The function indicates successful completion by a zero return value; a non-zero return value indicates failure. The first argument, sa, points to either a sockaddr_in structure (for IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP address and port number. The salen argument gives the length of the sockaddr_in or sockaddr_in6 structure. The function returns the nodename associated with the IP address in | the | buffer pointed to by the host argument. The caller provides the size of this buffer via the hostlen argument. The service name associated with the port number is returned in the buffer pointed to by serv, and the servlen argument gives the length of this buffer. The caller specifies not to return either string by providing a zero value for the hostlen or servlen arguments. Otherwise, the caller must provide buffers large enough to hold the nodename and the service name, | including the terminating null characters. Unfortunately most systems do not provide constants that specify the maximum size of either a fully-qualified domain name or a service name. Therefore to aid the application in allocating buffers for these two returned strings the following constants are defined in : #define NI_MAXHOST 1025 #define NI_MAXSERV 32 draft-ietf-ipngwg-bsd-api-new-02.txt [Page 29] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 The first value is actually defined as the constant MAXDNAME in recent versions of BIND's header (older versions of BIND define this constant to be 256) and the second is a guess based on the services listed in the current Assigned Numbers RFC. The final argument is a flag that changes the default actions of this function. By default the fully-qualified domain name (FQDN) for the host is looked up in the DNS and returned. If the flag bit NI_NOFQDN is set, only the nodename portion of the FQDN is returned for local hosts. | If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be located in the DNS, the numeric form of the host's address is returned instead of its name (e.g., by calling inet_ntop() instead of getnodebyaddr()). | If the flag bit NI_NAMEREQD is set, an error is returned if the host's name cannot be located in the DNS. If the flag bit NI_NUMERICSERV is set, the numeric form of the service address is returned (e.g., its port number) instead of its name. The two NI_NUMERICxxx flags are required to support the "-n" flag that many commands provide. A fifth flag bit, NI_DGRAM, specifies that the service is a datagram service, and causes getservbyport() to be called with a second argument of "udp" instead of its default of "tcp". This is required for the few ports (512-514) that have different services for UDP and TCP. These NI_xxx flags are defined in along with the AI_xxx flags already defined for getaddrinfo(). 6.6. Address Conversion Functions The two functions inet_addr() and inet_ntoa() convert an IPv4 address between binary and text form. IPv6 applications need similar functions. The following two functions convert both IPv6 and IPv4 addresses: #include #include int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, size_t size); draft-ietf-ipngwg-bsd-api-new-02.txt [Page 30] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 The inet_pton() function converts an address in its standard text presentation form into its numeric binary form. The af argument specifies the family of the address. Currently the AF_INET and AF_INET6 address families are supported. The src argument points to the string being passed in. The dst argument points to a buffer into which the function stores the numeric address. The address is returned in network byte order. Inet_pton() returns 1 if the conversion succeeds, 0 if the input is not a valid IPv4 dotted- decimal string or a valid IPv6 address string, or -1 with errno set to EAFNOSUPPORT if the af argument is unknown. The calling application must ensure that the buffer referred to by dst is large enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16 bytes for AF_INET6). If the af argument is AF_INET, the function accepts a string in the standard IPv4 dotted-decimal form: ddd.ddd.ddd.ddd where ddd is a one to three digit decimal number between 0 and 255. Note that many implementations of the existing inet_addr() and inet_aton() functions accept nonstandard input: octal numbers, hexadecimal numbers, and fewer than four numbers. inet_pton() does not accept these formats. If the af argument is AF_INET6, then the function accepts a string in one of the standard IPv6 text forms defined in Section 2.2 of the addressing architecture specification [2]. The inet_ntop() function converts a numeric address into a text string suitable for presentation. The af argument specifies the family of the address. This can be AF_INET or AF_INET6. The src argument points to a buffer holding an IPv4 address if the af argument is AF_INET, or an IPv6 address if the af argument is AF_INET6. The dst argument points to a buffer where the function will store the resulting text string. The size argument specifies the size of this buffer. The application must specify a non-NULL dst argument. For IPv6 addresses, the buffer must be at least 46-octets. For IPv4 addresses, the buffer must be at least 16-octets. In order to allow applications to easily declare buffers of the proper size to store IPv4 and IPv6 addresses in string form, the following two constants are defined in : #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 The inet_ntop() function returns a pointer to the buffer containing draft-ietf-ipngwg-bsd-api-new-02.txt [Page 31] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 the text string if the conversion succeeds, and NULL otherwise. Upon failure, errno is set to EAFNOSUPPORT if the af argument is invalid or ENOSPC if the size of the result buffer is inadequate. 6.7. Address Testing Macros The following macros can be used to test for special IPv6 addresses. #include int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); The first seven macros return true if the address is of the specified type, or false otherwise. The last five test the scope of a multicast address and return true if the address is a multicast address of the specified scope or false if the address is either not a multicast address or not of the specified scope. Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true | only for the two local-use IPv6 unicast addresses. These two macros | do not return true for IPv6 multicast addresses of either link-local | scope or site-local scope. | 7. Summary of New Definitions The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header. IFNAMSIZ struct if_nameindex{}; AI_ADDRCONFIG | AI_ALL | AI_CANONNAME AI_NUMERICHOST | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 32] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 AI_PASSIVE AI_V4MAPPED | EAI_ADDRFAMILY EAI_AGAIN EAI_BADFLAGS EAI_FAIL EAI_FAMILY EAI_MEMORY EAI_NODATA EAI_NONAME EAI_SERVICE EAI_SOCKTYPE EAI_SYSTEM NI_DGRAM NI_MAXHOST NI_MAXSERV NI_NAMEREQD NI_NOFQDN NI_NUMERICHOST NI_NUMERICSERV struct addrinfo{}; IN6ADDR_ANY_INIT IN6ADDR_LOOPBACK_INIT INET6_ADDRSTRLEN INET_ADDRSTRLEN IPPROTO_IPV6 IPV6_ADD_MEMBERSHIP * IPV6_DROP_MEMBERSHIP IPV6_MULTICAST_HOPS IPV6_MULTICAST_IF IPV6_MULTICAST_LOOP IPV6_UNICAST_HOPS SIN6_LEN extern const struct in6_addr in6addr_any; extern const struct in6_addr in6addr_loopback; struct in6_addr{}; struct ipv6_mreq{}; struct sockaddr_in6{}; AF_INET6 * PF_INET6 union sockaddr_union; | The following list summarizes the function and macro prototypes discussed in this memo, sorted by header. draft-ietf-ipngwg-bsd-api-new-02.txt [Page 33] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 int inet_pton(int, const char *, void *); const char *inet_ntop(int, const void *, char *, size_t); char *if_indextoname(unsigned int, char *); unsigned int if_nametoindex(const char *); void if_freenameindex(struct if_nameindex *); struct if_nameindex *if_nameindex(void); int getaddrinfo(const char *, const char *, const struct addrinfo *, struct addrinfo **); int getnameinfo(const struct sockaddr *, socklen_t, | char *, size_t, char *, size_t, int); void freeaddrinfo(struct addrinfo *); char *gai_strerror(int); struct hostent *getnodebyname(const char *, int, int);| struct hostent *getnodebyaddr(const void *, size_t, int);| void freehostent(struct hostent *); | int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); SA_LEN | 8. Security Considerations IPv6 provides a number of new security mechanisms, many of which need to be accessible to applications. Companion memos detailing the | extensions to the socket interfaces to support IPv6 security are | being written [3, 4]. | 9. Changes From RFC 2133 | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 34] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 Changes made in the March 1998 Edition (-01 draft): | - Changed all "hostname" to "nodename" for consistency with other | IPv6 documents. | - Section 3.3: changed comment for sin6_flowinfo to be "traffic | class & flow info" and updated corresponding text description to | current definition of these two fields. | - Section 3.10 ("Portablity Additions") is new. | - Section 6: a new paragraph was added reiterating that the | existing gethostbyname() and gethostbyaddr() are not changed. | - Section 6.1: change gethostbyname3() to getnodebyname(). Add | AI_DEFAULT to handle majority of applications. Renamed | AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and | IPv4 addresses too. Defined exactly what getnodebyname() must | return if the name argument is a numeric address string. | - Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword | items 2 and 3 in the description of how to handle IPv4-mapped and | IPv4-compatible addresses to "lookup a name" for a given address, | instead of specifying what type of DNS query to issue. | - Section 6.3: added two more requirements to getaddrinfo(). | - Section 7: added the following constants to the list for | : AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union | sockaddr_union and SA_LEN to the lists for . | - Updated references. | Changes made in the November 1997 Edition (-00 draft): | - The data types have been changed to conform with Draft 6.6 of the | Posix 1003.1g standard. Section 3.2: data type of s6_addr | changed to "uint8_t". Section 3.3: data type of sin6_family | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 35] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 changed to "sa_family_t". data type of sin6_port changed to | "in_port_t", data type of sin6_flowinfo changed to "uint32_t". | Section 3.4: same as Section 3.3, plus data type of sin6_len | changed to "uint8_t". Section 6.2: first argument of | gethostbyaddr() changed from "const char *" to "const void *" and | second argument changed from "int" to "size_t". Section 6.4: | second argument of getnameinfo() changed from "size_t" to | "socklen_t". | - The wording was changed when new structures were defined, to be | more explicit as to which header must be included to define the | structure: Section 3.2 (in6_addr{}), Section 3.3 | (sockaddr_in6{}), Section 3.4 (sockaddr_in6{}), Section 4.3 | (if_nameindex{}), Section 5.3 (ipv6_mreq{}), and Section 6.3 | (addrinfo{}). | - Section 4: NET_RT_LIST changed to NET_RT_IFLIST. | - Section 5.1: The IPV6_ADDRFORM socket option was removed. | - Section 5.3: Added a note that an option value other than 0 or 1 | for IPV6_MULTICAST_LOOP returns an error. Added a note that | IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP | can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and | IPV6_DROP_MEMBERSHIP cannot be used with getsockopt(). | - Section 6.1: Removed the description of gethostbyname2() and its | associated RES_USE_INET6 option, replacing it with | gethostbyname3(). | - Section 6.2: Added requirement that gethostbyaddr() be thread | safe. Reworded step 4 to avoid using the RES_USE_INET6 option. | - Section 6.3: Added the requirement that getaddrinfo() and | getnameinfo() be thread safe. Added the AI_NUMERICHOST flag. | - Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and | IN6_IS_ADDR_SITELOCAL macros. | Changes made to the draft -01 specification August 98 | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 36] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 - - Changed priority to traffic class in the spec. | - - Added the need for scope identification in section 2.1. | - - Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and | 3.4. | - - Changed 3.10 to use generic storage structure to support | holding | - IPv6 addresses and removed the SA_LEN macro. | - - Distinguished between invalid input parameters and system | failures for Interface Identification in Section 4.1 and 4.2. | - - Added defaults for multicast operations in section 5.2 and | changed the names from ADD to JOIN and DROP to LEAVE to be | consistent with IPv6 multicast terminology. | - - Changed getnodebyname to getipnodebyname, getnodebyaddr to | getipnodebyaddr, and added MT safe error code to funtion | parameters in section 6. | - - Moved freehostent to its own sub-section after getipnodebyaddr | now 6.3 (so this bumps all remaining sections in section 6. | - - Clarified the use of AI_ALL and AI_V4MAPPED that these are | dependent on the AF parameter and must be used as a conjuntion in | section 6.1. | - - Removed the restriction that literal addresses cannot be used | with a flags argument in section 6.1. | 10. Acknowledgments draft-ietf-ipngwg-bsd-api-new-02.txt [Page 37] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 Thanks to the many people who made suggestions and provided feedback to this document, including: | Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl Williams, and Kazu Yamamoto, | The getaddrinfo() and getnameinfo() functions are taken from an earlier Internet Draft by Keith Sklower. As noted in that draft, William Durst, Steven Wise, Michael Karels, and Eric Allman provided many useful discussions on the subject of protocol-independent name- to-address translation, and reviewed early versions of Keith Sklower's original proposal. Eric Allman implemented the first prototype of getaddrinfo(). The observation that specifying the pair of name and service would suffice for connecting to a service independent of protocol details was made by Marshall Rose in a proposal to X/Open for a "Uniform Network Interface". Craig Metz made many contributions to this document. Ramesh Govindan made a number of contributions and co-authored an earlier version of this memo. 11. References [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Internet Draft, , November | 1997. | [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", Internet Draft, , January | 1998. | [3] D. McDonald, "A Simple IP Security API Extension to BSD Sockets", Internet-Draft, , March | 1997. | [4] C. Metz, "Network Security API for Sockets", Internet-Draft, | draft-ietf-ipngwg-bsd-api-new-02.txt [Page 38] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 , January 1998. | [5] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT | 6.6, March 1997. | [6] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", RFC 2292, | February 1998. | [7] | P. Vixie, "Reverse Name Lookups of Encapsulated IPv4 Addresses in IPv6", Internet-Draft, , May 1996. 12. Authors' Addresses Robert E. Gilligan FreeGate Corporation | 1208 E. Arques Ave. | Sunnyvale, CA 94086 Phone: +1 408 617 1004 | Email: gilligan@freegate.net Susan Thomson Bell Communications Research MRE 2P-343, 445 South Street Morristown, NJ 07960 Telephone: +1 201 829 4514 Email: set@thumper.bellcore.com Jim Bound Compaq Computer Corporation | 110 Spitbrook Road ZK3-3/U14 Nashua, NH 03062-2698 Phone: +1 603 881 0400 Email: bound@zk3.dec.com W. Richard Stevens 1202 E. Paseo del Zorro Tucson, AZ 85718-2826 Phone: +1 520 297 9416 Email: rstevens@kohala.com draft-ietf-ipngwg-bsd-api-new-02.txt [Page 39] INTERNET-DRAFT IPv6 Socket Interface Extensions August 14, 1998 draft-ietf-ipngwg-bsd-api-new-02.txt [Page 40] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 11:21:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA06670 for ipng-dist; Fri, 14 Aug 1998 11:12:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA06663 for ; Fri, 14 Aug 1998 11:11:54 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA23135 for ; Fri, 14 Aug 1998 11:11:48 -0700 Received: from mail.gto.net.om (om2.gto.net.om [206.49.101.40]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA24675 for ; Fri, 14 Aug 1998 11:11:34 -0700 (PDT) Received: from default(really [209.58.12.202]) by mail.gto.net.om via sendmail with esmtp id for ; Fri, 14 Aug 1998 22:08:03 +0400 (OMAN) (Smail-3.2 1996-Jul-4 #7 built 1997-Oct-7) Message-ID: <35D47EA8.7F2F03EA@gto.net.om> Date: Fri, 14 Aug 1998 22:15:07 +0400 From: Peter Dawson X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: "Raghu V.V.J Vadapalli" CC: ipng Subject: (IPng 6174) Re: Reg: PATH MTU discovery X-Priority: 3 (Normal) References: <19980814154527.28174.rocketmail@send103.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu I have not gone thru RFC 1191..however jsut a quick question :) Are you suggesting that the MTU path discovery be similar to the ATM ? the 'onepass' call setup.... with the dest. ...responding with the MTU ?? If so.. this in turn, may affect the connection routing -- i.e limited. /Pete Raghu V.V.J Vadapalli wrote: > Dear All.. > > I was going through IPv6 PATH MTU discovery. > > Path MTU discovery involves no. of iterations. Right!! > > Why don't we use some mechanism for MTU discovery > as following. > > Whenever a node wants to find the PATH MTU > for a path between A and B. > Then A sends a packet which will collect the > minimum of all the MTU. When the destination > receives this DISCOVERY packet it sends it back to the > source node A. What's wrong with this method. Just I > want to clarify myself. > > Thanks in advance > -Raghu. > > _________________________________________________________ > DO YOU YAHOO!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > ----------------------------- > -------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 14:05:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA06789 for ipng-dist; Fri, 14 Aug 1998 13:53:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA06782 for ; Fri, 14 Aug 1998 13:52:56 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14478 for ; Fri, 14 Aug 1998 13:52:54 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA21123 for ; Fri, 14 Aug 1998 13:52:54 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 14 Aug 1998 13:52:50 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF07222856@RED-MSG-52> From: Brian Zill To: "'Peter Dawson'" , "Raghu V.V.J Vadapalli" Cc: ipng Subject: (IPng 6175) Re: Reg: PATH MTU discovery Date: Fri, 14 Aug 1998 13:52:48 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu's suggestion makes some sense to me. I was always surprised that IPv4 didn't do it this way, but assumed that it was because of required compatibility with the existing IPv4 infrastructure (something we have the luxury of not having to deal with for v6). Here's the proposal as I see it: Instead of iteratively sending out packets with successively smaller MTUs until one gets through (where each smaller MTU comes out of a Packet Too Big message sent by the current choke point), you would instead send one packet with the guaranteed-to-work MTU and a new hop-by-hop option. This hop-by-hop option would contain the MTU you'd like to use. Each router would look at it and lower it if it was larger than the next hop MTU. The node on the far end would send the final result back to you via a destination option. This gives you the path MTU in a single roundtrip with no dropped packets. You'd still want to re-probe every X minutes like with RFC-1981 PMTU discovery, but unlike that method, you wouldn't risk dropping packets on re-probe (since you're not actually raising your MTU, you're just adding the hop-by-hop option). The other obvious advantage is that you don't have this iterative dropping of packets going on, you can keep sending with the minimum MTU until you get the option data back. Of course, you'd also need to re-probe if you ever get a Packet Too Big message, but that's easy. Is there a reason why Path MTU discovery wasn't spec'd this way? It seems the obvious way to do it given the v6 mechanisms. If this is just because it was done that way in v4 (and v4 was hamstrung by its limited mechanisms), than I think we should fix it. --Brian > -----Original Message----- > From: Peter Dawson [SMTP:peterdd@gto.net.om] > Sent: Friday, August 14, 1998 11:15 AM > To: Raghu V.V.J Vadapalli > Cc: ipng > Subject: (IPng 6174) Re: Reg: PATH MTU discovery > > Raghu > > I have not gone thru RFC 1191..however jsut a quick question :) > > Are you suggesting that the MTU path discovery be similar to the > ATM ? the > 'onepass' call setup.... with the dest. ...responding with the > MTU ?? If so.. this in turn, may > affect the connection routing -- i.e limited. > > > /Pete > > Raghu V.V.J Vadapalli wrote: > > > Dear All.. > > > > I was going through IPv6 PATH MTU discovery. > > > > Path MTU discovery involves no. of iterations. Right!! > > > > Why don't we use some mechanism for MTU discovery > > as following. > > > > Whenever a node wants to find the PATH MTU > > for a path between A and B. > > Then A sends a packet which will collect the > > minimum of all the MTU. When the destination > > receives this DISCOVERY packet it sends it back to the > > source node A. What's wrong with this method. Just I > > want to clarify myself. > > > > Thanks in advance > > -Raghu. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 14:32:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA06862 for ipng-dist; Fri, 14 Aug 1998 14:19:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA06855 for ; Fri, 14 Aug 1998 14:19:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA23125 for ; Fri, 14 Aug 1998 14:19:44 -0700 Received: from mail.hq.tellabs.com (tlab-138-111-160-101.tellabs.com [138.111.160.101]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA09999 for ; Fri, 14 Aug 1998 14:19:43 -0700 (PDT) Received: from tellabs.com ([138.111.39.131] (may be forged)) by mail.hq.tellabs.com (8.8.6/8.8.6) with ESMTP id QAA08663; Fri, 14 Aug 1998 16:19:32 -0500 (CDT) Message-ID: <35D4ABAA.56E7A76C@tellabs.com> Date: Fri, 14 Aug 1998 17:27:06 -0400 From: Raghu Vadapalli Organization: Tellabs Inc, Hawthorne X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: bzill@microsoft.com CC: peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com Subject: (IPng 6176) Re: Reg: PATH MTU discovery References: <4FD6422BE942D111908D00805F3158DF07222856@RED-MSG-52> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is what exactly I want!!! Thanks -Raghu. bzill@microsoft.com wrote: > Raghu's suggestion makes some sense to me. I was always surprised that IPv4 > didn't do it this way, but assumed that it was because of required > compatibility with the existing IPv4 infrastructure (something we have the > luxury of not having to deal with for v6). > > Here's the proposal as I see it: Instead of iteratively sending out packets > with successively smaller MTUs until one gets through (where each smaller > MTU comes out of a Packet Too Big message sent by the current choke point), > you would instead send one packet with the guaranteed-to-work MTU and a new > hop-by-hop option. This hop-by-hop option would contain the MTU you'd like > to use. Each router would look at it and lower it if it was larger than the > next hop MTU. The node on the far end would send the final result back to > you via a destination option. This gives you the path MTU in a single > roundtrip with no dropped packets. > > You'd still want to re-probe every X minutes like with RFC-1981 PMTU > discovery, but unlike that method, you wouldn't risk dropping packets on > re-probe (since you're not actually raising your MTU, you're just adding the > hop-by-hop option). The other obvious advantage is that you don't have this > iterative dropping of packets going on, you can keep sending with the > minimum MTU until you get the option data back. > > Of course, you'd also need to re-probe if you ever get a Packet Too Big > message, but that's easy. > > Is there a reason why Path MTU discovery wasn't spec'd this way? It seems > the obvious way to do it given the v6 mechanisms. If this is just because > it was done that way in v4 (and v4 was hamstrung by its limited mechanisms), > than I think we should fix it. > > --Brian > > > -----Original Message----- > > From: Peter Dawson [SMTP:peterdd@gto.net.om] > > Sent: Friday, August 14, 1998 11:15 AM > > To: Raghu V.V.J Vadapalli > > Cc: ipng > > Subject: (IPng 6174) Re: Reg: PATH MTU discovery > > > > Raghu > > > > I have not gone thru RFC 1191..however jsut a quick question :) > > > > Are you suggesting that the MTU path discovery be similar to the > > ATM ? the > > 'onepass' call setup.... with the dest. ...responding with the > > MTU ?? If so.. this in turn, may > > affect the connection routing -- i.e limited. > > > > > > /Pete > > > > Raghu V.V.J Vadapalli wrote: > > > > > Dear All.. > > > > > > I was going through IPv6 PATH MTU discovery. > > > > > > Path MTU discovery involves no. of iterations. Right!! > > > > > > Why don't we use some mechanism for MTU discovery > > > as following. > > > > > > Whenever a node wants to find the PATH MTU > > > for a path between A and B. > > > Then A sends a packet which will collect the > > > minimum of all the MTU. When the destination > > > receives this DISCOVERY packet it sends it back to the > > > source node A. What's wrong with this method. Just I > > > want to clarify myself. > > > > > > Thanks in advance > > > -Raghu. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 15:50:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA07036 for ipng-dist; Fri, 14 Aug 1998 15:37:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA07025 for ; Fri, 14 Aug 1998 15:36:59 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA19840 for ; Fri, 14 Aug 1998 15:36:57 -0700 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by earth.sun.com (8.9.1/8.9.1) with SMTP id PAA27752 for ; Fri, 14 Aug 1998 15:36:55 -0700 (PDT) Received: from research.att.com ([135.207.30.100]) by rumor; Fri Aug 14 18:30:14 EDT 1998 Received: from postal.research.att.com ([135.207.23.30]) by research; Fri Aug 14 18:34:15 EDT 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id SAA04915; Fri, 14 Aug 1998 18:34:14 -0400 (EDT) Message-Id: <199808142234.SAA04915@postal.research.att.com> To: Raghu Vadapalli cc: bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com Subject: (IPng 6177) Re: Reg: PATH MTU discovery Date: Fri, 14 Aug 1998 18:34:13 -0400 From: Steve Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <35D4ABAA.56E7A76C@tellabs.com>, Raghu Vadapalli writes: > > > > Here's the proposal as I see it: Instead of iteratively sending out packets > > with successively smaller MTUs until one gets through (where each smaller > > MTU comes out of a Packet Too Big message sent by the current choke point), > > you would instead send one packet with the guaranteed-to-work MTU and a new > > hop-by-hop option. This hop-by-hop option would contain the MTU you'd like > > to use. Each router would look at it and lower it if it was larger than th > e > > next hop MTU. The node on the far end would send the final result back to > > you via a destination option. This gives you the path MTU in a single > > roundtrip with no dropped packets. ... > > Is there a reason why Path MTU discovery wasn't spec'd this way? It seems > > the obvious way to do it given the v6 mechanisms. If this is just because > > it was done that way in v4 (and v4 was hamstrung by its limited mechanisms), > > than I think we should fix it. The problem with that idea is that it puts a large load on the routers -- they have to examine many packets a lot more closely. And for short connections -- the large majority -- you'd be sending such packets (and hence examining them) for a substantial fraction of the packets sent. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 16:42:53 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA07190 for ipng-dist; Fri, 14 Aug 1998 16:28:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA07183 for ; Fri, 14 Aug 1998 16:28:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA02079 for ; Fri, 14 Aug 1998 16:28:18 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA21846 for ; Fri, 14 Aug 1998 16:28:10 -0700 (PDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id MAA28635; Fri, 14 Aug 1998 12:57:41 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5) id QAA05901; Fri, 14 Aug 1998 16:28:06 -0700 (PDT) From: Vivek Kashyap Message-Id: <199808142328.QAA05901@eng4.sequent.com> Subject: (IPng 6178) Re: Reg: PATH MTU discovery To: smb@research.att.com (Steve Bellovin) Date: Fri, 14 Aug 1998 16:28:05 -0700 (PDT) Cc: raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: <199808142234.SAA04915@postal.research.att.com> from "Steve Bellovin" at Aug 14, 98 06:34:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Is there a reason why Path MTU discovery wasn't spec'd this way? It seems > > > the obvious way to do it given the v6 mechanisms. If this is just because > > > it was done that way in v4 (and v4 was hamstrung by its limited mechanisms), > > > than I think we should fix it. > > The problem with that idea is that it puts a large load on the routers -- > they have to examine many packets a lot more closely. And for short > connections -- the large majority -- you'd be sending such packets (and > hence examining them) for a substantial fraction of the packets sent. I have suggested some changes to the path MTU discovery process. Attached is the suggestion and the comments of IPng working group. If the changes suggested (see below) interest you please send email to me. I'll setup a separate mailing list if there is interest in this topic. Thanks Vivek viv@sequent.com Below is the response from iesg chairs and the suggested changes. ----------------------------------------------------------------------------- Vivek, This is a response to your message to the IESG dated 18 May 1998 (appended below) requesting modification of the Path MTU Discovery specification for IPv6. We apologize for the long delay in responding to your message. What you propose is an interesting extension to PMTU Discovery, but we believe it is premature to conclude that it is an unqualified improvement to the current specification, and since your changes could be introduced in a backwards-compatible manner, it certainly does not warrant delaying the advancement of the current IPv6 specs to Draft Standard status. The current PMTU Discovery spec for IPv6 is based on existing practice with IPv4, which is widely implemented and works "OK". The changes you propose would have some benefits in some cases, but would also come at the cost of significant additional complexity in all hosts and router implementations. There are also some open issues, as you identified in your message, whose resolution would appear to lead to even more complexity (which in turn increases the probability of implementation bugs). The current spec, though not optimal in all cases, is simple, robust, and well tested. Finally, there may well be other reasons for hosts to maintain cached state for all individual destinations to which they recently sent packets (such as a cache of the discovered round-trip times, to benefit subsequent connections), which would negate any benefit of your proposed changes to PMTU Discovery. We think your proposal deserves further study and wider review, to gain confidence that it works correctly in all cases and that its implementation complexity is worth its benefits, and to see if enough people are convinced that the proposed changes are worth recommending. Since the proposal applies to both IPv4 and IPv6, we don't think the IPng working group is the best place to do that work. We suggest that you start up a mailing list, or perhaps try organizing a BOF on that topic at an upcoming IETF meeting, to measure how much interest there would be in pursuing your proposal and to help flush out any other problems/issues that you have not already identified. With respect to backwards compatibility with the current PMTU Discovery specifications and implementations, you have assumed that current implementations of IPv6 will ignore non-zero values in the Code field of the Packet Too Big ICMP message. Looking at the ICMPv6 spec, we see that we did not explicitly specify that non-zero Code values should be ignored in Packet Too Big messages, so we should clarify the spec to make that explicit, and will do so now. Thank-you for (indirectly) pointing out that ambiguity in the spec. Steve Deering & Bob Hinden Co-chairs of the IPng Working Group -------- > > Suggest change in Path MTU Discovery for IPv6: > > > With the current specification of Datagram too Big and Path > MTU Discovery (RFC 1981) the source host gets to know that > there is a bottleneck in the path somewhere. It cannot > aggregate this information to share with other connections > (unless they are to the same destination). Thus the source > host has to cache the path information on a per host basis. > Any representation for the path may be used but in all the > current implementations (that I am aware of) of Path MTU > discovery the path information is kept as a routing table > entry. The receipt of a Datagram Too Big message causes a > routing table entry to be created for the destination host. > > Any reduction in this table size reduces the resources > utilized to keep this information and in searching through the > large routing table. > > > I would like to suggest some modifications to achieve : > > . Aggregation of paths having the same PMTU > > . Reduction in resources utilized to store the Path MTU > > . Speed up in the MTU updates to all connections on a host > rather than each discovering it independently. > > . On deletion of a network route on the host, each of the > derived routes/paths has to be deleted too. With the > reduction in the number of such caches it would take less > time and simpler algorithms can be used. > > . utilities need to list a smaller set of routes. eg. > netstat. > > . routing protocols need to exchange smaller tables and/or not > weed through a large set of derived routes. > > > > Consider the following: > > Currently the end host receives a DTB message for > every host that lies beyond a particular router which > has the link that determines the path MTU. This > information, instead of being shared, is rediscovered > when a connection is made to any host beyond the > router. With servers which can have 1000s of > simultaneous connections any such bottleneck has the > potential of having 100s or 1000s per host path MTU > routes being kept. Furthermore, each of these 'routes' > will test the path for increases every 10 minutes > (default value) even if they had the same router's > outgoing link as the bottleneck. > > A trivial example is a server that happens to be > 'behind' a router that has a lower MTU on one of its > interfaces. If a large part of the cleintelle happens > to pass through that router, the server will end > up having a huge number of routes. > > If all this information could be consolidated in a > single 'route' that would cause the packets to go > through the bottleneck router, the end host would have > to keep only one route and only one packet would be > transmitted every 10 minutes. In essence a small set > of 'net routes' could replace the large number of > per host entries. > > > A slight modification (keeping the format still > compatible to the current one) to the Datagram too > Big, ICMP message can allow the router to send back > the prefix length of the route the router used to > determine the outgoing interface. This information can > then be used by the end host to create a 'net route' > instead of a host route. I have detailed this in the > draft : draft-kashyap-too-big-00.txt > > > However, two situations not covered in the above draft are : > > > (a) H -- R1 -- R2 ----R3 ----- > | > | > |------ > > At R2 there can be two route entries leading to the same > net but with one being more specific that the other. > i.e. the entries could be of the form: > > . A:B:C/48 > . A:B:C:D/64 > > MTU > (b) H --.... R1 --------- R2 --------- R3---- > A:B:C:D A:B: > > At R1 the packet used the more precise route but at the > router R2, which has a smaller mtu, the route entry has > a more general path. > > These topologies are not always a problem but may cause > situations when the correct MTU may not be detected by the > approach in the draft. > > The above two situations can be handled in the following way: > > A. A router always marks entries that have the relationship > as in (a). This is not difficult and can be done when > the route is added. > > > B. Define a hop-by-hop IP option (say P1) that specifies the > lenght of the prefix used by the host. This would be > used sparingly as detailed below. > A router replies to the host with an ICMP error message in the > following three situations: > > 1. The datagram is too big to sent out the interface (the > standard Datagram too big situation). > > 2. If the situation as in (a) exists. It replies with the > prefix length of the shorter route entry. (possibly a > different message or code can be defined). The router > determines this if the route it is using to send the > datagram is marked. > > 3. If situation as in (b) exists. If the prefix length of > in P1 is shorter than the route prefix in the route > to be used to forward the datagram. > > > > A host sends the P1 packet only when it needs to probe the > route. It need be configured to use the probe packet only if > it ever receives a Datagram too big packet ie. the probe > packets are sent only if a bottleneck has been found. > > > > A host creates (derives a more specific route) a route if it > receives ICMP errors of the above three types: > > 1. Datagram too Big > > The modified DTB message gives the prefix length. The > new route is constructed with the prefix length of > bits taken from the peer's address. See > draft-kashyap-too-big-00.txt for details. > > > 2. On receiving the error as defined in 2 or 3. above, the > host creates a route based on the prefix lenght received. > The route is constructed as in the case above except that > route is marked to indicate the situation as in (a) or (b). > Henceforth the path MTU discovery on this route occurs on a > per host basis. No more probe packets of type P1 are sent > on this path. > > > > The above is only an outline. It certainly can be improved. I > believe this approach will have the benefit of keeping the > host resources more manageable and also generate lesser number > of packets overall. > > Furthermore, depending on the factors that are important for a site, > the administrators can determine the 'type' of path MTU best for > them on the following lines: > > > RT_PMTU_DEFAULT: > as defined in the draft draft-kashyap-too-big-00.txt. > In an intranet for eg. the adminstrator may not care abou the > situations described above and may choose the simple approach > as defined in the draft. In an intranet, the administrators > can take care not to let situations as above arise. > > RT_PMTU_NET: > > The complete solution as outlined in this maii. > > RT_PMTU_HOST: > > Per host Path MTU as currently defined in RFC 1981 > > RT_PMTU_CONNECTION: > > If an application needs/wants to determine the path > MTU discovery. It may record it in the connection or > create 'host/net' routes. > > > > > Vivek Vivek -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 17:00:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA07290 for ipng-dist; Fri, 14 Aug 1998 16:44:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA07279 for ; Fri, 14 Aug 1998 16:44:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA06328 for ; Fri, 14 Aug 1998 16:44:35 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA28155 for ; Fri, 14 Aug 1998 16:44:36 -0700 (PDT) From: Masataka Ohta Message-Id: <199808142334.IAA00450@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA00450; Sat, 15 Aug 1998 08:34:22 +0900 Subject: (IPng 6179) Re: Reg: PATH MTU discovery To: smb@research.att.com (Steve Bellovin) Date: Sat, 15 Aug 98 8:34:21 JST Cc: raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: <199808142234.SAA04915@postal.research.att.com>; from "Steve Bellovin" at Aug 14, 98 6:34 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > The problem with that idea is that it puts a large load on the routers -- > they have to examine many packets a lot more closely. Right. However, when a router detect a packet larger than the link MTU, it puts the same large load on the router. > And for short > connections -- the large majority -- you'd be sending such packets (and > hence examining them) for a substantial fraction of the packets sent. For the short connection, you'd be sending failed PMTUD packets for a substantial fraction of the packets sent. Or, if the connection is extremely short, there will be no MTU discovery from the beginning. That is, PMTUD is a bad thing to do. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 17:12:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA07359 for ipng-dist; Fri, 14 Aug 1998 16:55:20 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id QAA07334 for ; Fri, 14 Aug 1998 16:54:45 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with SMTP id QAA20909; Fri, 14 Aug 1998 16:54:39 -0700 (PDT) Date: Fri, 14 Aug 1998 16:54:39 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6180) Re: Reg: PATH MTU discovery To: Brian Zill Cc: "'Peter Dawson'" , "Raghu V.V.J Vadapalli" , ipng In-Reply-To: "Your message with ID" <4FD6422BE942D111908D00805F3158DF07222856@RED-MSG-52> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Here's the proposal as I see it: Instead of iteratively sending out packets > with successively smaller MTUs until one gets through (where each smaller > MTU comes out of a Packet Too Big message sent by the current choke point), > you would instead send one packet with the guaranteed-to-work MTU and a new > hop-by-hop option. This hop-by-hop option would contain the MTU you'd like > to use. Each router would look at it and lower it if it was larger than the > next hop MTU. The node on the far end would send the final result back to > you via a destination option. This gives you the path MTU in a single > roundtrip with no dropped packets. A few comments: RFC 1981 supports multicast and I can't see how your proposal would do that without a potential implosion of "discovery responses". Adding one roundtrip to the start of each connection would be very expensive for short-lived connections. In fact RFC 1981 optimizes for what is likely to be a common case: the inteface MTU is smaller or equal to the path MTU. In this case there is no overhead for path MTU determination. Your proposal always incurs a constant overhead. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 17:13:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA07406 for ipng-dist; Fri, 14 Aug 1998 17:05:58 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA07398 for ; Fri, 14 Aug 1998 17:05:33 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with SMTP id RAA22246; Fri, 14 Aug 1998 17:05:32 -0700 (PDT) Date: Fri, 14 Aug 1998 17:05:32 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6181) Re: Reg: PATH MTU discovery To: Vivek Kashyap Cc: Steve Bellovin , raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808142328.QAA05901@eng4.sequent.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 suggested some changes to the path MTU discovery process. > Attached is the suggestion and the comments of IPng working group. Your proposal (adding a prefix length to the Packet Too Big message) adds the possibility of more powerful denial/degradation of service attacks. Today a forged Packet Too Big can be used to degrade the path MTU to a "small" value (1280 in IPv6 - some day that might be a small MTU but certainly isn't today) for a *single* destination. Adding the prefix length allows a forged Packet Too Big to decrease the mtu for all destinations - just set the prefix length to a value less that 4 bits. That might be a bad tradeoff. Note that even when using IPsec in its strictest form (requiring that all ICMP Packet Too Big message use IPsec i.e. all the routers can set up security associations) it would not be possible to determine whether or not the router has the authority to decrement the path MTU for a given prefix. (We assume it has authority to decrement the path MTU for the destination since the routing system forwarded the packet to it - but that doesn't mean that it can "speak" for any prefix). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 17:43:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA07580 for ipng-dist; Fri, 14 Aug 1998 17:28:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA07556 for ; Fri, 14 Aug 1998 17:27:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA16872 for ; Fri, 14 Aug 1998 17:27:39 -0700 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA15002 for ; Fri, 14 Aug 1998 17:27:40 -0700 (PDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 14 Aug 1998 17:27:39 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF07222858@RED-MSG-52> From: Brian Zill To: "'Erik Nordmark'" Cc: ipng Subject: (IPng 6182) Re: Reg: PATH MTU discovery Date: Fri, 14 Aug 1998 17:27:38 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > RFC 1981 supports multicast and I can't see how your proposal would do > that > without a potential implosion of "discovery responses". > Good point. > Adding one roundtrip to the start of each connection would be very > expensive for short-lived connections. > No, no extra roundtrip for connection-orientated protocols. For TCP, the initial SYN could carry the hop-by-hop, the returning SYN-ACK the destination option. You'd probably already know the path MTU by the time you sent any data, but it'd still work even if you sent data with the original SYN. It doesn't matter when in the packet stream you do this exchange, you can always send packets at the minimum MTU in the meantime. For non-connection protocols, you wouldn't have an ACK to piggyback on, so it could generate extra traffic. Of course, this is bounded to one extra packet (the destination option), while RFC-1981 is bounded to N extra packets (worst case of one Packet Too Big per router along the path). > In fact RFC 1981 optimizes for what is likely to be a common case: > the inteface MTU is smaller or equal to the path MTU. In this case > there is no overhead for path MTU determination. Your proposal > always incurs a constant overhead. > This is true, and is a variation of Steve Bellovin's (valid) criticism. It all comes down to whether you expect most large MTU packets to make it all the way through. RFC-1981 is optimistic (and gets really bad in the worst case), this proposal is pessimistic (and has constant overhead). If everyone agrees with you as to what the "common case" is, then I agree that it's probably best to leave things as they are. My concern was 1981's bad worst case. > Erik > Thanks for the input, --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 17:43:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA07581 for ipng-dist; Fri, 14 Aug 1998 17:28:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA07558 for ; Fri, 14 Aug 1998 17:27:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA16879; Fri, 14 Aug 1998 17:27:40 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA14961; Fri, 14 Aug 1998 17:27:36 -0700 (PDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id NAA04540; Fri, 14 Aug 1998 13:57:06 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5) id RAA00200; Fri, 14 Aug 1998 17:24:46 -0700 (PDT) From: Vivek Kashyap Message-Id: <199808150024.RAA00200@eng4.sequent.com> Subject: (IPng 6183) Re: Reg: PATH MTU discovery To: Erik.Nordmark@Eng Date: Fri, 14 Aug 1998 17:23:48 -0700 (PDT) Cc: viv@sequent.com, smb@research.att.com, raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Erik Nordmark" at Aug 14, 98 05:05:32 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > > I have suggested some changes to the path MTU discovery process. > > Attached is the suggestion and the comments of IPng working group. > > Your proposal (adding a prefix length to the Packet Too Big message) > adds the possibility of more powerful denial/degradation of service > attacks. > > Today a forged Packet Too Big can be used to degrade the > path MTU to a "small" value (1280 in IPv6 - some day that might be a small > MTU but certainly isn't today) for a *single* destination. > > Adding the prefix length allows a forged Packet Too Big to decrease > the mtu for all destinations - just set the prefix length to a value less > that 4 bits. > That might be a bad tradeoff. This might not be the case. Quoting from the the draft : ********** 5. Security considerations If the Datagram Too Big message returns a more general route than was used by the host, the indication is taken equivalent to the host route mask. This blocks the host from being fed faulty network information. The host may however be sent Datagram Too Big messages indicating the default route. The end host will end up creating host routes instead of subnet routes. This is no different from what happens now. A code that indicates a more precise route does not have any effect on theflow of data or the path MTU information related to the path. *********** There might be some other cases that are not covered and I would certainly like to discuss those. Vivek > > Note that even when using IPsec in its strictest form (requiring that all > ICMP Packet Too Big message use IPsec i.e. all the routers can set up > security associations) it would not be possible to determine whether or > not the router has the authority to decrement the path MTU for a given > prefix. (We assume it has authority to decrement the path MTU for > the destination since the routing system forwarded the packet to it - but > that doesn't mean that it can "speak" for any prefix). > > Erik > > -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 17:46:19 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA07638 for ipng-dist; Fri, 14 Aug 1998 17:37:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA07631 for ; Fri, 14 Aug 1998 17:36:56 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA18420 for ; Fri, 14 Aug 1998 17:36:55 -0700 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by earth.sun.com (8.9.1/8.9.1) with SMTP id RAA18186 for ; Fri, 14 Aug 1998 17:36:55 -0700 (PDT) Received: from research.att.com ([135.207.30.100]) by rumor; Fri Aug 14 20:30:14 EDT 1998 Received: from postal.research.att.com ([135.207.23.30]) by research; Fri Aug 14 20:34:16 EDT 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id UAA05956; Fri, 14 Aug 1998 20:34:15 -0400 (EDT) Message-Id: <199808150034.UAA05956@postal.research.att.com> To: Masataka Ohta cc: raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com Subject: (IPng 6184) Re: Reg: PATH MTU discovery Date: Fri, 14 Aug 1998 20:34:15 -0400 From: Steve Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808142334.IAA00450@necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites: > Steve; > > > The problem with that idea is that it puts a large load on the routers -- > > they have to examine many packets a lot more closely. > > Right. However, when a router detect a packet larger than the > link MTU, it puts the same large load on the router. Only if the packet is indeed larger than the link MTU. Today, that's not very common, for two reasons. First, by far the most common MTU on the sending host is 1500 bytes, the Ethernet maximum. Most serial links are configured to accept packets of that size, too, so they have no problem. Some hosts are FDDI-attached, and send ~4K byte packets; those trigger PMTU at the first border router to a net with a smaller MTU. And that brings up the second reason -- once a router has responded in that fashion, none of the other routers along the path need to react. With this proposal, all routers would have to react to the initial packet, regardless of size. > > > And for short > > connections -- the large majority -- you'd be sending such packets (and > > hence examining them) for a substantial fraction of the packets sent. > > For the short connection, you'd be sending failed PMTUD packets for > a substantial fraction of the packets sent. Or, if the connection is > extremely short, there will be no MTU discovery from the beginning. Since the kernel doesn't know that a new connection will be very short, it will send the discovery header all the time regardless. > > That is, PMTUD is a bad thing to do. I won't argue that point -- I'm uncertain of it myself. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 20:15:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA07789 for ipng-dist; Fri, 14 Aug 1998 20:06:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA07782 for ; Fri, 14 Aug 1998 20:05:57 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA06039 for ; Fri, 14 Aug 1998 20:05:57 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA02278 for ; Fri, 14 Aug 1998 20:05:52 -0700 (PDT) From: Masataka Ohta Message-Id: <199808150256.LAA00855@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA00855; Sat, 15 Aug 1998 11:55:45 +0859 Subject: (IPng 6185) Re: Reg: PATH MTU discovery To: smb@research.att.com (Steve Bellovin) Date: Sat, 15 Aug 98 11:55:44 JST Cc: mohta@necom830.hpcl.titech.ac.jp, raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: <199808150034.UAA05956@postal.research.att.com>; from "Steve Bellovin" at Aug 14, 98 8:34 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > > > The problem with that idea is that it puts a large load on the routers -- > > > they have to examine many packets a lot more closely. > > > > Right. However, when a router detect a packet larger than the > > link MTU, it puts the same large load on the router. > > Only if the packet is indeed larger than the link MTU. Today, > that's not very common, for two reasons. > > First, by far the most common MTU on the sending host is 1500 bytes, > the Ethernet maximum. Most serial links are configured to accept > packets of that size, too, so they have no problem. Here, you are saying that PMTUD not useful. > Some hosts are > FDDI-attached, and send ~4K byte packets; those trigger PMTU at the > first border router to a net with a smaller MTU. And, as the smaller MTU would be 1500, PMTUD is not necessary from the beginning. > And that brings up the > second reason -- once a router has responded in that fashion, none of > the other routers along the path need to react. With this proposal, > all routers would have to react to the initial packet, regardless of > size. If the minimum MTU field of the initial packet is initially set to the MTU of the outgoing interface, that is, almost always 1500, most routers along the path does not have to react, either. > > > And for short > > > connections -- the large majority -- you'd be sending such packets (and > > > hence examining them) for a substantial fraction of the packets sent. > > > > For the short connection, you'd be sending failed PMTUD packets for > > a substantial fraction of the packets sent. Or, if the connection is > > extremely short, there will be no MTU discovery from the beginning. > > Since the kernel doesn't know that a new connection will be very short, > it will send the discovery header all the time regardless. The kernel can be tuned to send it only after the connection is likely to need MTU larger than 1280, at which time PMTUD is almost certainly about to generate an ICMP error. > > That is, PMTUD is a bad thing to do. > > I won't argue that point -- I'm uncertain of it myself. My point is that your critics to the new proposal is equally applicable to PMTUD. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 20:19:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA07799 for ipng-dist; Fri, 14 Aug 1998 20:13:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA07792 for ; Fri, 14 Aug 1998 20:12:55 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA06554 for ; Fri, 14 Aug 1998 20:12:55 -0700 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by earth.sun.com (8.9.1/8.9.1) with SMTP id UAA04049 for ; Fri, 14 Aug 1998 20:12:55 -0700 (PDT) Received: from research.att.com ([135.207.30.100]) by rumor; Fri Aug 14 23:06:13 EDT 1998 Received: from postal.research.att.com ([135.207.23.30]) by research; Fri Aug 14 23:10:59 EDT 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id XAA07129; Fri, 14 Aug 1998 23:10:58 -0400 (EDT) Message-Id: <199808150310.XAA07129@postal.research.att.com> To: Masataka Ohta cc: raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com Subject: (IPng 6186) Re: Reg: PATH MTU discovery Date: Fri, 14 Aug 1998 23:10:58 -0400 From: Steve Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808150256.LAA00855@necom830.hpcl.titech.ac.jp>, Masataka Ohta wr ites: > Steve; > > > First, by far the most common MTU on the sending host is 1500 bytes, > > the Ethernet maximum. Most serial links are configured to accept > > packets of that size, too, so they have no problem. > > Here, you are saying that PMTUD not useful. > > > Some hosts are > > FDDI-attached, and send ~4K byte packets; those trigger PMTU at the > > first border router to a net with a smaller MTU. > > And, as the smaller MTU would be 1500, PMTUD is not necessary from the > beginning. > > > And that brings up the > > second reason -- once a router has responded in that fashion, none of > > the other routers along the path need to react. With this proposal, > > all routers would have to react to the initial packet, regardless of > > size. > > If the minimum MTU field of the initial packet is initially > set to the MTU of the outgoing interface, that is, almost always > 1500, most routers along the path does not have to react, either. > > > Since the kernel doesn't know that a new connection will be very short, > > it will send the discovery header all the time regardless. > > The kernel can be tuned to send it only after the connection is > likely to need MTU larger than 1280, at which time PMTUD is > almost certainly about to generate an ICMP error. > > > > That is, PMTUD is a bad thing to do. > > > > I won't argue that point -- I'm uncertain of it myself. > > My point is that your critics to the new proposal is equally > applicable to PMTUD. I'm not a fan of PMTU; as I said, I'm unsure of its utility, especially for IPv6 with a larger minimum MTU. But the killer problem with this scheme is that it creates something important and common that would bog down every router on the path. That's not acceptable engineering, in my book. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 14 23:38:19 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA07944 for ipng-dist; Fri, 14 Aug 1998 23:27:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA07937 for ; Fri, 14 Aug 1998 23:27:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA21874 for ; Fri, 14 Aug 1998 23:27:13 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA18188 for ; Fri, 14 Aug 1998 23:27:14 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 14 Aug 1998 23:27:14 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF07222859@RED-MSG-52> From: Brian Zill To: "'Steve Bellovin'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6187) Re: Reg: PATH MTU discovery Date: Fri, 14 Aug 1998 23:27:12 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, et. al., I don't want to argue strongly for this proposal, because I'm unconvinced it's a great idea. However, I don't think it's as bad as some are making it out to be. Specifically, > But the killer problem with > this scheme is that it creates something important and common > that would bog down every router on the path. > Every IPv4 router today, for every packet, must decrement the hop count, compare it to zero, and fix up the checksum. Now one of the plusses of IPv6 is that they don't have to do that anymore. But clearly it's within the realm of engineering capability. And it's not clear to me that looking at a field in a hop-by-hop option, comparing it to the outgoing MTU (a value the router has close at hand anyhow since it has to check it against the packet size), and updating it when necessary, is any more work than that. In fact, since in most cases you don't have to write a field, I'd guess it's easier. And they don't have to do it for every packet either. And when it comes to the worst case, I think everyone will agree that generating a Packet Too Big message is more work for a router. As an aside, if folks are worried about doing PMTU discovery for short-lived connections, it's trivial (under either scheme) to only do it for long-lived connections. You've got this re-probe timer running anyway, just don't probe at the start -- use the minimum MTU until the timer expires. --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 Sat Aug 15 01:21:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA08009 for ipng-dist; Sat, 15 Aug 1998 01:15:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA08002 for ; Sat, 15 Aug 1998 01:15:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA00300 for ; Sat, 15 Aug 1998 01:15:45 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA10370 for ; Sat, 15 Aug 1998 01:15:45 -0700 (PDT) From: Masataka Ohta Message-Id: <199808150805.RAA01273@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA01273; Sat, 15 Aug 1998 17:05:40 +0900 Subject: (IPng 6188) Re: Reg: PATH MTU discovery To: smb@research.att.com (Steve Bellovin) Date: Sat, 15 Aug 98 17:05:39 JST Cc: mohta@necom830.hpcl.titech.ac.jp, raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: <199808150310.XAA07129@postal.research.att.com>; from "Steve Bellovin" at Aug 14, 98 11:10 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > But the killer problem with > this scheme is that it creates something important and common > that would bog down every router on the path. That's not acceptable > engineering, in my book. My point is that PMTUD is also creating the same thing that is bogging down every router on the path. > I'm not a fan of PMTU; as I said, I'm unsure of its utility, especially > for IPv6 with a larger minimum MTU. I'm sure it useless, which is why I see the increase of the minimum MTU significant change. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 15 02:26:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA08116 for ipng-dist; Sat, 15 Aug 1998 02:21:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA08109 for ; Sat, 15 Aug 1998 02:21:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA03875 for ; Sat, 15 Aug 1998 02:21:36 -0700 Received: from hotmail.com (f196.hotmail.com [207.82.251.85]) by earth.sun.com (8.9.1/8.9.1) with SMTP id CAA21542 for ; Sat, 15 Aug 1998 02:21:36 -0700 (PDT) Received: (qmail 10986 invoked by uid 0); 15 Aug 1998 09:21:35 -0000 Message-ID: <19980815092135.10985.qmail@hotmail.com> Received: from 195.67.254.243 by www.hotmail.com with HTTP; Sat, 15 Aug 1998 02:21:35 PDT X-Originating-IP: [195.67.254.243] From: "Mike Stuard" To: ipng@sunroof.eng.sun.com Subject: (IPng 6189) MTU info into routers Content-Type: text/plain Date: Sat, 15 Aug 1998 02:21:35 PDT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why not just put the MTU information into the routingtables, at least into the edgerouters ? then this should be an issue for updating the routing protocolls. /Mike ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 15 02:56:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA08159 for ipng-dist; Sat, 15 Aug 1998 02:52:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA08152 for ; Sat, 15 Aug 1998 02:51:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA05311 for ; Sat, 15 Aug 1998 02:51:51 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA26442 for ; Sat, 15 Aug 1998 02:51:50 -0700 (PDT) From: Masataka Ohta Message-Id: <199808150942.SAA01353@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA01353; Sat, 15 Aug 1998 18:42:11 +0900 Subject: (IPng 6190) Re: MTU info into routers To: transmission65@hotmail.com (Mike Stuard) Date: Sat, 15 Aug 98 18:42:10 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <19980815092135.10985.qmail@hotmail.com>; from "Mike Stuard" at Aug 15, 98 2:21 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike; > Why not just put the MTU information into the > routingtables, at least into the edgerouters ? Because unicast routing tables are aggregated. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 15 07:08:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA08273 for ipng-dist; Sat, 15 Aug 1998 06:53:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA08266 for ; Sat, 15 Aug 1998 06:52:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA20692 for ; Sat, 15 Aug 1998 06:52:45 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA04920 for ; Sat, 15 Aug 1998 06:52:44 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA21455; Sat, 15 Aug 1998 23:52:18 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6191) Re: Reg: PATH MTU discovery In-Reply-To: Your message of "Sat, 15 Aug 1998 17:05:39 +0200." <199808150805.RAA01273@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Aug 1998 23:52:08 +1000 Message-Id: <12967.903189128@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 15 Aug 98 17:05:39 JST From: Masataka Ohta Message-ID: <199808150805.RAA01273@necom830.hpcl.titech.ac.jp> My point is that PMTUD is also creating the same thing that is bogging down every router on the path. This is not really correct. Whether or not PMTUD is done, routers need to check that they're not sending a packet bigger than the MTU of the outgoing link - just to make sure that the level 2 protocol for the link is correctly implemented. The hop by hop option method requires all routers examine the options of every packet containing the header to determine first that this is the option present, and then to validate that the value specified is within the range of the outgoing link (which also requires that hop by hop options be processed, or perhaps reprocessed, after the routing decision has been made). Since we expect that the vast majority of the time that the suggested MTU (probably 1500) will be OK, this is all work by all routers along the path for little benefit. PMTUD has the attribute that nothing special is required of a router unless the MTU of the outgoing link is exceeded, in which case the packet can't be transmitted anyway. When packets are dropped, it is generally polite to send ICMP reports indicating why (with all the obvious exceptions), so PMTUD as far as the routers are concerned really costs nothing (nothing beyond what would be being done anyway). PMTUD is generally quite cheap overall, as in most cases, the PMTU will be equal to the outgoing interface MTU, and when this is true, the whole thing is a no-op (the sending host does nothing at all unless the PMTU drops, and it receives a "too big" ICMP report). In most other cases, as has been indicated already, the choke point (or the nearest choke point) will be either on, or at the exit to, the local high speed LAN. Consequently the RTT required for the "here is this big packet" "that is too big, use this instead" exchange tends to be very low, and to be carried only over a path which will generally have plenty of available bandwidth (it is cheap to supply). And contrary to some belief, that PMTUD is not often required (apparently) because nothing in practice actually happens, does not imply that the whole thing is useless and a waste of time. While most paths will have a a PMTU of 1500, and this using 1500 octet sized packets is the optimal thing to do, we can expect occasional paths where the PMTU is just the minimum required, so we need a mechanism to detect when that happens, and cope with it while the path traverses such a link - and recover once it moves away. Further, we really would like hosts to transparently upgrade themselves in the future should the dominant PMTU rise above the current common 1500. PMTUD allows that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 15 15:05:58 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA08555 for ipng-dist; Sat, 15 Aug 1998 15:01:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA08548 for ; Sat, 15 Aug 1998 15:01:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA28095 for ; Sat, 15 Aug 1998 15:01:42 -0700 Received: from send1c.yahoomail.com (send1c.yahoomail.com [205.180.60.38]) by earth.sun.com (8.9.1/8.9.1) with SMTP id PAA07525 for ; Sat, 15 Aug 1998 15:01:43 -0700 (PDT) Message-ID: <19980815220410.17558.rocketmail@send1c.yahoomail.com> Received: from [138.111.39.131] by send1c; Sat, 15 Aug 1998 15:04:10 PDT Date: Sat, 15 Aug 1998 15:04:10 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6194) Reg: Jumbo Payload Option. To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All.. I was going through the internet draft IPv6 Jumbo Payload Option . I have one quick question. The draft says that "The Jumbo Payload option must not be used in a packet that carries a Fragment header ". Let us suppose I have a interface with MTU greater than 65535 and less than X. Let us suppose I have a packet with payload length greater than X. Then I should perform fragmentation. Right!!! .Then my IPv6 packet will have Jumpbo payload option with fragmentation header . Right!!! Is the above statement restricts this option. Thanks in advance -Raghu. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 15 15:42:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA08598 for ipng-dist; Sat, 15 Aug 1998 15:32:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA08591 for ; Sat, 15 Aug 1998 15:32:17 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA00087 for ; Sat, 15 Aug 1998 15:32:17 -0700 Received: from mail-oak-1.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA13084 for ; Sat, 15 Aug 1998 15:32:18 -0700 (PDT) Received: from msd-gw.hitachi.com (msd.hitachi.com [137.168.1.1]) by mail-oak-1.pilot.net with ESMTP id PAA15127 for ; Sat, 15 Aug 1998 15:32:18 -0700 (PDT) Received: from thunder.HICAM-MSD.Hitachi.COM (thunder [137.168.16.3]) by msd-gw.hitachi.com with ESMTP id PAA27172; Sat, 15 Aug 1998 15:31:26 -0700 (PDT) Received: from hw20.hicam-msd.hitachi.com (hw20.hicam-msd.hitachi.com [192.48.128.101]) by thunder.HICAM-MSD.Hitachi.COM with SMTP id PAA11995; Sat, 15 Aug 1998 15:31:10 -0700 (PDT) Received: from hw20 by hw20.hicam-msd.hitachi.com (SMI-8.6/SMI-SVR4) id PAA05783; Sat, 15 Aug 1998 15:30:58 -0700 Message-Id: <199808152230.PAA05783@hw20.hicam-msd.hitachi.com> Date: Sat, 15 Aug 1998 15:30:58 -0700 (PDT) From: Thomas Dineen Reply-To: Thomas Dineen Subject: (IPng 6195) Re: Reg: Jumbo Payload Option. To: ipng@sunroof.eng.sun.com Cc: thomasd@hicam-msd.hitachi.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: r8a5Ae/0NzJ0ENITgJLAHg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >> Let us suppose I have a interface with MTU greater than >> 65535 and less than X. Let us suppose I have a packet >> with payload length greater than X. Then I should >> perform fragmentation. Right!!! .Then my IPv6 >> packet will have Jumpbo payload option with >> fragmentation header . Right!!! Is the above >> statement restricts this option. So, is this a problem? How will we fix it? We could extend the Jumbo Frame Length to 64 bits. The the contents of an entire disk drive could be transmitted in one packet! Or, we could extend the Jumbo Frame Length to 128 bits. The the sum of all knowledge known by mankind could be sent in one packet! Or, we could delete the Jumbo Payload Option! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 15 16:16:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA08647 for ipng-dist; Sat, 15 Aug 1998 16:09:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA08640 for ; Sat, 15 Aug 1998 16:08:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA02123 for ; Sat, 15 Aug 1998 16:08:50 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA20323 for ; Sat, 15 Aug 1998 16:08:50 -0700 (PDT) From: Masataka Ohta Message-Id: <199808152259.HAA01775@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA01775; Sun, 16 Aug 1998 07:58:58 +0859 Subject: (IPng 6196) Re: Reg: PATH MTU discovery To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 16 Aug 98 7:58:57 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <12967.903189128@munnari.OZ.AU>; from "Robert Elz" at Aug 15, 98 11:52 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre; > The hop by hop option method requires all routers examine the options of > every packet containing the header to determine first that this is the option > present, and then to validate that the value specified is within the range of > the outgoing link (which also requires that hop by hop options be processed, > or perhaps reprocessed, after the routing decision has been made). With proper hardware implementation, it is as easy as packet size checking. > PMTUD has the attribute that nothing special is required of a router unless > the MTU of the outgoing link is exceeded, in which case the packet can't be > transmitted anyway. When packets are dropped, it is generally polite to send > ICMP reports indicating why (with all the obvious exceptions), So far, OK. > so PMTUD as far > as the routers are concerned really costs nothing (nothing beyond what would > be being done anyway). The problem of PMTUD is that it is impolite and costs a lot to periodically send packets which are almost certainly exceed the path MTU and burdens routers. > PMTUD is generally quite cheap overall, as in most cases, the PMTU will be > equal to the outgoing interface MTU, and when this is true, the whole thing > is a no-op (the sending host does nothing at all unless the PMTU drops, and > it receives a "too big" ICMP report). That is, in most cases PMTUD is not necessary. > In most other cases, as has been indicated already, the choke point (or the > nearest choke point) will be either on, or at the exit to, the local high > speed LAN. Consequently the RTT required for the "here is this big packet" > "that is too big, use this instead" exchange tends to be very low, and to > be carried only over a path which will generally have plenty of available > bandwidth (it is cheap to supply). In the LAN environment where the latency is "very low", there is no point to make the packet size large. In the LAN environment where the bandwidth is "plenty", there is no point of worrying about the header overhead. That is, even in your senario, PMTUD is useless. > And contrary to some belief, that PMTUD is not often required (apparently) > because nothing in practice actually happens, does not imply that the whole > thing is useless and a waste of time. While most paths will have a a PMTU > of 1500, and this using 1500 octet sized packets is the optimal thing to > do, we can expect occasional paths where the PMTU is just the minimum required, > so we need a mechanism to detect when that happens, and cope with it while > the path traverses such a link - and recover once it moves away. That was a valid arguement when the PMTU just the minimum required was 576. With minimum MTU of 1280, we don't need any mechanism to detect it actually is 1500. > Further, > we really would like hosts to transparently upgrade themselves in the future > should the dominant PMTU rise above the current common 1500. PMTUD allows > that. Wrong. As PMTUD is not applicable to multicast and connectionless communication, transparent upgrade is not possible and we must live with the minimum MTU of 1280. Instead, the limited applicability of PMTUD makes people not motivated to make link MTU larger than 1500. That is, the dominant PMTU will be 1500 forever (or until we must move to the second next generation IP, at least, which may be shorter than your expectation). Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 15 22:59:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA09039 for ipng-dist; Sat, 15 Aug 1998 22:54:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA09032 for ; Sat, 15 Aug 1998 22:54:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA26540 for ; Sat, 15 Aug 1998 22:54:33 -0700 Received: from saturn.wwc.edu (saturn.wwc.edu [192.147.173.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA00487 for ; Sat, 15 Aug 1998 22:54:34 -0700 (PDT) Received: from sphinx.wwc.edu (sphinx.wwc.edu [199.236.177.250]) by saturn.wwc.edu (8.9.1/8.9.1) with SMTP id WAA19239 for ; Sat, 15 Aug 1998 22:54:34 -0700 Date: Sat, 15 Aug 1998 23:01:38 -0700 (PDT) From: Jeffrey Streifling To: ipng@sunroof.eng.sun.com Subject: (IPng 6197) End-nodes and the 1500 octet reassembly buffer requirement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm new on the list, but I've been rummaging through the archived discussions of the last few months pertaining to changing the IPv6 min MTU from 576 to 1280 and I haven't found much about the 1500 octet reassembly buffer requirement. It occurred to me that if this 1500 octet requirement -- which was only 576 octets in IPv4 -- could be winched, kicking and screaming, down to match the 1280 octet minimum MTU in end-node stacks -- in contradistinction to routers that might need the elbow-room for tunneling, the "paper-path" in typical implementations could be significantly shortened, and some protocol pathologies could be eliminated. Since all the legacy protocols from IPv4 (e.g. DNS) were designed based on a 576 octet buffer reassembly size, I think it would be reasonable to hope that, even with the addition of new IPv6 specific headers, the minimum needed size would be somewhat less than 1280 octets. Therefore, programs/layers that offer packets between 1281 and 1500 octets really should be able to scale them down to fit in a possible 1280 octet PMTU. It would be silly to pass a 1500 octet packet to the IP layer when the PMTU is 1280 octets merely because the host at the other end has the room to reassemble the fragments. This behaviour may as well be prohibited. I think that support for datagram fragmentation should be made an optional part of the IPv6 standard. Clearly, it needs to be supported in nodes that do foo in IPv6 tunneling and in nodes that have applications that require the use of packets bigger than 1280 octets, but I think these are a minority, and reassembly buffers for applications that truly need big packets might as easily exceed 1500 octets as 1280 octets and become special cases, anyhow. Note that I'm not proposing to abolish fragmentation; it ought to be strongly recommended, and required on routers that do tunneling, but embedded systems and boot ROMs shouldn't need to include datagram reassembly code to be IPv6 compliant when that code will only be invoked in pathological cases. Applications really ought to limit themselves to 1280 octet datagrams as opposed to 1500 octet datagrams anyway. The only change this might make to existing code would be to ensure that rejection of a fragmented datagram of between 1281 and 1500 octets is handled as elegantly as rejection of a similar datagram of 1501+ octets. (No correct implementation should ever need to fragment a datagram of 1280 or fewer octets when the minimum MTU is 1280.) This is really just a way to restate the maxim, "Be conservative in what you send and liberal in what you accept." Okay, I've made my case. What am I missing? Jeffrey Streifling -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 15 23:14:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA09065 for ipng-dist; Sat, 15 Aug 1998 23:09:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA09058 for ; Sat, 15 Aug 1998 23:09:01 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA27307 for ; Sat, 15 Aug 1998 23:09:00 -0700 Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.200.88]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA02531 for ; Sat, 15 Aug 1998 23:09:02 -0700 (PDT) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id XAA17015; Sat, 15 Aug 1998 23:08:56 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Aug 1998 23:09:17 -0700 To: Jeffrey Streifling From: Steve Deering Subject: (IPng 6198) Re: End-nodes and the 1500 octet reassembly buffer requirement Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:01 PM -0700 8/15/98, Jeffrey Streifling wrote: > if this 1500 octet requirement -- which was only 576 > octets in IPv4 -- could be winched, kicking and > screaming, down to match the 1280 octet minimum MTU > in end-node stacks -- in contradistinction to routers > that might need the elbow-room for tunneling, ... Jeffrey, It is becoming more common for end-nodes to also be endpoints of tunnels, e.g., mobile IP tunnels or IPsec tunnels. That's why we specified a reassembly buffer size larger than the minumum MTU for all IPv6 nodes. 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 Sun Aug 16 05:19:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA09199 for ipng-dist; Sun, 16 Aug 1998 05:12:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA09192 for ; Sun, 16 Aug 1998 05:12:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA13699 for ; Sun, 16 Aug 1998 05:12:23 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id FAA23991 for ; Sun, 16 Aug 1998 05:12:22 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id MA22363; Sun, 16 Aug 1998 22:12:01 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6199) Re: Reg: PATH MTU discovery In-Reply-To: Your message of "Sun, 16 Aug 1998 07:58:57 +0200." <199808152259.HAA01775@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Aug 1998 22:12:00 +1000 Message-Id: <20045.903269520@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 16 Aug 98 7:58:57 JST From: Masataka Ohta Message-ID: <199808152259.HAA01775@necom830.hpcl.titech.ac.jp> Otha san, With proper hardware implementation, it is as easy as packet size checking. Of course, with "proper" hardware implementation. But packet size checking is mandatory (even for serial links with potentially unlimited packet size in theory, as I think you have pointed out before, the size must be limited to meet the assumptions about the CRC of the level 2 protocol). Fast hop by hop option checking would require extra hardware (or software or both) which is not otherwise required. That is, it is, as claimed, an extra burden. The problem of PMTUD is that it is impolite and costs a lot to periodically send packets which are almost certainly exceed the path MTU and burdens routers. Only if we assume that the choke point is somewhere where those costs are high, and I think you have agreed that in practice, that will not often be the case. That is, in most cases PMTUD is not necessary. No, not "not necessary", just "simple and easy and of little effort". Whether it is necessary or not depends upon whether we can guarantee that the choke point will be local - and of course, we cannot. PMTUD is thus necessary for correct operations (that or we must mandate a single MTU for all links, forever, and that one I don't think makes sense). In the LAN environment where the latency is "very low", there is no point to make the packet size large. No, I disagree. In a LAN environment, the data volume also tends to be quite high. Providing the bandwidth to cope is comparatively cheap and easy. Providing the switching is not. Thus the ideal is to transmit maximum volume in minimum packets. That means keeping the packet size as high as possible. Or, in more concrete terms, over my FDDI I want my NFS packets in 4K pieces thanks all the same... In the LAN environment where the bandwidth is "plenty", there is no point of worrying about the header overhead. Also not true. For the same reason. The bandwidth is cheap, the router overheads of processing the headers is not. That is, even in your senario, PMTUD is useless. I disagree. With minimum MTU of 1280, we don't need any mechanism to detect it actually is 1500. 1500 is a 17% (approx) increase over 1280. Of the actual payload (after the constant sized headers are removed) it will be even higher. While not enormous, that is a reasonable saving (even just saving 17% of all the header bytes floating around is useful). Wrong. As PMTUD is not applicable to multicast and connectionless communication, transparent upgrade is not possibleand we must live with the minimum MTU of 1280. I had an impression that a scheme for PMTUD for multicast was around, or coming - but never mind, whether or not multicast can benefit is irrelevant, all my TCP connections can benefit, and that is sufficient. Connectionless is not so clear cut - some connectionless communications can happily use PMTUD (tftp is an obvious example). Others (like the DNS) will find it quite difficult. Still, the dominant communications continue to be streams, and streams can benefit from PMTUD, and so should use it. Instead, the limited applicability of PMTUD makes people not motivated to make link MTU larger than 1500. The "limited applicability" is your conclusion. As long as nodes implement, and use, PMTUD, the motivation to make the limk MTU larger will be strong, as doing so will reap immediate benefits. The bigger argument for the PMTU remaining at 1500 is the continued dominance of ethernet variations with 1500 interface MTUs. Whether something new will displace ethernet and allow larger MTUs is anyone's guess. That is, the dominant PMTU will be 1500 forever (or until we must move to the second next generation IP, at least, which may be shorter than your expectation). I doubt which IP generation is in use has a lot to do with it, what does is the lowest of the MTUs of high use media - that means ethernet for now, and that means 1500. If everyone switched to FDDI tomorrow, so that MTUs of larger than 1500 on the backbones would make sense, then I think you'd see a lot of backbones attempting to cut their switching costs by increasing the MTU. Of course, this required that the nodes will notice the change, and that requires that the nodes have implemented MTUD. So, instead of arguing about it, just do it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 16 06:29:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA09255 for ipng-dist; Sun, 16 Aug 1998 06:23:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA09248 for ; Sun, 16 Aug 1998 06:23:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA16448 for ; Sun, 16 Aug 1998 06:23:30 -0700 Received: from dee.inr.ac.ru (dee.inr.ac.ru [193.233.7.82]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA03629 for ; Sun, 16 Aug 1998 06:23:31 -0700 (PDT) Received: (from root@localhost) by dee.inr.ac.ru (8.6.13/ANK+IPv6) id RAA18790; Sun, 16 Aug 1998 17:21:09 +0400 Message-Id: <199808161321.RAA18790@dee.inr.ac.ru> Subject: (IPng 6200) Re: Reg: Jumbo Payload Option. To: iprsvp@yahoo.com (Raghu V.V.J Vadapalli) Date: Sun, 16 Aug 1998 17:21:09 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <19980815220410.17558.rocketmail@send1c.yahoomail.com> from "Raghu V.V.J Vadapalli" at Aug 15, 98 03:04:10 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > Let us suppose I have a interface with MTU greater than > 65535 and less than X. Let us suppose I have a packet > with payload length greater than X. You never will have packets of payload > X on such kind of devices. Actually, you never should have packets with payload > X, even if X is lower, if your implementation follows IPv6 specs. IP level fragmentation is fallback solution, which is required only when protocol overhead (extension headers etc.) is so high, that IP level fragmentation would be necessary or much less expensive, than transport level fragmentation. Jumbo option addresses devices with potentially unlimited packet sizes (f.e. HIPPI) or with link layer fragmentation (f.e. ATM, though current ALs do not allow it) Apparently, in this cases there is no room for IP level fragmentation. Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 16 07:54:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA09317 for ipng-dist; Sun, 16 Aug 1998 07:49:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA09310 for ; Sun, 16 Aug 1998 07:49:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA20875 for ; Sun, 16 Aug 1998 07:49:33 -0700 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA17068 for ; Sun, 16 Aug 1998 07:49:33 -0700 (PDT) Message-ID: <19980816144748.5837.rocketmail@send1e.yahoomail.com> Received: from [209.94.102.42] by send1e; Sun, 16 Aug 1998 07:47:48 PDT Date: Sun, 16 Aug 1998 07:47:48 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6201) Re: Reg: Jumbo Payload Option. To: kuznet@ms2.inr.ac.ru Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Let us suppose I have a interface with MTU greater than > > 65535 and less than X. Let us suppose I have a packet > > with payload length greater than X. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > You never will have packets of payload > X > on such kind of devices. Actually, you never should > have packets with payload > X, even if X is lower, > if your implementation follows IPv6 specs. > > IP level fragmentation is fallback solution, > which is required only when protocol overhead > (extension headers etc.) is so high, that IP level > fragmentation would be necessary or much less expensive, > than transport level fragmentation. >>>>> I am still in learning phase. Does it mean fragmentation is needed only when extension headers are large. I don't think this is the case. Right!!!! I think transport layer is not aware of MTU. Right!!! So if it has a packet with payload length > Interface MTU . Then IP layer has to perform fragmentation. Am I correct? I am assuming that TRANSPORT layer is not aware of MTU. so I don't think fragmentation is needed only when the extension headers are big. > Jumbo option addresses devices with potentially > unlimited packet sizes (f.e. HIPPI) or with link layer > fragmentation (f.e. ATM, though current ALs do not allow it) > Apparently, in this cases there is no room for IP level > fragmentation. > What is the max. MTU of a HIPPI link. I am not clear about the LINK LAYER FRAGMENTATION. Can you please calrify!! Thanks !!! >>>>>> Does it mean that ordinary IP routing is not going to use JUMBO PAYLOAD option unless it is operating over HIPPI sort of links. So Jumbo payload option is not meant for IP over "ordinary link layers". Right!!! Just I want to clarify myself. Thanks alot for time!!! -Raghu. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 16 08:06:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA09338 for ipng-dist; Sun, 16 Aug 1998 08:01:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA09331 for ; Sun, 16 Aug 1998 08:01:43 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA21490 for ; Sun, 16 Aug 1998 08:01:42 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA18969 for ; Sun, 16 Aug 1998 08:01:33 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA00538; Sun, 16 Aug 1998 19:04:44 +0400 Message-Id: <199808161504.TAA00538@ms2.inr.ac.ru> Subject: (IPng 6202) Re: Reg: Jumbo Payload Option. To: iprsvp@yahoo.com (Raghu V.V.J Vadapalli) Date: Sun, 16 Aug 1998 19:04:44 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <19980816144748.5837.rocketmail@send1e.yahoomail.com> from "Raghu V.V.J Vadapalli" at Aug 16, 98 07:47:48 am From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! > Does it mean fragmentation is needed only when > extension headers are large. I don't think > this is the case. Right!!!! Not only. F.e. udp NFS over links with mtu < 8K+ is much more efficient, when fragmented by IP, because of huge transport overhead. > I think transport layer is not aware of MTU. Right!!! Not right. Transport layer must know mtu and should not try to send packets exceeding mtu. It was the case even in IPv4. > So if it has a packet with payload length > Interface > MTU . Then IP layer has to perform fragmentation. > Am I correct? No. IP layer should reply to this silly user with error to force him to make correct things 8) > What is the max. MTU of a HIPPI link. 4Gb. > operating over HIPPI sort of links. So Jumbo payload > option is not meant for IP over "ordinary link layers". > Right!!! Yes, it it is correct. Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 16 08:45:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA09389 for ipng-dist; Sun, 16 Aug 1998 08:36:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA09382 for ; Sun, 16 Aug 1998 08:35:57 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA23398 for ; Sun, 16 Aug 1998 08:35:56 -0700 Received: from dee.inr.ac.ru (dee.inr.ac.ru [193.233.7.82]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA25063 for ; Sun, 16 Aug 1998 08:35:53 -0700 (PDT) Received: (from root@localhost) by dee.inr.ac.ru (8.6.13/ANK+IPv6) id TAA18981; Sun, 16 Aug 1998 19:35:29 +0400 Message-Id: <199808161535.TAA18981@dee.inr.ac.ru> Subject: (IPng 6204) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: bound@zk3.dec.com Date: Sun, 16 Aug 1998 19:35:29 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808141633.AA03110@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Aug 14, 98 12:33:33 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > - Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. I remember this long discussion and do not want to restart it again, but I'd like to take your attention: You've just added new field to sockaddr_in6, which: * is useless, in 99.999% of cases, when global or unique site local addresses are used. * is useless on any single-homed node. * is not enough to make multihomed hosts and routers to work correctly, because they must know destination to reply in any case. * was completey covered for years by advanced API. And last but not the least: you've just grabbed one move 64 bit word. Listen, if you really thought enough and finally decided to break all existing implementations, why not to remove dead sin6_flowinfo field? In any case, flowinfo is semantically not related to sockaddr and would break normal "reply to the thing, which you received" model. Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 16 15:04:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA09569 for ipng-dist; Sun, 16 Aug 1998 14:52:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA09562 for ; Sun, 16 Aug 1998 14:52:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA18571 for ; Sun, 16 Aug 1998 14:52:01 -0700 Received: from send101.yahoomail.com (send101.yahoomail.com [205.180.60.87]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA01907 for ; Sun, 16 Aug 1998 14:52:00 -0700 (PDT) Message-ID: <19980816215118.18943.rocketmail@send101.yahoomail.com> Received: from [209.94.102.127] by send101.yahoomail.com; Sun, 16 Aug 1998 14:51:18 PDT Date: Sun, 16 Aug 1998 14:51:18 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6205) Reg: IP AS-TO-AS Interface. To: ipng Cc: raghuv119@hotmail.com, iprsvp@yahoo.com, qosr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All.. I have a proposal for AS-TO-AS interface for supporting QoS routing. It is some what similar to ATM pnni. The proposal is not complete. If anybody wants the entire proposal of this I can send them a copy of the same with all the proposals. I think it will work out (hope so :):):)) It defers from ATM pnni 1. There is no aggregation of route information. 2. There is no aggregation of QoS resources. It involves grouping of AS (as proposed in QoS routing internet draft ) into a PARENT AS. This is HIERARCHICAL routing model. A Connection request can classified into three types. 1. Intra Area Connection requests. 2. Inter Area Connection requests. 3. Interdomain Connection requests. A QoS Connection is defined as the "source router" to the "destination router". Source router : It is the router to which the source node is connected. It is upto the link layer technoligy to support the QoS from the source node to the source router. Destination Router: It is the router to which the destination node is connected. So In the proposed hierarchical routing model the end systems are the routers connected to the subnets. Intra Area QoS Connection Requests: An area is collection of subnets, routers and hosts. In practise the max. number of routers observed are 22. (Please check it). Each router within a Area maintains the complete topology information with QoS parameters. Each router maintains a graph of routers within a AREA with QoS paramaters of links. QOSPF (Check the internet draft ) ensures that each participating router has an identical QoS database. So whenever there is QoS connection request the source router can use the EXPLICIT SOURCE ROUTE object (refer QoS internet draft ) for the route specification in the RSVP PATH message. As all the routers within a AREA have the topology database there is little probability of connection failure. In case of stub areas the STUB ROUTER will take care of all the connection requests to the outside world. Note that stub router need not flood the router toplogy information into the stub area. Inter Area Connection request : Every AREA border router will maintain the TOPOLOGY INFORMATION OF THE areas. An area can be viewed as guarded by area border routers. An area border router will flood the CONNECTIVITY information of other ares into it's own area. The proposed addressing architecture for this case will be shown below. Which simplifies the selection algo. of the area border router for a router within a AREA. So AREA border router will advertise only the connectivity to the other border routers with QoS parameters. Based on the destination router the originating router will choose the area border router and the EXPLICIT SOURCE ROUTE OBJECT. If the source router uses a BAD EXPLICIT SOURCE ROUTE OBJECT then we can use CRANK BACK for resolving this issue for ALTERNATE ROUTING. Inter AS QoS Connection Requests: Bcos of the hierarchical structure this can be of two types. 1. A conn. request between two router at same hierarchical levels. 2. A conn. request between two router at different level. Even though the routing decisions are made irrespective of the hierarchical level I have choosen these two cases for explanation purpose. Peer Group: A set of ASs grouped for purposes of a particular peer group. Peer Group Level: The Level of the peer group in the PEER GROUP STACK. Peer Group Stack: A hierarchical routing as ATM PNNI peers. A peer group stack consists of several levels and each group level consists "groups of ASs". Observe that the lowest peer group is a AS. The next peer group can be a GROUP OF N ASs. QoS routing information regarding peer group stack: Every peer group stack border router will flood connectivity information of the peer group as a three tuple < Prefix, Prefix Length, QoS Parameters>. In the same the PEER GROUP BORDER ROUTERS WILL flood the QoS topology information of the neigh. peer group stack into it's own peer group stack. Observe that the connectivity informatio is just the reachbility information for the border router. When ever a BORDER ROUTER ( IT CAN BE A AREA BORDER ROUTE, PEER GROUP BORDER ROUTE, PEER GROUP LEVEL BORDER ROUTER, PEER GROUP STACK BORDER ROUTER) receives a EXPLICIT ROUTE OBJECT IN A RSVP PATH message it will update the SOURCE ROUTE OBJECT FROM IT'S own database. For this purpose I want to steal a FP from the addr. architecture and the addre. architecture will be 1. FORMAT PREFIX. 2. TOP LEVEL PEER GROUP STACK IDENTIFIER. 3. PEER GROUP LEVEL IDENTIFIER. 4 & 5 SITE LOCAL IDENTIFIER. 6. Subnet IDENTIFIER. 7. Interface Identifier. The number of bits in each of these addr. parts is not yet decided. Additional Burden and extensions: 1.BGP should be modified to support the identification of hierarchical levels. 2. I want steal one FP from the addr. space. 3. Change of Explicit Source route object in RSVP PATH message. ADVANTAGES: 1. QoS routing can be supported in the INTERNET with minimal database at the routers. otherwise each router has to maintain topology information of the internet with QoS parameters. 2. It supports QoS routing. Hope I am clear!!!! Waiting for your comments Thanks for your time!! -Raghu. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 16 16:41:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA09612 for ipng-dist; Sun, 16 Aug 1998 16:22:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA09605 for ; Sun, 16 Aug 1998 16:22:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA24731 for ; Sun, 16 Aug 1998 16:22:24 -0700 Received: from linux.silkroad.com ([198.133.151.17]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA19120 for ; Sun, 16 Aug 1998 16:22:22 -0700 (PDT) Received: (from ietf@localhost) by linux.silkroad.com (8.7.3/) id TAA03842 for ipng@sunroof.Eng.Sun.COM; Sun, 16 Aug 1998 19:22:20 -0400 From: Tim Bass (IETF) Message-Id: <199808162322.TAA03842@linux.silkroad.com> Subject: (IPng 6206) Re: IPv6 questions To: ipng@sunroof.eng.sun.com Date: Sun, 16 Aug 1998 19:22:20 -0400 (EDT) In-Reply-To: <16472.900254230@munnari.OZ.AU> from "Robert Elz" at Jul 13, 98 00:37:10 am X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre> I have no idea why anyone would want to keep arguing this after all kre> this time, I certainly don't know why I am bothering to reply, I ought kre> to be censured for it, and probably will be, but never mind. Apologies kre> in advance to everyone (else). Sorry to chime in, but I request permission to steal kre's apology in advance and comment. I've been censured so many times on this routing issue, it would not be correct to be silent. Also, I'm just catching up on email after two months on the beach in Asia (and expect no sympathy :) (embedded comments below) Antagonist> IPv6 is specifically supposed to address the problem of the dearth of IPv4 Antagonist> addresses. kre> And the routing table problems - one of the less often stated advantages of kre> IPv6 is simply that we get to start all over again with address space kre> assignments, and do it all again in a way that makes sense, while also making kre> it clear to everyone that the assignments must continue to make sense over kre> time (and hence IPv6 has made it much easier to renumber than IPv4, and work kre> is continuing to make it even easier - eventually we may have it that there's kre> no effort involved at all). Comments: Sorry, but the (above kre) comments are quite misleading to the casual reader. First of all, IP routing is completely decoupled with IP address space in the purist Internet model. Ok, granted, "we" messed up years ago, followed NSF AUP, screwed up global routing (making it unscalable) and the 'back designed' aggregation (aggravation....) as a quick, short term fix. However, the GOAL of IP is to DECOUPLE addresses, datagrams, transport, etc. up-the-stack. It is very major short sided engineering mistake to continue to design flaws into future designs. Aggregation is a flaw, a bandaid, because of the flawed, unscalable BGP exterior routing protocol. BGP created the problem, not IPv4 and not IPv6. And as long as the IETF and the Internet rely on BGP and it's malformed offspring, bandaids like provider based aggregation will be a monkey-wrench in the IP engine. There is no 'less offen stated avantages of IPv6' to start all over again and aggregate, because aggregation is flawed in itself. Tim Bass -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 16 17:58:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA09643 for ipng-dist; Sun, 16 Aug 1998 17:41:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA09636 for ; Sun, 16 Aug 1998 17:41:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA29407 for ; Sun, 16 Aug 1998 17:41:10 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA05104 for ; Sun, 16 Aug 1998 17:41:10 -0700 (PDT) From: Masataka Ohta Message-Id: <199808170031.JAA03244@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA03244; Mon, 17 Aug 1998 09:30:56 +0859 Subject: (IPng 6207) Re: Reg: PATH MTU discovery To: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 17 Aug 98 9:30:55 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <20045.903269520@munnari.OZ.AU>; from "Robert Elz" at Aug 16, 98 10:12 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre; > Of course, with "proper" hardware implementation. But packet size > checking is mandatory (even for serial links with potentially unlimited > packet size in theory, as I think you have pointed out before, the size > must be limited to meet the assumptions about the CRC of the level 2 > protocol). No, it's not me. It perhaps was Joachim. But that the size is limted does not make size check necessary. For examle, if the size is limited below 1500, implementatins which unconditionaly allows MTU of 1500 does not have to check the size limit. > Fast hop by hop option checking would require extra hardware (or software > or both) which is not otherwise required. That is, it is, as claimed, > an extra burden. These days, the amount of hardware is measured by chip count and is not affected by negligilbly small extra burden. > The problem of PMTUD is that it is impolite and costs a lot to > periodically send packets which are almost certainly exceed the > path MTU and burdens routers. > > Only if we assume that the choke point is somewhere where those costs > are high, and I think you have agreed that in practice, that will not > often be the case. You misunderstand me. I, instad, think you have agreed that, in practice, it is not often be the case that PMTUD is meaningful. > That is, in most cases PMTUD is not necessary. > > No, not "not necessary", just "simple and easy and of little effort". It may be of little effort at the end systems, but not at the choke points. > Whether it is necessary or not depends upon whether we can guarantee > that the choke point will be local - and of course, we cannot. And that we cannot is bad enough. > PMTUD > is thus necessary for correct operations (that or we must mandate a > single MTU for all links, forever, and that one I don't think makes sense). The assumption to make PMATU 1280 is good enough fo the correct operation. You can, of course, try to change MTU for the second next IP, though rest of us won't think it necessary. > In the LAN environment where the latency is "very low", there is no point to > make the packet size large. > > No, I disagree. In a LAN environment, the data volume also tends to > be quite high. The data volume has nothing to do even with the data bandwidth. > Providing the bandwidth to cope is comparatively cheap > and easy. Providing the switching is not. The reality these days is that even routing, not merely switching, is at the line sped. > Thus the ideal is to transmit See the reality. > Or, in more concrete terms, over my FDDI I want my NFS packets in 4K pieces > thanks all the same... > How can you explain the fact that giga ether routers are operating at the line speed even with an average packets sizes of 64 bytes? > In the LAN environment where the bandwidth > is "plenty", there is no point of worrying about the header overhead. > > Also not true. For the same reason. The bandwidth is cheap, the router > overheads of processing the headers is not. The prinmary overhead of router processing is at the routing table look up. Header processing of the headers is already negligible even with IPv4. > That is, even in your senario, PMTUD is useless. > > I disagree. How can you disagree? > With minimum MTU of 1280, we don't need any mechanism to detect it > actually is 1500. > > 1500 is a 17% (approx) increase over 1280. Sure. It is a 17% increase of 40 byte (or 60 byte including that of TCP) headers and is negligible. > Of the actual payload (after > the constant sized headers are removed) it will be even higher. While not > enormous, that is a reasonable saving (even just saving 17% of all the header > bytes floating around is useful). On the actual payload after the headers are removed, MTU does not matter. > Wrong. As PMTUD is not applicable to multicast and connectionless > communication, transparent upgrade is not possibleand we must > live with the minimum MTU of 1280. > > I had an impression that a scheme for PMTUD for multicast was around, > or coming - but never mind, No, because it is proven to be impossible. > whether or not multicast can benefit is irrelevant, Wrong. If you assume some impossible thing, you can prove anything possible, which is a well know theory of logic. > all my TCP connections can benefit, and that is sufficient. It is not sufficient to make minimum MTU increase transpearent. > Connectionless is not so clear cut - some connectionless communications can > happily use PMTUD (tftp is an obvious example). TFTP, of course, is connected in a sense that TCP over connectionless IP is connected. > Others (like the DNS) will > find it quite difficult. Still, the dominant communications continue to > be streams, and streams can benefit from PMTUD, and so should use it. The dominant communications continue to be those of TV broadcasting streams, which can not be benefitted from PMTUD. > Instead, the limited applicability of PMTUD makes people not motivated > to make link MTU larger than 1500. > > The "limited applicability" is your conclusion. No. We have already agreed PMTUD is limited that DNS, for example, is a problem. > That is, the dominant PMTU will be 1500 forever (or until we must move > to the second next generation IP, at least, which may be shorter than > your expectation). > > I doubt which IP generation is in use has a lot to do with it, what does is > the lowest of the MTUs of high use media - that means ethernet for now, and > that means 1500. If everyone switched to FDDI tomorrow, so that MTUs of > larger than 1500 on the backbones would make sense, then I think you'd see a > lot of backbones attempting to cut their switching costs by increasing the > MTU. Of course, this required that the nodes will notice the change, and > that requires that the nodes have implemented MTUD. MTUD is not sufficient which is why you need the second next generation. > So, instead of arguing > about it, just do it. Do IPv8, you mean? :-) Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 16 19:45:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA09700 for ipng-dist; Sun, 16 Aug 1998 19:33:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA09693 for ; Sun, 16 Aug 1998 19:32:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA06012 for ; Sun, 16 Aug 1998 19:32:34 -0700 Received: from send103.yahoomail.com (send103.yahoomail.com [205.180.60.92]) by earth.sun.com (8.9.1/8.9.1) with SMTP id TAA29517 for ; Sun, 16 Aug 1998 19:32:34 -0700 (PDT) Message-ID: <19980817023226.14449.rocketmail@send103.yahoomail.com> Received: from [209.94.102.159] by send103.yahoomail.com; Sun, 16 Aug 1998 19:32:26 PDT Date: Sun, 16 Aug 1998 19:32:26 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6208) Re: Reg: IP AS-TO-AS Interface. To: "Guo, Liang" Cc: qosr , ipng , raghuv119@hotmail.com, iprsvp@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi!!!! The main concept is as follows: The EXPLICIT ROUTE OBJECT will be updated at each BORDER ROUTER.( A BORDER ROUTER CAN BE A AREA BORDER ROUTER, PEER GROUP BORDER ROUTER, PEER GROUP LEVEL BORDER ROUTER, PEER GROUP STACK BORDER ROUTER ). The source router will choose the BORDER ROUTER depending on the PREFIX of the addr. architecture proposed. All the BORDER ROUTER WILL MAINTAIN the internal topology . For Example: An Area border router will maintain internal topology of the AREA. An PEER GROUP BORDER at the lowest level ( i.e., an AS ) border routers will maintain the REACHBILITY INFORMATION of the AREA BORDER ROUTERS but not the internal TOPOLOGY of the AREA. So when a ROUTER in AREA1 wants establish a conn. to router in AREA2 it will fill the EXPLICIT ROUTE SOURCE OBJECT upto the AREA2 border router. The AREA2 border will be choosen based on the prefix of the DESTINATION. ( The format of the addr. architecture allows you to do so.It just like LONGEST PREFIX MATCH algo.) So When the AREA2 border router receives the EXPLICIT SOURCE ROUTE OBJECT it updates this object from it's own database. So the packet will be routed from this router based on the UPDATED EXPLICIT SOURCE ROUTE OBJECT. So there is no ON DEMAND PATH COMPUTATION. Hope I am clear. Thanks -Raghu. > On Sun, 16 Aug 1998, Raghu V.V.J Vadapalli wrote: > > > Dear All.. > > > > I have a proposal for AS-TO-AS interface for supporting > > QoS routing. It is some what similar to ATM pnni. The > > proposal is not complete. If anybody wants the entire > > proposal of this I can send them a copy of the same with > > all the proposals. I think it will work out (hope so :):):)) > > > > It defers from ATM pnni > > 1. There is no aggregation of route information. > > 2. There is no aggregation of QoS resources. > > > Sounds interesting, can I have a complete version of the proposal? > I was just wondering how to obtain the QoS information > for the entire path without aggregation, > seems that you are using an on-demand > path QoS info collection, but that would increase the set up time. > > > Guo, Liang > > guol@ccs.neu.edu College of Computer Science, > (617)373-7920 (O) 161 Cullinane Hall, > (617)472-5173 (H) Northeastern University. > http://www.ccs.neu.edu/home/guol MA 02115. > > > > _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 01:13:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id BAA09900 for ipng-dist; Mon, 17 Aug 1998 01:04:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA09888 for ; Mon, 17 Aug 1998 01:04:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA01721 for ; Mon, 17 Aug 1998 01:04:19 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA22652 for ; Mon, 17 Aug 1998 01:03:47 -0700 (PDT) From: Masataka Ohta Message-Id: <199808170753.QAA03782@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA03782; Mon, 17 Aug 1998 16:52:47 +0859 Subject: (IPng 6210) Re: Reg: PATH MTU discovery To: dan@tik.ee.ethz.ch (Dan S. Decasper) Date: Mon, 17 Aug 98 16:52:46 JST Cc: mohta@necom830.hpcl.titech.ac.jp, kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com, dan@tik.ee.ethz.ch In-Reply-To: <199808170618.IAA14162@tik2.ethz.ch>; from "Dan S. Decasper" at Aug 17, 98 8:10 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan; > >The prinmary overhead of router processing is at the routing table > >look up. > Actually I got some very interesting input on that last paragraph from > somebody of Bay Architecture Lab the other day. They told me that a typical > IP router spends only ~ 50% of the total forwarding time in the routing > table lookup if you use one of these new lookup schemes. The rest is other > processing like frame alignment, checksum check, hop count inc, check for > options, demultiplex to protocol, etc... That does also seem to be the > reason why technologies like tag switching which shortcut the routing > lookup do _not_ improve routing performance by an order of magnitude. You misunderstand the entire point of tag switching. Dispite all the hypes, tag switching does NOT shortcut the routing table look up nor does it help to reduce the size of the routing table. Tag switching, flow or tolopogy driven, does NOT help aggregate the routing table. Instead, it shortcuts some frame processing overhead to extract the destination address, port and/or flow label, which is already small enough. It also make the space of addresses (or something to index the routing table) more dense. But, as the look up speed is determined by the size of the table, tag switching is not useful for performance. Thus, just as the new option on MTU discovery does not affect the performance, tag switching neither. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 02:17:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA09949 for ipng-dist; Mon, 17 Aug 1998 02:03:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA09942 for ; Mon, 17 Aug 1998 02:02:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA06329 for ; Mon, 17 Aug 1998 02:02:39 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA07456 for ; Mon, 17 Aug 1998 02:02:39 -0700 (PDT) From: Masataka Ohta Message-Id: <199808170851.RAA04034@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA04034; Mon, 17 Aug 1998 17:51:18 +0900 Subject: (IPng 6212) Re: Reg: PATH MTU discovery To: dan@tik.ee.ethz.ch (Dan S. Decasper) Date: Mon, 17 Aug 98 17:51:17 JST Cc: mohta@necom830.hpcl.titech.ac.jp, kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com In-Reply-To: <199808170841.KAA18294@tik2.ethz.ch>; from "Dan S. Decasper" at Aug 17, 98 10:39 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan; > But I'm a little frustrated with your > statement that I "completely misunderstood the point of tag switching" > since I spend some time reading some of the RFCs and drafs and thinking > about it. I'm a lot frustrated with all the hypes on tag switching including yours, as I am the person to propose CSR and held a BoF at Danvers knowing all the benefits (little) and lmitations of it. Best effort tag switching is meaningless. > >to index the routing table) more dense. But, as the look up > >speed is determined by the size of the table, tag switching is not > >useful for performance. > New lookup schemes like my office mate Waldvogel's (in SIGCOMM'97) or > Shrinivasan/Varghese (in SIGMETRICS'98) both have the nice property that > the lookup time is (almost) independent of the size of the routing table > and determined only by the length of the prefixes. I think you are not aware of the fact that accessing a 1K entry SRAM costs less than accessing a 16M entry SRAM. Please don't assume constant time memory arithmetic. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 05:49:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA10084 for ipng-dist; Mon, 17 Aug 1998 05:31:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA10077 for ; Mon, 17 Aug 1998 05:30:54 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA23889 for ; Mon, 17 Aug 1998 05:30:52 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA01259 for ; Mon, 17 Aug 1998 05:30:48 -0700 (PDT) From: Masataka Ohta Message-Id: <199808171221.VAA04336@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA04336; Mon, 17 Aug 1998 21:21:08 +0900 Subject: (IPng 6214) Re: Reg: PATH MTU discovery To: dan@tik.ee.ethz.ch (Dan S. Decasper) Date: Mon, 17 Aug 98 21:21:07 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199808170940.LAA20443@tik2.ethz.ch>; from "Dan S. Decasper" at Aug 17, 98 11:39 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan; > I'm not _at all_ hyping for tag switching I'm bored of your hype that tag switching had bypassed routing table lookup. Worse, it has nothing to do with the inefficiency of PMTUD. PERIOD. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 07:29:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA10159 for ipng-dist; Mon, 17 Aug 1998 07:10:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA10152 for ; Mon, 17 Aug 1998 07:09:58 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA04575 for ; Mon, 17 Aug 1998 07:09:56 -0700 Received: from saturn.wwc.edu (saturn.wwc.edu [192.147.173.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA08825 for ; Mon, 17 Aug 1998 07:09:57 -0700 (PDT) Received: from sphinx.wwc.edu (sphinx.wwc.edu [199.236.177.250]) by saturn.wwc.edu (8.9.1/8.9.1) with SMTP id HAA03958; Mon, 17 Aug 1998 07:09:53 -0700 Date: Mon, 17 Aug 1998 07:17:03 -0700 (PDT) From: Jeffrey Streifling To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: (IPng 6215) Re: End-nodes and the 1500 octet reassembly buffer requirement In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is becoming more common for end-nodes to also be endpoints of > tunnels, e.g., mobile IP tunnels or IPsec tunnels. That's why > we specified a reassembly buffer size larger than the minumum MTU > for all IPv6 nodes. Clearly, fragmentation support is absolutely necessary in all nodes that do any kind of tunneling, and a 1500 octet reassembly buffer is a bare minimum for these. But if tunneling is the only big reason for the 1500 octet requirement, it might reasonably be confined to nodes that need to do tunneling, even if this turns out to be 95% or more of all nodes. Note that TCP and UDP are technically only 'recommended' protocols, even though practically every node out there supports them. My only point is that since the need for fragmentation support seems to be confined to tunnels and certain protocols like NFS (where fragmentation is the most efficient way to go), it would be nice to define how to interact with nodes that don't handle fragmentation at all. Jeffrey Streifling -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 07:44:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA10175 for ipng-dist; Mon, 17 Aug 1998 07:28:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA10168 for ; Mon, 17 Aug 1998 07:28:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA07560 for ; Mon, 17 Aug 1998 07:28:32 -0700 Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA16978 for ; Mon, 17 Aug 1998 07:28:30 -0700 (PDT) Received: from komsys-pc-mw.ethz.ch (komsys-pc-mw [129.132.66.24]) by tik2.ethz.ch (8.8.8/8.8.8) with SMTP id QAA05704; Mon, 17 Aug 1998 16:28:27 +0200 (MET DST) Received: by komsys-pc-mw.ethz.ch (NX5.67f2/NX3.0X) id AA07841; Mon, 17 Aug 98 16:28:23 +0200 Message-Id: <9808171428.AA07841@komsys-pc-mw.ethz.ch> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <199808150942.SAA01353@necom830.hpcl.titech.ac.jp> X-Nextstep-Mailer: Mail 3.3 (Enhance 2.2) Received: by NeXT.Mailer (1.118.2) From: Marcel Waldvogel Date: Mon, 17 Aug 1998 16:28:22 +0200 To: Masataka Ohta Subject: (IPng 6216) Re: MTU info into routers Cc: transmission65@hotmail.com (Mike Stuard), ipng@sunroof.eng.sun.com References: <199808150942.SAA01353@necom830.hpcl.titech.ac.jp> Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 15 Aug 98, Masataka Ohta wrote: > > Why not just put the MTU information into the > > routingtables, at least into the edgerouters ? > Because unicast routing tables are aggregated. Nevertheless, I think Mike's proposal has some merits: Even with aggregation, one could send back the range (min, max) of PMTUs leading to the final destination, according to the information from routing. This could be used by end systems to find the correct PMTU with (many) fewer round-trips, reducing the overall load on the routers. Even with just taking the min of the routing PMTUs, an implementation would be on the safe side and have an MTU advantage when compared to the constant 1280. PMTU discovery using the routing system would gain even more when used over multicast links: instead of causing possible floods of non-aggregatable ICMPs, the PMTU advertisements could be merged. -Marcel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 09:56:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA10417 for ipng-dist; Mon, 17 Aug 1998 09:48:36 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA10410 for ; Mon, 17 Aug 1998 09:48:30 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with ESMTP id JAA05228 for ; Mon, 17 Aug 1998 09:48:28 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA05384 for ipng@sunroof.eng.sun.com; Mon, 17 Aug 1998 09:47:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA08402 for ; Sat, 15 Aug 1998 12:48:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA20822 for ; Sat, 15 Aug 1998 12:48:21 -0700 Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA13471 for ; Sat, 15 Aug 1998 12:48:23 -0700 (PDT) Received: from hochstetter (hochstetter.argon.com [208.234.161.53]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id PAA02780; Sat, 15 Aug 1998 15:48:20 -0400 (EDT) Message-Id: <3.0.3.32.19980815154950.00967bd0@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 15 Aug 1998 15:49:50 -0400 To: Brian Zill , "'Steve Bellovin'" From: Frank Kastenholz Subject: (IPng 6218) Re: Reg: PATH MTU discovery Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4FD6422BE942D111908D00805F3158DF07222859@RED-MSG-52> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:27 PM 8/14/98 -0700, Brian Zill wrote: >> But the killer problem with >> this scheme is that it creates something important and common >> that would bog down every router on the path. >> >Every IPv4 router today, for every packet, must decrement the hop count, >compare it to zero, and fix up the checksum. Now one of the plusses of IPv6 >is that they don't have to do that anymore. Dealing with the TTL and fixing the checksum are extremely low cost operations. We know exactly where they are in the packet header. We know that they are there. We know what do to with them (EG, the IP checksum update for ttl-- has been highly optimized, it probably can be done in 3-6 instructions). Options may or may not be there and if they are, you don't know exactly where in the header, meaning you have to scan the packet header+options to see if the one you are interested in is there or not. Updating the field, _once_you_find_it_ is trivial. >And when it comes to the worst case, I think everyone will agree that >generating a Packet Too Big message is more work for a router. No. Everyone will not agree. The router I'm building right now can generate ICMP error messages (including the broken packet's entire header) much faster than it can parse packets in its fast path, to say nothing of the slow path... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 09:57:17 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA10390 for ipng-dist; Mon, 17 Aug 1998 09:46:48 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA10383 for ; Mon, 17 Aug 1998 09:46:42 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with ESMTP id JAA04899 for ; Mon, 17 Aug 1998 09:46:40 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA05352 for ipng@sunroof.eng.sun.com; Mon, 17 Aug 1998 09:45:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA08403 for ; Sat, 15 Aug 1998 12:48:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA20820 for ; Sat, 15 Aug 1998 12:48:21 -0700 Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA13469 for ; Sat, 15 Aug 1998 12:48:22 -0700 (PDT) Received: from hochstetter (hochstetter.argon.com [208.234.161.53]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id PAA02777; Sat, 15 Aug 1998 15:48:19 -0400 (EDT) Message-Id: <3.0.3.32.19980815153341.00964270@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 15 Aug 1998 15:33:41 -0400 To: Steve Bellovin , Raghu Vadapalli From: Frank Kastenholz Subject: (IPng 6217) Re: Reg: PATH MTU discovery Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199808142234.SAA04915@postal.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:34 PM 8/14/98 -0400, Steve Bellovin wrote: >In message <35D4ABAA.56E7A76C@tellabs.com>, Raghu Vadapalli writes: >> > >> > Here's the proposal as I see it: Instead of iteratively sending out packets >> > with successively smaller MTUs until one gets through (where each smaller >> > MTU comes out of a Packet Too Big message sent by the current choke point), >> > you would instead send one packet with the guaranteed-to-work MTU and a new >> > hop-by-hop option. This hop-by-hop option would contain the MTU you'd like >> > to use. Each router would look at it and lower it if it was larger than th >> e >> > next hop MTU. The node on the far end would send the final result back to >> > you via a destination option. This gives you the path MTU in a single >> > roundtrip with no dropped packets. > > >The problem with that idea is that it puts a large load on the routers -- >they have to examine many packets a lot more closely. this is even more problematic for asic-based routers which usually do not process options (v4 or v6) in the asic. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 10:45:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA10550 for ipng-dist; Mon, 17 Aug 1998 10:32:22 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id KAA10543 for ; Mon, 17 Aug 1998 10:32:17 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with ESMTP id KAA11913 for ; Mon, 17 Aug 1998 10:32:16 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA05529 for ipng@sunroof.eng.sun.com; Mon, 17 Aug 1998 10:31:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA09847 for ; Sun, 16 Aug 1998 23:20:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA23545 for ; Sun, 16 Aug 1998 23:20:08 -0700 Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA26020 for ; Sun, 16 Aug 1998 23:20:09 -0700 (PDT) Received: from tril (dynppp39.dialup.ethz.ch [192.33.93.39]) by tik2.ethz.ch (8.8.8/8.8.8) with SMTP id IAA14162; Mon, 17 Aug 1998 08:18:47 +0200 (MET DST) Message-Id: <199808170618.IAA14162@tik2.ethz.ch> X-Sender: dan@tik2.ethz.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 17 Aug 1998 08:10:37 +0200 To: Masataka Ohta , kre@munnari.OZ.AU (Robert Elz) From: "Dan S. Decasper" Subject: (IPng 6219) Re: Reg: PATH MTU discovery Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com, dan@tik.ee.ethz.ch In-Reply-To: <199808170031.JAA03244@necom830.hpcl.titech.ac.jp> References: <20045.903269520@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:30 AM 8/17/98 +0900, Masataka Ohta wrote: [...] >> >> Also not true. For the same reason. The bandwidth is cheap, the router >> overheads of processing the headers is not. > >The prinmary overhead of router processing is at the routing table >look up. > Actually I got some very interesting input on that last paragraph from somebody of Bay Architecture Lab the other day. They told me that a typical IP router spends only ~ 50% of the total forwarding time in the routing table lookup if you use one of these new lookup schemes. The rest is other processing like frame alignment, checksum check, hop count inc, check for options, demultiplex to protocol, etc... That does also seem to be the reason why technologies like tag switching which shortcut the routing lookup do _not_ improve routing performance by an order of magnitude. -Dan = ------------------------------------------------------------------ = = http://www.tik.ee.ethz.ch/~dan finger -l dan@kom1.ethz.ch = = Computer Engineering and Networks Laboratory (TIK), ETH Zurich, CH = -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 10:45:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA10568 for ipng-dist; Mon, 17 Aug 1998 10:36:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id KAA10561 for ; Mon, 17 Aug 1998 10:36:03 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with ESMTP id KAA12408 for ; Mon, 17 Aug 1998 10:36:02 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA05567 for ipng@sunroof.eng.sun.com; Mon, 17 Aug 1998 10:34:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id BAA09924 for ; Mon, 17 Aug 1998 01:46:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA05030 for ; Mon, 17 Aug 1998 01:46:31 -0700 Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id BAA03434 for ; Mon, 17 Aug 1998 01:46:30 -0700 (PDT) Received: from komsys-pc-dd (komsys-pc-dd [129.132.66.28]) by tik2.ethz.ch (8.8.8/8.8.8) with SMTP id KAA18294; Mon, 17 Aug 1998 10:41:20 +0200 (MET DST) Message-Id: <199808170841.KAA18294@tik2.ethz.ch> X-Sender: dan@tik2.ethz.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 17 Aug 1998 10:39:57 +0100 To: Masataka Ohta From: "Dan S. Decasper" Subject: (IPng 6221) Re: Reg: PATH MTU discovery Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com In-Reply-To: <199808170753.QAA03782@necom830.hpcl.titech.ac.jp> References: <199808170618.IAA14162@tik2.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id BAA09925 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka, At 08:52 AM 8/17/98 , you wrote: >Dan; > >> >The prinmary overhead of router processing is at the routing table >> >look up. > >> Actually I got some very interesting input on that last paragraph from >> somebody of Bay Architecture Lab the other day. They told me that a typical >> IP router spends only ~ 50% of the total forwarding time in the routing >> table lookup if you use one of these new lookup schemes. The rest is other >> processing like frame alignment, checksum check, hop count inc, check for >> options, demultiplex to protocol, etc... That does also seem to be the >> reason why technologies like tag switching which shortcut the routing >> lookup do _not_ improve routing performance by an order of magnitude. > >You misunderstand the entire point of tag switching. > Did I? This is from Cisco's web site: =Cisco IOS™ software delivers scalability to enhance =network capacity and performance while protecting your network =investments. =Cisco IOS Tag Switching, a new technology from Cisco Systems, is =an ideal solution to meet these challenges. Tag Switching fuses the =intelligence of routing with the performance of switching to scale =existing networks to meet future growth demands. With this =technology, networks can handle more traffic, users, media-rich data, =or bandwidth-intensive applications. I think this somehow implies better forwarding performance (more traffic, bandwidth-intensive applications)?!? >Dispite all the hypes, tag switching does NOT shortcut the routing Ya, it's probably all hype... >table look up nor does it help to reduce the size of the routing >table. Tag switching, flow or tolopogy driven, does NOT help >aggregate the routing table. > I'm not talking about aggregation. Per flow tagging is probably the opposite of aggregation. It's more about replacing a longest prefix match operation with a simple hash lookup, which can be (more easily) done in hardware. >Instead, it shortcuts some frame processing overhead to extract >the destination address, port and/or flow label, which is already >small enough. It also make the space of addresses (or something >to index the routing table) more dense. But, as the look up >speed is determined by the size of the table, tag switching is not >useful for performance. > New lookup schemes like my office mate Waldvogel's (in SIGCOMM'97) or Shrinivasan/Varghese (in SIGMETRICS'98) both have the nice property that the lookup time is (almost) independent of the size of the routing table and determined only by the length of the prefixes. >Thus, just as the new option on MTU discovery does not affect >the performance, tag switching neither. > I'm not saying tag switching for IP routing is good or bad, I'm probably not in a position to judge that due to lack of experience with the technology (and it's implementation). But I'm a little frustrated with your statement that I "completely misunderstood the point of tag switching" since I spend some time reading some of the RFCs and drafs and thinking about it. -Dan = ------------------------------------------------------------------ = = http://www.tik.ee.ethz.ch/~dan finger -l dan@kom1.ethz.ch = = Computer Engineering and Networks Laboratory (TIK), ETH Zurich, CH = -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 10:46:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA10559 for ipng-dist; Mon, 17 Aug 1998 10:34:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA10552 for ; Mon, 17 Aug 1998 10:34:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA24944 for ; Mon, 17 Aug 1998 10:34:06 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA02138 for ; Mon, 17 Aug 1998 10:34:03 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA11119; Tue, 18 Aug 1998 03:33:47 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6220) Re: Reg: PATH MTU discovery In-Reply-To: Your message of "Mon, 17 Aug 1998 09:30:55 +0200." <199808170031.JAA03244@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Aug 1998 03:33:44 +1000 Message-Id: <4543.903375224@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 17 Aug 98 9:30:55 JST From: Masataka Ohta Message-ID: <199808170031.JAA03244@necom830.hpcl.titech.ac.jp> But that the size is limted does not make size check necessary. For examle, if the size is limited below 1500, implementatins which unconditionaly allows MTU of 1500 does not have to check the size limit. Huh? You mean, if the packet is smaller than 1500 I don't have to check to see if it is bigger? That makes lots of sense.... really... Only in the case that an implementation is designed so that all of its interfaces are of the same MTU could any simplification be made, and even there that would be a very dangerous practice, as just because the MTU of a link is N doe snot guarantee that a packet larger than N won't be sent by a mis-behaving node. There still needs to be some kind of check. These days, the amount of hardware is measured by chip count and is not affected by negligilbly small extra burden. But the more complex the chips the harder they are to design, and the more likely they are to have bugs. And chip bugs (especially ones discovered late) are costly to fix. You're proposing added complexity for essentially no practical benefit. I, instad, think you have agreed that, in practice, it is not often be the case that PMTUD is meaningful. No, I don't agree with that. I think it is always meaningful. What I agree with is that it is often trivial to perform, with no cost to anyone. That it is often trivial is no excuse for ignoring it. It may be of little effort at the end systems, but not at the choke points. I disagree. The chole point has to do everything anyway (unless we define away choke points by requiring all packets be no bigger than N for some N, and requiring that all links be able to carry N octet packets). Even then the choke point still has to verify packet correctness (if it can physically receive a larger packet, then you can guarante that in practice it will receive some). The assumption to make PMATU 1280 is good enough fo the correct operation. Correct perhaps. Effecient, no. The reality these days is that even routing, not merely switching, is at the line sped. It can be, but that is expensive. Real cheap routers don't do line speed routing for tinygrams even at 10Mbit line speeds. And in any case, it isn't just the routers (or switches) that matter - it is also the end systems that have do deal with more packets than are needed. How can you disagree? I am me. I can disagree with practically anything... Wrong. If you assume some impossible thing, you can prove anything possible, which is a well know theory of logic. Of course. But no argument I have made has been predicated on the impossible (in this case, apparently, that multicast PMTUD can be made to work). I do not require that the world be perfect, and that everything work. If PMTUD will work for me for TCP, and occasional other stream based applications, then I will take that benefit, and not moan about how it doesn't work for multicast, or the DNS. Unless you have a better scheme that will work for multicast and/or the DNS, and which will automatically allow packets to grow to the real PMTU then I will keep what works for some traffic, and worry about the other traffic once someone figures out how to do it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 10:46:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA10590 for ipng-dist; Mon, 17 Aug 1998 10:40:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id KAA10582 for ; Mon, 17 Aug 1998 10:39:48 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with ESMTP id KAA13098 for ; Mon, 17 Aug 1998 10:39:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA05599 for ipng@sunroof.eng.sun.com; Mon, 17 Aug 1998 10:38:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA09985 for ; Mon, 17 Aug 1998 02:41:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA09631 for ; Mon, 17 Aug 1998 02:41:00 -0700 Received: from tik2.ethz.ch (tik2.ethz.ch [129.132.119.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA17570 for ; Mon, 17 Aug 1998 02:40:59 -0700 (PDT) Received: from komsys-pc-dd (komsys-pc-dd [129.132.66.28]) by tik2.ethz.ch (8.8.8/8.8.8) with SMTP id LAA20443; Mon, 17 Aug 1998 11:40:38 +0200 (MET DST) Message-Id: <199808170940.LAA20443@tik2.ethz.ch> X-Sender: dan@tik2.ethz.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 17 Aug 1998 11:39:15 +0100 To: Masataka Ohta From: "Dan S. Decasper" Subject: (IPng 6222) Re: Reg: PATH MTU discovery Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199808170851.RAA04034@necom830.hpcl.titech.ac.jp> References: <199808170841.KAA18294@tik2.ethz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka, At 09:51 AM 8/17/98 , Masataka Ohta wrote: [...] > >I'm a lot frustrated with all the hypes on tag switching including >yours, as I am the person to propose CSR and held a BoF at Danvers >knowing all the benefits (little) and lmitations of it. Best effort >tag switching is meaningless. > I'm not _at all_ hyping for tag switching (please look at my initial mail again, if anything, then I was arguing _against_). There is a paper in this year's SIGCOMM by Varghese et al which shows that even L4 IP switching can be done very fast using the right algorithm, so even for per flow switching/routing it might be questionable. I'm looking at it in the context of active networking and found it quite interesting though. I think it has potential for upcoming applications so I keep an eye on it. >> >to index the routing table) more dense. But, as the look up >> >speed is determined by the size of the table, tag switching is not >> >useful for performance. > >> New lookup schemes like my office mate Waldvogel's (in SIGCOMM'97) or >> Shrinivasan/Varghese (in SIGMETRICS'98) both have the nice property that >> the lookup time is (almost) independent of the size of the routing table >> and determined only by the length of the prefixes. > >I think you are not aware of the fact that accessing a 1K entry SRAM >costs less than accessing a 16M entry SRAM. > >Please don't assume constant time memory arithmetic. > I'm not sure what you mean by that last sentence. However, some of the new schemes compress a full backbone routing table to some 250KB which easily fits into an L2 cache. By aligning the data to cache lines they further optimize the performance of the lookup. The impact of the size of the table is negligible compared to the rest of the overhead. -Dan = ------------------------------------------------------------------ = = http://www.tik.ee.ethz.ch/~dan finger -l dan@kom1.ethz.ch = = Computer Engineering and Networks Laboratory (TIK), ETH Zurich, CH = -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 13:02:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA10840 for ipng-dist; Mon, 17 Aug 1998 12:56:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA10833 for ; Mon, 17 Aug 1998 12:55:57 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA10571 for ; Mon, 17 Aug 1998 12:55:54 -0700 Received: from send101.yahoomail.com (send101.yahoomail.com [205.180.60.87]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA27519 for ; Mon, 17 Aug 1998 12:55:55 -0700 (PDT) Message-ID: <19980817195510.20247.rocketmail@send101.yahoomail.com> Received: from [138.111.39.131] by send101.yahoomail.com; Mon, 17 Aug 1998 12:55:10 PDT Date: Mon, 17 Aug 1998 12:55:10 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6224) Reg: IP AS-to-AS Interface To: ipng Cc: qosr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All.. Right now I can't send the copy of the same. Right now A BIG COMM. giant has right over that draft. I am in touch with them. I will let you as soon as hear from them. I am very sorry for that. Thanks -Raghu. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 13:02:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA10827 for ipng-dist; Mon, 17 Aug 1998 12:52:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA10820 for ; Mon, 17 Aug 1998 12:52:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA09735 for ; Mon, 17 Aug 1998 12:52:33 -0700 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA25384 for ; Mon, 17 Aug 1998 12:52:34 -0700 (PDT) Message-ID: <19980817195045.12886.rocketmail@send1e.yahoomail.com> Received: from [138.111.39.131] by send1e; Mon, 17 Aug 1998 12:50:45 PDT Date: Mon, 17 Aug 1998 12:50:45 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6223) Reg: Multicasting Routing To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All.. What are the basic MULTICASTING ROUTING (v4 and v6 )internet drafts or RFCs. Thanks in advance -Raghu. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 13:18:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA10931 for ipng-dist; Mon, 17 Aug 1998 13:06:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA10924 for ; Mon, 17 Aug 1998 13:05:59 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA13129 for ; Mon, 17 Aug 1998 13:05:56 -0700 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA04125 for ; Mon, 17 Aug 1998 13:05:57 -0700 (PDT) Message-ID: <19980817200409.20644.rocketmail@send1e.yahoomail.com> Received: from [138.111.39.131] by send1e; Mon, 17 Aug 1998 13:04:09 PDT Date: Mon, 17 Aug 1998 13:04:09 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6225) Reg: IPv4 routers. To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all.. Are there any internet drafts availiable for transition from IPv4 to IPv6 and how the IPv4 routers are going to handle the IPv6 protocol packets. Thanks -Raghu. _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 14:03:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA11005 for ipng-dist; Mon, 17 Aug 1998 13:51:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA10998 for ; Mon, 17 Aug 1998 13:51:43 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA26151 for ; Mon, 17 Aug 1998 13:51:40 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA05419 for ; Mon, 17 Aug 1998 13:51:38 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id NAA14955; Mon, 17 Aug 1998 13:51:26 -0700 (PDT) Message-Id: <3.0.5.32.19980817135008.00952bd0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 17 Aug 1998 13:50:08 -0700 To: "Raghu V.V.J Vadapalli" From: Bob Hinden Subject: (IPng 6226) Re: Reg: IPv4 routers. Cc: ipng In-Reply-To: <19980817200409.20644.rocketmail@send1e.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk General information on IPv6 and related issues can be found at: http://playground.sun.com/ipng 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 Aug 17 18:25:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA11275 for ipng-dist; Mon, 17 Aug 1998 18:13:38 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id SAA11268 for ; Mon, 17 Aug 1998 18:13:22 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with SMTP id SAA19100; Mon, 17 Aug 1998 18:13:16 -0700 (PDT) Date: Mon, 17 Aug 1998 18:13:15 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6227) Re: Reg: PATH MTU discovery To: Vivek Kashyap Cc: Erik.Nordmark@Eng, smb@research.att.com, raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808150024.RAA00200@eng4.sequent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This might not be the case. Quoting from the the draft : > > ********** > 5. Security considerations > > > If the Datagram Too Big message returns a more general route than > was used by the host, the indication is taken equivalent to the > host route mask. This blocks the host from being fed faulty network > information. The host may however be sent Datagram Too Big messages > indicating the default route. The end host will end up creating > host routes instead of subnet routes. This is no different from > what happens now. A code that indicates a more precise route does > not have any effect on theflow of data or the path MTU information > related to the path. > *********** I must have missed that in your proposal. However, in IPv6 I'd expect almost all hosts (according to RFC 1970) to have nothing but default routes and a per-host destination cache. For such hosts your proposal wouldn't provide any benefits, right? 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 Mon Aug 17 18:46:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA11302 for ipng-dist; Mon, 17 Aug 1998 18:34:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA11295 for ; Mon, 17 Aug 1998 18:34:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA28574 for ; Mon, 17 Aug 1998 18:34:33 -0700 Received: from lexicon.ins.com (lexicon.ins.com [199.0.193.11]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA01299 for ; Mon, 17 Aug 1998 18:34:35 -0700 (PDT) Received: from svlcawss.ins.com (svlcawss.ins.com [199.0.193.236]) by lexicon.ins.com (8.8.8/8.8.8) with SMTP id SAA27445 for ; Mon, 17 Aug 1998 18:34:34 -0700 (PDT) Received: from 192.9.25.1 by svlcawss.ins.com with SMTP (WorldSecure Server SMTP Relay(WSS) v3.0.1); Sat, 15 Aug 98 02:32:21 -0700 X-Server-Uuid: aadd1a76-264d-11d1-91c7-080009d97107 Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA23984; Sat, 15 Aug 1998 02:26:22 -0700 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id CAA08789; Sat, 15 Aug 1998 02:26:20 -0700 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA08116 for ipng-dist; Sat, 15 Aug 1998 02:21:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA08109 for ; Sat, 15 Aug 1998 02:21:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA03875 for ; Sat, 15 Aug 1998 02:21:36 -0700 Received: from hotmail.com (f196.hotmail.com [207.82.251.85]) by earth.sun.com (8.9.1/8.9.1) with SMTP id CAA21542 for ; Sat, 15 Aug 1998 02:21:36 -0700 (PDT) Received: (qmail 10986 invoked by uid 0); 15 Aug 1998 09:21:35 -0000 Message-ID: <19980815092135.10985.qmail@hotmail.com> Received: from 195.67.254.243 by www.hotmail.com with HTTP; Sat, 15 Aug 1998 02:21:35 PDT X-Originating-IP: [195.67.254.243] From: "Mike Stuard" To: ipng@sunroof.eng.sun.com Subject: (IPng 6228) MTU info into routers Content-Type: text/plain Date: Sat, 15 Aug 1998 02:21:35 PDT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why not just put the MTU information into the routingtables, at least into the edgerouters ? then this should be an issue for updating the routing protocolls. /Mike ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 21:40:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA13022 for ipng-dist; Mon, 17 Aug 1998 21:32:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA13015 for ; Mon, 17 Aug 1998 21:32:22 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA21614 for ; Mon, 17 Aug 1998 21:32:22 -0700 Received: from imo24.mx.aol.com (imo24.mx.aol.com [198.81.17.68]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA02077 for ; Mon, 17 Aug 1998 21:32:22 -0700 (PDT) Received: from Telford001@aol.com by imo24.mx.aol.com (IMOv14_b1.1) id MINUa22588; Tue, 18 Aug 1998 00:30:55 -0400 (EDT) Message-ID: <6d8f5143.35d90380@aol.com> Date: Tue, 18 Aug 1998 00:30:55 EDT To: dan@tik.ee.ethz.ch, mohta@necom830.hpcl.titech.ac.jp, kre@munnari.OZ.AU Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6229) Re: Reg: PATH MTU discovery Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 8/17/98 2:06:09 PM Eastern Daylight Time, dan@tik.ee.ethz.ch writes: > At 09:30 AM 8/17/98 +0900, Masataka Ohta wrote: > [...] > >> Also not true. For the same reason. The bandwidth is cheap, the router > >> overheads of processing the headers is not. > >The prinmary overhead of router processing is at the routing table > >look up. > Actually I got some very interesting input on that last paragraph from > somebody of Bay Architecture Lab the other day. They told me that a typical > IP router spends only ~ 50% of the total forwarding time in the routing > table lookup if you use one of these new lookup schemes. The rest is other > processing like frame alignment, checksum check, hop count inc, check for > options, demultiplex to protocol, etc... That does also seem to be the > reason why technologies like tag switching which shortcut the routing > lookup do _not_ improve routing performance by an order of magnitude. LAN switching is in a sense a form of tag switching (the MAC address serving as the tag without any of the network layer architectural problems associated with MPLS). We found that the TTI VLAN Router functioning as a pure LAN switch (or evolved multiprotocol IMP for constructing WAN backbones) could switch 2.25-2.5 times as many packets as when it functioned as a pure router. We have found memory bandwidth to be the major factor that limits packet switching performance. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 22:07:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA13043 for ipng-dist; Mon, 17 Aug 1998 21:53:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA13036 for ; Mon, 17 Aug 1998 21:52:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA24023 for ; Mon, 17 Aug 1998 21:52:52 -0700 Received: from saturn.wwc.edu (saturn.wwc.edu [192.147.173.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA08924 for ; Mon, 17 Aug 1998 21:52:53 -0700 (PDT) Received: from sphinx.wwc.edu (sphinx.wwc.edu [199.236.177.250]) by saturn.wwc.edu (8.9.1/8.9.1) with SMTP id VAA18924 for ; Mon, 17 Aug 1998 21:52:52 -0700 Date: Mon, 17 Aug 1998 22:00:09 -0700 (PDT) From: Jeffrey Streifling Reply-To: Jeffrey Streifling To: ipng@sunroof.eng.sun.com Subject: (IPng 6230) Discovering PMTU without a special option Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been wondering if it might be possible to figure out the PMTU without pingponging each router or bogging them down with a hop-by-hop option by making the option implicit in the construction of packets. For example: Suppose that hosts interested in increasing their MTU tack on a few nulls after the IP packet proper in each frame (Ethernet, PPP, FDDI, whatever). The real packet length is determined from the Payload Length field in the IP packet itself; the zero bytes have no effect on the 1's complement checksum. Cooperative routers would make their decision whether or not to send an ICMP packet-to-big message based on the payload length field, and then heave the whole frame to the transmission ASIC or subroutine (preserving any trailing nulls), which would in turn simply truncate the packet after the first outbound-MTU bytes (that is, preserve any trailing garbage in routed frames up to the MTU). Cooperative end-nodes would notice the total frame size, which exactly equals the PMTU, and return this as a special IP option in the next suitable packet headed that direction (based on flows, connections, or what have you). This would seem to require nothing particularly special of routers, but quickly sleuth out the PMTU without a lot of extra traffic (e.g. failed tries and ICMP replies). I'll readily admit that this approach permanently limits lower layers that do not preserve an exact frame length (do they exist?) to an MTU of 1280. This is probably not a good idea in its current form (I'm not that lucky), but the general approach (truncating packets under certain conditions) might lead to an efficient PMTUD mechanism that does not unduly burden ASIC routers. (Maybe a special IP options should be used to reserve space for truncation? Maybe a special flow label could be reserved for truncatable packets?) Jeffrey Streifling -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 22:31:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA13074 for ipng-dist; Mon, 17 Aug 1998 22:26:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA13067 for ; Mon, 17 Aug 1998 22:25:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA27453 for ; Mon, 17 Aug 1998 22:25:50 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA19051 for ; Mon, 17 Aug 1998 22:24:56 -0700 (PDT) From: Masataka Ohta Message-Id: <199808180514.OAA05933@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA05933; Tue, 18 Aug 1998 14:14:23 +0900 Subject: (IPng 6231) Re: Reg: PATH MTU discovery To: kasten@argon.com (Frank Kastenholz) Date: Tue, 18 Aug 98 14:14:22 JST Cc: smb@research.att.com, raghu.vadapalli@tellabs.com, ipng@sunroof.eng.sun.com In-Reply-To: <3.0.3.32.19980815153341.00964270@shultz.argon.com>; from "Frank Kastenholz" at Aug 15, 98 3:33 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Frank; :>And when it comes to the worst case, I think everyone will agree that :>generating a Packet Too Big message is more work for a router. : :No. Everyone will not agree. The router I'm building right now :can generate ICMP error messages (including the broken packet's :entire header) much faster than it can parse packets in its fast :path, to say nothing of the slow path... So, you say you can parse the entire header so fast to detect the tail of the header sequence. That's hard to swallow. But, assuming you can, :> this is even more problematic for asic-based routers which :> usually do not process options (v4 or v6) in the asic. you'll have no difficulty to let your router process the proposed options even faster. The problem is that, though you can specify anything and it may be implemented very fast, it costs. Note that my point is that PMTUD is just as bad as the new proposal. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 22:31:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA13084 for ipng-dist; Mon, 17 Aug 1998 22:28:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA13077 for ; Mon, 17 Aug 1998 22:28:49 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA27777 for ; Mon, 17 Aug 1998 22:28:48 -0700 Received: from imo25.mx.aol.com (imo25.mx.aol.com [198.81.17.69]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA20492 for ; Mon, 17 Aug 1998 22:28:49 -0700 (PDT) Received: from Telford001@aol.com by imo25.mx.aol.com (IMOv14_b1.1) id GEWOa07259; Tue, 18 Aug 1998 01:28:02 -0400 (EDT) Message-ID: <29d58e5a.35d910e4@aol.com> Date: Tue, 18 Aug 1998 01:28:02 EDT To: kasten@argon.com, bzill@microsoft.com, smb@research.att.com Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6232) Re: Reg: PATH MTU discovery Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 8/17/98 1:16:20 PM Eastern Daylight Time, kasten@argon.com writes: > At 11:27 PM 8/14/98 -0700, Brian Zill wrote: > >> But the killer problem with > >> this scheme is that it creates something important and common > >> that would bog down every router on the path. > >Every IPv4 router today, for every packet, must decrement the hop count, > >compare it to zero, and fix up the checksum. Now one of the plusses of > >IPv6 is that they don't have to do that anymore. > Dealing with the TTL and fixing the checksum are extremely low > cost operations. We know exactly where they are in the packet > header. We know that they are there. We know what do to with them > (EG, the IP checksum update for ttl-- has been highly optimized, > it probably can be done in 3-6 instructions). Options may or may > not be there and if they are, you don't know exactly where in the > header, meaning you have to scan the packet header+options > to see if the one you are interested in is there or not. > Updating the field, _once_you_find_it_ is trivial. I was under the impression that IPv4 routers were supposed to check the checksum as well as merely decrement the ttl and update the checksum (not to suggest that I consider IPv6 anything but pointless). > >And when it comes to the worst case, I think everyone will agree that > >generating a Packet Too Big message is more work for a router. > No. Everyone will not agree. The router I'm building right now > can generate ICMP error messages (including the broken packet's > entire header) much faster than it can parse packets in its fast > path, to say nothing of the slow path... The claim is: generating an IP header + generating an ICMP header + copying or setting up pointers to the IP header + 64 bits of the packet that engenders the ICMP response + setting up some sort of mac header costs more than reading and processing the IP header (assumed meaning of parsing packets in the fast path). Sounds really weird and rather hideous. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 17 22:47:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA13112 for ipng-dist; Mon, 17 Aug 1998 22:43:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA13105 for ; Mon, 17 Aug 1998 22:43:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA29474 for ; Mon, 17 Aug 1998 22:43:33 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA25822 for ; Mon, 17 Aug 1998 22:43:24 -0700 (PDT) From: Masataka Ohta Message-Id: <199808180532.OAA05970@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA05970; Tue, 18 Aug 1998 14:31:58 +0859 Subject: (IPng 6233) Re: Reg: PATH MTU discovery To: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 18 Aug 98 14:31:58 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <4543.903375224@munnari.OZ.AU>; from "Robert Elz" at Aug 18, 98 3:33 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre; > But that the size is limted does not make size check necessary. For > examle, if the size is limited below 1500, implementatins which > unconditionaly allows MTU of 1500 does not have to check the size > limit. > > Huh? You mean, if the packet is smaller than 1500 I don't have to > check to see if it is bigger? Huh? Bigger than what? You don't have to check PMTU. > as just because > the MTU of a link is N doe snot guarantee that a packet larger than N > won't be sent by a mis-behaving node. There still needs to be some kind > of check. It's not a check against PMTU, detection of which costs even though the value is untrustworthy. It will be infrequent enough that it does not cost performance. > But the more complex the chips the harder they are to design, and > the more likely they are to have bugs. And chip bugs (especially > ones discovered late) are costly to fix. You're proposing added > complexity for essentially no practical benefit. I'm proposing to remove PMTUD because it has no practical benefit. > No, I don't agree with that. I think it is always meaningful. What > I agree with is that it is often trivial to perform, with no cost to > anyone. That it is often trivial is no excuse for ignoring it. PMTUD costs performance of routers on the path. > It may be of little effort at the end systems, but not at the > choke points. > > I disagree. The chole point has to do everything anyway No, it does not have to generate so many error packets, unless PMTUD generates so many unnecessarily large packets. > Correct perhaps. Effecient, no. > > The reality these days is that even routing, not merely switching, > is at the line sped. > > It can be, but that is expensive. Real cheap routers don't do line speed > routing for tinygrams even at 10Mbit line speeds. MTU of 576 was already large enough to make it not tinygrams. > And in any case, it isn't > just the routers (or switches) that matter - it is also the end systems > that have do deal with more packets than are needed. The end system has all the power to decode the content, which is often as complex as MPEG2, of packets, > How can you disagree? > > I am me. I can disagree with practically anything... That's a practically meaningless disagreement. > I do not require that the world be perfect, and that everything work. > If PMTUD will work for me for TCP, and occasional other stream based > applications, then I will take that benefit, and not moan about how > it doesn't work for multicast, or the DNS. The major stream of the real world, however, is that for TV broadcasting. Moreover, TCP performs just fine with MTU of 1280, especially within a LAN environment, as you mentioned, where the latency is low. > Unless you have a better > scheme that will work for multicast and/or the DNS, and which will > automatically allow packets to grow to the real PMTU then I will keep > what works for some traffic, and worry about the other traffic once > someone figures out how to do it. You are requiring me to make the world perfect. I can make it so (or consistent, at least) by removing PMTUD entirely. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 05:03:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA13498 for ipng-dist; Tue, 18 Aug 1998 04:58:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA13491 for ; Tue, 18 Aug 1998 04:58:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA06384 for ; Tue, 18 Aug 1998 04:57:59 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA13686 for ; Tue, 18 Aug 1998 04:57:56 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA06610; Tue, 18 Aug 1998 07:57:21 -0400 (EDT) Message-Id: <199808181157.HAA06610@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 6234) Document Action: Proposed TLA and NLA Assignment Rules to Informational Date: Tue, 18 Aug 1998 07:57:21 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft Proposed TLA and NLA Assignment Rules as an Informational RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 06:18:36 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA13597 for ipng-dist; Tue, 18 Aug 1998 06:08:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA13590 for ; Tue, 18 Aug 1998 06:08:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA13784 for ; Tue, 18 Aug 1998 06:08:16 -0700 Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA09799 for ; Tue, 18 Aug 1998 06:08:17 -0700 (PDT) Received: from hochstetter (hochstetter.argon.com [208.234.161.53]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id JAA29221; Tue, 18 Aug 1998 09:08:00 -0400 (EDT) Message-Id: <3.0.3.32.19980818085426.009ad440@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 18 Aug 1998 08:54:26 -0400 To: Masataka Ohta From: Frank Kastenholz Subject: (IPng 6236) Re: Reg: PATH MTU discovery Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199808180514.OAA05933@necom830.hpcl.titech.ac.jp> References: <3.0.3.32.19980815153341.00964270@shultz.argon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:14 PM 8/18/98 JST, Masataka Ohta wrote: >:>And when it comes to the worst case, I think everyone will agree that >:>generating a Packet Too Big message is more work for a router. >: >:No. Everyone will not agree. The router I'm building right now >:can generate ICMP error messages (including the broken packet's >:entire header) much faster than it can parse packets in its fast >:path, to say nothing of the slow path... > >So, you say you can parse the entire header so fast to detect the >tail of the header sequence. no. the tradeoff to which i responded was "no-options and generate icmp error messages" vs "look for a pmtu option someplace in the packet header/options and then modify it". i can _not_ find the end of the option list easily. i can not find the proposed mtu option easily. >:> this is even more problematic for asic-based routers which >:> usually do not process options (v4 or v6) in the asic. > >you'll have no difficulty to let your router process the proposed >options even faster. with options (v4 or v6), you don't know that option X is always present and always at a fixed offset in the packet. so you have to step through the options one at a time looking at it, deciding if you are interested in it or not, and then going on to the next one. you don't know if an option is not present until you've evaluated all options. thus, if we had the postulated path-mtu-option, the packet processor has to scan the entire option list. in an asic, this scan costs tremendously. once the option is located, once you know exactly where in the byte stream the option exists, then yes putting in the new data value is easy. though in terms of time, it takes my design the same amount of time to either update the option value or generate the icmp packet. // >The problem is that, though you can specify anything and it may >be implemented very fast, it costs. > >Note that my point is that PMTUD is just as bad as the new proposal. both approaches have cost. but the comment that i responded to talked only about "cost to the router". there is a cost to the network for sending the extra icmp messages and the 'too big' packets. but for high-speed asic-based routers, the extra traffic is not an issue; it is an issue if and only if the links get 100% loaded and then only because some other packet is not transmitted ("bandwidth is free, until you run out"). there is also a cost to the end user since their data will move around slower (all those lost packets). but if lots of packets have options in them, then the high-speed routers will divert more packets to the 'slow path', consuming more resources and possibly degrading overall router performance (or worse, stealing cycles that could be used to do routing protocol calculations). frank kastenholz -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 06:18:39 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA13588 for ipng-dist; Tue, 18 Aug 1998 06:08:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA13581 for ; Tue, 18 Aug 1998 06:08:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA13746 for ; Tue, 18 Aug 1998 06:08:00 -0700 Received: from shultz.argon.com (shultz.argon.com [208.234.161.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA09687 for ; Tue, 18 Aug 1998 06:08:02 -0700 (PDT) Received: from hochstetter (hochstetter.argon.com [208.234.161.53]) by shultz.argon.com (8.8.6/8.8.6) with SMTP id JAA29227; Tue, 18 Aug 1998 09:08:01 -0400 (EDT) Message-Id: <3.0.3.32.19980818090609.009b8100@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 18 Aug 1998 09:06:09 -0400 To: ipng@sunroof.eng.sun.com, Telford001@aol.com From: Frank Kastenholz Subject: (IPng 6235) Re: Reg: PATH MTU discovery In-Reply-To: <29d58e5a.35d910e4@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 01:28 AM 8/18/98 EDT, Telford001@aol.com wrote: >I was under the impression that IPv4 routers were supposed >to check the checksum as well as merely decrement the >ttl and update the checksum they do. but that has nothing to do with v6 or this mailing list. but to continue on the tangent for a moment, in asics, the cost of checking the checksum is quite low. with a bit of work it can be made to have 0 net-cost (i.e. if you were to turn off checksum checking, the packets would get processed no faster than if it's on). // >> >And when it comes to the worst case, I think everyone will agree that >> >generating a Packet Too Big message is more work for a router. > >> No. Everyone will not agree. The router I'm building right now >> can generate ICMP error messages (including the broken packet's >> entire header) much faster than it can parse packets in its fast >> path, to say nothing of the slow path... > >The claim is: > >generating an IP header + generating an ICMP header + copying or >setting up pointers to the IP header + 64 bits of the packet that >engenders the ICMP response + setting up some sort of >mac header > >costs more than > >reading and processing the IP header (assumed meaning >of parsing packets in the fast path). > >Sounds really weird and rather hideous. remember, i'm doing this in an asic. in an asic there are things that can be done that can't be done in software. optimization or algorithm design or processor choice or whatever do not let you do something that can't be done in software - they just let you do something easier or faster. frank kastenholz -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 07:20:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA13680 for ipng-dist; Tue, 18 Aug 1998 07:10:57 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id HAA13673 for ; Tue, 18 Aug 1998 07:10:49 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with ESMTP id HAA03149; Tue, 18 Aug 1998 07:10:47 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id HAA03605; Tue, 18 Aug 1998 07:09:33 -0700 (PDT) Date: Tue, 18 Aug 1998 07:09:33 -0700 (PDT) From: Mukesh Kacker Message-Id: <199808181409.HAA03605@lucknow.eng.sun.com> To: bound@zk3.dec.com Subject: (IPng 6237) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: mukesh@lucknow.eng.sun.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I have some concerns that the new text used to describe the new sockaddr_storage structure and the philosophy behind it may not be reflected strongly enough in this new Basic API draft. It does reflect verbatim, the structure proposed by Erik Nordmark in IPng 5841 (and got support from Tim Hartrick and Rich Stevens in IPng 5844 and 5854), it has potential for mis-interpretation leading to error prone implementations. More specifically, the sockaddr_storage structure can use a specific implementation example that illustrates use of a forcing alignment along a specific boundary. Also, in its current form, it seems to suggest that alignment fields go after a char[] array and using that to force alignment can get tricky and may require padding both before and after such an alignment-forcing field. Even if the alignment requirement is derived from some field in the middle of a data structure, (e.g. sin6_addr field in sockaddr_in structure), the more convenient way is to derive from that alignment requirement a boundary for the start of the data structure and pad at the end. I did do a quick draft of some suggested changes which try to spell out the ideas and have included those below for consideration. [ They might be a bit verbose but I hope they get the point across :-) I would welcome others to come up with more compact presentation. I have also suggested changes to some text unrelated to sockaddr_storage but rather to sockaddr_in6 which may be a related nit, and that can also be considered an independent clarification. ] Comments/improvements from others are welcome too. ===========================about sockaddr_storage=========== > > > One simple additions to the sockets API can help application writers. | > REPLACE above text with following: " One simple additions to the sockets API can help application writers is the "stuct sockaddr_storage" which can be designed with the following goals. It has, - storage sufficient for storing all supported protocol specific socket address data structures (e.g. sockaddr_in, sockaddr_in6) - aligned at an appropriate boundary so pointers to casts to protocol specific socket address data structures can access their fields without aligment problems. " > struct sockaddr_storage { > char _ss_maxsize[128]; /* Implementation Specific */ > /* > * Plus implementation specific fields to ensure sufficient > * alignment. > * > */ > }; > REPLACE above with following. " #define _SS_MAXSIZE 128 /* Implementation specific max size */ struct sockaddr_storage { /* * Implementation specific fields to ensure sufficient * alignment. * (Assume the size(s) above adds up to ) */ char _ss_padsize[_SS_MAXSIZE-]; /* Implementation Specific size */ }; As an example in an Implementation where the strictest alignment needed needed among all protocols supported by the Socket interface is 64 bits, an implementation of "struct sockaddr_storage" could be #define _SS_MAXSIZE 128 /* max size of 128 */ struct sockaddr_storage { int64_t _ss_align64; /* 64 bits or 8 octets */ char _ss_padsize[_SS_MAXSIZE - 8] /* pad of 120 octets */ }; " > This structure solves the problem that you don't know how big the | > retrieve buffer for a socket address structure needs to be until you | > have received that structure (e.g., getpeername()). Also, much | > existing code assumes that any socket address structure can fit in a | > generic sockaddr structure. While this has been true for IPv4 socket | > address structures, it has always been false for Unix domain socket | > address structures (but in practice this has not been a problem) and | > it is also false for IPv6 socket address structures (which can be a | > problem). | > > So now an application can to the following: | > > struct sockaddr_storage ss; > .... > struct sockaddr_in6 *sin6; > > sin6 = (struct sockaddr_in6 *) &ss; > > > Each implementation can add whatever fields it needs to get appropriate | > aligment. | > MODIFY last sentence above to following: " Each implementation is free to add fields to sockaddr_storage structure in manner that forces compilers to ensure the alignment of storage for a data structure fields at a desired level of alignment as required by the rules of the C language. The above example illustrates an implementation specific field "_ss_align64" used to force a 64-bit alignment which covers proper alignment good enough for needs of sockaddr_in6 (IPv6), sockaddr_in (IPv4) and sockaddr_un (Unix domain) address data structures " ============== about sockaddr_in6================== Text elsewhere about sockaddr_in6 (not modified in this update to draft) in the text states: > The ordering of elements in this structure is specifically designed > so that the sin6_addr field will be aligned on a 64-bit boundary. > This is done for optimum performance on 64-bit architectures. > I would suggest extending the first sentence to clarify an unstated assumption so above text looks like following The ordering of elements in this structure is specifically designed so that the sin6_addr field will be aligned on a 64-bit boundary when data structure storage starts on a 64-bit boundary. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is done for optimum performance on 64-bit architectures. ============================================================== - Mukesh Kacker Sun Microsystems Inc Internet Engineering mukesh.kacker@eng.sun.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 09:41:23 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA14133 for ipng-dist; Tue, 18 Aug 1998 09:31:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA14124 for ; Tue, 18 Aug 1998 09:30:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA07784 for ; Tue, 18 Aug 1998 09:30:46 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA02685 for ; Tue, 18 Aug 1998 09:30:43 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA17086; Tue, 18 Aug 1998 11:32:56 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA10975; Tue, 18 Aug 98 11:30:30 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id LAA01227; Tue, 18 Aug 1998 11:30:30 -0500 Message-Id: <199808181630.LAA01227@cubbie.aud.alcatel.com> Date: Tue, 18 Aug 1998 11:30:29 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6238) Re: Discovering PMTU an intermediate approach To: ipng@sunroof.eng.sun.com Cc: chirgi@cubbie.aud.alcatel.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: tO83UkrS/GhUf+/yyQoiLw== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all, sorry for barging in (but I sincerely believe I followed most of the replies regarding MTU discovery. I just want to add few my 2 cents worth.... as usual hot-debates are welcome (but dont expect me to reply promptly excuse me for that :-))) In my view (my apologies if some one already discussed the following): It would be useful to start with 576 bytes (as all IPv6 nodes have to implement this without exception to the best of knowledge???) Thus, we can have an algo that is similar to slow-start of TCP. Start with 576 then increase it by a delta (yep, how to choose delta? any ideas?) till you recieve a ICMP MTU exceeded error message. The delta has to be chosen appropriately that such that the 576 + (n-1)*delta < PMTU < 576 + n*delta is always true.. (I dont know how feasible it is, as I dont have any typical values, but I would like any feedback on this, thanks) By the above scheme we always have *only one* ICMP error message indicating the PMTU but at the cost of 1. choosing delta 2. some fragmention of packets at the source node during initial detection phase (but the packets are guaranteed to go through till PMTU is exceeded) The above scheme *assumes* the following: 1. Its better to get initial packets fragmented at the source node itself (as required by IPv6) and keep the transfer of the info (datagrams) going.. rather than have a maximum of N (yep, maximum but not always) error messages from the intermediate routes, where N being number of intermediate links. 2. Signalling involving Error messages indicating MTU exceeded, are more costly (in terms of delay and may be bandwidth also) 3. Dynamic path changes make RSVP OPWA-like for discovering MTU some what costlier (in terms of processing, delay) and make path change detection necessary. with best regards to all, Girish -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 10:28:19 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA14234 for ipng-dist; Tue, 18 Aug 1998 10:15:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA14227 for ; Tue, 18 Aug 1998 10:15:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA23481 for ; Tue, 18 Aug 1998 10:15:16 -0700 Received: from mail.hq.tellabs.com (tlab-138-111-160-101.tellabs.com [138.111.160.101]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA01719 for ; Tue, 18 Aug 1998 10:15:16 -0700 (PDT) Received: from tellabs.com ([138.111.39.131] (may be forged)) by mail.hq.tellabs.com (8.8.6/8.8.6) with ESMTP id MAA08285; Tue, 18 Aug 1998 12:15:03 -0500 (CDT) Message-ID: <35D9B850.CB3B3A77@tellabs.com> Date: Tue, 18 Aug 1998 13:22:38 -0400 From: Raghu Vadapalli Organization: Tellabs Inc, Hawthorne X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: chirgi@aud.alcatel.com, ipng@sunroof.eng.sun.com Subject: (IPng 6239) Re: Discovering PMTU an intermediate approach References: <199808181630.LAA01227@cubbie.aud.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi!!!! Regarding ur proposal 1. Wastage of BW if the LINKS can really support more than what u start with. 2. This what PMTU6 does beofe the conn. But not with the initial value of 576. 3. The PMTU converges faster . As the DELTA in that case is a variable and is a better approximate. right. 4. conn. latency. -Raghu. chirgi@aud.alcatel.com wrote: > Dear all, > > sorry for barging in (but I sincerely believe I followed most of > the replies regarding MTU discovery. > > I just want to add few my 2 cents worth.... > > as usual hot-debates are welcome (but dont expect me to reply promptly > excuse me for that :-))) > > In my view (my apologies if some one already discussed the following): > > It would be useful to start with 576 bytes (as all IPv6 nodes > have to implement this without exception to the best of knowledge???) > > Thus, we can have an algo that is similar to slow-start of TCP. > Start with 576 then increase it by a delta (yep, how to choose delta? > any ideas?) till you recieve a ICMP MTU exceeded error message. The delta > has to be chosen appropriately that such that the > > 576 + (n-1)*delta < PMTU < 576 + n*delta is always true.. > > (I dont know how feasible it is, as I dont have any typical values, > but I would like any feedback on this, thanks) > > By the above scheme we always have *only one* ICMP error message indicating > the PMTU but at the cost of 1. choosing delta 2. some fragmention of packets > at the source node during initial detection phase (but the packets are guaranteed > to go through till PMTU is exceeded) > > The above scheme *assumes* the following: > > 1. Its better to get initial packets fragmented at the source node itself > (as required by IPv6) and keep the transfer of the info (datagrams) going.. > rather than have a maximum of N (yep, maximum but not always) error messages > from the intermediate routes, where N being number of intermediate links. > > 2. Signalling involving Error messages indicating MTU exceeded, > are more costly (in terms of delay and may be bandwidth also) > > 3. Dynamic path changes make RSVP OPWA-like for discovering MTU > some what costlier (in terms of processing, delay) and make path change detection necessary. > > with best regards to all, > Girish > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 10:41:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA14298 for ipng-dist; Tue, 18 Aug 1998 10:27:50 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id KAA14291 for ; Tue, 18 Aug 1998 10:27:26 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with ESMTP id KAA24902 for ; Tue, 18 Aug 1998 10:27:25 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA07520 for ipng@sunroof.eng.sun.com; Tue, 18 Aug 1998 10:26:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA14264 for ; Tue, 18 Aug 1998 10:26:12 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA27119 for ; Tue, 18 Aug 1998 10:26:09 -0700 Received: from wacko.redbacknetworks.COM (wacko.redbacknetworks.com [155.53.130.200]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA08958 for ; Tue, 18 Aug 1998 10:26:06 -0700 (PDT) Received: from rino.redbacknetworks.com (maui.redbacknetworks.com [155.53.144.15]) by wacko.redbacknetworks.COM (8.8.5/8.8.5) with ESMTP id KAA06601; Tue, 18 Aug 1998 10:24:45 -0700 (PDT) Message-ID: <35D9B9F6.EC970AAA@redbacknetworks.com> Date: Tue, 18 Aug 1998 10:29:26 -0700 From: Jim Solomon Organization: RedBack Networks X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: agenda@ietf.org CC: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com Subject: (IPng 6241) Updated agenda for mobileip and Last Call reminder X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greetings, Just a reminder that we are in MOBILEIP-Working-Group Last Call for Mobile IPv6 (draft-ietf-mobileip-ipv6-06.txt) to Proposed Standard. The IPv6 community is strongly encouraged to make comments before the MOBILEIP working group meeting of Monday morning in Chicago. Regards, Jim & Erik ===== IP Routing for Wireless/Mobile Hosts (mobileip) Monday, 8/24/98, 0930 - 1130 Co-chairs: Erik Nordmark Jim Solomon Agenda: 1. Stuart Jacobs , 15min, Mobile IP and Public Key Based Authentication (draft-jacobs-mobileip-pki-auth-00.txt) 2. Charles Perkins , 15min Mobile IP and DIAMETER (draft-calhoun-diameter-mobileip-00.txt) 3. Shin We , 15min, Reverse Network Address Translators (RAT) (draft-teoyeow-mip-rat-00.txt) 4. Gabriel Montenegro , 10min, Negotiated Address Reuse (NAR) (draft-montenegro-aatn-nar-00.txt) 5. Dave Johnson , 65min, Mobility Support in IPv6 (draft-ietf-mobileip-ipv6-06.txt, draft-ietf-ipngwg-resv-anycast-00.txt) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 11:14:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA14393 for ipng-dist; Tue, 18 Aug 1998 11:03:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA14381 for ; Tue, 18 Aug 1998 11:03:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA10657 for ; Tue, 18 Aug 1998 11:02:57 -0700 Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA03162 for ; Tue, 18 Aug 1998 11:02:57 -0700 (PDT) Received: from rdxsunhost.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1) id AA21437; Tue, 18 Aug 1998 13:05:07 CDT Received: from cubbie.aud.alcatel.com by rdxsunhost.Aud.Alcatel.COM (4.1/SMI-4.1) id AA15232; Tue, 18 Aug 98 13:02:41 CDT Received: from cubbie by cubbie.aud.alcatel.com (SMI-8.6/SMI-SVR4) id NAA01327; Tue, 18 Aug 1998 13:02:41 -0500 Message-Id: <199808181802.NAA01327@cubbie.aud.alcatel.com> Date: Tue, 18 Aug 1998 13:02:41 -0500 (CDT) From: Girish Chiruvolu Reply-To: Girish Chiruvolu Subject: (IPng 6242) Re: Discovering PMTU an intermediate approach To: ipng@sunroof.eng.sun.com Cc: chirgi@cubbie.aud.alcatel.com Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: gyQTsEvEMTrIBJBof/HaXQ== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thats wonderful, so we all agree that slow-start TCP-like algo that uses exponential back-off PMTU6 (I never saw this 'PMTU6' word, may be I missed it, but is it rfc 1981?, should be a draft more recent than that...) is good and converges faster, yes? (I just avoided mention of exponential-backoff in previous disc.) so using 576 as initial value but with PMTU6, should set aside all the arguments :-)))) I believe the discussion was started with 'iterative MTU' discovery and proved that it was inefficient by many including original author (of the discussion thread)!! If one-pass method is examined, one needs to detect dynamic path changes and that is an involved process. However, one may utilize (a variant of ) RSVP facilities, as well.... Link BW will not be wasted except for header overhead (a little more overhead) (assuming the source does fragmentation to the initial packets and it intends to utilize the BW to maximum extent possible) Yep, elaborate MTU discovery does not make sense if one were to send a few datagrams on and off. One might as well use the plain (brute-force) MTU discovery (i.e., keep sending min of max-es of MTUs so far indicated by any intermediate node during detection phase). By the way, (this may be off the purview of this mailing list) can any one let me know what is the MTU (or likely to be used) for mobile wirless IPs (at the wirless interface)? I remember somwhere around 276 bytes (but thats in non-IP env). Thats all from me for a while folks, Thanks a lot with best wishes, Girish > Date: Tue, 18 Aug 1998 13:22:38 -0400 > From: Raghu Vadapalli > Mime-Version: 1.0 > To: chirgi@aud.alcatel.com, ipng@sunroof.Eng.Sun.COM > Subject: Re: (IPng 6238) Re: Discovering PMTU an intermediate approach > Content-Transfer-Encoding: 7bit > > Hi!!!! > > Regarding ur proposal > > 1. Wastage of BW if the LINKS can really support more than what u start with. > 2. This what PMTU6 does beofe the conn. But not with the initial value of 576. > 3. The PMTU converges faster . As the DELTA in that case is a variable and > is a better approximate. right. > 4. conn. latency. > > -Raghu. > chirgi@aud.alcatel.com wrote: > > > Dear all, > > > > sorry for barging in (but I sincerely believe I followed most of > > the replies regarding MTU discovery. > > > > I just want to add few my 2 cents worth.... > > > > as usual hot-debates are welcome (but dont expect me to reply promptly > > excuse me for that :-))) > > > > In my view (my apologies if some one already discussed the following): > > > > It would be useful to start with 576 bytes (as all IPv6 nodes > > have to implement this without exception to the best of knowledge???) > > > > Thus, we can have an algo that is similar to slow-start of TCP. > > Start with 576 then increase it by a delta (yep, how to choose delta? > > any ideas?) till you recieve a ICMP MTU exceeded error message. The delta > > has to be chosen appropriately that such that the > > > > 576 + (n-1)*delta < PMTU < 576 + n*delta is always true.. > > > > (I dont know how feasible it is, as I dont have any typical values, > > but I would like any feedback on this, thanks) > > > > By the above scheme we always have *only one* ICMP error message indicating > > the PMTU but at the cost of 1. choosing delta 2. some fragmention of packets > > at the source node during initial detection phase (but the packets are guaranteed > > to go through till PMTU is exceeded) > > > > The above scheme *assumes* the following: > > > > 1. Its better to get initial packets fragmented at the source node itself > > (as required by IPv6) and keep the transfer of the info (datagrams) going.. > > rather than have a maximum of N (yep, maximum but not always) error messages > > from the intermediate routes, where N being number of intermediate links. > > > > 2. Signalling involving Error messages indicating MTU exceeded, > > are more costly (in terms of delay and may be bandwidth also) > > > > 3. Dynamic path changes make RSVP OPWA-like for discovering MTU > > some what costlier (in terms of processing, delay) and make path change detection necessary. > > > > with best regards to all, > > Girish > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 13:50:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA14615 for ipng-dist; Tue, 18 Aug 1998 13:38:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA14608 for ; Tue, 18 Aug 1998 13:38:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA23146 for ; Tue, 18 Aug 1998 13:38:12 -0700 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA05222 for ; Tue, 18 Aug 1998 13:38:12 -0700 (PDT) Received: from inner.net (annex10-u18.itd.nrl.navy.mil [132.250.82.18]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA21072; Tue, 18 Aug 1998 16:30:22 -0400 (EDT) Message-Id: <199808182030.QAA21072@itd.nrl.navy.mil> To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 6244) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Fri, 14 Aug 1998 12:33:33 EDT." <199808141633.AA03110@wasted.zk3.dec.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 18 Aug 1998 16:29:24 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808141633.AA03110@wasted.zk3.dec.com>, you write: > - adding AI flags from getnodebyname to getaddrinfo. The reason > is this is not our spec but POSIX's, if folks feel we can change > it still I would like some discussion. This is bad. >- Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. This is bad. >- Changed 3.10 to use generic storage structure to support holding > IPv6 addresses and removed the SA_LEN macro. This is bad. >- Changed getnodebyname to getipnodebyname, getnodebyaddr to > getipnodebyaddr, and added MT safe error code to funtion parameters > in section 6. This is bad. How many of these changes came from people who had issues while writing code, and how many of them came from people who do not write code? -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 14:08:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA14643 for ipng-dist; Tue, 18 Aug 1998 13:58:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA14636 for ; Tue, 18 Aug 1998 13:58:28 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA29450; Tue, 18 Aug 1998 13:58:24 -0700 Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA17857; Tue, 18 Aug 1998 13:58:24 -0700 (PDT) Received: from inner.net (annex10-u18.itd.nrl.navy.mil [132.250.82.18]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA21499; Tue, 18 Aug 1998 16:57:36 -0400 (EDT) Message-Id: <199808182057.QAA21499@itd.nrl.navy.mil> To: Mukesh Kacker cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 6245) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Tue, 18 Aug 1998 07:09:33 PDT." <199808181409.HAA03605@lucknow.eng.sun.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 18 Aug 1998 16:56:33 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808181409.HAA03605@lucknow.eng.sun.com>, you write: > I have some concerns that the new text used to describe the new >sockaddr_storage structure and the philosophy behind it may not be >reflected strongly enough in this new Basic API draft. >It does reflect verbatim, the structure proposed by Erik Nordmark >in IPng 5841 (and got support from Tim Hartrick and Rich Stevens in >IPng 5844 and 5854), it has potential for mis-interpretation leading >to error prone implementations. Note that these alignment problems did not exist in the previous draft where this was a union containing a struct sockaddr. While I'm not at all convinced that the previous draft's union and its definition were a problem (and I have lots of code that backs up that opinion), it seems to me that Erik's original concern would be far better addressed by something like: union sockaddr_union { struct sockaddr sa; char __pad[128]; } Than by what's in Jim's draft. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 15:28:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA14818 for ipng-dist; Tue, 18 Aug 1998 15:18:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA14806 for ; Tue, 18 Aug 1998 15:18:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA23488 for ; Tue, 18 Aug 1998 15:18:41 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA07020 for ; Tue, 18 Aug 1998 15:18:41 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id PAA20233; Tue, 18 Aug 1998 15:18:40 -0700 (PDT) Message-Id: <3.0.5.32.19980818151716.00a1f750@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 18 Aug 1998 15:17:16 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6246) Draft IPng W.G. Agenda Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the proposed agenda for the IPng sessions at the Chicago IETF. Both sessions will be Multicast. Suggestions for changes/additions/etc to us. Bob Hinden / Steve Deering -------------------------------------------- IPng Meeting Agenda ------------------- TUESDAY, August 25, 1998, 1545-1800 (Sheraton 5) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) UNH Interoperability Testing Report / W. Lenharth (5 min) Document Status / R. Hinden (10 min) New Documents to Draft Standard / R. Hinden (5 min) IPv6 Address Assignment Status / R. Hinden, R. Fink (10 min) IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min) Mobile IPv6 Status / D. Johnson (10 min) IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung (30 min) DNS Extension to Support IP Version 6 / M. Crawford (30 min) THURSDAY, August 27, 1998, 0900-1130 (Sheraton 4) Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (15 min) Jumbograms / S. Deering (15 min) Maximum header length (or minimum assured payload length) / M. Ohta (15 min) & Make PMTUD purely optional Router Renumbering / M. Crawford (15 min) Multicast Listener Discovery Protocol / S. Deering (10 min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 15:49:58 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA14850 for ipng-dist; Tue, 18 Aug 1998 15:39:22 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA14843 for ; Tue, 18 Aug 1998 15:39:14 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1a+Sun/8.9.1) with ESMTP id PAA11731; Tue, 18 Aug 1998 15:39:12 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id PAA03922; Tue, 18 Aug 1998 15:37:57 -0700 (PDT) Date: Tue, 18 Aug 1998 15:37:57 -0700 (PDT) From: Mukesh Kacker Message-Id: <199808182237.PAA03922@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, cmetz@inner.net Subject: (IPng 6247) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, some comments follow > > Note that these alignment problems did not exist in the previous draft where > this was a union containing a struct sockaddr. > While I'm not at all convinced that the previous draft's union and its > definition were a problem > I must confess I was not "active" in following the previous draft as I was busy with other things and have not followed all the problems people may have articulated about sockaddr_union (and currently don't want to search the archives :-)). I do however see some different problems with it. Socket API in BSD has been a multiprotocol API architecture. People could insert new protocols by inserting a new netproto/protocol.h (e.g , ) header independent of The sockaddr_union as it was presented in previous draft was the first instance that architecture was being broken by a requirement to modify data structures when introducing new protocols and potentially introduce packaging and binary compatibility issues. You can question the real-life need for any protocol other than IP :-) but it is important to retain the ability of people to tinker and research with new ones, plug into existing APIs without affecting life for rest of OS. For the problem that it was attempting to solve, it seemed like too big a hammer and I guess people wanted an alternate solution. I am not sure what reason made people get away from it but I do think that is the right direction. > (and I have lots of code that backs up that opinion), I believe if you ported tested your code over multiple platform ABIs and multiple compilers and thought long term evolution of products, you may have different opinions. The alignment issues and problems caused by them are real. Industry folks who have dealt with processor specific or other transitions such as LP64 worry about these things. > it seems to me that Erik's original concern would be far better addressed by > something like: > > union sockaddr_union { > struct sockaddr sa; > char __pad[128]; > } > > Than by what's in Jim's draft. > I don't think that takes care of alignment issues at all. In the worlds of Sockets-without-SA_LEN, I believe the compiler doing minimally sufficient alignment will only be constrained to layout above data structure on a "short" (2 bytes in most platforms I would guess) aligned boundary. In Sockets-with-SA_LEN, world the compiler would only be constrained to lay that one out on a "u_char" aligned boundary (on most platforms 1 byte and that implies no alignment restriction.) If I understand correctly, the need here is to have a data type that can store any (or atleast sockaddr_in, sockaddr_in6, and sockaddr_un) Socket address data structures as those three protcols are bundled on most Unix based platforms. The solution should control the alignment to be compatible for all of those and more. I think with current C translators, the "largest" alignment many current platforms can do is 64-bits and they will choose to do that. Some may even choose 128 bits (PowerPC processor ABI supported 16 byte alignment, not sure if any compilers did). These choices can be made by people's desires for binary compatibility and the platform ABI. Those choices can affect that efficiency of IN6_* macros etc. and other internals of API implementation. I think that is the goal in Erik's proposal and my refinement of it. You seem to have working code using sockaddr_union and we all know the pains of having to modify seemingly working code. My sympathies :-). But ability to learn and refine based on peer review and implementation diversity and achieving rough consensus is one of the strengths of the IETF process. I hope that will be inspiration for you in the few days/nights hacking it may take you to convert that code to use whatever emerges. :-) Take care. - Mukesh Kacker Internet Engineering mukesh.kacker@eng.sun.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 15:50:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA14863 for ipng-dist; Tue, 18 Aug 1998 15:46:05 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA14856 for ; Tue, 18 Aug 1998 15:45:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA01959; Tue, 18 Aug 1998 15:45:48 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA21772; Tue, 18 Aug 1998 15:45:49 -0700 (PDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id MAA07811; Tue, 18 Aug 1998 12:13:43 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5) id PAA13784; Tue, 18 Aug 1998 15:45:36 -0700 (PDT) From: Vivek Kashyap Message-Id: <199808182245.PAA13784@eng4.sequent.com> Subject: (IPng 6248) Re: Reg: PATH MTU discovery To: Erik.Nordmark@Eng Date: Tue, 18 Aug 1998 15:45:36 -0700 (PDT) Cc: viv@sequent.com, smb@research.att.com, raghu.vadapalli@tellabs.com, bzill@microsoft.com, peterdd@gto.net.om, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Erik Nordmark" at Aug 17, 98 06:13:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > However, in IPv6 I'd expect almost all hosts (according to RFC 1970) to have > nothing but default routes and a per-host destination cache. For such hosts > your proposal wouldn't provide any benefits, right? > > Erik > Erik, The per host destination cache for off-link destinations is indistinguishable from a routing table. The per host destination cache has a pointer to the on-link router for off-link destinations. If there is nothing distinguishing two destination host entries other than the destination then they can be coalesced into one by making then entry a per 'net' entry-- which is what I propose. 'net' = the route derived from the prefix match returned by the choke pointand the destination address. The basic idea that I have proposed is : . PMTUD as currently defined requires per host information to be kept. This can be a per host cache, though cache has the side effect of attrition, and hence I would just keep the information. Consider a few thousand connections (my concern is for large servers) active simultaneously. So my cache would grow as more connections are made and decrease as the connections terminate. for e.g. freeBSD implementation of cloned routes. * proposal * Modify the DTB message received to return the prefix it used to find the outgoing route. This prefix tells the host the 'net' and its bottleneck. If behind this choke point are a few 1000 end hosts [the (web)server is at the head quarters and there are clients in location X] I don't have to keep the information about each one of them if they all are bottlnecked at the same router. One entry will do. Currently the multiple entries (in routing table or the destination cache) will have duplicated information in this situation. e.g. with the above change one would not see 1000 routes (or destination cache entries) in netstat but see only a few that are needed. The DTB modification as defined in is backwards compatible with the currently ICMP6 DTB message. . Currently for each host the PMTU discovery process is attempted every 10 minutes (default) to see if there is an increase. * proposal * With 'net' (for definition of net see the draft and my previous mail) entry the only one detection needs to be done and not for every host. Essentially the benefits to be realised by the change suggested by me are : . Aggregation of paths having the same PMTU . Reduction in resources utilized to store the Path MTU . Speed up in the MTU updates to all connections on a host rather than each discovering it independently. . On deletion of a network route on the host, each of the derived routes/paths has to be deleted too. With the reduction in the number of such caches it would take less time and simpler algorithms can be used. . utilities need to list a smaller set of routes. eg. netstat. . routing protocols need to exchange smaller tables and/or not weed through a large set of derived routes. For routing topologies that are not strictly hierarchical a little more effort is required. I have detailed that in my previous mail. Vivek > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 20:27:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA15261 for ipng-dist; Tue, 18 Aug 1998 20:23:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA15254 for ; Tue, 18 Aug 1998 20:22:54 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA29407 for ; Tue, 18 Aug 1998 20:22:53 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id UAA17577 for ; Tue, 18 Aug 1998 20:19:20 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id DA18926; Wed, 19 Aug 1998 13:06:13 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Vivek Kashyap Cc: iprsvp@yahoo.com, ipng@sunroof.eng.sun.com Subject: (IPng 6249) Re: Reg: PATH MTU discovery In-Reply-To: Your message of "Tue, 18 Aug 1998 15:45:36 MST." <199808182245.PAA13784@eng4.sequent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Aug 1998 13:06:07 +1000 Message-Id: <17374.903495967@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 18 Aug 1998 15:45:36 -0700 (PDT) From: Vivek Kashyap Message-ID: <199808182245.PAA13784@eng4.sequent.com> Modify the DTB message received to return the prefix it used to find the outgoing route. That doesn't work. Eg: consider a very common case. Assume I am sending packets to you. My packets traverse an FDDI to my FDDI exit point, there they hit a 100Mbit ether, the PMTU decreases to 1500, and from that point (we'll assume) that's OK, and the 1500 works to get the rest of the way to you (for the purposes of this example it makes no difference). I send my 4K packet over the FDDI, it hits the choke point, the "too big" ICMP comes back, and using your model, it includes the prefix of the route used ... in this instance that is 0/0. What you've accomplished by that is to tell my node that the PMTU to everywhere is 1500, which is patently not true, I can reach lots of local stuff with a 4K PMTU (and since that's my outgoing interface MTU, I have never received a "too big" from anywhere for any of those destinations, hence I have no mask information to apply to them). Further, as far as my host is concerned I have just one route to everything of concern here, the exit path to my local router (we have multple FDDI rings here, I need to traverse 2 or 3 of them to get to the choke point - the local one doesn't have a lot on it directly - mostly all I care about is the router which gets to the bigger campus backbone ring). Now it's true that now I have that smaller PMTU applied to all my local destinations (it seems) I will perform PMTUD on them, and discover that I can actually send larger packets, but just as I'm doing that, I'll also be doing it on my connection to you, and re-learing the smaller PMTU to 0/0 all over again, and the whole process will repeat. This is just a basic example of the true problem, which is that there can be holes in routes - that is, a route can cover "everything in this range except ...". For your scheme to work, the ICMP "too big" would need to convey that information - that is, a single mask isn't enough, it needs to be a set of masks, though the sending router could perhaps calculate the biggest single mask which had no "except" blocks to subtract, and send that. Unfortunately, that's not enough - the "too big" ICMP would then need to be examined and modified by every router on the path back to me, as any of those might have exceptions unknown to the router at the choke point which would need to be applied. That is, while my route to your net in general might have a 1500 octet choke point, at some router between my host and the choke point there could be another router with a private backdoor route to some small subset of your hosts (not including the one I am actually communicating with) which avoids the 1500 byte choke point. This is really the same problem as caused "network unreachable" to be written off as a useless lost cause years ago, and to be reinterpreted to mean "host unreachable" - the complications of attempting to correctly convey network mask information are simply too difficult, too expensive, and in practice, often too useless, to be worth the bother. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 18 22:21:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA15319 for ipng-dist; Tue, 18 Aug 1998 22:10:00 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id WAA15312 for ; Tue, 18 Aug 1998 22:09:47 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id WAA07146; Tue, 18 Aug 1998 22:09:41 -0700 (PDT) Date: Tue, 18 Aug 1998 22:09:05 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6250) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: Craig Metz Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808182030.QAA21072@itd.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In message <199808141633.AA03110@wasted.zk3.dec.com>, you write: > > - adding AI flags from getnodebyname to getaddrinfo. The reason > > is this is not our spec but POSIX's, if folks feel we can change > > it still I would like some discussion. > > This is bad. > > >- Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. > > This is bad. > > >- Changed 3.10 to use generic storage structure to support holding > > IPv6 addresses and removed the SA_LEN macro. > > This is bad. > > >- Changed getnodebyname to getipnodebyname, getnodebyaddr to > > getipnodebyaddr, and added MT safe error code to funtion parameters > > in section 6. > > This is bad. > > How many of these changes came from people who had issues while writing > code, and how many of them came from people who do not write code? I don't see a major problem with any of the changes and I think I suggested a fair number of them. And when I don't hack on the IPv6 implementation I work on convincing app developpers to port to the IPv6 APIs thus I end up having to explain this stuff a lot! 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 Aug 19 10:54:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA16423 for ipng-dist; Wed, 19 Aug 1998 10:41:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA16416 for ; Wed, 19 Aug 1998 10:41:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA24103 for ; Wed, 19 Aug 1998 10:41:16 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA13519 for ; Wed, 19 Aug 1998 10:41:16 -0700 (PDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id HAA12347; Wed, 19 Aug 1998 07:09:18 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5) id KAA26957; Wed, 19 Aug 1998 10:41:12 -0700 (PDT) From: Vivek Kashyap Message-Id: <199808191741.KAA26957@eng4.sequent.com> Subject: (IPng 6253) Re: Reg: PATH MTU discovery To: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 19 Aug 1998 10:41:11 -0700 (PDT) Cc: viv@sequent.com, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: <17374.903495967@munnari.OZ.AU> from "Robert Elz" at Aug 19, 98 01:06:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, No, it works. In the simplified statement I mentioned that DTB message received will return the prefix used to find the outgoing route but as specified in the earlier more detailed mail (and the draft) the case of a default route/host route are to be taken to be equivalent for this change. So in this case the use of the default route by the FDDI exit point will return 0/0 ( actually the mask code,not the mask, will be 128 as per my draft for backward compatibility), and will be taken to be equivalent to a host route specification. This is same as how it would work for this situation as per RFC1981 too. Excerpt from the draft : --------- 4.4 Case 4 If the Datagram Too Big message returns the code indicating that the router used the default route, it may be taken equivalent to the indication of the use of a host route. If the information returned indicates a more general route than the route that was used then the information must be discarded and it be considered to be a host route mask. The local routing information is received using a routing protocol or set up by an administrator and must not be overridden. 5. Security considerations If the Datagram Too Big message returns a more general route than was used by the host, the indication is taken equivalent to the host route mask. This blocks the host from being fed faulty network information. The host may however be sent Datagram Too Big messages indicating the default route. The end host will end up creating host routes instead of subnet routes. This is no different from what happens now. A code that indicates a more precise route does not have any effect on theflow of data or the path MTU information related to the path. ----------- The change is very simple and it works fine in almost all cases. There is some complication in 2 specific topologies and those require some extra effort. In these situations the problem is that the increase of PMTU may not be detected. I have appended the solution and the problem below. And one can always avoid these situations (for e.g. in an intranet). Another aspect that I would like to specify is the options or 'type' of path MTU one may need to use. . an options is not to use Path MTU -- always use 1280 . PMTU_DEFAULT -- as defined in draft draft-kashyap-too-big-00.txt. . PMTU_NET -- as defined in the above draft and including the solution discussed below . PMTU_HOST -- as defined in RFC 1981 (if you want to) . PMTU_CONNECTION -- If an application needs/wants to determine the path MTU and act upon it based on its requirements. The system passes the information received to the application. The application may record it in the connection or create 'host/route' routes for its use. The two topologies are : ----------------- > Consider the following: > > Currently the end host receives a DTB message for > every host that lies beyond a particular router which > has the link that determines the path MTU. This > information, instead of being shared, is rediscovered > when a connection is made to any host beyond the > router. With servers which can have 1000s of > simultaneous connections any such bottleneck has the > potential of having 100s or 1000s per host path MTU > routes being kept. Furthermore, each of these 'routes' > will test the path for increases every 10 minutes > (default value) even if they had the same router's > outgoing link as the bottleneck. > > A trivial example is a server that happens to be > 'behind' a router that has a lower MTU on one of its > interfaces. If a large part of the cleintelle happens > to pass through that router, the server will end > up having a huge number of routes. > > If all this information could be consolidated in a > single 'route' that would cause the packets to go > through the bottleneck router, the end host would have > to keep only one route and only one packet would be > transmitted every 10 minutes. In essence a small set > of 'net routes' could replace the large number of > per host entries. > > > A slight modification (keeping the format still > compatible to the current one) to the Datagram too > Big, ICMP message can allow the router to send back > the prefix length of the route the router used to > determine the outgoing interface. This information can > then be used by the end host to create a 'net route' > instead of a host route. I have detailed this in the > draft : draft-kashyap-too-big-00.txt > > > However, two situations not covered in the above draft are : > > > (a) H -- R1 -- R2 ----R3 ----- > | > | > |------ > > At R2 there can be two route entries leading to the same > net but with one being more specific that the other. > i.e. the entries could be of the form: > > . A:B:C/48 > . A:B:C:D/64 > > MTU > (b) H --.... R1 --------- R2 --------- R3---- > A:B:C:D A:B: > > At R1 the packet used the more precise route but at the > router R2, which has a smaller mtu, the route entry has > a more general path. > > These topologies are not always a problem but may cause > situations when the correct MTU may not be detected by the > approach in the draft. > > The above two situations can be handled in the following way: > > A. A router always marks entries that have the relationship > as in (a). This is not difficult and can be done when > the route is added. > > > B. Define a hop-by-hop IP option (say P1) that specifies the > lenght of the prefix used by the host. This would be > used sparingly as detailed below. > > A router replies to the host with an ICMP error message in the > following three situations: > > 1. The datagram is too big to sent out the interface (the > standard Datagram too big situation). > > 2. If the situation as in (a) exists. It replies with the > prefix length of the shorter route entry. (possibly a > different message or code can be defined). The router > determines this if the route it is using to send the > datagram is marked. > > 3. If situation as in (b) exists. If the prefix length of > in P1 is shorter than the route prefix in the route > to be used to forward the datagram. > > > > A host sends the P1 packet only when it needs to probe the > route. It need be configured to use the probe packet only if > it ever receives a Datagram too big packet ie. the probe > packets are sent only if a bottleneck has been found. > > > > A host creates (derives a more specific route) a route if it > receives ICMP errors of the above three types: > > 1. Datagram too Big > > The modified DTB message gives the prefix length. The > new route is constructed with the prefix length of > bits taken from the peer's address. See > draft-kashyap-too-big-00.txt for details. > > > 2. On receiving the error as defined in 2 or 3. above, the > host creates a route based on the prefix lenght received. > The route is constructed as in the case above except that > route is marked to indicate the situation as in (a) or (b). > Henceforth the path MTU discovery on this route occurs on a > per host basis. No more probe packets of type P1 are sent > on this path. > > > The above is only an outline. It certainly can be improved. I > believe this approach will have the benefit of keeping the > host resources more manageable and also generate lesser number > of packets overall. > > > Date: Tue, 18 Aug 1998 15:45:36 -0700 (PDT) > From: Vivek Kashyap > Message-ID: <199808182245.PAA13784@eng4.sequent.com> > > Modify the DTB message received to return the prefix it used to > find the outgoing route. > > That doesn't work. > > Eg: consider a very common case. Assume I am sending packets to > you. My packets traverse an FDDI to my FDDI exit point, there they > hit a 100Mbit ether, the PMTU decreases to 1500, and from that point > (we'll assume) that's OK, and the 1500 works to get the rest of the > way to you (for the purposes of this example it makes no difference). > > I send my 4K packet over the FDDI, it hits the choke point, the "too big" > ICMP comes back, and using your model, it includes the prefix of the route > used ... in this instance that is 0/0. > > What you've accomplished by that is to tell my node that the PMTU to everywhere > is 1500, which is patently not true, I can reach lots of local stuff with > a 4K PMTU (and since that's my outgoing interface MTU, I have never received > a "too big" from anywhere for any of those destinations, hence I have no > mask information to apply to them). Further, as far as my host is concerned > I have just one route to everything of concern here, the exit path to my > local router (we have multple FDDI rings here, I need to traverse 2 or 3 > of them to get to the choke point - the local one doesn't have a lot on it > directly - mostly all I care about is the router which gets to the bigger > campus backbone ring). > > Now it's true that now I have that smaller PMTU applied to all my local > destinations (it seems) I will perform PMTUD on them, and discover that I can > actually send larger packets, but just as I'm doing that, I'll also be doing > it on my connection to you, and re-learing the smaller PMTU to 0/0 all over > again, and the whole process will repeat. > > This is just a basic example of the true problem, which is that there can > be holes in routes - that is, a route can cover "everything in this range > except ...". For your scheme to work, the ICMP "too big" would need to > convey that information - that is, a single mask isn't enough, it needs > to be a set of masks, though the sending router could perhaps calculate the > biggest single mask which had no "except" blocks to subtract, and send that. > > Unfortunately, that's not enough - the "too big" ICMP would then need to > be examined and modified by every router on the path back to me, as any > of those might have exceptions unknown to the router at the choke point > which would need to be applied. That is, while my route to your net in > general might have a 1500 octet choke point, at some router between my > host and the choke point there could be another router with a private > backdoor route to some small subset of your hosts (not including the one > I am actually communicating with) which avoids the 1500 byte choke point. > > This is really the same problem as caused "network unreachable" to be > written off as a useless lost cause years ago, and to be reinterpreted to > mean "host unreachable" - the complications of attempting to correctly convey > network mask information are simply too difficult, too expensive, and > in practice, often too useless, to be worth the bother. > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 11:57:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA16536 for ipng-dist; Wed, 19 Aug 1998 11:50:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA16524 for ; Wed, 19 Aug 1998 11:50:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA16350 for ; Wed, 19 Aug 1998 11:50:45 -0700 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA29410 for ; Wed, 19 Aug 1998 11:50:45 -0700 (PDT) Message-ID: <19980819184853.3620.rocketmail@send1e.yahoomail.com> Received: from [138.111.39.131] by send1e; Wed, 19 Aug 1998 11:48:53 PDT Date: Wed, 19 Aug 1998 11:48:53 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6254) Reg: Routing Tables Size . To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All.. How does a typical IPv6 table look like. I am worried about the size of the routing table. As each node can have many interfaces and each with many addresses of size 128 bits. Thanks -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 12:23:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA16600 for ipng-dist; Wed, 19 Aug 1998 12:16:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA16593 for ; Wed, 19 Aug 1998 12:16:42 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA24495 for ; Wed, 19 Aug 1998 12:16:35 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA15320 for ; Wed, 19 Aug 1998 12:16:38 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id PAA23171; Wed, 19 Aug 1998 15:16:36 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA31747; Wed, 19 Aug 1998 15:16:35 -0400 Message-Id: <199808191916.AA31747@wasted.zk3.dec.com> To: "Raghu V.V.J Vadapalli" Cc: ipng Subject: (IPng 6255) Re: Reg: Routing Tables Size . In-Reply-To: Your message of "Wed, 19 Aug 1998 11:48:53 PDT." <19980819184853.3620.rocketmail@send1e.yahoomail.com> Date: Wed, 19 Aug 1998 15:16:35 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu, In our first initial tests the size of the table has not been an issue, but rather how you build it and access it on a 64bit machine anyway. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 12:49:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA16685 for ipng-dist; Wed, 19 Aug 1998 12:42:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA16678 for ; Wed, 19 Aug 1998 12:41:37 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA02602 for ; Wed, 19 Aug 1998 12:41:31 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA28931 for ; Wed, 19 Aug 1998 12:41:22 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id PAA15643; Wed, 19 Aug 1998 15:41:21 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA01067; Wed, 19 Aug 1998 15:41:21 -0400 Message-Id: <199808191941.AA01067@wasted.zk3.dec.com> To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6258) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Tue, 18 Aug 1998 16:29:24 -0300." <199808182030.QAA21072@itd.nrl.navy.mil> Date: Wed, 19 Aug 1998 15:41:21 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, >> - adding AI flags from getnodebyname to getaddrinfo. The reason >> is this is not our spec but POSIX's, if folks feel we can change >> it still I would like some discussion. > > This is bad. I agree with you and have no intention of updating getaddrinfo without support from either XNET or POSIX. >>- Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. > > This is bad. Why? >>- Changed 3.10 to use generic storage structure to support holding >> IPv6 addresses and removed the SA_LEN macro. > > This is bad. Why? >>- Changed getnodebyname to getipnodebyname, getnodebyaddr to >> getipnodebyaddr, and added MT safe error code to funtion parameters >> in section 6. > This is bad. Why? > How many of these changes came from people who had issues while writing code, >and how many of them came from people who do not write code? All the input came from folks implementing the API so I assume they all write code. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 12:49:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA16651 for ipng-dist; Wed, 19 Aug 1998 12:37:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA16643 for ; Wed, 19 Aug 1998 12:37:31 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA00153 for ; Wed, 19 Aug 1998 12:35:52 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA25821 for ; Wed, 19 Aug 1998 12:35:43 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id PAA31513; Wed, 19 Aug 1998 15:35:09 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00594; Wed, 19 Aug 1998 15:35:09 -0400 Message-Id: <199808191935.AA00594@wasted.zk3.dec.com> To: kuznet@ms2.inr.ac.ru Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6256) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Sun, 16 Aug 1998 19:35:29 +0400." <199808161535.TAA18981@dee.inr.ac.ru> Date: Wed, 19 Aug 1998 15:35:09 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk High There, >Hello! > >> - Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. >I remember this long discussion and do not want to restart it >again, but I'd like to take your attention: OK. >You've just added new field to sockaddr_in6, which: Note its not 'me' )---> but consensus of the Working Group. >* is useless, in 99.999% of cases, when global or unique site local > addresses are used. Agreed. >* is useless on any single-homed node. Agreed. >* is not enough to make multihomed hosts and routers > to work correctly, because they must know destination > to reply in any case. Here I don't agree. sin6_scope_id represents a "set" of interfaces. Which interfaces is selected is an implementation issue. This will help clearly if you have 6 interfaces for site-A and 8 interfaces for site-B. It will select which set of interfaces by identifying that this packet is to be sent out site-A or site-B interface set. >* was completey covered for years by advanced API. Not really. The Advanced API specifies the exact interface index of an outgoing packet. So for example if you have Interface set for Site-A is equal to X'0000' by masking the Site-A value in an implementation to: X'0A01' = fta0 X'0A02' = fta1 Interface set for Site-B is equal to X'0100' by masking the Site-B valune in an implementaiton to: X'0102' = fta2 X'0103' = fta3 Hence fta0 and fta1 are in different site than fta2 and fta3. But using the Advanced API and setting interface index to 03 we are saying directly go over fta3 (e.g. Site-B). But when using the basic api and then set sin6_scope_id to become 0100 we are saying to the implementation select the best interface for Site-B not Site-A on this node. This cannot be done with the Advanced API today. >And last but not the least: you've just grabbed >one move 64 bit word. Sorry I can parse this? >Listen, if you really thought enough and finally decided to break >all existing implementations, why not to remove dead sin6_flowinfo field? Again please I am the editor at this point representing consensus. But the flow label is still in the IPv6 header and RSVP is using too for IPv6. So it is not dead. >In any case, flowinfo is semantically not related to sockaddr >and would break normal "reply to the thing, which you received" model. I do not think the working group agrees with you. I do not either. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 12:49:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA16664 for ipng-dist; Wed, 19 Aug 1998 12:40:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA16657 for ; Wed, 19 Aug 1998 12:40:01 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA01066; Wed, 19 Aug 1998 12:39:41 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA27044; Wed, 19 Aug 1998 12:38:12 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id PAA20020; Wed, 19 Aug 1998 15:38:11 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA28254; Wed, 19 Aug 1998 15:38:10 -0400 Message-Id: <199808191938.AA28254@wasted.zk3.dec.com> To: Mukesh Kacker Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6257) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Tue, 18 Aug 1998 07:09:33 PDT." <199808181409.HAA03605@lucknow.eng.sun.com> Date: Wed, 19 Aug 1998 15:38:10 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, I have no issue with your suggestions I will add them to the next draft and I assume too we have consensus on getting rid if the union in favor of the storage type proposed by Erik. I must have missed the mail as I did take what I got from Erik and repeated it. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 13:01:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA16701 for ipng-dist; Wed, 19 Aug 1998 12:49:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA16694 for ; Wed, 19 Aug 1998 12:49:03 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA04483; Wed, 19 Aug 1998 12:48:59 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA03072; Wed, 19 Aug 1998 12:49:00 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id PAA12685; Wed, 19 Aug 1998 15:48:58 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA01650; Wed, 19 Aug 1998 15:48:58 -0400 Message-Id: <199808191948.AA01650@wasted.zk3.dec.com> To: Mukesh Kacker Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6259) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Tue, 18 Aug 1998 15:37:57 PDT." <199808182237.PAA03922@lucknow.eng.sun.com> Date: Wed, 19 Aug 1998 15:48:58 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, Unfortuneately your correct in your response to Craig. But at this point I don't believe anything matters but "IP" and that will be the only supported AF in the real market forever, once the complete conversion of legacy protocols dies and become extinct. TCP/IP wins and all else looses. Period end of discussion. I do think the storage arguments hold water for the same reason we defined the in6_addr to be char [128]. It will work on all architectures. But I did not support Erik just as a note because I think anything else matters besides TCP/IP!!!! /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 13:38:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA16845 for ipng-dist; Wed, 19 Aug 1998 13:24:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA16838 for ; Wed, 19 Aug 1998 13:24:28 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14467 for ; Wed, 19 Aug 1998 13:24:25 -0700 Received: from dragon.cit.buffalo.edu (dragon.cit.buffalo.edu [128.205.10.22]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA22058 for ; Wed, 19 Aug 1998 13:24:25 -0700 (PDT) Received: (from jpb@localhost) by dragon.cit.buffalo.edu (8.8.5/8.8.2) id QAA18622 for ipng@sunroof.Eng.Sun.COM; Wed, 19 Aug 1998 16:24:23 -0400 (EDT) From: Jerry P Bucklaew Message-Id: <199808192024.QAA18622@dragon.cit.buffalo.edu> Subject: (IPng 6260) IPV6 and tcpd To: ipng@sunroof.eng.sun.com Date: Wed, 19 Aug 1998 16:24:22 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To ALL: I am running IPV6 on a solaris workstation and was wondering if a ipv6 tcp wrapper (tcpd) was available. I was using the wrappers before I upgraded but they got removed with the upgrade. I do not want to downgrade but am nervous about running without them. -- Jerry Bucklaew 645-6495 jpb@dragon.cit.buffalo.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 13:44:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA16877 for ipng-dist; Wed, 19 Aug 1998 13:35:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA16870 for ; Wed, 19 Aug 1998 13:35:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA17412 for ; Wed, 19 Aug 1998 13:35:06 -0700 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA28479 for ; Wed, 19 Aug 1998 13:35:06 -0700 (PDT) From: Margaret Wasserman To: iprsvp@yahoo.com CC: ipng@sunroof.eng.sun.com In-reply-to: <19980819184853.3620.rocketmail@send1e.yahoomail.com> (iprsvp@yahoo.com) Subject: (IPng 6261) Re: Reg: Routing Tables Size . Date: Wed, 19 Aug 98 16:35:03 -0400 Message-ID: <9808191635.aa25325@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >How does a typical IPv6 table look like. I am worried about >the size of the routing table. As each node >can have many interfaces and each with many addresses of size >128 bits. I'm not sure that there is a "typical" IPv6 routing table yet. I'm only familiar with our implementation. In our implementation, there is only one IP address, the destination address, held for each IP Address/Prefix Length pair in the routing table. Different entries for the same IP Address/Prefix Length pair (i.e. for different routing protocols) are linked off of a single route head which contains the address and prefix information. We hold the "mask" information as an 8-byte Prefix Length. The next-hop gateway address is referenced in-place in the Neighbor Discovery cache, thus resulting in only one IP Address held per active next-hop gateway. Individual routing entries point to the appropriate next-hop address, they do not contain their own copy of the address. So, with proper routing table design, the impact of the longer IPv6 addresses on routing table size can be considerably less than you might think. Margaret Margaret Wasserman mrf@epilogue.com Director of IP Development (617) 245-0804 Integrated Systems, Inc. FAX: (617) 245-8122 Epilogue Embedded Solutions http://www.epilogue.com 333 North Ave, 4th Floor http://www.isi.com Wakefield, MA 01880, USA Sales: info@epilogue.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 14:20:03 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA17015 for ipng-dist; Wed, 19 Aug 1998 14:09:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA17008 for ; Wed, 19 Aug 1998 14:08:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA27748; Wed, 19 Aug 1998 14:08:42 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA08041; Wed, 19 Aug 1998 13:49:48 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id UAA09370; Wed, 19 Aug 1998 20:49:35 GMT Message-Id: <199808192049.UAA09370@inner.net> To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: (IPng 6262) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Tue, 18 Aug 1998 22:09:05 PDT." X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 19 Aug 1998 16:48:49 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >> In message <199808141633.AA03110@wasted.zk3.dec.com>, you write: >> > - adding AI flags from getnodebyname to getaddrinfo. The reason >> > is this is not our spec but POSIX's, if folks feel we can change >> > it still I would like some discussion. >> >> This is bad. If you're using getaddrinfo() correctly (IMO), you'll use AF_INET for IPv4 addresses, AF_INET6 for IPv6 addresses, and *never* *ever* use AF_INET6 for IPv4 addresses. Therefore the getnodebyname flags this draft adds to getaddrinfo are unnecessary and bogus. If you're using getaddrinfo(), which is there to be protocol independent, and then trying to treat all the world as AF_INET6, you are broken. >> >- Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. >> >> This is bad. I'm just not convinced this is needed. I am convinced that changing struct sockaddr_in6 this late in the game is a very very bad thing. >> >- Changed 3.10 to use generic storage structure to support holding >> > IPv6 addresses and removed the SA_LEN macro. >> >> This is bad. This makes it impossible to obtain the length of a generic sockaddr portably, especially when there might be variable length addresses. That makes it impossible to be protocol independent. >> >- Changed getnodebyname to getipnodebyname, getnodebyaddr to >> > getipnodebyaddr, and added MT safe error code to funtion parameters >> > in section 6. >> I've long argued that the evolution of gethostbyname2/gethostbyname*/ getnodebyname/getipnodebyname/et al. is just bogus and that using getaddrinfo() and getnameinfo() correctly and being protocol family independent is the right way to go. Apps that do things this way can seamlessly use IPv4, IPv6, and whatever other network protocol you want. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 14:20:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA17024 for ipng-dist; Wed, 19 Aug 1998 14:13:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA17017 for ; Wed, 19 Aug 1998 14:12:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA29096; Wed, 19 Aug 1998 14:12:47 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA22494; Wed, 19 Aug 1998 14:12:45 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id VAA09398; Wed, 19 Aug 1998 21:12:36 GMT Message-Id: <199808192112.VAA09398@inner.net> To: Mukesh Kacker cc: ipng@sunroof.eng.sun.com Subject: (IPng 6263) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Tue, 18 Aug 1998 15:37:57 PDT." <199808182237.PAA03922@lucknow.eng.sun.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 19 Aug 1998 17:11:54 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808182237.PAA03922@lucknow.eng.sun.com>, you write: >The sockaddr_union as it was presented in previous draft was the first >instance that architecture was being broken by a requirement to modify > data structures when introducing new protocols and >potentially introduce packaging and binary compatibility issues. I agree with that. HOWEVER, one must already modify to add AF_foo and PF_foo, so I don't believe that this is a problem that doesn't already exist. >You can question the real-life need for any protocol other than >IP :-) I'm a big believer in protocol-family independence in apps, which makes it much easier to deal with protocols other than IP. >For the problem that it was attempting to solve, it seemed like too >big a hammer and I guess people wanted an alternate solution. I am not >sure what reason made people get away from it but I do think that is >the right direction. If putting the individual sockaddrs in the union is a big problem, then we don't do it. I don't remember seeing any substantive arguments that this caused real problems. But I can see how it doesn't leave people with a general warm fuzzy feeling, since it does require the use of stupid C tricks. >I think that is the goal in Erik's proposal and my refinement of it. I am lucky enough to live in a world where the compiler is GCC. I sometimes forget that others have compilers that aren't as sane. If your compiler won't align a struct sockaddr automatically however it needs to be aligned in order to be accessed without an alignment trap, more things will break than are within the scope of this API to fix. (and at that point, IMO, the problem is your compiler and/or user selected alignment options) The reason why I thought that a definition like: union sockaddr_union { struct sockaddr sa; char __pad[128]; } would be correct in alignment is that I expected that compilers would align it according to the strictest criteria of the union's members, which would mean that it would end up getting aligned according to the same criteria as struct sockaddr. So are you saying that your compiler does not do this, and would align such a union in a way differently than it might align a struct sockaddr? Can some kind soul speak for what ANSI C has to say, if anything, about this? >You seem to have working code using sockaddr_union and we all know the >pains of having to modify seemingly working code. My sympathies :-). This is an easy (though annoying) change for me. I just would like to see any changes made be steps in the forward direction. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 14:28:20 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA17053 for ipng-dist; Wed, 19 Aug 1998 14:21:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA17046 for ; Wed, 19 Aug 1998 14:21:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA01670 for ; Wed, 19 Aug 1998 14:21:23 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA27988 for ; Wed, 19 Aug 1998 14:21:23 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id VAA09428; Wed, 19 Aug 1998 21:20:55 GMT Message-Id: <199808192120.VAA09428@inner.net> To: bound@zk3.dec.com cc: kuznet@ms2.inr.ac.ru, ipng@sunroof.eng.sun.com Subject: (IPng 6264) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Wed, 19 Aug 1998 15:35:09 EDT." <199808191935.AA00594@wasted.zk3.dec.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 19 Aug 1998 17:20:07 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808191935.AA00594@wasted.zk3.dec.com>, you write: >Note its not 'me' )---> but consensus of the Working Group. >Again please I am the editor at this point representing consensus. >I do not think the working group agrees with you. I do not either. I assert that there is not consensus on this change. You have two people who write code telling you this is not the right solution to this problem. >This cannot be done with the Advanced API today. The Advanced API or another that I've been working on can be made to solve this problem without requiring the sockaddr to change. This change puts things in the sockaddr that just plain do not belong in a sockaddr. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 15:22:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA17185 for ipng-dist; Wed, 19 Aug 1998 15:12:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA17178 for ; Wed, 19 Aug 1998 15:11:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA17250 for ; Wed, 19 Aug 1998 15:11:47 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA26037 for ; Wed, 19 Aug 1998 15:11:48 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id PAA25031; Wed, 19 Aug 1998 15:11:15 -0700 (PDT) Message-Id: <3.0.5.32.19980819150948.00929cc0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 19 Aug 1998 15:09:48 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 6265) Updated IPng W.G. Agenda Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the updated agenda for the IPng sessions at the Chicago IETF. Both sessions will be Multicast. Suggestions for changes/additions/etc to us. Bob Hinden / Steve Deering -------------------------------------------- IPng Meeting Agenda ------------------- TUESDAY, August 25, 1998, 1545-1800 (Sheraton 5) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) UNH Interoperability Testing Report / W. Lenharth (5 min) Document Status / R. Hinden (10 min) New Documents to Draft Standard / R. Hinden (5 min) IPv6 Address Assignment Status / R. Hinden, R. Fink (10 min) IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min) Mobile IPv6 Status / D. Johnson (10 min) IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung (30 min) DNS Extension to Support IP Version 6 / M. Crawford (30 min) Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (15 min) THURSDAY, August 27, 1998, 0900-1130 (Sheraton 4) Jumbograms / S. Deering (15 min) Maximum header length (or minimum assured payload length) / M. Ohta (15 min) & Make PMTUD purely optional Router Renumbering / M. Crawford (15 min) Multicast Listener Discovery Protocol / S. Deering (10 min) IPv6 Naming interoperabilty issues / J. Paugh (15 min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 18:27:01 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA17400 for ipng-dist; Wed, 19 Aug 1998 18:14:31 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id SAA17393 for ; Wed, 19 Aug 1998 18:14:10 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA04493; Wed, 19 Aug 1998 18:14:06 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id SAA04478; Wed, 19 Aug 1998 18:12:50 -0700 (PDT) Date: Wed, 19 Aug 1998 18:12:50 -0700 (PDT) From: Mukesh Kacker Message-Id: <199808200112.SAA04478@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, cmetz@inner.net Subject: (IPng 6266) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I agree with that. HOWEVER, one must already modify to add > AF_foo and PF_foo, so I don't believe that this is a problem that doesn't > already exist. > Perhaps, but that is using one more constant value to an already existing integer namespace is not as strong a problem. People experimenting with new stuff can experiment with constant 9999 or some such unused number and add their and experiment and aspire to get a AF/PF_foo presence :-) It is far less intrusive than a data structure which implies either sucking in #include of all other header files. (Or re-engineering with hidden common header files to include these address data structures ... there are issues with name space reservation for applications vs system APIs and other nightmares you don't want to know :-) that in theory help prevent application portability breakage which vendors have to deal with.) Therefore, a sockaddr_union would bring in a much more engineering and packaging issues to address a problem that has an alternate solution that does not require that. > I'm a big believer in protocol-family independence in apps, which makes it > much easier to deal with protocols other than IP. I find "protocol-family independence" in applications too strong a promise and hard to do. I personally prefer the "multi-protocol" buzzword. :-) Interfaces should be multi-protocol and allow protocols and API to evolve separately to the maximal extent possible from status quo. > > The reason why I thought that a definition like: > > union sockaddr_union { > struct sockaddr sa; > char __pad[128]; > } > > would be correct in alignment is that I expected that compilers would align > it according to the strictest criteria of the union's members, which would mean > that it would end up getting aligned according to the same criteria as struct > sockaddr. > Can some kind soul speak for what ANSI C has to say, if anything, about this? I will probably be learning forever about nuances of ANSI/ISO C so I would not claim to be an expert in it but I will take a shot at explaining this one. I don't see how the above causes alignment. We do seem to have a disconnect somewhere. I am assuming that in the above proposal you are using the generic struct sockaddr from I agree that in the above data structure sockaddr is what would dicate the alignment of the union. But... In Sockets-without-sa_len, the "struct sockaddr" is defined as: struct sockaddr { u_short sa_family; /* address family */ char sa_data[14]; /* up to 14 bytes of direct address */ }; This implies a strictest alignment of "unsigned short" (i.e most likely 2 bytes) In Sockets-with-sa_len, the "struct sockaddr" is defined as: struct sockaddr { u_char sa_len; /* total length */ u_char sa_family; /* address family */ char sa_data[14]; /* actually longer; address value */ }; This would imply a strictest alignment of only "char/u_char" (i.e. 1 byte or no alignment constraint). I know there is code "out there" that uses "struct sockaddr" with IPv4 and "works" for years because it happens to be the first thing in a function (compilers usually start allocation of automatics aligned ...I think!) or some such explanation but it still is dangerous non-portable practice. Therefore it isn't enough that it works for some. Whereever possible, we should do engineering that encourages portable programming. Compilers can arbitrary choose more strict alignment but even if they stick to these values they are compliant with ANSI/ISO C and then risk of mishaps is high. Perhaps (speculation) gcc always picks some safe more strict boundary. I am glad gcc exists and serves the community. But what-gcc-does does not define the C language semantics and doing something different is not the definition of an "insane compiler" :-) [ And nothing here is motivated with specifics of what any Sun compiler does or not for these alignment issues. :-) I would rather be safe than worry about when Compiler writers may choose to play within their legal sandbox they are allowed to play in and do release++ and change something on me. ] -Mukesh Kacker Internet Engineering mukesh.kacker@eng.sun.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 19:19:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA17490 for ipng-dist; Wed, 19 Aug 1998 19:05:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA17483 for ; Wed, 19 Aug 1998 19:05:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA11608; Wed, 19 Aug 1998 19:05:24 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA11735; Wed, 19 Aug 1998 19:05:26 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id CAA09823; Thu, 20 Aug 1998 02:05:17 GMT Message-Id: <199808200205.CAA09823@inner.net> To: Mukesh Kacker cc: ipng@sunroof.eng.sun.com Subject: (IPng 6268) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Wed, 19 Aug 1998 18:12:50 PDT." <199808200112.SAA04478@lucknow.eng.sun.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 19 Aug 1998 22:04:23 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808200112.SAA04478@lucknow.eng.sun.com>, you write: >It is far less intrusive than a data structure which implies >either sucking in #include of all other header files. >(Or re-engineering with hidden common header files to include these address >data structures ... there are issues with name space reservation for >applications vs system APIs and other nightmares you don't want to >know :-) that in theory help prevent application portability breakage >which vendors have to deal with.) Where did you get the idea that this is required? The NRL implementation's definition looks sort of like this (I say sort of because I don't have access to the source tree right this moment): #ifndef _NETINET_IN_H struct sockaddr_in {}; struct sockaddr_in6 {}; #endif /* _NETINET_IN_H */ #ifndef _SYS_UN_H struct sockaddr_un {}; #endif /* _SYS_UN_H */ union sockaddr_union { struct sockaddr sa; struct sockaddr_in sin; struct sockaddr_in6 sin6; struct sockaddr_un sun; char __pad[128]; /* should actually be MHLEN on 4.4-derived systems! */ }; GCC happily accepts this, as does other compilers I've tried. I have asked several people for a ANSI C thumbs-up or thumbs-down on whether this is actually kosher and have gotten no response. It's clearly a stupid C trick that I can understand objections to. >Therefore, a sockaddr_union would bring in a much more engineering and >packaging issues to address a problem that has an alternate solution that >does not require that. Again, if this is the concern, then simply remove the family-specific entries and the problem is solved. In my opinion, Eric's solution with your fixes ends up being much more complex than a definition like: union sockaddr_union { struct sockaddr sa; char __pad[128]; } Such a definition would do what I want it to do and should do what you want it to do. >I find "protocol-family independence" in applications too strong a promise >and hard to do. I personally prefer the "multi-protocol" buzzword. :-) >Interfaces should be multi-protocol and allow protocols and >API to evolve separately to the maximal extent possible from status quo. My telnet runs over AF_LOCAL. If I go and implement EPRT/EPSV for AF_LOCAL, those should run over it, too. I agree that protocol-family independence in the perfect sense is too strong a promise, but I think that operating with all protocol families with a very small set of common similar assumptions is very possible. I also think it's important that implementors set their goals at that level. Many IPv6 implementations' applications are a mess of twisty if statements between AF_INET and AF_INET6. If implementors learn nothing else from IPv6, we should learn how to get rid of applications' dependencies on particular protocols. >I agree that in the above data structure sockaddr is what would dicate >the alignment of the union. But... In my opinion, this is the only part of the argument within the control of this API. If you have issues with the alignment of a struct sockaddr in different compilers and in different ABI environments, then the IPv6 API spec is not the place to be taking those up -- that's a POSIX p1003.1g sockets interface issue. If struct sockaddr is broken, then you've got much bigger problems than just fall in the IPv6 problem space. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 20:57:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA17572 for ipng-dist; Wed, 19 Aug 1998 20:45:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id UAA17565 for ; Wed, 19 Aug 1998 20:45:15 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA22895; Wed, 19 Aug 1998 20:45:07 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id UAA04542; Wed, 19 Aug 1998 20:43:50 -0700 (PDT) Date: Wed, 19 Aug 1998 20:43:50 -0700 (PDT) From: Mukesh Kacker Message-Id: <199808200343.UAA04542@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, cmetz@inner.net Subject: (IPng 6269) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > #ifndef _NETINET_IN_H > struct sockaddr_in {}; > struct sockaddr_in6 {}; > #endif /* _NETINET_IN_H */ > #ifndef _SYS_UN_H > struct sockaddr_un {}; > #endif /* _SYS_UN_H */ > That is as as much of a problem/non problem any of the solutions I have seen. It still is introducing more protocol specific data declarations in . It seems like a fine effort to make things work, but I would still vote for looking other alternatives. > If you have issues with the alignment of a struct sockaddr in different > compilers and in different ABI environments, then the IPv6 API spec is not the > place to be taking those up -- that's a POSIX p1003.1g sockets interface > issue. Huh ! I am not sure I get this. API definitions here need to be as ready as possible so making them a portable standard ideally implies minimal work atleast on substantive issues. (There will always be nitty gritty details to work out). Not thinking of those in IPv6 API would be undesirable. > If struct sockaddr is broken, then you've got much bigger problems than > just fall in the IPv6 problem space. > IMHO, "struct sockaddr" makes nice type for doing type casts and that is about it and it does a fine job at that. If you don't use it to store things, it is not broken. :-) (I don't see where P1003.1g requires me to store things in sockaddr. I don't see any "bigger problems"). I would like to discourage use of struct sockaddr to store real addresses. (It has a history that implies other things and so we can't just increase its size either). To store things, I would prefer an invention like sockaddr_storage than a sockaddr_union including a sockaddr-plus-pad with other loaded semantics and alignment issues. I find that a more architecturally preferable evolution. Thanks for your comments. -Mukesh Kacker mukesh.kacker@eng.sun.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 21:17:08 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA17613 for ipng-dist; Wed, 19 Aug 1998 21:06:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA17606 for ; Wed, 19 Aug 1998 21:06:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA28009; Wed, 19 Aug 1998 21:05:58 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA19368; Wed, 19 Aug 1998 21:05:57 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id EAA00305; Thu, 20 Aug 1998 04:05:44 GMT Message-Id: <199808200405.EAA00305@inner.net> To: Mukesh Kacker cc: ipng@sunroof.eng.sun.com Subject: (IPng 6270) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Wed, 19 Aug 1998 20:43:50 PDT." <199808200343.UAA04542@lucknow.eng.sun.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 20 Aug 1998 00:04:59 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808200343.UAA04542@lucknow.eng.sun.com>, you write: >IMHO, "struct sockaddr" makes nice type for doing type casts and >that is about it and it does a fine job at that. >If you don't use it to store things, it is not broken. :-) >To store things, I would prefer an invention like sockaddr_storage >than a sockaddr_union including a sockaddr-plus-pad with other loaded >semantics and alignment issues. All your previous arguments about why struct sockaddr isn't acceptable appear to apply just as well to struct sockaddr_in6, since its first two bytes are either two uint8_t s or uint16_t s. Are you saying that I can't use a struct sockaddr_in6 to hold a struct sockaddr_in6, but must instead use a struct sockaddr_storage to hold a struct sockaddr_in6 and cast it to a struct sockaddr_in6? That's fubar. Have any other implementors had problems with this? -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 22:32:28 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id WAA17683 for ipng-dist; Wed, 19 Aug 1998 22:19:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id WAA17676 for ; Wed, 19 Aug 1998 22:19:27 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA06405 for ; Wed, 19 Aug 1998 22:19:25 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id WAA12644 for ; Wed, 19 Aug 1998 22:19:27 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id BAA05344; Thu, 20 Aug 1998 01:17:49 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA29862; Thu, 20 Aug 1998 01:17:49 -0400 Message-Id: <199808200517.AA29862@wasted.zk3.dec.com> To: Craig Metz Cc: kuznet@ms2.inr.ac.ru, ipng@sunroof.eng.sun.com Subject: (IPng 6271) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Wed, 19 Aug 1998 17:20:07 -0300." <199808192120.VAA09428@inner.net> Date: Thu, 20 Aug 1998 01:17:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, >>I do not think the working group agrees with you. I do not either. > I assert that there is not consensus on this change. > > You have two people who write code telling you this is not the right solution >to this problem. Well I have 10+ people who write code including me and are shipping the code in the market and we don't agree with you. So I declare we have consensus per the many others that want this change. This includes vendors who have all agreed to accept this change specifically Compaq, Sun, Mentat, BSDi, KAMET, and Microsoft. If your issue is it will break much code I happen to agree with you but I read the WG wants this change so bad it will break the binaries one more time. I am not happy about that as a co-author or the entire issue. But we MUST adhere to consensus and I have to admit we have that right now per this subject. >>This cannot be done with the Advanced API today. > The Advanced API or another that I've been working on can be made to solve >this problem without requiring the sockaddr to change. This change puts things >in the sockaddr that just plain do not belong in a sockaddr. Please explain in detail. And why are you waiting until now I must ask as a co-author of this spec? This discussion was on the mail list for two months and I am a bit annoyed with anyone who is not listening on this list who is not a newcomer or new to IPv6 or this WG mail list? Even if I may agree with them philosophically. We have to do the right thing per consensus and I see it in the group. Otherwise this whole thing breaks down. Do you understand we have consensus we must support scope identification for the API per that very long drawn out discussion on site prefixes? That is what caused this entire issue. thanks, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 19 23:59:19 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA17761 for ipng-dist; Wed, 19 Aug 1998 23:48:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA17754 for ; Wed, 19 Aug 1998 23:48:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA19425 for ; Wed, 19 Aug 1998 23:48:14 -0700 Received: from gatesrv.RZ.UniBw-Muenchen.de (gatesrv.RZ.UniBw-Muenchen.de [137.193.10.21]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA08051 for ; Wed, 19 Aug 1998 23:48:11 -0700 (PDT) Received: from penelope.et.unibw-muenchen.de (penelope.ET.UniBw-Muenchen.de [137.193.227.6]) by gatesrv.RZ.UniBw-Muenchen.de (8.9.1/8.8.Beta.1) with ESMTP id IAA14971; Thu, 20 Aug 1998 08:48:00 +0200 (MET DST) Received: from hades (hades.ET.UniBw-Muenchen.de [137.193.227.7]) by penelope.et.unibw-muenchen.de (8.8.7/8.8.7) with SMTP id IAA07894; Thu, 20 Aug 1998 08:47:44 +0200 (MET DST) Message-Id: <3.0.5.32.19980820084748.00950890@penelope.et.unibw-muenchen.de> Reply-To: pb@bieringer.de X-Sender: list4peter@penelope.et.unibw-muenchen.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 20 Aug 1998 08:47:48 +0200 To: Jerry P Bucklaew From: Peter Bieringer Subject: (IPng 6272) Re: IPV6 and tcpd Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199808192024.QAA18622@dragon.cit.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 16:24 19.08.98 -0400, Jerry P Bucklaew wrote: >To ALL: > > I am running IPV6 on a solaris workstation and was wondering if a ipv6 >tcp wrapper (tcpd) was available. I was using the wrappers before I upgraded >but they got removed with the upgrade. I do not want to downgrade but am >nervous about running without them. It exists a IPv6 ported wrapper for Linux, perhaps it's easy to port it to Solaris. See here for details: http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO-4.html#tcp-wrapper 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 Thu Aug 20 08:25:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA17959 for ipng-dist; Thu, 20 Aug 1998 08:03:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA17952 for ; Thu, 20 Aug 1998 08:03:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA27065 for ; Thu, 20 Aug 1998 08:03:06 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA17190 for ; Thu, 20 Aug 1998 08:02:58 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA31801; Thu, 20 Aug 1998 19:01:21 +0400 Message-Id: <199808201501.TAA31801@ms2.inr.ac.ru> Subject: (IPng 6273) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: bound@zk3.dec.com Date: Thu, 20 Aug 1998 19:01:21 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com, cmetz@inner.net Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808191935.AA00594@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Aug 19, 98 03:35:09 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > Here I don't agree. sin6_scope_id represents a "set" of interfaces. etc. I understand it. However, I see no reasons to put this in high extent ancillary thing to place, which will be used by all the applications. Optional things must be optional. > But the flow label is still in the IPv6 header and RSVP is using too for > IPv6. So it is not dead. Certainly, in IPv6 header it is not dead. However, sockaddr_in6 has nothing to do with IPv6 header, as you understand. > Note its not 'me' )---> but consensus of the Working Group. 8)8) Do I talk to a medium speaking from face of an anonymous Working Group? I beg pardon, I do not believe, that sin6_site_id could pass through Working Group. At least, knowing Mr. W. Stevens by his seminal texts, it is difficult to imagine how he could approve this. Maybe, he is on vacations yet 8) If it is true however, than this WG should rethink its status. If it will continue in this manner to fancy about imaginary problems, instead of summarizing real experience of real implementations, you will never make anything useful. BTW it is very strange, but vendors mentioned in your reply to Craig are sort of far from frontiers of IPv6 development, is not it? At least, I never heard that they contributed something useful. Seems, such kind of questions will be actual for them only in the next millenium. 8) Alexey Kuznetsov. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 09:28:19 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA18075 for ipng-dist; Thu, 20 Aug 1998 09:12:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18068 for ; Thu, 20 Aug 1998 09:12:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA13863 for ; Thu, 20 Aug 1998 09:12:26 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA28889 for ; Thu, 20 Aug 1998 09:12:25 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id LAA02932; Thu, 20 Aug 1998 11:11:49 -0500 (CDT) Date: Thu, 20 Aug 1998 11:11:49 -0500 (CDT) From: David Borman Message-Id: <199808201611.LAA02932@frantic.bsdi.com> To: kuznet@ms2.inr.ac.ru Subject: (IPng 6274) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Thu, 20 Aug 1998 19:01:21 +0400 (MSK DST) > Reply-To: kuznet@ms2.inr.ac.ru > From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) > ... > > Here I don't agree. sin6_scope_id represents a "set" of interfaces. > etc. > > I understand it. However, I see no reasons to put this in high extent > ancillary thing to place, which will be used by all the applications. > > Optional things must be optional. It is only optional when dealing with globally unique addresses. When dealing with a link-local address on a multi-homed host, or a site-local address on a multi-sited host, it is not optional. Without sin6_scope_id you cannot write a simple UDP application to blindly use recvfrom()/sendto() to receive and reply to a message, unless you restrict the application to machines that have only one interface or restrict it to just global addresses, neither of which is an acceptable solution. > BTW it is very strange, but vendors mentioned in your reply > to Craig are sort of far from frontiers of IPv6 development, is not it? Sorry, but I can't just let that comment pass. BSDI was in that list. Just because you don't see much directly from me and/or BSDI does not mean that we are not involved and/or knowledgable. My job is not just IPv6, so to minimize my workload, I tend to follow the mailing list, and only jump in when I see things going astray (from my viewpoint). I (and Mike Karels) have strong interest and history in the socket interface, which includes defining the various sockaddr structures. Believe me, you'd hear a lot more from me if I disagreed with things (like right now, when I see a discussion popping up at the last minute to try and eliminate sin6_scope_id, which has already reached consensus on the list after much discussion). I also tend to let the discussion go a bit on the list to see where it is going before I jump in. With all the good folks on this list, things usually get worked out to my satsifaction without my having to jump into every discussion. To paraphrase Q from an episode of Star Trek the Next Generation that I saw last night, you may not see me, but I'll be watching! :-) -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 09:50:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA18110 for ipng-dist; Thu, 20 Aug 1998 09:30:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18102 for ; Thu, 20 Aug 1998 09:30:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA18762 for ; Thu, 20 Aug 1998 09:30:12 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA10086 for ; Thu, 20 Aug 1998 09:30:10 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA32627; Thu, 20 Aug 1998 20:29:52 +0400 Message-Id: <199808201629.UAA32627@ms2.inr.ac.ru> Subject: (IPng 6275) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: dab@BSDI.COM (David Borman) Date: Thu, 20 Aug 1998 20:29:51 +0400 (MSK DST) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808201611.LAA02932@frantic.bsdi.com> from "David Borman" at Aug 20, 98 11:11:49 am From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > Without sin6_scope_id you cannot write a simple UDP application > to blindly use recvfrom()/sendto() to receive and reply to a > message, unless you restrict the application to machines that > have only one interface or restrict it to just global addresses, > neither of which is an acceptable solution. It was one of main points of my first letter. Let me to cite myself: > > * is not enough to make multihomed hosts and routers > > to work correctly, because they must know destination > > to reply in any case. So that you will have to use advanced API in any case on multihomed hosts. Actually, it is very unpleasant bug in most of existing IP applications, which makes them unusable in multihoming environments. I'd not like that it was propagated to IPv6. To resume: you will not able to cheat broken applications and force them to become correct in any case. They are broken, that's all to say. > Sorry, but I can't just let that comment pass. BSDI was in that list. > Just because you don't see much directly from me and/or BSDI does not > mean that we are not involved and/or knowledgable. I beg pardon. I am really shamed but hope that this mistake will not prevent you of reading previous comment. Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 09:50:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA18154 for ipng-dist; Thu, 20 Aug 1998 09:39:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA18147 for ; Thu, 20 Aug 1998 09:39:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA21174 for ; Thu, 20 Aug 1998 09:39:26 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA15962 for ; Thu, 20 Aug 1998 09:39:23 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id QAA00916; Thu, 20 Aug 1998 16:39:10 GMT Message-Id: <199808201639.QAA00916@inner.net> To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Subject: (IPng 6276) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Thu, 20 Aug 1998 01:17:48 EDT." <199808200517.AA29862@wasted.zk3.dec.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 20 Aug 1998 12:38:25 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808200517.AA29862@wasted.zk3.dec.com>, you write: >Well I have 10+ people who write code including me and are shipping the >code in the market and we don't agree with you. So I declare we have >consensus per the many others that want this change. This includes vendors >who have all agreed to accept this change specifically Compaq, Sun, Mentat, >BSDi, KAMET, and Microsoft. Have those vendors said that they agree with the feature, or that they agree with the way you're implementing it? One does not mean the other. >And why are you waiting until now I must ask as a co-author of this >spec? This is the first I saw of the text. Many things have been discussed on this list that have later been quietly fixed. >Do you understand we have consensus we must support scope identification >for the API per that very long drawn out discussion on site prefixes? >That is what caused this entire issue. I am not arguing that supporting scope identification is a bad thing. That's already been discussed. I am arguing that: 1. Going back to the intentions of the basic API/advanced API split, this is inappropriate for the basic API and is an advanced API issue. You yourself acknowledged on this list that the overwhelming majority of IPv6 applications do not want or need this feature and that it's only needed for very special apps solving a specific problem. 2. Changing struct sockaddr_in6 this late in the game is a VERY bad thing. 3. This does not need to be done by changing sockaddr_in6; it can be done through control messages and/or through another API. For example, if the scope can be identified by an integer, than why not have a {g,s}etsockopt that gets/sets that integer for socket-wide use and a control message carrying an integer that receives/specifies it for per-datagram use? What if I want to get/set this scope but don't want to or can't pass a sockaddr? 4. In no other protocol family that I've ever seen does the sockaddr carry interface information. It's something the sockaddr is not intended to carry. 5. There is not consensus on the implementation of this feature that you are using. You are trying to shout down all further discussion on the subject by repeating "the working group has consensus" in every other paragraph, but shouting it repeatedly does not make it so. It sure seems to me like what we have here is not consensus, but apathy -- if so many people support your method of implementation, why is it that so few are discussing this? -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 10:47:18 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA18403 for ipng-dist; Thu, 20 Aug 1998 10:36:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA18393 for ; Thu, 20 Aug 1998 10:36:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA09121 for ; Thu, 20 Aug 1998 10:36:17 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA22510 for ; Thu, 20 Aug 1998 10:36:14 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04656; Thu, 20 Aug 98 10:34:54 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA00833; Thu, 20 Aug 1998 10:38:42 -0700 Date: Thu, 20 Aug 1998 10:38:42 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199808201738.KAA00833@feller.mentat.com> To: kuznet@ms2.inr.ac.ru, dab@BSDI.COM Subject: (IPng 6277) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexey, > > > > Optional things must be optional. > > It is only optional when dealing with globally unique addresses. > When dealing with a link-local address on a multi-homed host, or > a site-local address on a multi-sited host, it is not optional. > > Without sin6_scope_id you cannot write a simple UDP application > to blindly use recvfrom()/sendto() to receive and reply to a > message, unless you restrict the application to machines that > have only one interface or restrict it to just global addresses, > neither of which is an acceptable solution. > David is correct here. In fact it is worse than he describes. Given a sockaddr_in6 which does not have a scope identification mechanism, server applications like ftpd will need to littered with usage of IPv6 ancillary data in order to adequately support multi-homed and multi-sited nodes. This makes application porting a much more time consuming and error prone endeavor. This can all be avoided by forcing the sockaddr_in6 to unambigously identify the peer or local address being used. As of today multi-sited nodes are only a vague fantasy but I think we can agree that multi-homed nodes are a very common thing. > > BTW it is very strange, but vendors mentioned in your reply > > to Craig are sort of far from frontiers of IPv6 development, is not it? > > Sorry, but I can't just let that comment pass. BSDI was in that list. > Just because you don't see much directly from me and/or BSDI does not > mean that we are not involved and/or knowledgable. My job is not just > IPv6, so to minimize my workload, I tend to follow the mailing list, > and only jump in when I see things going astray (from my viewpoint). > I (and Mike Karels) have strong interest and history in the socket > interface, which includes defining the various sockaddr structures. > Believe me, you'd hear a lot more from me if I disagreed with things > (like right now, when I see a discussion popping up at the last minute > to try and eliminate sin6_scope_id, which has already reached consensus > on the list after much discussion). I also tend to let the discussion > go a bit on the list to see where it is going before I jump in. With > all the good folks on this list, things usually get worked out to my > satsifaction without my having to jump into every discussion. To > paraphrase Q from an episode of Star Trek the Next Generation that I > saw last night, you may not see me, but I'll be watching! :-) > Yes, I can't let it pass either. To put it more succinctly than David, your comment above is bunk. Compaq (formerly Digital), KAME, Mentat and SunSoft have all been working on implementations of IPv6 for more than three years. Digital and SunSoft had implementations of SIPP prior to that. I don't know about the status of a BSDI implementation but as David noted, there are a couple of people working there who might know just a little about how sockets is supposed to work. No fuzzy headed architect suggested these changes. They were suggested by folks who have their hands in the code. If there are serious technical problems then those problems need to be addressed. Making the argument that the individuals who made the proposals and support the proposals don't have "standing" is both inaccurate and fails to address the problems, assuming that they exist at all. 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 Aug 20 10:59:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA18438 for ipng-dist; Thu, 20 Aug 1998 10:52:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA18431 for ; Thu, 20 Aug 1998 10:52:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA15263 for ; Thu, 20 Aug 1998 10:52:14 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA04063 for ; Thu, 20 Aug 1998 10:52:10 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id MAA03113; Thu, 20 Aug 1998 12:52:06 -0500 (CDT) Date: Thu, 20 Aug 1998 12:52:06 -0500 (CDT) From: David Borman Message-Id: <199808201752.MAA03113@frantic.bsdi.com> To: kuznet@ms2.inr.ac.ru Subject: (IPng 6279) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Without sin6_scope_id you cannot write a simple UDP application > > to blindly use recvfrom()/sendto() to receive and reply to a > > message, unless you restrict the application to machines that > > have only one interface or restrict it to just global addresses, > > neither of which is an acceptable solution. > > It was one of main points of my first letter. Let me to cite myself: > > > > * is not enough to make multihomed hosts and routers > > > to work correctly, because they must know destination > > > to reply in any case. > > So that you will have to use advanced API in any case > on multihomed hosts. Actually, it is very unpleasant bug > in most of existing IP applications, which makes them unusable > in multihoming environments. I'd not like that it was propagated to IPv6. > To resume: you will not able to cheat broken applications and force > them to become correct in any case. They are broken, that's all to say. We must be misunderstanding each other. Let me try to clarify myself. When you do a recvfrom(), you get the address from which the packet originated, and that is the address to reply to with a sendto(). The problem with site-local and link-local addresses is that they are not globally unique. So, in addition to the address, you also need to know which site/link the address applies to, and that is what is stored in sin6_scope_id. Perhaps your concerns are with the client side, which needs to do a sendto()/recvfrom(). In that case, it must fill in both the IPv6 link/site address and sin6_scope_id in order for the packet to be sent. There still is the issue of how the application initially gets that addr/scope pair to begin with, but that is outside of the sockaddr definition. The point is that the sockaddr_in6 structure does not currently contain enough information to uniquely identify a remote address for link-local and site-local addresses. The addition of the sin6_scope_id fixes that. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 10:59:40 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA18428 for ipng-dist; Thu, 20 Aug 1998 10:48:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA18421 for ; Thu, 20 Aug 1998 10:47:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA13406 for ; Thu, 20 Aug 1998 10:47:36 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA00699 for ; Thu, 20 Aug 1998 10:47:36 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA26110; Fri, 21 Aug 1998 03:44:25 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Craig Metz Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 6278) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Thu, 20 Aug 1998 12:38:25 -0300." <199808201639.QAA00916@inner.net> Date: Fri, 21 Aug 1998 03:44:25 +1000 Message-Id: <639.903635065@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Aug 1998 12:38:25 -0300 From: Craig Metz Message-ID: <199808201639.QAA00916@inner.net> 4. In no other protocol family that I've ever seen does the sockaddr carry interface information. It's something the sockaddr is not intended to carry. The scope is not really interface information, it is a part of the address. A site local address is meaningless without some kind of identification of which site is meant (unless there is only one, and you're certain of that), similarly for link local addresses and links. Some of us would have preferred to embed the extra identification into the spare bits that exist in these addresses, but the WG decided against that (largely, I think, because it would have required somehow agreeing common identifiers to use for the site and link by all hosts in that site or on the link). Since the identifier isn't in the 128 address bits, and is needed as a part of the address, it really must be appended to it somehow. That is exactly what the API has done. There really is very little rational choice, and kludge deifinitions at this (comparatively early really, as product lifetimes go) stage would be truly unfortunate. It is unfortunate that we didn't realise this much sooner, but it is very fortunate that it was discovered now (well, last year) and not in a few years from now, when a half way decent fix really would have been difficult. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 11:24:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18500 for ipng-dist; Thu, 20 Aug 1998 11:11:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18493 for ; Thu, 20 Aug 1998 11:11:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA21963 for ; Thu, 20 Aug 1998 11:10:57 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA16969 for ; Thu, 20 Aug 1998 11:10:50 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id NAA03164; Thu, 20 Aug 1998 13:09:53 -0500 (CDT) Date: Thu, 20 Aug 1998 13:09:53 -0500 (CDT) From: David Borman Message-Id: <199808201809.NAA03164@frantic.bsdi.com> To: bound@zk3.dec.com, cmetz@inner.net Subject: (IPng 6280) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig and Jim, > 1. Going back to the intentions of the basic API/advanced API split, this > is inappropriate for the basic API and is an advanced API issue. You > yourself acknowledged on this list that the overwhelming majority of > IPv6 applications do not want or need this feature and that it's only > needed for very special apps solving a specific problem. No, it is needed for a simpe UDP application to be able to reliably reply to link-local or site-local addresses from a multi-homed/sited hosts. > 2. Changing struct sockaddr_in6 this late in the game is a VERY bad thing. That all depends on when you think the game began, and when you think it is going to end. :-) But seriosly, BSD/OS 4.0 is now shipping, and we have the old sockaddr_in6 definition. I *really* would have liked to have had sin6_scope_id decided earlier so that we could have shipped with the new definition, but the schedules just wouldn't allow it. So, I'm still in favor of adding sin6_scope_id, even though I know it will introduce a binary compatability problem. But I've resolved with binary compatability issues many times before, and I don't see this as any big deal. (Note, the fact that we *do* have an sa_len field will make things easier (I still find it hard to believe that there are vendors that haven't adopted sa_len, and the standards all have to reflect that, but that's another story...)) > 3. This does not need to be done by changing sockaddr_in6; it can be done > through control messages and/or through another API. For example, if the > scope can be identified by an integer, than why not have a {g,s}etsockopt > that gets/sets that integer for socket-wide use and a control message > carrying an integer that receives/specifies it for per-datagram use? > What if I want to get/set this scope but don't want to or can't pass a > sockaddr? That doesn't solve the simple UDP recvfrom()/sendto() application. > 4. In no other protocol family that I've ever seen does the sockaddr carry > interface information. It's something the sockaddr is not intended to > carry. In IPv6, link-local and site-local addresses are not globally unique. To make the dumb recvfrom()/sendto() UDP application work, you have to include along with the link-local/site-local address some indicator of which link/site the address is to be associated with. All IPv4 address are globally unique, so it doesn't have this problem. > 5. There is not consensus on the implementation of this feature that you are > using. You are trying to shout down all further discussion on the subject > by repeating "the working group has consensus" in every other paragraph, > but shouting it repeatedly does not make it so. It sure seems to me like > what we have here is not consensus, but apathy -- if so many people > support your method of implementation, why is it that so few are > discussing this? My understanding was that we had consensus on adding this a long time ago, and the only thing that was being argued was whether we needed one or two new fields. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 11:24:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18526 for ipng-dist; Thu, 20 Aug 1998 11:21:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18519 for ; Thu, 20 Aug 1998 11:21:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA25259 for ; Thu, 20 Aug 1998 11:21:21 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA23906 for ; Thu, 20 Aug 1998 11:21:13 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA00943; Thu, 20 Aug 1998 22:20:42 +0400 Message-Id: <199808201820.WAA00943@ms2.inr.ac.ru> Subject: (IPng 6282) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: thartric@mentat.com (Tim Hartrick) Date: Thu, 20 Aug 1998 22:20:42 +0400 (MSK DST) Cc: dab@BSDI.COM, ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808201738.KAA00833@feller.mentat.com> from "Tim Hartrick" at Aug 20, 98 10:38:42 am From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > As of today multi-sited nodes are only a vague fantasy but I think we > can agree that multi-homed nodes are a very common thing. I do not try to argue that multi-homed nodes are real thing. I know one thing: I know that only couple of OSes gave some interface to support them until now (even in IPv4). And they did not try to break sockaddr_in* to make it. > your comment above is bunk. Compaq (formerly Digital), Argh, I beg pardon. I did not take into account that Digital is not digital anymore 8)8) BTW recently I've tried to beg pardon for this my silly sentence, but you force me to elaborate: None of listed vendors tried to fix multi-homing bugs in their products for all years of IPv4 life. F.e. Sun is well-known as vendor producing broken NFS servers, which replied from wrong addresses and forced their clients to search for stupid workarounds to the problem. (I say about Sun, not because it is alone, but because it would be natural to expect NFS correctness of them) As you understand, it was impossible to force them to respect basic internet requirements. Moreover, I consider the fact, that they agreed with change of sockaddr_in6 structure NOW as direct indication, that they have NO real IPv6 application base after years of development. The point. Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 11:24:52 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18517 for ipng-dist; Thu, 20 Aug 1998 11:20:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18510 for ; Thu, 20 Aug 1998 11:20:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA24875 for ; Thu, 20 Aug 1998 11:20:11 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA23257 for ; Thu, 20 Aug 1998 11:20:12 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA27935; Thu, 20 Aug 1998 13:19:51 -0500 Message-Id: <199808201819.NAA27935@gungnir.fnal.gov> To: Vivek Kashyap Cc: kre@munnari.OZ.AU (Robert Elz), iprsvp@yahoo.com, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 6281) Re: Reg: PATH MTU discovery In-reply-to: Your message of Wed, 19 Aug 1998 10:41:11 PDT. <199808191741.KAA26957@eng4.sequent.com> Date: Thu, 20 Aug 1998 13:19:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Robert, > > No, it works. No, it does not, and kre explained very well why any scheme which supplies a mask-length with a packet-too-big will fail. I can only elaborate with another example. If you still don't understand, re-read kre's message. Suppose a host H has a large-MTU interface and an address on a subnet w:x:y:z::/64, inside a site with prefix w:x:y::/48, which supports this large MTU value throughout. Let H's route table contain only w:x:y:z::/64 prefix and default. H sends a large packet to w:x:a:b:c:d:e:f, and the router R which found the packet too big would have forwarded it based on a route for w:x::/32. (The router also has a route for w:x:y::/48.) You would then have H reduce the packet size for destinitions inside and outside the site because of this message from R. When it eventually tried larger packets again, the only feedback would come from R. 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 Thu Aug 20 11:57:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18621 for ipng-dist; Thu, 20 Aug 1998 11:43:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18614 for ; Thu, 20 Aug 1998 11:42:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA02174 for ; Thu, 20 Aug 1998 11:42:49 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA08918 for ; Thu, 20 Aug 1998 11:42:50 -0700 (PDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id IAA17314; Thu, 20 Aug 1998 08:10:52 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.8.5) id LAA27055; Thu, 20 Aug 1998 11:42:46 -0700 (PDT) From: Vivek Kashyap Message-Id: <199808201842.LAA27055@eng4.sequent.com> Subject: (IPng 6283) Re: Reg: PATH MTU discovery To: crawdad@fnal.gov (Matt Crawford) Date: Thu, 20 Aug 1998 11:42:46 -0700 (PDT) Cc: viv@sequent.com, kre@munnari.OZ.AU, iprsvp@yahoo.com, ipng@sunroof.eng.sun.com In-Reply-To: <199808201819.NAA27935@gungnir.fnal.gov> from "Matt Crawford" at Aug 20, 98 01:19:51 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt,Kre, your example is not covered by the simple change of returning the prefix length but as I have discussed in my previous mail more work is required. The two cases not covered by the simple change of providing the prefix length are : (a) H -- R1 -- R2 ----R3 ----- | | |------ At R2 there can be two route entries leading to the same net but with one being more specific that the other. i.e. the entries could be of the form: . A:B:C/48 . A:B:C:D/64 (b) H --.... R1 --------- R2 --------- R3---- A:B:C:D A:B: At R1 the packet used the more precise route but at the router R2, which has a smaller mtu, the route entry has a more general path. What you pointed out is same as in case (a). Sorry I missed it in in Kre's explanation. Attached is the solution to the above cases. It is not a simple change as above but a set of feasible changes. And that is the reason why I propose options to be chosen by the site administrator : . no PMTU, PMTU with the simple change, PMTU with the changes for the above two cases included, PMTU as in RFC 1981, PMTU extended so that the kernel doesn't act on the information but passes it to the application. Solution to the two cases: The above two situations can be handled in the following way: A. A router always marks entries that have the relationship as in (a). This is not difficult and can be done when the route is added. B. Define a hop-by-hop IP option (say P1) that specifies the lenght of the prefix used by the host. This would be used sparingly as detailed below. A router replies to the host with an ICMP error message in the following three situations: 1. The datagram is too big to sent out the interface (the standard Datagram too big situation). 2. If the situation as in (a) exists. It replies with the prefix length of the shorter route entry. (possibly a different message or code can be defined). The router determines this if the route it is using to send the datagram is marked. 3. If situation as in (b) exists. If the prefix length of in P1 is shorter than the route prefix in the route to be used to forward the datagram. A host sends the P1 packet only when it needs to probe the route. It need be configured to use the probe packet only if it ever receives a Datagram too big packet ie. the probe packets are sent only if a bottleneck has been found. A host creates (derives a more specific route) a route if it receives ICMP errors of the above three types: 1. Datagram too Big The modified DTB message gives the prefix length. The new route is constructed with the prefix length of bits taken from the peer's address. See draft-kashyap-too-big-00.txt for details. 2. On receiving the error as defined in 2 or 3. above, the host creates a route based on the prefix lenght received. The route is constructed as in the case above except that route is marked to indicate the situation as in (a) or (b). Henceforth the path MTU discovery on this route occurs on a per host basis. No more probe packets of type P1 are sent on this path. The above is only an outline. It certainly can be improved. I believe this approach will have the benefit of keeping the host resources more manageable and also generate lesser number of packets overall. Vivek > > No, it does not, and kre explained very well why any scheme which > supplies a mask-length with a packet-too-big will fail. I can only > elaborate with another example. If you still don't understand, > re-read kre's message. > > Suppose a host H has a large-MTU interface and an address on a subnet > w:x:y:z::/64, inside a site with prefix w:x:y::/48, which supports > this large MTU value throughout. Let H's route table contain only > w:x:y:z::/64 prefix and default. H sends a large packet to > w:x:a:b:c:d:e:f, and the router R which found the packet too big > would have forwarded it based on a route for w:x::/32. (The router > also has a route for w:x:y::/48.) > > You would then have H reduce the packet size for destinitions inside > and outside the site because of this message from R. When it > eventually tried larger packets again, the only feedback would come > from R. > Matt Crawford > -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 11:57:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18643 for ipng-dist; Thu, 20 Aug 1998 11:48:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18636 for ; Thu, 20 Aug 1998 11:48:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA03714; Thu, 20 Aug 1998 11:48:21 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA12769; Thu, 20 Aug 1998 11:48:18 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id SAA01175; Thu, 20 Aug 1998 18:48:08 GMT Message-Id: <199808201848.SAA01175@inner.net> To: Mukesh Kacker cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 6284) API/union sockaddr_union/struct sockaddr_storage X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 20 Aug 1998 14:47:17 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've had some offline discussions with a few people, and I think that a solution that could make everyone happy is a definition like so: #define __ALIGNMENT uint64_t union sockaddr_whatever { struct sockaddr sa; struct { __ALIGNMENT __pad1; char __pad2[128 - sizeof(__ALIGNMENT)]; } __pad; } This gives Mukesh the alignment guarantees that he believes he's not getting and still has a real struct sockaddr inside it for access without a cast. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 12:06:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18662 for ipng-dist; Thu, 20 Aug 1998 11:57:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18655 for ; Thu, 20 Aug 1998 11:57:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA06158 for ; Thu, 20 Aug 1998 11:57:30 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA18382 for ; Thu, 20 Aug 1998 11:57:31 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id SAA01222; Thu, 20 Aug 1998 18:57:13 GMT Message-Id: <199808201857.SAA01222@inner.net> To: Robert Elz cc: ipng@sunroof.eng.sun.com Subject: (IPng 6285) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Fri, 21 Aug 1998 03:44:25 +1000." <639.903635065@munnari.OZ.AU> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 20 Aug 1998 14:56:21 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <639.903635065@munnari.OZ.AU>, you write: >The scope is not really interface information, it is a part of the >address. A site local address is meaningless without some kind of >identification of which site is meant (unless there is only one, and >you're certain of that), similarly for link local addresses and links. Ah, OK. I see it now. This is not quite the explanation that I had been given by others. >Since the identifier isn't in the 128 address bits, and is needed as a >part of the address, it really must be appended to it somehow. That is >exactly what the API has done. One concern: How does this information get into the sockaddr to begin with? Doing it this way does mean that getaddrinfo() on the result of a getnameinfo() will now give you back a different sockaddr, and that's not very good. So far, what I'm hearing from people is that the content of this field and how it's obtained is still an area involving hand-waving. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 12:08:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18683 for ipng-dist; Thu, 20 Aug 1998 11:58:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18666 for ; Thu, 20 Aug 1998 11:57:56 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA06257 for ; Thu, 20 Aug 1998 11:57:52 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA18568 for ; Thu, 20 Aug 1998 11:57:52 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA05360; Thu, 20 Aug 98 11:56:33 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA00878; Thu, 20 Aug 1998 12:00:21 -0700 Date: Thu, 20 Aug 1998 12:00:21 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199808201900.MAA00878@feller.mentat.com> To: cmetz@inner.net, dab@BSDI.COM Subject: (IPng 6286) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David and Craig, > > > 1. Going back to the intentions of the basic API/advanced API split, this > > is inappropriate for the basic API and is an advanced API issue. You > > yourself acknowledged on this list that the overwhelming majority of > > IPv6 applications do not want or need this feature and that it's only > > needed for very special apps solving a specific problem. > > No, it is needed for a simpe UDP application to be able to reliably reply > to link-local or site-local addresses from a multi-homed/sited hosts. > Correct. > > 2. Changing struct sockaddr_in6 this late in the game is a VERY bad thing. > > That all depends on when you think the game began, and when you think > it is going to end. :-) > > But seriosly, BSD/OS 4.0 is now shipping, and we have the old sockaddr_in6 > definition. I *really* would have liked to have had sin6_scope_id decided > earlier so that we could have shipped with the new definition, but the > schedules just wouldn't allow it. So, I'm still in favor of adding > sin6_scope_id, even though I know it will introduce a binary compatability > problem. But I've resolved with binary compatability issues many times > before, and I don't see this as any big deal. (Note, the fact that we > *do* have an sa_len field will make things easier (I still find it hard > to believe that there are vendors that haven't adopted sa_len, and the > standards all have to reflect that, but that's another story...)) > We are essentially in the same boat. We had to close the tree with the old sockaddr_in6 still in use because the draft was in flux and we just had to move on. This has the potential for being a real pain but I still think we need to change the sockaddr_in6 to have the scope identification. If we don't do it now then we will be looking at using ancillary data for every trivial IPv6 application from now until the end of time. That would be really bad. There is no doubt that we, the working group, messed up in not dealing with this problem earlier. Kazu from KAME suggested something similar quite a while ago (~2 years ago) and the working group didn't quite get it at the time and it got dropped. We are better off fixing it late than never. If we wait any longer, never it will be. > > 3. This does not need to be done by changing sockaddr_in6; it can be done > > through control messages and/or through another API. For example, if the > > scope can be identified by an integer, than why not have a {g,s}etsockopt > > that gets/sets that integer for socket-wide use and a control message > > carrying an integer that receives/specifies it for per-datagram use? > > What if I want to get/set this scope but don't want to or can't pass a > > sockaddr? > > That doesn't solve the simple UDP recvfrom()/sendto() application. > Correct. > > 4. In no other protocol family that I've ever seen does the sockaddr carry > > interface information. It's something the sockaddr is not intended to > > carry. > > In IPv6, link-local and site-local addresses are not globally unique. > To make the dumb recvfrom()/sendto() UDP application work, you have > to include along with the link-local/site-local address some indicator > of which link/site the address is to be associated with. All IPv4 address > are globally unique, so it doesn't have this problem. > Correct. > > > 5. There is not consensus on the implementation of this feature that you are > > using. You are trying to shout down all further discussion on the subject > > by repeating "the working group has consensus" in every other paragraph, > > but shouting it repeatedly does not make it so. It sure seems to me like > > what we have here is not consensus, but apathy -- if so many people > > support your method of implementation, why is it that so few are > > discussing this? > > My understanding was that we had consensus on adding this a long time > ago, and the only thing that was being argued was whether we needed > one or two new fields. > This was my understanding of the situation as well. The shouting on this topic took place many moons ago. Once the shouting settled down the con- sensus was pretty clear that something needed to be done. Then came the shouting about what form the "something" would take. I think we have a reasonable compromise on the form of the "something". We need to move on. 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 Aug 20 12:09:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA18698 for ipng-dist; Thu, 20 Aug 1998 11:59:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA18691 for ; Thu, 20 Aug 1998 11:59:23 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA06625 for ; Thu, 20 Aug 1998 11:59:19 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id LAA19486 for ; Thu, 20 Aug 1998 11:59:16 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA01276; Thu, 20 Aug 1998 22:58:55 +0400 Message-Id: <199808201858.WAA01276@ms2.inr.ac.ru> Subject: (IPng 6287) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: dab@BSDI.COM (David Borman) Date: Thu, 20 Aug 1998 22:58:55 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808201752.MAA03113@frantic.bsdi.com> from "David Borman" at Aug 20, 98 12:52:06 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > The point is that the sockaddr_in6 structure does not currently > contain enough information to uniquely identify a remote address > for link-local and site-local addresses. The addition of the > sin6_scope_id fixes that. Yes, I really was imprecise. I talk not about sender address. I talk about recipient address. Multihoming application must know its OWN address to reply. Basic API gives no access to this address (but socket binding), so that: Statement I. Multihomig issues are completely outside of scope of Basic API. They are subject of Advanced API. Statement II. Hence, applications using Basic API cannot work in multihomimg environment in any case. Statement III. Problems with link-local and site-local addresses are importnant only in multihoming case. Hence, they are out of scope of Basic API. Seems, it is more clear. I'd like to pronounce one more thing. Though it was not reason of my eager 8)8) mails, but I think it is worth to say. Did you not find, that extension of 16 byte address by more 4 bytes sounds a bit strange? If site-local addresses do not work without it, it would be better to delete references to them from RFCs 8) Actually, I do not believe (I will not refer to authorities, but I know that I am not alone here), that site local addresses in this form will be used in real life. Certainly, concept of administratively scoped addresses will be used widely, but they will be selected from global address pool, and identified by local policy. Well, it is probable that fec0:: will be used for this purpose, but only provided if some vendors will not hardwire to their OSes their special and, hence, not enough flexible, interpretation 8)8)8) Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 14:56:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA19073 for ipng-dist; Thu, 20 Aug 1998 14:46:50 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id OAA19066 for ; Thu, 20 Aug 1998 14:46:40 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id OAA02140; Thu, 20 Aug 1998 14:46:25 -0700 (PDT) Date: Thu, 20 Aug 1998 14:45:48 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6288) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: David Borman Cc: kuznet@ms2.inr.ac.ru, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808201752.MAA03113@frantic.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Perhaps your concerns are with the client side, which needs to do a > sendto()/recvfrom(). In that case, it must fill in both the IPv6 > link/site address and sin6_scope_id in order for the packet to be > sent. There still is the issue of how the application initially gets > that addr/scope pair to begin with, but that is outside of the sockaddr > definition. Presumably getaddrinfo() can fill in that information. Thus even though it is unspecied how the DNS and other name services would determine the sin6_scope_id in this case, the client side application would not need modified to explicitly set sin6_scope_id. Note that getipnodebyname() can not help here since it only returns the IPv6 address and not the whole sockaddr_in6. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 15:16:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19164 for ipng-dist; Thu, 20 Aug 1998 15:05:17 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA19157 for ; Thu, 20 Aug 1998 15:04:52 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA05023; Thu, 20 Aug 1998 15:04:44 -0700 (PDT) Date: Thu, 20 Aug 1998 15:04:07 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6289) Re: API/union sockaddr_union/struct sockaddr_storage To: Craig Metz Cc: Mukesh Kacker , bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808201848.SAA01175@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I've had some offline discussions with a few people, and I think that a > solution that could make everyone happy is a definition like so: > > #define __ALIGNMENT uint64_t > union sockaddr_whatever { > struct sockaddr sa; > struct { > __ALIGNMENT __pad1; > char __pad2[128 - sizeof(__ALIGNMENT)]; > } __pad; > } I'd prefer if it would be a struct instead of a union (since the socket API doesn't expose any unions today and why start). Thus I'd prefer: #define __SOCKADDR_ALIGNMENT uint64_t struct sockaddr_storage { struct sockaddr sa; struct { __ALIGNMENT __pad1; char __pad2[128 - sizeof(__SOCKADDR_ALIGNMENT) - sizeof (struct sockaddr)]; } __pad; }; (Where __SOCKADDR_ALIGNMENT is implementation dependet but needs to be a multiple of 64 bits to support to ensure that sin6_addr is 64 bit aligned when a sockadr_in6 is cast to the above structure.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 15:30:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19241 for ipng-dist; Thu, 20 Aug 1998 15:18:49 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA19234 for ; Thu, 20 Aug 1998 15:18:20 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA07091; Thu, 20 Aug 1998 15:18:15 -0700 (PDT) Date: Thu, 20 Aug 1998 15:17:38 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6291) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: Craig Metz Cc: Robert Elz , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808201857.SAA01222@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One concern: How does this information get into the sockaddr to begin with? > Doing it this way does mean that getaddrinfo() on the result of a > getnameinfo() will now give you back a different sockaddr, and that's not > very good. So far, what I'm hearing from people is that the content of this > field and how it's obtained is still an area involving hand-waving. Could you clarify your concern with an example? Thanks, Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 15:50:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19329 for ipng-dist; Thu, 20 Aug 1998 15:40:17 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA19322 for ; Thu, 20 Aug 1998 15:40:05 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA10240; Thu, 20 Aug 1998 15:39:57 -0700 (PDT) Date: Thu, 20 Aug 1998 15:39:21 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6292) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: kuznet@ms2.inr.ac.ru Cc: David Borman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808201858.WAA01276@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I talk not about sender address. I talk about recipient > address. Multihoming application must know its OWN address to reply. > Basic API gives no access to this address (but socket binding), > so that: > Statement I. Multihomig issues are completely outside of scope > of Basic API. They are subject of Advanced API. That might be your interpretation - I don't know what the WG consensus is in this area. > Statement II. Hence, applications using Basic API cannot > work in multihomimg environment in any case. The severity of the two problems is quite different. Without a sin6_scope_id mechanism communication using link- and site-local address will just fail. The issue of using the correct source address for UDP request/response applications is application specific. RFC 1123 (section 2.3 second paragraph) has a SHOULD that many applications (e.g. NFS and ONC RPC) violate but still work (at least as long as there are no stateful devices like firewalls in the path). Other applications (e.g. the BIND DNS server and xntpd) use multiple sockets each bound to a specific IP address to satisfy the requirement today with IPv4. > Statement III. Problems with link-local and site-local addresses > are importnant only in multihoming case. Hence, they are out of > scope of Basic API. I would disagree. But you are bringing up an interesting point. My question for the WG is: Is it enough to provide the current socket API mechanisms (bind one socket for each local IP address on a multihomed machine) in the basic API for IPv6, or should we try to fix this so that all IPv6 UDP server side applications (those that just use recvfrom/sendto) automatically get the same source address in the reply as the specific destination address in the request? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 15:51:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19362 for ipng-dist; Thu, 20 Aug 1998 15:44:45 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id PAA19355 for ; Thu, 20 Aug 1998 15:44:34 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id PAA10798; Thu, 20 Aug 1998 15:44:32 -0700 (PDT) Date: Thu, 20 Aug 1998 15:43:56 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6293) Usefulness of site local addresses (again) To: kuznet@ms2.inr.ac.ru Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808201858.WAA01276@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Actually, I do not believe (I will not refer to authorities, > but I know that I am not alone here), that site local addresses > in this form will be used in real life. This has been debated on and off for a year or so. In order to make some progress on this issue can you please look at the "site-prefixes" draft and send me comments on that draft. Since I missed the ID cutoff for Chicago you can only get the latest draft from (I'll make sure it shows up in the ID directories after the meeting): ftp://playground.sun.com/pub/nordmark/draft-ietf-ipngwg-site-prefixes-02.txt Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 16:06:59 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA19419 for ipng-dist; Thu, 20 Aug 1998 15:55:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA19412 for ; Thu, 20 Aug 1998 15:55:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA14664; Thu, 20 Aug 1998 15:55:18 -0700 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA07084; Thu, 20 Aug 1998 15:55:15 -0700 (PDT) Received: from duplo.sm.sony.co.jp (duplo.sm.sony.co.jp [133.138.10.221] (may be forged)) by onoe2.sm.sony.co.jp (8.9.0/Sony6.1MX) with ESMTP id HAA08264; Fri, 21 Aug 1998 07:55:10 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.8.8/8.8.8) id HAA05372; Fri, 21 Aug 1998 07:54:54 +0900 (JST) Date: Fri, 21 Aug 1998 07:54:54 +0900 (JST) From: Atsushi Onoe Message-Id: <199808202254.HAA05372@duplo.sm.sony.co.jp> To: cmetz@inner.net Cc: Mukesh.Kacker@Eng, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 6294) Re: API/union sockaddr_union/struct sockaddr_storage In-Reply-To: Your message of "Thu, 20 Aug 1998 14:47:17 -0300" <199808201848.SAA01175@inner.net> References: <199808201848.SAA01175@inner.net> X-Mailer: Cue version 0.2 (980810-1527/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > #define __ALIGNMENT uint64_t > union sockaddr_whatever { > struct sockaddr sa; > struct { > __ALIGNMENT __pad1; > char __pad2[128 - sizeof(__ALIGNMENT)]; > } __pad; > } It would be more simple: #define __SOCKADDR_ALIGNMENT uint64_t union sockaddr_storage { struct sockaddr ss_sa; __SOCKADDR_ALIGNMENT __ss_align; char __ss_room[128]; }; or for Erik: #define __SOCKADDR_ALIGNMENT uint64_t struct sockaddr_storage { union { struct sockaddr __ss_sa; __SOCKADDR_ALIGNMENT __ss_align; char __ss_room[128]; } __ss_union; }; #define ss_sa __ss_union.__ss_sa Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 17:00:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id QAA19485 for ipng-dist; Thu, 20 Aug 1998 16:49:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id QAA19478 for ; Thu, 20 Aug 1998 16:49:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA29977; Thu, 20 Aug 1998 16:49:37 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id QAA03744; Thu, 20 Aug 1998 16:49:38 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id XAA01792; Thu, 20 Aug 1998 23:49:21 GMT Message-Id: <199808202349.XAA01792@inner.net> To: Erik Nordmark , Atsushi Onoe cc: Mukesh Kacker , ipng@sunroof.eng.sun.com Subject: (IPng 6295) Re: API/union sockaddr_union/struct sockaddr_storage In-reply-to: Your message of "Thu, 20 Aug 1998 15:04:07 PDT." X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 20 Aug 1998 19:48:31 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Eric Nordmark writes: >Thus I'd prefer: > >#define __SOCKADDR_ALIGNMENT uint64_t >struct sockaddr_storage { > struct sockaddr sa; > struct { > __ALIGNMENT __pad1; > char __pad2[128 - sizeof(__SOCKADDR_ALIGNMENT) - sizeof (struct sockaddr)] >; > } __pad; }; > >(Where __SOCKADDR_ALIGNMENT is implementation dependet but needs to be >a multiple of 64 bits to support to ensure that sin6_addr is 64 bit aligned >when a sockadr_in6 is cast to the above structure.) I don't believe this definition satisfies Mukesh's alignment concerns. If it does, it's fine with me. In message <199808202254.HAA05372@duplo.sm.sony.co.jp>, Atsushi Onoe writes: >It would be more simple: > > #define __SOCKADDR_ALIGNMENT uint64_t > union sockaddr_storage { > struct sockaddr ss_sa; > __SOCKADDR_ALIGNMENT __ss_align; > char __ss_room[128]; > }; Actually, I think this might be the best definition of the bunch. Mukesh, does this satisfy your alignment concerns? -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 17:20:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19604 for ipng-dist; Thu, 20 Aug 1998 17:07:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19597 for ; Thu, 20 Aug 1998 17:07:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA04759; Thu, 20 Aug 1998 17:07:48 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA12586; Thu, 20 Aug 1998 17:07:46 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id AAA01818; Fri, 21 Aug 1998 00:07:39 GMT Message-Id: <199808210007.AAA01818@inner.net> To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: (IPng 6296) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Thu, 20 Aug 1998 15:17:38 PDT." X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 20 Aug 1998 20:02:46 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >Could you clarify your concern with an example? This is a simplified demonstration. To restate my concern, IMO the property that getaddrinfo(getnameinfo(sa)) == sa for numeric lookups needs to hold (with ai_socktype and ai_flags possibly needing to be specified out of band) or the functions are a lot less useful. Asserting as the WG has that: 1. The scope ID is essential addressing information 2. The scope ID is not stored in the address proper Then not having a way for getaddrinfo()/getnameinfo() to provide a user interface to the scope ID is a very very bad thing. Perhaps, if the scope ID is as essential as people assert, then we should extend the syntax for the numeric printable string representation of an IPv6 address to allow the user to specify this information. -Craig void example(struct sockaddr *sa) { char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV]; struct addrinfo *ai, req; int i; if (i = getnameinfo(sa, SA_LEN(sa), hbuf, NI_MAXHOST, sbuf, NI_MAXSERV, NI_NUMERICHOST | NI_NUMERICSERV)) { fprintf(stderr, "getnameinfo returned %s(%d)\n", i, gai_strerror(i)); exit(1); } memset(&req, 0, sizeof(struct addrinfo)); req.ai_family = sa->sa_family; if (i = getaddrinfo(hbuf, sbuf, &req, &ai)) { fprintf(stderr, "getaddrinfo(%s, %s, ...) returned %s(%d)\n", hbuf, sbuf, i, gai_strerror(i)); exit(1); } if (ai->ai_next) fprintf(stderr, "Numeric lookup resulted in multiple addresses?!\n"); if (memcmp(sa, ai->ai_addr, ai->ai_addrlen)) fprintf(stderr, "Congratulations, you've broken it\n"); freeaddrinfo(ai); } -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 17:20:56 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19614 for ipng-dist; Thu, 20 Aug 1998 17:16:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19607 for ; Thu, 20 Aug 1998 17:16:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA07174; Thu, 20 Aug 1998 17:16:07 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA16932; Thu, 20 Aug 1998 17:16:08 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id AAA01834; Fri, 21 Aug 1998 00:15:57 GMT Message-Id: <199808210015.AAA01834@inner.net> To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: (IPng 6297) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Thu, 20 Aug 1998 15:39:21 PDT." X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 20 Aug 1998 20:15:10 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >My question for the WG is: > Is it enough to provide the current socket API mechanisms (bind one socket > for each local IP address on a multihomed machine) in the basic API for >IPv6, or > should we try to fix this so that all IPv6 UDP server side applications > (those that just use recvfrom/sendto) automatically get the same source > address in the reply as the specific destination address in the request? For most UDP apps, I believe that the current IPv4 multi-homing behavior is enough for the basic API. You can also do the trick where you bind a socket for every local address. For those UDP apps where the protocol requires that the reply's source address matches the request's destination address, we have IN6_PKTINFO, which happens to solve this problem nicely IMO. We can even have something like IN6_PKTINFO that instead runs off the scope ID. These I believe are advanced API issues. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 20 17:45:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA19685 for ipng-dist; Thu, 20 Aug 1998 17:33:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id RAA19678 for ; Thu, 20 Aug 1998 17:33:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA12159 for ; Thu, 20 Aug 1998 17:33:33 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA24873 for ; Thu, 20 Aug 1998 17:33:35 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 20 Aug 1998 17:33:35 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8112F@RED-MSG-50> From: Richard Draves To: "'Craig Metz'" , Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6298) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.t xt Date: Thu, 20 Aug 1998 17:33:32 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Perhaps, > if the scope ID > is as essential as people assert, then we should extend the > syntax for the > numeric printable string representation of an IPv6 address to > allow the user > to specify this information. Unfortunately I won't be at IETF next week. So let me express in email my support for adding a scope id to sockaddr_in6. In my experience developing an IPv6 stack and porting applications to it, link-local and site-local addresses are very awkward and difficult to use without it. Note that in our implementation almost *all* hosts are multi-homed, because of virtual links like 6-over-4. I also support changing the string representation of IPv6 addresses to allow users to specify this information. (Note I don't expect "real" users to be typing in raw IPv6 addresses... but admins, developers, etc will.) But I think that's a minority position. I also support changing the string representation to support URLs. I know that's a minority position. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 02:45:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA20200 for ipng-dist; Fri, 21 Aug 1998 02:40:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA20193 for ; Fri, 21 Aug 1998 02:40:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA13514 for ; Fri, 21 Aug 1998 02:40:24 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.9.1/8.9.1) with SMTP id CAA23983 for ; Fri, 21 Aug 1998 02:40:23 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA31797; Fri, 21 Aug 1998 19:39:56 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6299) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Thu, 20 Aug 1998 14:56:21 -0300." <199808201857.SAA01222@inner.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Aug 1998 19:39:55 +1000 Message-Id: <7370.903692395@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 20 Aug 1998 14:56:21 -0300 From: Craig Metz Message-ID: <199808201857.SAA01222@inner.net> So far, what I'm hearing from people is that the content of this field and how it's obtained is still an area involving hand-waving. Yes, I think you're right, and I agree that the basic "convert this name to an address" type function should be supplying this information. That basically means that such functions ought to be returning sockaddr's instead of just the 128 (or whatever) bit string. Of course, issues of compatability with IPv4 APIs make this difficult. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 05:46:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA20321 for ipng-dist; Fri, 21 Aug 1998 05:35:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA20314 for ; Fri, 21 Aug 1998 05:34:59 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA25680 for ; Fri, 21 Aug 1998 05:34:56 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA10568 for ; Fri, 21 Aug 1998 05:34:56 -0700 (PDT) Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id IAA20049; Fri, 21 Aug 1998 08:34:24 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30976; Fri, 21 Aug 1998 08:34:21 -0400 Message-Id: <199808211234.AA30976@wasted.zk3.dec.com> To: kuznet@ms2.inr.ac.ru Cc: ipng@sunroof.eng.sun.com, cmetz@inner.net Subject: (IPng 6300) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Thu, 20 Aug 1998 19:01:21 +0400." <199808201501.TAA31801@ms2.inr.ac.ru> Date: Fri, 21 Aug 1998 08:34:20 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I understand it. However, I see no reasons to put this in high extent >ancillary thing to place, which will be used by all the applications. The WG wants this done in the socket address. >Certainly, in IPv6 header it is not dead. >However, sockaddr_in6 has nothing to do with IPv6 header, >as you understand. It will be used by the RSVP API, and other QOS applications. >8)8) Do I talk to a medium speaking from face of an anonymous >Working Group? I beg pardon, I do not believe, that sin6_site_id >could pass through Working Group. At least, knowing Mr. W. Stevens >by his seminal texts, it is difficult to imagine how he could >approve this. Maybe, he is on vacations yet 8) No Richard is not on vacation and both of us are working on this. I am the editor at this point. Both of us want this spec wrapped up. The WG connsenus is that THIS WILL BE IN THIS BSD API SPEC. >If it is true however, than this WG should rethink its status. >If it will continue in this manner to fancy about imaginary problems, >instead of summarizing real experience of real implementations, >you will never make anything useful. >BTW it is very strange, but vendors mentioned in your reply >to Craig are sort of far from frontiers of IPv6 development, is not it? >At least, I never heard that they contributed something useful. >Seems, such kind of questions will be actual for them >only in the next millenium. 8) Excuse me but you are now uninformed. Compaq (formerly Digital and Sun) have had implementations for 5 years of IPv6 and all the engineers workiing on it are also principal authors of both core and extended IPv6 specifications. In fact you from my knowledge are the new kid on the block telling those who have been here a long time we don't know what we are doing and quite frankly I find it offensive so chill out. Mentat, IBM, HP, and many from Japan have had implementations at interoperatbility bake-offs for 2 years. I have never seen Craig's code at those events. So you are really uninformed. Right now it is only you and Craig complaining and I am sorry that is not enough and I guess you and Craig will have to live with these changes. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 06:21:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA20347 for ipng-dist; Fri, 21 Aug 1998 06:06:49 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id GAA20340 for ; Fri, 21 Aug 1998 06:06:36 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id GAA10088; Fri, 21 Aug 1998 06:06:30 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id GAA05189; Fri, 21 Aug 1998 06:05:10 -0700 (PDT) Date: Fri, 21 Aug 1998 06:05:10 -0700 (PDT) From: Mukesh Kacker Message-Id: <199808211305.GAA05189@lucknow.eng.sun.com> To: Erik.Nordmark@Eng, onoe@sm.sony.co.jp, cmetz@inner.net Subject: (IPng 6301) Re: API/union sockaddr_union/struct sockaddr_storage Cc: Mukesh.Kacker@Eng, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > >#define __SOCKADDR_ALIGNMENT uint64_t > >struct sockaddr_storage { > > struct sockaddr sa; > > struct { > > __ALIGNMENT __pad1; > > char __pad2[128 - sizeof(__SOCKADDR_ALIGNMENT) - sizeof (struct sockaddr)] > >; > > } __pad; }; > > > >(Where __SOCKADDR_ALIGNMENT is implementation dependet but needs to be > >a multiple of 64 bits to support to ensure that sin6_addr is 64 bit aligned > >when a sockadr_in6 is cast to the above structure.) > > I don't believe this definition satisfies Mukesh's alignment concerns. If it > does, it's fine with me. > Craig, the alignment restrictions do not come from the "first field" of the data structure but requirement that layout should allow all fields to be aligned so is driven by the "strictest/largest" alignment costrained field. The above layout will work atleast for the current values because "sizeof (struct sockaddr)" is 16. A <64-bit aligned ptr> -16 is still 64 bit aligned so it works. So the above works, though I would have still preferred a design that keeps the "largest alginment" field as first field of data structure so it is easy to design/think about this issue. My guess is that Erik proposed the layout as above to bury all the "pad/align" data-structure-smithing fields together separate from the "useful" field "sa". Instead of proposing new/varied data structures to bore the audience I would like to bring back the issue to think more about what is the requirement of what we are trying to achieve here in a separate email. -Mukesh Kacker mukesh.kacker@eng.sun.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 06:21:42 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA20361 for ipng-dist; Fri, 21 Aug 1998 06:12:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA20354 for ; Fri, 21 Aug 1998 06:11:35 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA00299; Fri, 21 Aug 1998 06:11:31 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA24760; Fri, 21 Aug 1998 06:11:33 -0700 (PDT) Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id JAA14027; Fri, 21 Aug 1998 09:11:32 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA02699; Fri, 21 Aug 1998 09:11:31 -0400 Message-Id: <199808211311.AA02699@wasted.zk3.dec.com> To: Richard Draves Cc: "'Craig Metz'" , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: (IPng 6302) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.t xt In-Reply-To: Your message of "Thu, 20 Aug 1998 17:33:32 PDT." <4D0A23B3F74DD111ACCD00805F31D8100AF8112F@RED-MSG-50> Date: Fri, 21 Aug 1998 09:11:31 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, One of the changes to the 02 draft was to support literal strings. See the changes in the new draft. This was input from Sun during June mail and appeared to have consensus. 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 Fri Aug 21 06:43:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA20420 for ipng-dist; Fri, 21 Aug 1998 06:29:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA20413 for ; Fri, 21 Aug 1998 06:29:35 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA02428 for ; Fri, 21 Aug 1998 06:29:31 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA02664 for ; Fri, 21 Aug 1998 06:29:33 -0700 (PDT) Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id JAA20884; Fri, 21 Aug 1998 09:29:32 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA04613; Fri, 21 Aug 1998 09:29:32 -0400 Message-Id: <199808211329.AA04613@wasted.zk3.dec.com> To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6303) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Date: Fri, 21 Aug 1998 09:29:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, I was telling you we had consensus for implementation of scope_id and for the changes to section 3.10 "portability". I was trying to avoid large mail flow but the names you have seen yesterday and others and besides me had discussed these issues in depth. On this mailing list. As far as the storage struct issue I am waiting to hear Mukesh's response to that last suggestion? Then I would ask if all agree to what that answer is. If you take that to be shouting then so be it. What my main focus is now is to wrap this up and ship a spec to the vendors and ISVs to build IPv6 products. So far you or Alexy have said nothing technically to convince me to change the spec. I still believe as a note Mukesh's last mail is fine and that your issue will work in that form too. But I will keep out of this as I don't think it is a big deal either way really. So it would be good if we can wrap that issue up by next week. As far as breaking the code. I hear you and feel the pain I have to fix the API on our implementation per all this and know all too well what I am facing. But I am not changing any code until this spec gets done and I hope that is before mid september. And we have over 500 users using our IPv6 implementation and two major ISVs that have ported test kits to the basic API. Now I have to go tell them we have to break that model. But I believe again consensus was we have to break the implementations for the scope_id. I even sent mail that this is an issue just like you did over 7 weeks ago on this list. Response to me was we have to do it. So I will admit that I am a bit frustrated we had to rehash this issue as you were on the list and heard the discussion. As far as scope_id I think Kre did a good job of responding to you on that, so I will not add to that comment. It is a place holder for tomorrow and we do need it for sure. As far as the Advanced API spec I am very concerned. I think we may need new authors to take the Advanced API spec on as Rich and Matt have both told me they are too busy to work on this spec. I believe Erik showed interest in working on this spec? I know I do not have the time. But there are some implementors that have issues with the present spec as a note for the Advanced API. But lets get the basic one nailed down first. I am offline until Sunday night and will be at the IETF monday p.m. till thursday a.m. 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 Fri Aug 21 07:17:48 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20538 for ipng-dist; Fri, 21 Aug 1998 07:03:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA20531 for ; Fri, 21 Aug 1998 07:03:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA12655; Fri, 21 Aug 1998 07:03:45 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA17024; Fri, 21 Aug 1998 07:03:45 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA05769; Fri, 21 Aug 1998 18:03:40 +0400 Message-Id: <199808211403.SAA05769@ms2.inr.ac.ru> Subject: (IPng 6304) Re: Usefulness of site local addresses (again) To: Erik.Nordmark@Eng Date: Fri, 21 Aug 1998 18:03:40 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: from "Erik Nordmark" at Aug 20, 98 03:43:56 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > In order to make some progress on this issue can you please > look at the "site-prefixes" draft and send me comments on that draft. > Since I missed the ID cutoff for Chicago you can only get the latest draft > from (I'll make sure it shows up in the ID directories after the meeting): > ftp://playground.sun.com/pub/nordmark/draft-ietf-ipngwg-site-prefixes-02.txt I read -01. It was superb. I even implemented addrconf side of version -01 8) I'll read -02 tonight. I agree with this and previous your mail, and have only two notes: 1. about binding sockets. This facility was used only by couple of applications in IPv4 (bind and xntpd, I do not know more), and was used improperly. At least, all stable versions of named before 8.x never reread interface address list, forcing to reload it every time, when they change. In IPv6, where addresses have more dynamic nature, the problem is much more difficult. You may get very old micro-patch to bind, making it correctly (ftp://ftp.inr.ac.ru/ip-routing/bind-4.9.5-REL.dif.gz) and you will understand, that amount of work to make to solve the problem once and forever is ridiculously small, provided you use advanced api. Moreover, some hosts have hundreds of aliased addresses, it is pretty not wise to force them to open sockets for each of them. About ONC RPC. It wouldbe "worked" only because clients matched replies only by XID value. It does not satisfy the most minimal robustness requirements. 2. > The severity of the two problems is quite different. Fish cannot be of first degree of freshness and of second one. 8) Fish is either fresh or rotted. Jim may try to assure me, that it is possible to eat and all of people except for me have already eated it and they are still alive. I insist: it has bad smell, I am afraid to eat it. 8)8) When WG stay on attitude of trade agent trying to sell stale goodies, it is sad. Maybe, they have cold in the head. 8) Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 07:23:44 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20560 for ipng-dist; Fri, 21 Aug 1998 07:18:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA20553 for ; Fri, 21 Aug 1998 07:18:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA16986 for ; Fri, 21 Aug 1998 07:18:12 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA23887 for ; Fri, 21 Aug 1998 07:18:11 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA05925; Fri, 21 Aug 1998 18:17:50 +0400 Message-Id: <199808211417.SAA05925@ms2.inr.ac.ru> Subject: (IPng 6305) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: bound@zk3.dec.com Date: Fri, 21 Aug 1998 18:17:50 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com, cmetz@inner.net Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808211234.AA30976@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Aug 21, 98 08:34:20 am From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > The WG wants this done in the socket address. OK. It sounds more definitely. > >Certainly, in IPv6 header it is not dead. > >However, sockaddr_in6 has nothing to do with IPv6 header, > >as you understand. > > It will be used by the RSVP API, and other QOS applications. Seems, I deserved that you stopped to read the things, which I write at all 8) sin6_flowinfo cannot be used by QoS applications, believe me. I have some experience in this area. Maybe, more experience than someone another. Explanation is ridiculously simple: flowlabel is associated with source address. Hence it has real meaning only in received sockaddr. To avoid situation, when application uses received address for reply blindly and hence tries to use invalid flowlabel, it will be ignored by sendto(). This "feature" is known since this field appeared, you cannot not know about it. Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 07:46:26 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20614 for ipng-dist; Fri, 21 Aug 1998 07:42:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA20607 for ; Fri, 21 Aug 1998 07:42:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA24352; Fri, 21 Aug 1998 07:42:30 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA05556; Fri, 21 Aug 1998 07:42:30 -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 KAA15428; Fri, 21 Aug 1998 10:42:09 -0400 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA28512; Fri, 21 Aug 1998 10:42:10 -0400 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA23758; Fri, 21 Aug 1998 10:42:07 -0400 Message-Id: <35DD873F.D336136A@raleigh.ibm.com> Date: Fri, 21 Aug 1998 10:42:07 -0400 From: Brian Haberman Organization: Remote Access Products X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: kuznet@ms2.inr.ac.ru Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com Subject: (IPng 6306) Re: Usefulness of site local addresses (again) References: <199808211403.SAA05769@ms2.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexey, There is another draft that addresses the site-scoping issue from a routing perspective. You can find that by following this http://www.ietf.org/internet-drafts/draft-haberman-ipv6-site-route-00.txt. Brian Haberman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 08:00:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20644 for ipng-dist; Fri, 21 Aug 1998 07:56:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA20637 for ; Fri, 21 Aug 1998 07:56:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA27792 for ; Fri, 21 Aug 1998 07:56:14 -0700 Received: from send102.yahoomail.com (send102.yahoomail.com [205.180.60.90]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA12628 for ; Fri, 21 Aug 1998 07:56:15 -0700 (PDT) Message-ID: <19980821145558.11789.rocketmail@send102.yahoomail.com> Received: from [138.111.39.131] by send102.yahoomail.com; Fri, 21 Aug 1998 07:55:58 PDT Date: Fri, 21 Aug 1998 07:55:58 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6307) Reg: Site Prefix and AREA Identification. To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all... Can I reserve some n bits for identifying the AREA in the context of a OSPF. Then it will reduce the burden on site boundary router. Thanks -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 08:01:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA20657 for ipng-dist; Fri, 21 Aug 1998 07:57:19 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id HAA20650 for ; Fri, 21 Aug 1998 07:57:05 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id HAA18052; Fri, 21 Aug 1998 07:56:52 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id HAA05230; Fri, 21 Aug 1998 07:55:34 -0700 (PDT) Date: Fri, 21 Aug 1998 07:55:34 -0700 (PDT) From: Mukesh Kacker Message-Id: <199808211455.HAA05230@lucknow.eng.sun.com> To: Erik.Nordmark@Eng, onoe@sm.sony.co.jp, cmetz@inner.net, Mukesh.Kacker@Eng Subject: (IPng 6308) Re: API/union sockaddr_union/struct sockaddr_storage Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would like to bring back the issue to think more about what is > the requirement of what we are trying to achieve here in a separate > email. > Here is the "separate email". in an attempt to bring focus on problem/issues. Hopefully it can help with the Corridor-BOF I see coming at Chicago :-) and let us sort things then. I will shut up till then and not contribute to exponential growth in email traffic and allow people to tune in on more interesting discussions on other channels :-) The problem being addressed in the words in the specification is: > This structure solves the problem that you don't know how big the | > retrieve buffer for a socket address structure needs to be until you | > have received that structure (e.g., getpeername()). Also, much | > existing code assumes that any socket address structure can fit in a | > generic sockaddr structure. While this has been true for IPv4 socket | So the design in the specification (and some other proposals) so far has worked with the requirements: (A) a data structure type big enough to store various protocol specific address data structures. (B) a type that aligns storage so that when I cast it to a protocol specific address, I can address the fields without alignment trouble. So force it to be on a predicatable implmentation-specific maximal alignment. It seems that there is some requirement (C) which people want and have not stated and various competing proposals are flying around. With trying to derive that in mind I can cook up the following hypothetical code which uses sockaddr_storage and tries to use it. 1 { 2 struct sockaddr_storage ss; 3 struct sockaddr *sap; 4 ... 5 getpeername(fd, (struct sockaddr *)&ss, 6 sizeof (struct sockaddr_storage)); 7 sap = (struct sockaddr *) &ss; <============THIS LINE ? 8 9 sa_family/sa_len/whatever and 10 determine protocol specific address structure and cast to it> 11 e.g 12 if (sa->sa_family == AF_INET6) 13 sin6 = (struct sockaddr_in6 *)&ss; 14 15 17 } If the structure contains a "struct sockaddr", I see that cast on line 7 marked as "THIS LINE ?" which can be avoided if there is an embedded "struct sockaddr" as first thing and people can reference family/len without doing a cast. (And I guess that is why Erik's latest proposal puts the field first as then family/len will be filled in by the getpeername()). Is the unstated requirement (C) that I want to reference family/sa_len without having to do the cast in line 7 above ? I would like people to state the unstated requirement and focus on that. Frankly, I personally still do not think that cast above is that undue a burden that we should invent increasingly ugly data structures and continue to prefer sockaddr_storage without an embedded "struct sockaddr" though I can live with it. The above cast on line 7 is no big deal. Or maybe I have not understood the "true set of requirements". There are other issues of places where "struct sockaddr" is used such as "struct if*" in that people have been inventing a "larger sockaddr" for. But those are beyond the scope the Basic API but if that is contributing to any unstated requirement, I would like to hear it. Will continue this discussion in the "Corridor BOF" at IETF. -Mukesh Kacker mukesh.kacker@eng.sun.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 08:40:05 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA20726 for ipng-dist; Fri, 21 Aug 1998 08:30:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA20719 for ; Fri, 21 Aug 1998 08:30:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA05485 for ; Fri, 21 Aug 1998 08:30:33 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA02078 for ; Fri, 21 Aug 1998 08:30:33 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id PAA00638; Fri, 21 Aug 1998 15:30:18 GMT Message-Id: <199808211530.PAA00638@inner.net> To: Robert Elz cc: ipng@sunroof.eng.sun.com Subject: (IPng 6309) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Fri, 21 Aug 1998 19:39:55 +1000." <7370.903692395@munnari.OZ.AU> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 21 Aug 1998 11:29:26 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <7370.903692395@munnari.OZ.AU>, you write: > So far, what I'm hearing from people is that the content of this field > and how it's obtained is still an area involving hand-waving. > >Yes, I think you're right, and I agree that the basic "convert this name >to an address" type function should be supplying this information. That >basically means that such functions ought to be returning sockaddr's instead >of just the 128 (or whatever) bit string. Making it part of the string would solve that problem. Then what about DNS? -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 08:41:15 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA20749 for ipng-dist; Fri, 21 Aug 1998 08:38:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA20742 for ; Fri, 21 Aug 1998 08:38:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA07035; Fri, 21 Aug 1998 08:38:09 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA06206; Fri, 21 Aug 1998 08:38:06 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id PAA00649; Fri, 21 Aug 1998 15:37:59 GMT Message-Id: <199808211537.PAA00649@inner.net> To: Mukesh Kacker cc: ipng@sunroof.eng.sun.com Subject: (IPng 6310) Re: API/union sockaddr_union/struct sockaddr_storage In-reply-to: Your message of "Fri, 21 Aug 1998 07:55:34 PDT." <199808211455.HAA05230@lucknow.eng.sun.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 21 Aug 1998 11:37:09 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808211455.HAA05230@lucknow.eng.sun.com>, you write: > (A) a data structure type big enough to store various protocol specific > address data structures. Not quite -- needs to be large enough to store any sockaddr the system will give you. > (B) a type that aligns storage so that when I cast it to a protocol > specific address, I can address the fields without alignment > trouble. So force it to be on a predicatable implmentation-specific > maximal alignment. The first sentence yes; the second one maybe not. It depends on what you define "maximal alignment" to mean. >Is the unstated requirement (C) that I want to reference family/sa_len >without having to do the cast in line 7 above ? I would like people to state >the unstated requirement and focus on that. Yes. If you have to do a cast to get there, you've vastly increased your opportunities to shoot yourself in the foot since the cast overrides much of the compiler's type-related sanity checking. Doing it your way also creates another variable, though hopefully your optimizer is smart enough to realize that it references the same object. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 08:42:13 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA20758 for ipng-dist; Fri, 21 Aug 1998 08:39:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA20751 for ; Fri, 21 Aug 1998 08:39:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA07418; Fri, 21 Aug 1998 08:39:45 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA07050; Fri, 21 Aug 1998 08:39:43 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id PAA00654; Fri, 21 Aug 1998 15:39:36 GMT Message-Id: <199808211539.PAA00654@inner.net> To: Mukesh Kacker cc: ipng@sunroof.eng.sun.com Subject: (IPng 6311) Re: API/union sockaddr_union/struct sockaddr_storage In-reply-to: Your message of "Fri, 21 Aug 1998 06:05:10 PDT." <199808211305.GAA05189@lucknow.eng.sun.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 21 Aug 1998 11:38:44 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808211305.GAA05189@lucknow.eng.sun.com>, you write: >So the above works, though I would have >still preferred a design that keeps the "largest alginment" field >as first field of data structure so it is easy to design/think about >this issue. Then perhaps you should read the second half of that message; Atsushi Onoe's proposal does just that. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 09:16:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA20849 for ipng-dist; Fri, 21 Aug 1998 09:07:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA20842 for ; Fri, 21 Aug 1998 09:06:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA14778 for ; Fri, 21 Aug 1998 09:06:35 -0700 Received: from send102.yahoomail.com (send102.yahoomail.com [205.180.60.90]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA22940 for ; Fri, 21 Aug 1998 09:06:35 -0700 (PDT) Message-ID: <19980821160617.6030.rocketmail@send102.yahoomail.com> Received: from [138.111.39.131] by send102.yahoomail.com; Fri, 21 Aug 1998 09:06:17 PDT Date: Fri, 21 Aug 1998 09:06:17 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6312) Reg: EUI-64 bit format To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi!! Does EUI-64 reserve a block for multicasting hardware addresses. Thanks -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 09:34:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA20886 for ipng-dist; Fri, 21 Aug 1998 09:26:04 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA20879 for ; Fri, 21 Aug 1998 09:25:51 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA27016; Fri, 21 Aug 1998 09:25:46 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1+Sun/8.9.1) id JAA05258; Fri, 21 Aug 1998 09:24:28 -0700 (PDT) Date: Fri, 21 Aug 1998 09:24:28 -0700 (PDT) From: Mukesh Kacker Message-Id: <199808211624.JAA05258@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, cmetz@inner.net Subject: (IPng 6313) Re: API/union sockaddr_union/struct sockaddr_storage Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >Is the unstated requirement (C) that I want to reference family/sa_len > >without having to do the cast in line 7 above ? I would like people to state > >the unstated requirement and focus on that. > > Yes. > > If you have to do a cast to get there, you've vastly increased your > opportunities to shoot yourself in the foot since the cast overrides much of > the compiler's type-related sanity checking. Doing it your way also creates > another variable, though hopefully your optimizer is smart enough to realize > that it references the same object. > Hmmm...I guess you don't like type casts, then I would suggest using another language then :-). This is a fringe case of a need where one can expect multiple types of addresses to get filled in. I don't think we should design APIs to avoid "shoot yourself in the foot" with sloppy coding spanning a few-lines of scope and compilers that can't handle optimization. There are code paths where one needs to deal with careful optimization such as what you have in mind. But it is not a a religious doctrine to be applied everywhere and this instance does not qualify by my measure. If we go looking for those issues to solve and optimize everywhere, we would be spinning forever redesigning everything based on what limitations whose compiler has and what is perfectly optimal etc. Sorry, but atleast I personally don't feel "converted" to expand the requirements to include a "access sa_family etc without cast and structure offset" requirement based on these arguments. Sure, we can design committee-camel-data structures with compromises that satisfy everyone, but I am not sure that is a good thing. -Mukesh Kacker mukesh.kacker@eng.sun.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 13:58:41 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA21135 for ipng-dist; Fri, 21 Aug 1998 13:53:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA21128 for ; Fri, 21 Aug 1998 13:52:57 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA07113 for ; Fri, 21 Aug 1998 13:52:55 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA09581 for ; Fri, 21 Aug 1998 13:52:55 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id ; Fri, 21 Aug 1998 13:52:55 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8113C@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 6314) Routing header questions Date: Fri, 21 Aug 1998 13:52:53 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft has very helpful pseudo-code for processing the Routing (Type 0) header. But I still have a few low-level questions: 1. The draft specifies a check that the new destination address (Address[i]) is not multicast. What about checking for the unspecified address? Surely that should be disallowed also. What about the loopback address? What about v4-mapped addresses? 2. Suppose I receive a packet A, discover there's a routing header and process it to get a new packet B. The processing consists of decrementing the hop limit, decrementing segments left, and swapping in a new destination address. Should I also zero out the Reserved field in the Routing header, or should I pass that field through unchanged? 3. Suppose I need to generate an ICMP error while doing this processing. Should ICMP error payload be the unmodified packet A? Or should it be a partly-processed packet with the modifications that have been made up to the point where the error was detected? Or can implementations make different choices here? [As a related example: when a router receives a packet with a hop limit of 1, does the ICMP error payload typically show the hop limit to be 1 or 0? Does it matter?] 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 Aug 21 14:36:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA21221 for ipng-dist; Fri, 21 Aug 1998 14:30:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA21214 for ; Fri, 21 Aug 1998 14:29:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA17331 for ; Fri, 21 Aug 1998 14:29:45 -0700 Received: from csgrad.cs.vt.edu (csgrad.cs.vt.edu [128.173.41.41]) by earth.sun.com (8.9.1/8.9.1) with SMTP id OAA29539 for ; Fri, 21 Aug 1998 14:29:46 -0700 (PDT) Received: from localhost by csgrad.cs.vt.edu (5.65v4.0/1.1.10.5/10Mar98-1026AM) id AA13204; Fri, 21 Aug 1998 17:29:44 -0400 Date: Fri, 21 Aug 1998 17:29:44 -0400 (EDT) From: Jianxin Zhao To: "'IPng List'" Subject: (IPng 6315) thousands of sockets on one machine Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, This is Jianxin from Virginia Tech. I'm reengineering a digital library system. According to the current design, there will be at least thousands of active sockets on the back end server when user number increases (for example over 20,000). I don't know how much memory space and cpu power will be consumed by managing sockets if there are thousands of or more sockets active on one machine. Also according to current design there will also be thousands of threads running on same machine, again I want to know how much overhead are there if such situation happened in one machine. if it's not practical we may have to change our design to handle more users. Can somone give me some advice on these two issues ? thank you in advance. Have a nice day ! Jianxin ---------------------------------------------------------------------- Jianxin Zhao E-mail: jxzhao@csgrad.cs.vt.edu Graduate student Tel: (540)961-0405 Computer Science Department Address: 11600 F Foxtrail Ln. NW Virginia Tech. BLACKSBURG VA 24060 WWW: http://csgrad.cs.vt.edu/~jxzhao ---------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 15:39:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA21297 for ipng-dist; Fri, 21 Aug 1998 15:32:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA21290 for ; Fri, 21 Aug 1998 15:32:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA04567 for ; Fri, 21 Aug 1998 15:32:01 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA00230 for ; Fri, 21 Aug 1998 15:32:01 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 21 Aug 1998 15:32:01 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8113E@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: (IPng 6316) RE: Routing header questions Date: Fri, 21 Aug 1998 15:31:55 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. The draft specifies a check that the new destination > address (Address[i]) is not multicast. What about checking > for the unspecified address? Surely that should be disallowed > also. What about the loopback address? What about v4-mapped addresses? Btw, I'm assuming that if the new destination address is a link-local address, then the outgoing link should be the same as the incoming link. Similarly if the destination address is site-local, it should stay within the site that it came in on. Is this other people's interpretation? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 21 15:57:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA21377 for ipng-dist; Fri, 21 Aug 1998 15:50:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA21370 for ; Fri, 21 Aug 1998 15:50:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA10875 for ; Fri, 21 Aug 1998 15:50:31 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id PAA08898 for ; Fri, 21 Aug 1998 15:50:31 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA18110; Fri, 21 Aug 98 15:49:13 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA00789; Fri, 21 Aug 1998 15:53:03 -0700 Date: Fri, 21 Aug 1998 15:53:03 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199808212253.PAA00789@feller.mentat.com> To: ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: (IPng 6317) Re: Routing header questions X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, My $.02. > > 1. The draft specifies a check that the new destination address (Address[i]) > is not multicast. What about checking for the unspecified address? Surely > that should be disallowed also. What about the loopback address? What about > v4-mapped addresses? > I believe that the algorithm expects that the base forwarding code will sniff out all the other bogus conditions and act accordingly. The multicast check needs to be there because the base forwarding code won't necessarily view a multicast destination as bogus. > 2. Suppose I receive a packet A, discover there's a routing header and > process it to get a new packet B. The processing consists of decrementing > the hop limit, decrementing segments left, and swapping in a new destination > address. Should I also zero out the Reserved field in the Routing header, or > should I pass that field through unchanged? > My view is that this field should be set to zero my the originator and ignored by the forwarders and the final destination. > 3. Suppose I need to generate an ICMP error while doing this processing. > Should ICMP error payload be the unmodified packet A? Or should it be a > partly-processed packet with the modifications that have been made up to the > point where the error was detected? Or can implementations make different > choices here? > Clearly, one could arrange the routing header code in such a way as to guarantee that no fields were updated until everything is known to be good. This is what we attempt do. If this is not possible then I suspect that it would be sufficient to simply return the partially updated header. > [As a related example: when a router receives a packet with a hop limit of > 1, does the ICMP error payload typically show the hop limit to be 1 or 0? > Does it matter?] > In our case the forwarding code would return an offending datagram with a decremented hop limit. 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 Aug 24 11:41:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA23067 for ipng-dist; Mon, 24 Aug 1998 11:33:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA23060 for ; Mon, 24 Aug 1998 11:33:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA19884 for ; Mon, 24 Aug 1998 11:33:19 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA27927 for ; Mon, 24 Aug 1998 11:33:19 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id ; Mon, 24 Aug 1998 11:33:18 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8114E@RED-MSG-50> From: Richard Draves To: "'thartric@mentat.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 6323) RE: Routing header questions Date: Mon, 24 Aug 1998 11:33:09 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I believe that the algorithm expects that the base forwarding > code will > sniff out all the other bogus conditions and act accordingly. > The multicast > check needs to be there because the base forwarding code > won't necessarily > view a multicast destination as bogus. I've read most of the RFCs/IDs and I don't recall a discussion of what checks the base forwarding code should perform. Has this been written down somewhere? For example if the destination address is unspecified or loopback, should the packet be silently discarded or should an ICMP error be sent? (Discarded I would assume.) If the source address is link-local or site-local and the packet is leaving that scope, should it be silently discarded or should an ICMP error be sent? (An ICMP error is appropriate here I think, but which one? [I vaguely recall an email discussion of this case.]) Should there be other sanity checks on the source address? Etc. The case of a loopback destination address is interesting - in the generic forwarding case it doesn't make sense to me, but in the routing header case it could be allowed I suppose. > > 2. Suppose I receive a packet A, discover there's a routing > header and > > process it to get a new packet B. The processing consists > of decrementing > > the hop limit, decrementing segments left, and swapping in > a new destination > > address. Should I also zero out the Reserved field in the > Routing header, or > > should I pass that field through unchanged? > > > > My view is that this field should be set to zero my the originator and > ignored by the forwarders and the final destination. I agree that would preserve the most flexibility for the field, but if I read the spec literally I think as a forwarder I should zero the Reserved field. 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 Mon Aug 24 17:47:25 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA23431 for ipng-dist; Mon, 24 Aug 1998 17:35:36 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA23422 for ; Mon, 24 Aug 1998 17:35:19 -0700 (PDT) Received: from lillen (hobo102 [129.146.31.102]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id RAA13191; Mon, 24 Aug 1998 17:35:06 -0700 (PDT) Date: Mon, 24 Aug 1998 14:20:16 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6324) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: kuznet@ms2.inr.ac.ru Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, cmetz@inner.net In-Reply-To: "Your message with ID" <199808211417.SAA05925@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > sin6_flowinfo cannot be used by QoS applications, believe me. > I have some experience in this area. Maybe, more experience > than someone another. > > Explanation is ridiculously simple: flowlabel is associated > with source address. Hence it has real meaning only in received sockaddr. > To avoid situation, when application uses received address for reply > blindly and hence tries to use invalid flowlabel, it will be ignored > by sendto(). This "feature" is known since this field appeared, > you cannot not know about it. 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. 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 Mon Aug 24 17:48:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id RAA23438 for ipng-dist; Mon, 24 Aug 1998 17:35:48 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id RAA23430 for ; Mon, 24 Aug 1998 17:35:32 -0700 (PDT) Received: from lillen (hobo102 [129.146.31.102]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id RAA13197; Mon, 24 Aug 1998 17:35:14 -0700 (PDT) Date: Mon, 24 Aug 1998 14:30:54 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6325) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: Craig Metz Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808210007.AAA01818@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is a simplified demonstration. To restate my concern, IMO the property > that getaddrinfo(getnameinfo(sa)) == sa for numeric lookups needs to hold > (with ai_socktype and ai_flags possibly needing to be specified out of band) > or the functions are a lot less useful. The first draft of the basic API years ago had a sin6_flowinfo field which violated your desired property. Thus if you want to argue that we should remove sin6_flowinfo and sin6_flowid you need to provide a lot stronger arguments why the above property is required. 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 Mon Aug 24 20:11:43 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA23675 for ipng-dist; Mon, 24 Aug 1998 20:05:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA23668; Mon, 24 Aug 1998 20:05:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA00159; Mon, 24 Aug 1998 20:05:40 -0700 Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA25274; Mon, 24 Aug 1998 20:05:40 -0700 (PDT) Received: from classic ([207.227.19.97]) by jazz.viagenie.qc.ca (Viagenie/8.8.8) with SMTP id WAA08883; Mon, 24 Aug 1998 22:59:12 -0400 (EDT) Message-Id: <3.0.5.32.19980824230411.02dc8d70@mail.viagenie.qc.ca> Prefer-Language: fr, en X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 24 Aug 1998 23:04:11 -0400 To: ietf@ietf.org, 6bone@isi.edu, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, c2-tech@canarie.ca From: Marc Blanchet Subject: (IPng 6326) ipv6 connections available in the terminal room of the ietf meeting Cc: Florent.Parent@viagenie.qc.ca Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id UAB23669 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, we have configured an ipv6 router on the network of the ietf terminal room. This router is connected to our ipv6 router on Viagénie-network (which is one of the pTLA on the 6bone) by a ipv6 over ipv4 tunnel, so that it is connected to the 6bone. Anybody who have an IPv6 stack can automatically get an ipv6 address without any configuration to get connected to the 6bone. You will receive an address in the viagénie net range 3ffe:0b00:c18:2::/64. The router is up since 20h00 monday 24th and will be there all week long. We've tested both freebsd inria ipv6 and Microsoft NT ipv6 implementations on our portables and were able to connect to any ipv6 host on the 6bone. The idea of this service came from my collegue Florent Parent. We would like to hear anybody who tried this service. Please mention your implementation. Have fun, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp :57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifié, Éditions Logiques, 1997 ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 24 20:21:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA23703 for ipng-dist; Mon, 24 Aug 1998 20:14:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA23696 for ; Mon, 24 Aug 1998 20:13:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA01190 for ; Mon, 24 Aug 1998 20:13:39 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id UAA28831 for ; Mon, 24 Aug 1998 20:13:40 -0700 (PDT) Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA09911; Mon, 24 Aug 98 20:11:39 PDT Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id UAA01250; Mon, 24 Aug 1998 20:13:33 -0700 Date: Mon, 24 Aug 1998 20:13:33 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199808250313.UAA01250@orna.mentat.com> To: kuznet@ms2.inr.ac.ru, Erik.Nordmark@Eng Subject: (IPng 6327) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, cmetz@inner.net X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > sin6_flowinfo cannot be used by QoS applications, believe me. > > I have some experience in this area. Maybe, more experience > > than someone another. > > > > Explanation is ridiculously simple: flowlabel is associated > > with source address. Hence it has real meaning only in received sockaddr. > > To avoid situation, when application uses received address for reply > > blindly and hence tries to use invalid flowlabel, it will be ignored > > by sendto(). This "feature" is known since this field appeared, > > you cannot not know about it. > > 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. > Hmm... I don't really see why the API should even return flow label information in the sockaddr_in6's returned from recvfrom, recvmsg and accept. Is there any utility in an application knowing these values? I can see returning the class bits but not the flow label bits. 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 Aug 24 20:29:16 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA23720 for ipng-dist; Mon, 24 Aug 1998 20:21:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id UAA23713 for ; Mon, 24 Aug 1998 20:21:08 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA02192 for ; Mon, 24 Aug 1998 20:20:52 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id UAA02042 for ; Mon, 24 Aug 1998 20:20:53 -0700 (PDT) Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA09971; Mon, 24 Aug 98 20:19:32 PDT Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id UAA01317; Mon, 24 Aug 1998 20:21:26 -0700 Date: Mon, 24 Aug 1998 20:21:26 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199808250321.UAA01317@orna.mentat.com> To: ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: (IPng 6328) Re: Routing header questions X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > > > I believe that the algorithm expects that the base forwarding > > code will > > sniff out all the other bogus conditions and act accordingly. > > The multicast > > check needs to be there because the base forwarding code > > won't necessarily > > view a multicast destination as bogus. > > I've read most of the RFCs/IDs and I don't recall a discussion of what > checks the base forwarding code should perform. Has this been written down > somewhere? For example if the destination address is unspecified or > loopback, should the packet be silently discarded or should an ICMP error be > sent? (Discarded I would assume.) If the source address is link-local or > site-local and the packet is leaving that scope, should it be silently > discarded or should an ICMP error be sent? (An ICMP error is appropriate > here I think, but which one? [I vaguely recall an email discussion of this > case.]) Should there be other sanity checks on the source address? Etc. > > The case of a loopback destination address is interesting - in the generic > forwarding case it doesn't make sense to me, but in the routing header case > it could be allowed I suppose. > You are correct that there is limited guidance in the documents about what datagrams with what bogus source and/or destination addresses should and should not be forwarded. The only point I was attempting to make was that the illegal cases for which you are checking in your source route processing code are conditions which are probably equally illegal in absense of a source route and could be checked in the base forwarding code. The lone exception to this being a multicast destination which is perfectly legal except if the destination was pulled from a routine header. 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 Aug 24 23:42:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA23890 for ipng-dist; Mon, 24 Aug 1998 23:35:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA23883 for ; Mon, 24 Aug 1998 23:35:45 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA25074 for ; Mon, 24 Aug 1998 23:35:44 -0700 Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA11430 for ; Mon, 24 Aug 1998 23:35:40 -0700 (PDT) Received: from localhost (kame201.kame.net [203.178.141.201]) by orange.kame.net (8.8.8+3.0Wbeta13/3.6W) with ESMTP id PAA18366; Tue, 25 Aug 1998 15:35:10 +0900 (JST) To: ipng@sunroof.eng.sun.com Cc: richdr@microsoft.com Subject: (IPng 6330) Re: Routing header questions In-Reply-To: Your message of "Fri, 21 Aug 1998 13:52:53 -0700" <4D0A23B3F74DD111ACCD00805F31D8100AF8113C@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF8113C@RED-MSG-50> X-Mailer: Mew version 1.93b52 on Emacs 20.2 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980825153209C.jinmei@isl.rdc.toshiba.co.jp> Date: Tue, 25 Aug 1998 15:32:09 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980522 Lines: 97 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, >>>>> On Fri, 21 Aug 1998 13:52:53 -0700, >>>>> Richard Draves said: > The draft has very helpful pseudo-code for processing the Routing (Type 0) > header. But I still have a few low-level questions: > 1. The draft specifies a check that the new destination address (Address[i]) > is not multicast. What about checking for the unspecified address? Surely > that should be disallowed also. What about the loopback address? What about > v4-mapped addresses? Personally, I would prefer that the same rule should be applied both for the IPv6 source and destination addresses and for the addresses in a routing header. For example, - The unspecified address should not appear in a routing header. - The loopback address should not appear in a routing header if the packet comes from an outside of the node. - If a link-local scope address contains in the routing header, the packet should not be forwarded to other links. But as you said, there seems to be no explicit description in the IPv6 specification about the scope of addresses in a routing header. I would prefer that the specification should be clearer on this point, but I admit it is not so serious problem to stop advancing the state of the specification. > 2. Suppose I receive a packet A, discover there's a routing header and > process it to get a new packet B. The processing consists of decrementing > the hop limit, decrementing segments left, and swapping in a new destination > address. Should I also zero out the Reserved field in the Routing header, or > should I pass that field through unchanged? IMO, we SHOULD NOT zero out the field. In a later mail, you also said that we should zero the field when forwarding by spec. Do you mean the description below? Reserved 32-bit reserved field. Initialized to zero for transmission; ignored on reception. (from draft-ietf-ipngwg-ipv6-spec-v2-02.txt) If so, in my understanding, the word `transmission' means origination. That is, the statement is applied only for the source of the packet. If we allow intermediate forwarders to rewrite the reserved field, there is another problem related with IPsec; when we calculate authentication data for an AH, we must regard the reserved field of a routing header as mutable and must set zero(or other constant value) in the field before calculation. But there is no such description in the AH draft. This may cause serious interoperability problems. > 3. Suppose I need to generate an ICMP error while doing this processing. > Should ICMP error payload be the unmodified packet A? Or should it be a > partly-processed packet with the modifications that have been made up to the > point where the error was detected? Or can implementations make different > choices here? Our implementation, called KAME, returns an ICMP error without any modifications in the erroneous packet if the error occurs in the routing header procession. I think it is better than modifying the packet. Suppose that the case where the value of the segment field is 2 and the value of the extension header length field is also 2. This is illegal since segment left is greater than the number of addresses in the routing header computed by dividing Hdr Ext Len by 2(see the algorithm in page 16 of ipngwg-ipv6-spec-v2-02). But what if we decrement segment left before returning ICMP error? The modified error packet is completely valid, so the receiver of the error would confuse. > [As a related example: when a router receives a packet with a hop limit of > 1, does the ICMP error payload typically show the hop limit to be 1 or 0? > Does it matter?] I don't know the typical case. But KAME kernel returns an error without modifying the packet, that is, the hop limit field of the error packet remains 1. INRIA kernel also seems to keep the field unchanged. On the other hand, the ICMPv6 specification says as follows: If a router receives a packet with a Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it MUST discard the packet and send an ICMPv6 Time Exceeded message with Code 0 to the source of the packet. (from draft-ietf-ipngwg-icmp-v2-01.txt) It can be interpreted that a router decrements the hop limit before sending ICMP error. But I think the difference is not a problem in this case. The receiver of the error can easily understand what was wrong by the error type and the code regardless of the value of the hop limit field in the error data. Regards, JINMEI, Tatuya KAME project jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 00:17:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id AAA23921 for ipng-dist; Tue, 25 Aug 1998 00:09:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id AAA23913 for ; Tue, 25 Aug 1998 00:08:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id AAA28534 for ; Tue, 25 Aug 1998 00:08:37 -0700 Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA22624 for ; Tue, 25 Aug 1998 00:08:38 -0700 (PDT) Received: from localhost (kame201.kame.net [203.178.141.201]) by orange.kame.net (8.8.8+3.0Wbeta13/3.6W) with ESMTP id QAA18472; Tue, 25 Aug 1998 16:08:17 +0900 (JST) To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6331) Re: Routing header questions In-Reply-To: Your message of "Fri, 21 Aug 1998 13:52:53 -0700" <4D0A23B3F74DD111ACCD00805F31D8100AF8113C@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF8113C@RED-MSG-50> X-Mailer: Mew version 1.93b52 on Emacs 20.2 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980825160516B.jinmei@isl.rdc.toshiba.co.jp> Date: Tue, 25 Aug 1998 16:05:16 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 980522 Lines: 45 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 21 Aug 1998 13:52:53 -0700, >>>>> Richard Draves said: > 1. The draft specifies a check that the new destination address (Address[i]) > is not multicast. What about checking for the unspecified address? Surely > that should be disallowed also. What about the loopback address? What about > v4-mapped addresses? I have a related question about multicast destinations with routing headers. What should we do if the IPv6 destination is a multicast address and the packet contains a type-0 routing header, whose segment left field is 0? The specification says we must accept the packet anyhow if the segment left is 0: If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header. (draft-ietf-ipngwg-ipv6-spec-v2-02.txt, Page 12) The specification also says that a multicast destination with a type-0 routing header must be disallowed: Multicast addresses must not appear in a Routing header of Type 0, or in the IPv6 Destination Address field of a packet carrying a Routing header of Type 0. (draft-ietf-ipngwg-ipv6-spec-v2-02.txt, Page 15) The specification does not explicitly show which rule should be preferred when both conditions happen simultaneously. But if we follow the algorithm in page 16 of the draft, we prefer the 1st rule; we accept the packet even if the destination is a multicast address. But the fact that we receive such a packet shows that the previous forwarder did not follow the specification, since the multicast address should have been appeared in the routing header. Is it the right behavior? I would like to know other implementers' opinion. Thanks in advance. JINMEI, Tatuya KAME project jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 06:57:33 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA24109 for ipng-dist; Tue, 25 Aug 1998 06:52:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA24102 for ; Tue, 25 Aug 1998 06:52:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA06730; Tue, 25 Aug 1998 06:52:39 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA16852; Tue, 25 Aug 1998 06:52:34 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id RAA30899; Tue, 25 Aug 1998 17:52:04 +0400 Message-Id: <199808251352.RAA30899@ms2.inr.ac.ru> Subject: (IPng 6333) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: Erik.Nordmark@Eng Date: Tue, 25 Aug 1998 17:52:04 +0400 (MSK DST) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, cmetz@inner.net Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: from "Erik Nordmark" at Aug 24, 98 02:20:16 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > 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. It would be real disaster for protocol-independant applications. Actually, I think Sun should understand it much better than me. ONC RPC, XTI... For now the only exit for sendto() is to ignore this field. BTW flowinfo, received with recvfrom(), is valid but pretty useless value. At least, I failed to invent some real applications for it. flowlabel is interesting for sender and for intermediate routers, but not for receiver. BTW do you know something about Sun plans on XTI and IPv6? Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 07:19:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA24162 for ipng-dist; Tue, 25 Aug 1998 07:11:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA24155 for ; Tue, 25 Aug 1998 07:11:05 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA10157; Tue, 25 Aug 1998 07:10:59 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA28452; Tue, 25 Aug 1998 07:10:54 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA31069; Tue, 25 Aug 1998 18:10:34 +0400 Message-Id: <199808251410.SAA31069@ms2.inr.ac.ru> Subject: (IPng 6334) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: thartric@mentat.com (Tim Hartrick) Date: Tue, 25 Aug 1998 18:10:34 +0400 (MSK DST) Cc: Erik.Nordmark@Eng, bound@zk3.dec.com, ipng@sunroof.eng.sun.com, cmetz@inner.net Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808250313.UAA01250@orna.mentat.com> from "Tim Hartrick" at Aug 24, 98 08:13:33 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > Hmm... I don't really see why the API should even return flow label > information in the sockaddr_in6's returned from recvfrom, recvmsg and > accept. Is there any utility in an application knowing these values? > > I can see returning the class bits but not the flow label bits. Yes. There is no point. And class bits are also not useful for receiver, because they may be changed in transit. To continue this thought: they are not useful in sendto() too. Kernel has to check for flowlabel validity/uniqueness in any case, so that flowlabels are allocated, leased and released not depending on "stateless" sendto(). 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. Until bsd-api-02 appeared there was only one justification for preserving sin6_flowinfo, it played role of 8byte alignment pad for sin6_addr 8)8) Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 09:55:04 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA24431 for ipng-dist; Tue, 25 Aug 1998 09:50:26 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA24424 for ; Tue, 25 Aug 1998 09:50:21 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA17582 for ; Tue, 25 Aug 1998 09:50:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA04217 for ipng@sunroof.eng.sun.com; Tue, 25 Aug 1998 09:49:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA24358; Tue, 25 Aug 1998 09:14:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA10129; Tue, 25 Aug 1998 09:14:10 -0700 Received: from turmeric.itojun.org (mach93.xnet.com [207.227.19.93] (may be forged)) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA18848; Tue, 25 Aug 1998 09:14:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turmeric.itojun.org (8.8.5/3.3W3) with ESMTP id BAA07082; Wed, 26 Aug 1998 01:13:33 +0900 (JST) To: Marc Blanchet cc: 6bone@ISI.EDU, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, c2-tech@canarie.ca, Florent.Parent@viagenie.qc.ca In-reply-to: Marc.Blanchet's message of Mon, 24 Aug 98 23:04:11 -0400. <3.0.5.32.19980824230411.02dc8d70@mail.viagenie.qc.ca> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 6336) Re: ipv6 connections available in the terminal room of the ietf meeting cc: itojun@itojun.org From: Jun-ichiro itojun Itoh Date: Wed, 26 Aug 1998 01:13:33 +0900 Message-ID: <7079.904061613@cardamom.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >we have configured an ipv6 router on the network of the ietf terminal room. > This router is connected to our ipv6 router on Viag nie-network (which is >one of the pTLA on the 6bone) by a ipv6 over ipv4 tunnel, so that it is >connected to the 6bone. Anybody who have an IPv6 stack can automatically >get an ipv6 address without any configuration to get connected to the >6bone. You will receive an address in the viag nie net range >3ffe:0b00:c18:2::/64. (snip) >We would like to hear anybody who tried this service. Please mention your >implementation. KAME (http://www.kame.net/) works right with your router, and I can perform ssh6 toward my home. Thanks for your effort, itojun@kame.net jun-ichiro itojun itoh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 10:10:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA24502 for ipng-dist; Tue, 25 Aug 1998 10:03:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA24493 for ; Tue, 25 Aug 1998 10:02:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA23944 for ; Tue, 25 Aug 1998 10:02:51 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA21421 for ; Tue, 25 Aug 1998 10:02:51 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 25 Aug 1998 10:02:51 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8115F@RED-MSG-50> From: Richard Draves To: "'JINMEI Tatuya / ????'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6337) RE: Routing header questions Date: Tue, 25 Aug 1998 10:02:47 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: jinmei@isl.rdc.toshiba.co.jp > > IMO, we SHOULD NOT zero out the field. In a later mail, you also said > that we should zero the field when forwarding by spec. Do you mean the > description below? > > Reserved 32-bit reserved field. Initialized > to zero for > transmission; ignored on reception. > (from draft-ietf-ipngwg-ipv6-spec-v2-02.txt) > > If so, in my understanding, the word `transmission' means > origination. > That is, the statement is applied only for the source of the packet. > > If we allow intermediate forwarders to rewrite the reserved field, > there is another problem related with IPsec; when we calculate > authentication data for an AH, we must regard the reserved field of a > routing header as mutable and must set zero(or other constant value) > in the field before calculation. But there is no such description in > the AH draft. This may cause serious interoperability problems. This would be an obstacle to using the reserved field for something new in the future. It would not be an interoperability problem for current implementations, which always set the reserved field to zero. This is another good argument for not rewriting the reserved field, but my reading of the draft(and how I implemented it before initiating this email thread) is that the forwarder should zero the reserved field. My reasoning is that first the forwarder receives the packet with routing header and per the draft, ignores the value of the reserved field. Then the forwarder sends a new packet with a rewritten routing header, and again per the draft the reserved field in the new packet should be zero. I think if there's to be any hope of using this reserved field in the future, the spec should be clear that the forwarder should pass the reserved field through unchanged. This is probably not motivation enough to revise the draft, but if a new draft is produced for other reasons it would be nice to have this clarified. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 10:17:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA24535 for ipng-dist; Tue, 25 Aug 1998 10:11:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA24528 for ; Tue, 25 Aug 1998 10:11:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA26229 for ; Tue, 25 Aug 1998 10:11:07 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA27267 for ; Tue, 25 Aug 1998 10:11:07 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id ; Tue, 25 Aug 1998 10:11:07 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81160@RED-MSG-50> From: Richard Draves To: "'JINMEI Tatuya / ????'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6338) RE: Routing header questions Date: Tue, 25 Aug 1998 10:11:05 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The specification does not explicitly show which rule should be > preferred when both conditions happen simultaneously. But if we follow > the algorithm in page 16 of the draft, we prefer the 1st rule; we > accept the packet even if the destination is a multicast address. But > the fact that we receive such a packet shows that the previous > forwarder did not follow the specification, since the multicast > address should have been appeared in the routing header. Is it the > right behavior? > > I would like to know other implementers' opinion. Thanks in advance. I first check for SegmentsLeft == 0. Then RoutingType == 0. Then odd Header Ext Len. Then SegmentsLeft too big. Then multicast 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 Tue Aug 25 10:23:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA24577 for ipng-dist; Tue, 25 Aug 1998 10:16:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA24569 for ; Tue, 25 Aug 1998 10:15:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA27559 for ; Tue, 25 Aug 1998 10:15:45 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA00549 for ; Tue, 25 Aug 1998 10:15:39 -0700 (PDT) Received: by INET-IMC-05 with Internet Mail Service (5.5.2232.9) id ; Tue, 25 Aug 1998 10:15:37 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81161@RED-MSG-50> From: Richard Draves To: "'thartric@mentat.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6339) Re: Routing header questions Date: Tue, 25 Aug 1998 10:15:35 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You are correct that there is limited guidance in the documents about > what datagrams with what bogus source and/or destination > addresses should > and should not be forwarded. The only point I was attempting > to make was > that the illegal cases for which you are checking in your source route > processing code are conditions which are probably equally > illegal in absense > of a source route and could be checked in the base forwarding > code. The > lone exception to this being a multicast destination which is > perfectly > legal except if the destination was pulled from a routine header. I was trying to agree with you and then raise the issue that it would be very nice to have some specifications for the base forwarding code. I think one reason this is confusing is that the pseudo-code for the routing header goes through checking and decrementing the hop limit. Normally I would think the "base forwarding code" would handle this. So it's strange that the pseudo-code contains one generic forwarding check but not all of them. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 11:33:10 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id LAA24756 for ipng-dist; Tue, 25 Aug 1998 11:24:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id LAA24749 for ; Tue, 25 Aug 1998 11:24:28 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA20723; Tue, 25 Aug 1998 11:24:25 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA20916; Tue, 25 Aug 1998 11:24:24 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id OAA29723; Tue, 25 Aug 1998 14:22:08 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03353; Tue, 25 Aug 1998 14:22:07 -0400 Message-Id: <199808251822.AA03353@wasted.zk3.dec.com> To: kuznet@ms2.inr.ac.ru Cc: thartric@mentat.com (Tim Hartrick), Erik.Nordmark@Eng, bound@zk3.dec.com, ipng@sunroof.eng.sun.com, cmetz@inner.net Subject: (IPng 6340) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Tue, 25 Aug 1998 18:10:34 +0400." <199808251410.SAA31069@ms2.inr.ac.ru> Date: Tue, 25 Aug 1998 14:22:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexy, We are using the sin6flow is as by rsvp for ipv6 and by RAPI. It is also being used by several Voice over IP vendors. But regardless we will keep the flow in the sockaddr as your the only one who believes it is not important. It appears we need to state the case for recv* as Tim has pointed out for the flow on receive side. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 13:43:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA24903 for ipng-dist; Tue, 25 Aug 1998 13:38:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA24896 for ; Tue, 25 Aug 1998 13:38:21 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA29210 for ; Tue, 25 Aug 1998 13:38:20 -0700 Received: from imo11.mx.aol.com (imo11.mx.aol.com [198.81.17.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA14053 for ; Tue, 25 Aug 1998 13:38:19 -0700 (PDT) Received: from Telford001@aol.com by imo11.mx.aol.com (IMOv14_b1.1) id GXGEa02730; Tue, 25 Aug 1998 16:37:43 -0400 (EDT) Message-ID: Date: Tue, 25 Aug 1998 16:37:43 EDT To: kasten@argon.com, ipng@sunroof.eng.sun.com Cc: Telford001@aol.com Mime-Version: 1.0 Subject: (IPng 6341) Re: Reg: PATH MTU discovery Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 170 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 8/18/98 2:11:33 PM Eastern Daylight Time, kasten@argon.com writes: > >> No. Everyone will not agree. The router I'm building right now > >> can generate ICMP error messages (including the broken packet's > >> entire header) much faster than it can parse packets in its fast > >> path, to say nothing of the slow path... > >The claim is: > >generating an IP header + generating an ICMP header + copying or > >setting up pointers to the IP header + 64 bits of the packet that > >engenders the ICMP response + setting up some sort of > >mac header > >costs more than > >reading and processing the IP header (assumed meaning > >of parsing packets in the fast path). > >Sounds really weird and rather hideous. > remember, i'm doing this in an asic. in an asic there are things > that can be done that can't be done in software. optimization or > algorithm design or processor choice or whatever do not let you > do something that can't be done in software - they just let you > do something easier or faster. Perhaps I missed part of the discussion, but it was not obvious that we were discussing ASIC based implementations, which are generally a misguided approach to the problem of high performance packet switching and should not be treated as important in the development of internetworking standards. While one can do all sorts of things in parallel in custom programmable logic devices that might no be doable with standard processors, such capabilities are not really relevant to the high performance packet switching problem in situations of large traffic. When there is not much traffic, the cost of custom techniques is disproportionate. Nevertheless, if we ignore the inappropriateness of ASIC based packet switching solutions as well as cost and other relevant issues and choose to use an ASIC based design, as the packet is received serially, the header can be stored into ASIC registers and the header fields can be processed in the logic so that as soon as the last header byte is read from the network interface and the header checksum is passed the packet can be forwarded, or the ICMP response can be generated. In both cases, a full route look-up must be made to determine on which interface to send either the forwarded IP packet or the IP packet with the ICMP response. I have run across some bogus optimizations of NFS, where in processing an NFS request the server just sends the response out the interface the request came on with a destination MAC address that was the source MAC address of the request. Such optimizations are incorrect because there is no reason to believe the NFS response should reverse the path on which the orignal packet came. If such a bogus optimization is used for ICMP responses, first one must ask why anyone bothers to optimize the error path. Then one must note that this situation is even worse than for the server because if the source MAC address was the MAC address of the wrong router, the IP packet containing the ICMP response could well be forwarded back to the generating router (with an ICMP redirect) that would then have to route the packet fully. Flipping source and destination MAC addresses could also interact badly with bandwidth reservations (although in truth integrated services and MPLS are misconceived). If cost is no constraint on the ASIC and if routing and ICMP procedures are correctly, implemented, there is no reason for ICMP responses to be generated faster than packets can be forwarded. If cost is a constraint, spending resources to optimize error paths seems wrong whether the packet switching is done in software or in an ASIC. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 25 13:45:54 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA24912 for ipng-dist; Tue, 25 Aug 1998 13:42:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA24905 for ; Tue, 25 Aug 1998 13:42:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA00507 for ; Tue, 25 Aug 1998 13:42:33 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA16783 for ; Tue, 25 Aug 1998 13:42:31 -0700 (PDT) Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA16880; Tue, 25 Aug 98 13:41:00 PDT Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id NAA04060; Tue, 25 Aug 1998 13:42:57 -0700 Date: Tue, 25 Aug 1998 13:42:57 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199808252042.NAA04060@orna.mentat.com> To: thartric@mentat.com, richdr@microsoft.com Subject: (IPng 6342) Re: Routing header questions Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > > I was trying to agree with you and then raise the issue that it would be > very nice to have some specifications for the base forwarding code. > Understood. > I think one reason this is confusing is that the pseudo-code for the routing > header goes through checking and decrementing the hop limit. Normally I > would think the "base forwarding code" would handle this. So it's strange > that the pseudo-code contains one generic forwarding check but not all of > them. > Agreed. 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 Aug 26 05:11:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id FAA25552 for ipng-dist; Wed, 26 Aug 1998 05:06:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id FAA25545 for ; Wed, 26 Aug 1998 05:06:26 -0700 (PDT) From: Telford001@aol.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA23849 for ; Wed, 26 Aug 1998 05:06:23 -0700 Received: from imo19.mx.aol.com (imo19.mx.aol.com [198.81.17.9]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA27797 for ; Wed, 26 Aug 1998 05:06:25 -0700 (PDT) Received: from Telford001@aol.com by imo19.mx.aol.com (IMOv14_b1.1) id GSPOa16535; Wed, 26 Aug 1998 08:05:43 -0400 (EDT) Message-ID: <5bcfeefc.35e3fa18@aol.com> Date: Wed, 26 Aug 1998 08:05:43 EDT To: Telford001@aol.com, kasten@argon.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Subject: (IPng 6345) Re: Reg: PATH MTU discovery Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In a message dated 8/18/98 2:11:33 PM Eastern Daylight Time, kasten@argon.com writes: > >> No. Everyone will not agree. The router I'm building right now > >> can generate ICMP error messages (including the broken packet's > >> entire header) much faster than it can parse packets in its fast > >> path, to say nothing of the slow path... > >The claim is: > >generating an IP header + generating an ICMP header + copying or > >setting up pointers to the IP header + 64 bits of the packet that > >engenders the ICMP response + setting up some sort of > >mac header > >costs more than > >reading and processing the IP header (assumed meaning > >of parsing packets in the fast path). > >Sounds really weird and rather hideous. > remember, i'm doing this in an asic. in an asic there are things > that can be done that can't be done in software. optimization or > algorithm design or processor choice or whatever do not let you > do something that can't be done in software - they just let you > do something easier or faster. Perhaps I missed part of the discussion, but it was not obvious that we were discussing ASIC based implementations, which are generally a misguided approach to the problem of high performance packet switching and should not be treated as important in the development of internetworking standards. While one can do all sorts of things in parallel in custom programmable logic devices that might no be doable with standard processors, such capabilities are not really relevant to the high performance packet switching problem in situations of large traffic. When there is not much traffic, the cost of custom techniques is disproportionate. Nevertheless, if we ignore the inappropriateness of ASIC based packet switching solutions as well as cost and other relevant issues and choose to use an ASIC based design, as the packet is received serially, the header can be stored into ASIC registers and the header fields can be processed in the logic so that as soon as the last header byte is read from the network interface and the header checksum is passed the packet can be forwarded, or the ICMP response can be generated. In both cases, a full route look-up must be made to determine on which interface to send either the forwarded IP packet or the IP packet with the ICMP response. I have run across some bogus optimizations of NFS, where in processing an NFS request the server just sends the response out the interface the request came on with a destination MAC address that was the source MAC address of the request. Such optimizations are incorrect because there is no reason to believe the NFS response should reverse the path on which the orignal packet came. If such a bogus optimization is used for ICMP responses, first one must ask why anyone bothers to optimize the error path. Then one must note that this situation is even worse than for the server because if the source MAC address was the MAC address of the wrong router, the IP packet containing the ICMP response could well be forwarded back to the generating router (with an ICMP redirect) that would then have to route the packet fully. Flipping source and destination MAC addresses could also interact badly with bandwidth reservations (although in truth integrated services and MPLS are misconceived). If cost is no constraint on the ASIC and if routing and ICMP procedures are correctly, implemented, there is no reason for ICMP responses to be generated faster than packets can be forwarded. If cost is a constraint, spending resources to optimize error paths seems wrong whether the packet switching is done in software or in an ASIC. Joachim Martillo Telford Tools, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 26 08:53:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA25675 for ipng-dist; Wed, 26 Aug 1998 08:48:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA25668 for ; Wed, 26 Aug 1998 08:48:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA02598; Wed, 26 Aug 1998 08:48:10 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA19881; Wed, 26 Aug 1998 08:48:03 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA05214; Wed, 26 Aug 1998 19:46:39 +0400 Message-Id: <199808261546.TAA05214@ms2.inr.ac.ru> Subject: (IPng 6347) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: bound@zk3.dec.com Date: Wed, 26 Aug 1998 19:46:39 +0400 (MSK DST) Cc: thartric@mentat.com, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com, cmetz@inner.net Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808251822.AA03353@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Aug 25, 98 02:22:07 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > We are using the sin6flow is as by rsvp for ipv6 and by RAPI. > It is also being used by several Voice over IP vendors. It is very interesting. I know only one rsvp implementation supporting flow labels and it is mine one 8) Actually, I never saw (only heard) about another rsvp impls. working with IPv6 properly 8) Could you give me pointers? Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 26 09:43:14 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA25841 for ipng-dist; Wed, 26 Aug 1998 09:34:06 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA25834 for ; Wed, 26 Aug 1998 09:33:53 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA21277 for ; Wed, 26 Aug 1998 09:33:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA07042 for ipng@sunroof.eng.sun.com; Wed, 26 Aug 1998 09:32:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA25488 for ; Wed, 26 Aug 1998 03:03:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA15483 for ; Wed, 26 Aug 1998 03:03:33 -0700 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id DAA24001 for ; Wed, 26 Aug 1998 03:03:33 -0700 (PDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id FAA16920 for ; Wed, 26 Aug 1998 05:03:33 -0500 (CDT) Comments: ( Received on ftpbox.mot.com from client pobox.mot.com, sender odedw@mcil.comm.mot.com ) Received: from srv203.mcil.comm.mot.com (srv203.mcil.comm.mot.com [145.9.16.203]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with SMTP id FAA11992 for ; Wed, 26 Aug 1998 05:03:31 -0500 (CDT) Received: from ac208.mcil.comm.mot.com by srv203.mcil.comm.mot.com (4.1/SMI-4.1) id AA19722; Wed, 26 Aug 98 13:03:29 IDT Received: (from odedw@localhost) by ac208.mcil.comm.mot.com (8.7.3/8.7.3) id NAA16169 for ipng@sunroof.eng.sun.com; Wed, 26 Aug 1998 13:03:28 +0300 (IDT) Date: Wed, 26 Aug 1998 13:03:28 +0300 (IDT) From: Oded Weissman Message-Id: <9808261303.ZM16167@mcil.comm.mot.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: ipng@sunroof.eng.sun.com Subject: (IPng 6348) IP snooping package Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Looking for IP snooping package for unix The API should return the buffer of the IP frame (header + data). thanks Oded , , ("\''/").___..--''"`-._ Oded Weissman [Big O] `o_ o ) `-. ( ).`-.__.`) Software Engineer (_Y_.)' ._ ) `._ `. ``-..-' Motorola Communication _..`--'_..-_/ /--'_.' .' Israel 972-3-565(9526) (il),-'' (li),' ((!.-' odedw@mcil.comm.mot.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 26 09:43:21 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA25876 for ipng-dist; Wed, 26 Aug 1998 09:36:25 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA25869 for ; Wed, 26 Aug 1998 09:36:20 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA21518 for ; Wed, 26 Aug 1998 09:36:19 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA07101 for ipng@sunroof.eng.sun.com; Wed, 26 Aug 1998 09:35:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA25642 for ; Wed, 26 Aug 1998 08:29:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA27137 for ; Wed, 26 Aug 1998 08:29:51 -0700 Received: from turmeric.itojun.org (mach190.xnet.com [207.227.19.190]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA07665 for ; Wed, 26 Aug 1998 08:29:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turmeric.itojun.org (8.8.5/3.3W3) with ESMTP id AAA00553; Thu, 27 Aug 1998 00:29:32 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 6349) error to TCP6 toward anycast address? cc: itojun@itojun.org From: Jun-ichiro itojun Itoh Date: Thu, 27 Aug 1998 00:29:31 +0900 Message-ID: <550.904145371@turmeric.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If the following situation happen, how router B should send an error notification to host A? - host A has a global address, 3ffe:0501::A. - router B has global addresses 3ffe:0501::B and 3ffe:0502::B', and anycast address 3ffe:0501::1. - host A (mistakingly) performed telnet toward 3ffe:0501::1, which is an anycast address. NOTE: this is because host A has no way to check if he is connecting to anycast address, or non-anycast address. 3ffe:0501::A 3ffe:0501::B 3ffe:0502::B' 3ffe:0501::1 anycast host A router B ----------------------> SYN to 3ffe:0501::1 port X <---------------------- what kind of error report is suitable? TCP6 RST cannot be returned from B to A, since B has to use anycast address 3ffe:0501::1 in this case. (which is prohibited) ICMP6 port unreach(code=4), or ICMP6 address unreach(code=3) may be nice, but their semantics is not quite suitable for this situation. If B sends no error report, A has to wait until TCP timeouts, which is not really a pleasant behavior. Am I mistaking something? Any comments/implementation experiences would be helpful... itojun@kame.net jun-ichiro itoh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 26 14:35:17 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA26237 for ipng-dist; Wed, 26 Aug 1998 14:31:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA26230; Wed, 26 Aug 1998 14:31:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA15504; Wed, 26 Aug 1998 14:30:59 -0700 Received: from turmeric.itojun.org (mach131.xnet.com [207.227.19.131]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA08752; Wed, 26 Aug 1998 14:30:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turmeric.itojun.org (8.8.5/3.3W3) with ESMTP id GAA00939; Thu, 27 Aug 1998 06:30:14 +0900 (JST) To: Marc Blanchet , 6bone@ISI.EDU, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, c2-tech@canarie.ca, Florent.Parent@viagenie.qc.ca In-reply-to: itojun's message of Wed, 26 Aug 98 01:13:33 JST. <7079.904061613@cardamom.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: (IPng 6350) Re: ipv6 connections available in the terminal room of the ietf meeting cc: itojun@itojun.org Date: Thu, 27 Aug 1998 06:30:14 +0900 Message-ID: <936.904167014@turmeric.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>we have configured an ipv6 router on the network of the ietf terminal room. >> This router is connected to our ipv6 router on Viag nie-network (which is >>one of the pTLA on the 6bone) by a ipv6 over ipv4 tunnel, so that it is >>connected to the 6bone. Anybody who have an IPv6 stack can automatically >>get an ipv6 address without any configuration to get connected to the >>6bone. You will receive an address in the viag nie net range >>3ffe:0b00:c18:2::/64. >(snip) >>We would like to hear anybody who tried this service. Please mention your >>implementation. > KAME (http://www.kame.net/) works right with your router, and I can > perform ssh6 toward my home. Thanks for your effort, It does not work since lunchtime of Wednesday, since autonomous bit of prefix information is not set. (I once thought that it is a KAME local problem, but it seems to be cisco problem...) itojun --- 06:20:11.995020 fe80::200:cff:fe34:6f1b > fe80::200:86ff:fe05:80da: icmp6: router advertisement(chlim=255, router_ltime=1800, reachable_time=0, retrans_time=0)(src lladdr: 0:0:c:34:6f:1b)(prefix info: valid_ltime=86400, preffered_ltime=86400, prefix=3ffe:b00:c18:2::/64) [pri 0x7] (len 56, hlim 255) 6700 0000 0038 3aff fe80 0000 0000 0000 0200 0cff fe34 6f1b fe80 0000 0000 0000 0200 86ff fe05 80da 8600 38e3 ff00 0708 0000 0000 0000 0000 0101 0000 0c34 6f1b 0304 4000 0001 5180 0001 5180 0000 0000 ~~ has to be 0x40 3ffe 0b00 0c18 0002 0000 0000 0000 0000 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 26 21:01:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id UAA26818 for ipng-dist; Wed, 26 Aug 1998 20:56:36 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id UAA26811 for ; Wed, 26 Aug 1998 20:56:26 -0700 (PDT) Received: from unknown (hobo111 [129.146.31.111]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id UAA16145; Wed, 26 Aug 1998 20:56:24 -0700 (PDT) Date: Wed, 26 Aug 1998 18:27:50 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6353) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199808141633.AA03110@wasted.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 How will applications set sin6_scope_id? It could get it set transparently in getaddrinfo() or in addresses returned by recvfrom(). But do we need something else? For the link-local case we have the if_nametoindex function but there is nothing to get site ids for the site-local case. Thus we could add if_nametoindex() like functions to map from an interface name (e.g. "le0") to the site id for the site that includes the "le0" interface. We *could* do this by adding another argument to if_nametoindex() and if_indextoname() to specify whether it is an interface id or a site id. If we don't want to do this now I think the draft should point out that getaddrinfo() and recvfrom/recvmsg will set the sin6_scope_id. Right now the draft seems underspecified since it doesn't state any method whereby sin6_scope_id can be set (short of if_nametoindex for link-locals). 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 Aug 26 23:38:51 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id XAA26892 for ipng-dist; Wed, 26 Aug 1998 23:30:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id XAA26885 for ; Wed, 26 Aug 1998 23:29:59 -0700 (PDT) From: mohammed.j.saleh@ac.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA02121 for ; Wed, 26 Aug 1998 23:29:55 -0700 Received: from sxhab.compuserve.net (sxhab.compuserve.net [149.174.177.79]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA29581 for ; Wed, 26 Aug 1998 23:29:56 -0700 (PDT) Received: from aamta.compuserve.net ([149.174.177.83]) by sxhab.compuserve.net (8.8.8/8.6.12) with SMTP id CAA26019.; Thu, 27 Aug 1998 02:24:36 -0400 (EDT) Received: by aamta.compuserve.net(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 8525666D.0022F636 ; Thu, 27 Aug 1998 02:21:52 -0400 X-Lotus-FromDomain: ACIN@CSERVE To: ipng@sunroof.eng.sun.com Message-ID: Date: Thu, 27 Aug 1998 09:03:34 +0300 Subject: (IPng 6354) the draft : draft-ietf-ipngwg-bsd-api-new-02.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Can any one tell me how to get the draft draft-ietf-ipngwg-bsd-api-new-02.txt through mail ??? 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 Aug 27 08:22:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA27239 for ipng-dist; Thu, 27 Aug 1998 08:19:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA27232 for ; Thu, 27 Aug 1998 08:18:44 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA28076; Thu, 27 Aug 1998 08:18:43 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA02558; Thu, 27 Aug 1998 08:18:42 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id LAA22850; Thu, 27 Aug 1998 11:18:37 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA26438; Thu, 27 Aug 1998 11:18:36 -0400 Message-Id: <199808271518.AA26438@wasted.zk3.dec.com> To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6355) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Wed, 26 Aug 1998 18:27:50 PDT." Date: Thu, 27 Aug 1998 11:18:36 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, It is underspecified as is the whole topic. It is there now as a placeholder. I would suggest we add how this will be used in the advanced api down the road. Initial implementations will not use this except for link-local. In that case the index can be used we now have. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 27 10:20:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA27372 for ipng-dist; Thu, 27 Aug 1998 10:15:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA27365 for ; Thu, 27 Aug 1998 10:15:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA29093 for ; Thu, 27 Aug 1998 10:15:00 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.9.1/8.9.1) with SMTP id KAA16681 for ; Thu, 27 Aug 1998 10:15:01 -0700 (PDT) Received: from orna.mentat.com (mbone.mentat.com) by mentat.com (4.1/SMI-4.1) id AA04170; Thu, 27 Aug 98 10:13:38 PDT Received: by orna.mentat.com (SMI-8.6/SMI-SVR4) id KAA11359; Thu, 27 Aug 1998 10:15:37 -0700 Date: Thu, 27 Aug 1998 10:15:37 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199808271715.KAA11359@orna.mentat.com> To: bound@zk3.dec.com, Erik.Nordmark@Eng Subject: (IPng 6356) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > If we don't want to do this now I think the draft should point out > that getaddrinfo() and recvfrom/recvmsg will set the sin6_scope_id. > > Right now the draft seems underspecified since it doesn't state any method > whereby sin6_scope_id can be set (short of if_nametoindex for link-locals). > I guess I had assumed that it was implicit that recvfrom, recvmsg and accept would set the scope id appropriately based on the the contents of the sin6_addr and the configuration of the machine. If some folks think that it needs to be more explicit then I don't have a problem with that. Noting that getaddrinfo may also initialize the scope id based on system configuration is also fine by me. Specifying anything else about how to handle multi-sited nodes is going to drag us into address string representation discussions, DNS discussions and a whole lot of other areas that are really academic at this point. When I first proposed this change what seems like a decade ago now, I was hoping to make the absolute minimum change that was required in order to make multi-sited nodes feasible and help make multi-homed nodes easier. I really hoped not to get sucked into a nasty drawn out discussion about a bunch of relatively academic points. That hope was dashed within seconds. I think we have something specified now that will deal with the original issue and leaves us the ability to come back and solve the other problems in the future. Hopefully we can get this document cooked and move on. My $.02. 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 Aug 27 10:41:29 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA27426 for ipng-dist; Thu, 27 Aug 1998 10:33:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA27419 for ; Thu, 27 Aug 1998 10:33:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA05983 for ; Thu, 27 Aug 1998 10:33:33 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA29734 for ; Thu, 27 Aug 1998 10:33:30 -0700 (PDT) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 27 Aug 1998 10:33:28 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81192@RED-MSG-50> From: Richard Draves To: "'Jun-ichiro itojun Itoh'" , ipng@sunroof.eng.sun.com Cc: itojun@itojun.org Subject: (IPng 6357) RE: error to TCP6 toward anycast address? Date: Thu, 27 Aug 1998 10:33:27 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If the following situation happen, how router B should > send an error > notification to host A? > > - host A has a global address, 3ffe:0501::A. > - router B has global addresses 3ffe:0501::B and 3ffe:0502::B', > and anycast address 3ffe:0501::1. > - host A (mistakingly) performed telnet toward > 3ffe:0501::1, which > is an anycast address. > NOTE: this is because host A has no way to > check if he is > connecting to anycast address, or non-anycast address. This is rather similar to the case of an SYN packet which is sent to a multicast address. In that case the receiving TCP is required to silently ignore the SYN. So I think that should be the answer in this case as well. I agree this is not friendly for the sender. A sender can know that it shouldn't send a SYN to a multicast address, but it can't know that it's trying to use an anycast address. An alternative would be to invent a new ICMP error (or reuse an existing error code, although I agree they don't seem quite appropriate), and then use this new ICMP error when the destination address in the SYN is inappropriate (multicast or anycast). But this would be change from v4 practice. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 27 12:41:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA27628 for ipng-dist; Thu, 27 Aug 1998 12:31:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA27621 for ; Thu, 27 Aug 1998 12:31:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA13505 for ; Thu, 27 Aug 1998 12:31:21 -0700 Received: from send1e.yahoomail.com (send1e.yahoomail.com [205.180.60.64]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA15495 for ; Thu, 27 Aug 1998 12:31:03 -0700 (PDT) Message-ID: <19980827192904.29864.rocketmail@send1e.yahoomail.com> Received: from [138.111.39.131] by send1e; Thu, 27 Aug 1998 12:29:04 PDT Date: Thu, 27 Aug 1998 12:29:04 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6358) Reg: ADDRESS. To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All... I have one basic question. Hope it is not silly..:):):):) with IPv4, I just need to remember a 32 bit address for all the applications (telnet,ftp...) Do you expect me to remember a 128 bit IP address with IPv6. Are there any shortcuts ?. Thanks in advance -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 27 12:59:47 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA27671 for ipng-dist; Thu, 27 Aug 1998 12:50:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA27661 for ; Thu, 27 Aug 1998 12:49:50 -0700 (PDT) From: bmanning@ISI.EDU Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA18652 for ; Thu, 27 Aug 1998 12:49:47 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA26309 for ; Thu, 27 Aug 1998 12:49:44 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id MAA10467; Thu, 27 Aug 1998 12:49:43 -0700 (PDT) Posted-Date: Thu, 27 Aug 1998 12:45:05 -0700 (PDT) Message-Id: <199808271945.AA10193@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Thu, 27 Aug 1998 12:45:05 -0700 Subject: (IPng 6359) Re: Reg: ADDRESS. To: iprsvp@yahoo.com (Raghu V.V.J Vadapalli) Date: Thu, 27 Aug 1998 12:45:05 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <19980827192904.29864.rocketmail@send1e.yahoomail.com> from "Raghu V.V.J Vadapalli" at Aug 27, 98 12:29:04 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some claim that even in todays Internet, the most persistent identifier of a node is its DNS label. > > Dear All... > I have one basic question. Hope it is not silly..:):):):) > > with IPv4, I just need to remember a 32 bit address for > all the applications (telnet,ftp...) > Do you expect me to remember a 128 bit IP address with IPv6. > Are there any shortcuts ?. > > Thanks in advance > -Raghu. > > > > > == > ------------------------------------------------------------ > > > > > > > _________________________________________________________ > DO YOU YAHOO!? > Get your free @yahoo.com address at http://mail.yahoo.com > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- --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 Aug 27 13:37:52 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id NAA27774 for ipng-dist; Thu, 27 Aug 1998 13:28:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id NAA27767 for ; Thu, 27 Aug 1998 13:28:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA29195 for ; Thu, 27 Aug 1998 13:28:06 -0700 Received: from send1b.yahoomail.com (send1b.yahoomail.com [205.180.60.23]) by earth.sun.com (8.9.1/8.9.1) with SMTP id NAA17584 for ; Thu, 27 Aug 1998 13:28:06 -0700 (PDT) Message-ID: <19980827202736.10677.rocketmail@send1b.yahoomail.com> Received: from [138.111.39.131] by send1b; Thu, 27 Aug 1998 13:27:36 PDT Date: Thu, 27 Aug 1998 13:27:36 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6360) Re: Reg: ADDRESS. To: bmanning@ISI.EDU Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi!!! Can I do this? If possible.. I want to avoid typeing the prefixes at least for link local and site local addresses. Can I . I agree that I can use DNS services. Just I want to explore this possibility. Thanks -Raghu. ---bmanning@ISI.EDU wrote: > > > Some claim that even in todays Internet, the most persistent > identifier of a node is its DNS label. > > > > > > Dear All... > > I have one basic question. Hope it is not silly..:):):):) > > > > with IPv4, I just need to remember a 32 bit address for > > all the applications (telnet,ftp...) > > Do you expect me to remember a 128 bit IP address with IPv6. > > Are there any shortcuts ?. > > > > Thanks in advance > > -Raghu. > > > > > > > > > > == > > ------------------------------------------------------------ > > > > > > > > > > > > > > _________________________________________________________ > > DO YOU YAHOO!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > -- > --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 > -------------------------------------------------------------------- > == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 27 14:39:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id OAA27848 for ipng-dist; Thu, 27 Aug 1998 14:33:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id OAA27841 for ; Thu, 27 Aug 1998 14:33:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA20105 for ; Thu, 27 Aug 1998 14:33:48 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA28138 for ; Thu, 27 Aug 1998 14:33:47 -0700 (PDT) Received: from nestvx.kar.dec.com (nestvx.kar.dec.com [16.185.112.1]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id RAA02618; Thu, 27 Aug 1998 17:32:48 -0400 (EDT) Received: from whopper.kar.dec.com by nestvx.kar.dec.com; (5.65/1.1.8.2/10Jul96-9.1MPM) id AA14856; Thu, 27 Aug 1998 23:32:39 +0200 Received: from localhost by whopper.kar.dec.com (5.65v3.2/1.1.10.5/21Apr97-0951PM) id AA31627; Thu, 27 Aug 1998 23:32:36 +0200 Message-Id: <9808272132.AA31627@whopper.kar.dec.com> To: ipng@sunroof.eng.sun.com Cc: jork@kar.dec.com, kuznet@ms2.inr.ac.ru Subject: (IPng 6361) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-Reply-To: Your message of "Wed, 26 Aug 98 19:46:39 +0400." <199808261546.TAA05214@ms2.inr.ac.ru> Date: Thu, 27 Aug 98 23:32:36 +0200 From: "Markus Jork" X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexey, > > We are using the sin6flow is as by rsvp for ipv6 and by RAPI. > > It is also being used by several Voice over IP vendors. > > It is very interesting. I know only one rsvp implementation > supporting flow labels and it is mine one 8) > Actually, I never saw (only heard) about another rsvp impls. > working with IPv6 properly 8) > > Could you give me pointers? Compaq's DIGITAL UNIX IPv6 Early Adopters Kit includes a RSVP implementation with flowlabel support. See http://www.digital.com/ipv6/host-implementation.html for how to obtain the IPv6 kit. This is a binary kit running on Alphas with DIGTIAL UNIX 4.0d. The flowlabel is supported in RAPI, the RSVP daemon and also in the kernel for IPv6 packet classification (there is a packet scheduler providing Controlled Load service on LAN interfaces). Markus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 27 18:27:00 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id SAA28168 for ipng-dist; Thu, 27 Aug 1998 18:23:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id SAA28161 for ; Thu, 27 Aug 1998 18:23:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA14739 for ; Thu, 27 Aug 1998 18:23:14 -0700 Received: from turmeric.itojun.org (mach74.xnet.com [207.227.19.74]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA23045 for ; Thu, 27 Aug 1998 18:23:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turmeric.itojun.org (8.8.5/3.3W3) with ESMTP id KAA00511 for ; Fri, 28 Aug 1998 10:22:42 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 6362) detecting IPv6 stack type 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 X-Mailer: comp (MHng project) version 1998/02/23 14:27:23, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 28 Aug 1998 10:22:42 +0900 Message-ID: <508.904267362@turmeric.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To implement IPv6 application, we sometime need to check: - what kind of IPv6 stack is it - what is an optional compiler option (-L, -I, -l) The following is a configure.in fragment for GNU autoconf for that. If you have any input (for other stacks, maybe) please let me know. I'll try to maintain updated version somewhere on the web (maybe somewhere in http://www.kame.net) itojun@kame.net jun-ichiro itojun itoh --- AC_MSG_CHECKING([whether to enable ipv6]) AC_ARG_ENABLE(ipv6, [ --enable-ipv6 Enable ipv6 (with ipv4) support --disable-ipv6 Disable ipv6 support], [ case "$enableval" in no) AC_MSG_RESULT(no) ipv6=no ;; *) AC_MSG_RESULT(yes) AC_DEFINE(ENABLE_IPV6) ipv6=yes ;; esac ], AC_TRY_RUN([ /* AF_INET6 avalable check */ #include #include main() { exit(0); if (socket(AF_INET6, SOCK_STREAM, 0) < 0) exit(1); else exit(0); } ], AC_MSG_RESULT(yes) AC_DEFINE(ENABLE_IPV6) ipv6=yes, AC_MSG_RESULT(no) ipv6=no, AC_MSG_RESULT(no) ipv6=no )) ipv6type=unknown ipv6lib=none if test "$ipv6" = "yes"; then AC_MSG_CHECKING([ipv6 stack type]) dnl linux is checked later, as it does not have #define for IPv6 for i in inria kame toshiba v6d zeta linux; do case $i in inria) dnl http://www.kame.net/ AC_EGREP_CPP(yes, [dnl #include #ifdef IPV6_INRIA_VERSION yes #endif], [ipv6type=$i; CFLAGS="-DINET6 $CFLAGS"]) ;; kame) dnl http://www.kame.net/ AC_EGREP_CPP(yes, [dnl #include #ifdef __KAME__ yes #endif], [ipv6type=$i; ipv6lib=inet6; ipv6libdir=/usr/local/v6/lib; CFLAGS="-DINET6 $CFLAGS"]) ;; linux) dnl http://www.v6.linux.or.jp/ if test -d /usr/inet6; then ipv6type=$i ipv6lib=inet6 ipv6libdir=/usr/inet6/lib CFLAGS="-DINET6 -I/usr/inet6/include $CFLAGS" fi ;; toshiba) AC_EGREP_CPP(yes, [dnl #include #ifdef _TOSHIBA_INET6 yes #endif], [ipv6type=$i; ipv6lib=inet6; ipv6libdir=/usr/local/v6/lib; CFLAGS="-DINET6 $CFLAGS"]) ;; v6d) AC_EGREP_CPP(yes, [dnl #include #ifdef __V6D__ yes #endif], [ipv6type=$i; ipv6lib=v6; ipv6libdir=/usr/local/v6/lib; CFLAGS="-I/usr/local/v6/include $CFLAGS"]) ;; zeta) AC_EGREP_CPP(yes, [dnl #include #ifdef _ZETA_MINAMI_INET6 yes #endif], [ipv6type=$i; ipv6lib=inet6; ipv6libdir=/usr/local/v6/lib; CFLAGS="-DINET6 $CFLAGS"]) ;; esac if test "$ipv6type" != "unknown"; then break fi done AC_MSG_RESULT($ipv6type) fi if test "$ipv6" = "yes" -a "$ipv6lib" != "none"; then if test -d $ipv6libdir -a -f $ipv6libdir/lib$ipv6lib.a; then LIBS="-L$ipv6libdir -l$ipv6lib $LIBS" else echo 'Fatal: no $ipv6lib library found. cannot continue.' echo "You need to fetch lib$ipv6lib.a from appropriate" echo 'ipv6 kit and compile beforehand.' exit 1 fi fi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 27 21:22:35 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA28301 for ipng-dist; Thu, 27 Aug 1998 21:17:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA28294 for ; Thu, 27 Aug 1998 21:17:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA05640 for ; Thu, 27 Aug 1998 21:17:46 -0700 Received: from turmeric.itojun.org (mach190.xnet.com [207.227.19.190]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA24626 for ; Thu, 27 Aug 1998 21:17:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turmeric.itojun.org (8.8.5/3.3W3) with ESMTP id NAA01740 for ; Fri, 28 Aug 1998 13:17:16 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 6363) ietf terminal room: unknown HBH option code? 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 X-Mailer: comp (MHng project) version 1998/02/23 14:27:23, by Jun-ichiro Itoh MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-ID: Date: Fri, 28 Aug 1998 13:17:16 +0900 Message-ID: <1737.904277836@turmeric.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In IETF terminal room, we see a non-popular HBH code from fe80::208:c7ff:fe1a:39a9. I would like to know what the code is, and whose implementation is it... Thanks, 0xc7 means: xxx00111 7 ?? (undefined) xx0xxxxx non-mutable 11xxxxxx discard and send ICMP error if the code is unknown http://www.isi.edu/in-notes/iana/assignments/ipv6-parameters has no definition for code 7. itojun@kame.net jun-ichiro itojun itoh --- 13:03:15.388831 fe80::208:c7ff:fe1a:39a9 > ff02::1:ff1a:39a9: HBH (type 199: len=2) icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff1a:39a9 (len 32) 6000 0000 0020 0001 fe80 0000 0000 0000 0208 c7ff fe1a 39a9 ff02 0000 0000 0000 0000 0001 ff1a 39a9 3a00 c702 0000 0100 ~~ 8300 0cd0 0000 0000 ff02 0000 0000 0000 0000 0001 ff1a 39a9 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 28 02:31:49 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id CAA28443 for ipng-dist; Fri, 28 Aug 1998 02:27:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id CAA28436 for ; Fri, 28 Aug 1998 02:27:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA03054 for ; Fri, 28 Aug 1998 02:27:36 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id CAA27261 for ; Fri, 28 Aug 1998 02:27:31 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id NAA00641; Fri, 28 Aug 1998 13:26:34 +0400 Message-Id: <199808280926.NAA00641@ms2.inr.ac.ru> Subject: (IPng 6364) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: jork@kar.dec.com (Markus Jork) Date: Fri, 28 Aug 1998 13:26:34 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com, jork@kar.dec.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <9808272132.AA31627@whopper.kar.dec.com> from "Markus Jork" at Aug 27, 98 11:32:36 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > Compaq's DIGITAL UNIX IPv6 Early Adopters Kit includes a RSVP Thank you! Do you know, is it possible to open direct tunnel to some node running this to test for interoperability? Certainly, it does not make much of sense, but it would allow to test at least for protocol compatibility. It is pretty boring to talk only to one kind of neighbours, all of them have identical bugs in any case 8)8) Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 28 06:29:12 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA28622 for ipng-dist; Fri, 28 Aug 1998 06:19:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA28615 for ; Fri, 28 Aug 1998 06:19:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA20879 for ; Fri, 28 Aug 1998 06:19:34 -0700 Received: from send1c.yahoomail.com (send1c.yahoomail.com [205.180.60.38]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA04697 for ; Fri, 28 Aug 1998 06:19:36 -0700 (PDT) Message-ID: <19980828132211.27769.rocketmail@send1c.yahoomail.com> Received: from [138.111.39.131] by send1c; Fri, 28 Aug 1998 06:22:11 PDT Date: Fri, 28 Aug 1998 06:22:11 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6365) Reg: Flow Label To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi!!! Are there any internet drafts or RFCs related to "use flow label for Qos routing". Thanks in advance -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 28 08:56:45 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA28814 for ipng-dist; Fri, 28 Aug 1998 08:50:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA28787 for ; Fri, 28 Aug 1998 08:50:01 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26891 for ; Fri, 28 Aug 1998 08:49:58 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA24323 for ; Fri, 28 Aug 1998 08:49:57 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA07158; Fri, 28 Aug 1998 17:49:55 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id RAA22809; Fri, 28 Aug 1998 17:49:55 +0200 (MET DST) Message-Id: <199808281549.RAA22809@givry.inria.fr> From: Francis Dupont To: Jun-ichiro itojun Itoh cc: ipng@sunroof.eng.sun.com Subject: (IPng 6368) Re: detecting IPv6 stack type In-reply-to: Your message of Fri, 28 Aug 1998 10:22:42 +0900. <508.904267362@turmeric.itojun.org> Date: Fri, 28 Aug 1998 17:49:54 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: - what kind of IPv6 stack is it => for my implementation you can use IPV6_INRIA_VERSION. For instance Jean-Luc Richier's IPv6 support in the lsof tool uses it for conditional compilation... Francis.Dupont@inria.fr PS: the IPV6_INRIA_VERSION macro is defined at the beginning of /usr/include/netinet/in.h and its value is the date of last heavy (ie likely incompatible somewhere) change. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 28 09:47:50 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA28960 for ipng-dist; Fri, 28 Aug 1998 09:37:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA28953 for ; Fri, 28 Aug 1998 09:37:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA09921 for ; Fri, 28 Aug 1998 09:37:46 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA25366 for ; Fri, 28 Aug 1998 09:37:47 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id ; Fri, 28 Aug 1998 09:37:46 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF8119B@RED-MSG-50> From: Richard Draves To: "'Jun-ichiro itojun Itoh'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 6369) RE: ietf terminal room: unknown HBH option code? Date: Fri, 28 Aug 1998 09:37:37 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Our MSR IPv6 1.1 release uses 0xc7 as the code for the Router Alert hop-by-hop option in MLD packets. I don't know why we used that particular value, but we had to make up something because (as far as I know) there is no official value for the Router Alert option. What value are other implementations using for this option? Rich > -----Original Message----- > From: Jun-ichiro itojun Itoh [mailto:itojun@itojun.org] > Sent: Thursday, August 27, 1998 9:17 PM > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6363) ietf terminal room: unknown HBH option code? > > > In IETF terminal room, we see a non-popular HBH code from > fe80::208:c7ff:fe1a:39a9. I would like to know what > the code is, > and whose implementation is it... Thanks, > > 0xc7 means: > xxx00111 7 ?? (undefined) > xx0xxxxx non-mutable > 11xxxxxx discard and send ICMP error if the code > is unknown > http://www.isi.edu/in-notes/iana/assignments/ipv6-parameters has no definition for code 7. itojun@kame.net jun-ichiro itojun itoh --- 13:03:15.388831 fe80::208:c7ff:fe1a:39a9 > ff02::1:ff1a:39a9: HBH (type 199: len=2) icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff1a:39a9 (len 32) 6000 0000 0020 0001 fe80 0000 0000 0000 0208 c7ff fe1a 39a9 ff02 0000 0000 0000 0000 0001 ff1a 39a9 3a00 c702 0000 0100 ~~ 8300 0cd0 0000 0000 ff02 0000 0000 0000 0000 0001 ff1a 39a9 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 28 09:53:31 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA28981 for ipng-dist; Fri, 28 Aug 1998 09:48:05 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA28968 for ; Fri, 28 Aug 1998 09:47:55 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA13103 for ; Fri, 28 Aug 1998 09:47:54 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA11737 for ipng@sunroof.eng.sun.com; Fri, 28 Aug 1998 09:46:47 -0700 (PDT) Received: from sunmail1.Sun.COM (sunmail1.Corp.Sun.COM [129.145.1.2]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA28740 for ; Fri, 28 Aug 1998 08:06:06 -0700 (PDT) Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id IAA21397; Fri, 28 Aug 1998 08:06:04 -0700 Received: from unknown (hobo206 [129.146.31.206]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id IAA01650; Fri, 28 Aug 1998 08:06:02 -0700 (PDT) Date: Thu, 27 Aug 1998 21:43:27 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6370) Security hole in 6over4 To: brian@hursley.ibm.com Cc: cmj@3com.com, ipng@sunroof.Sun.COM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just realized this problem. ND uses the hoplimit=255 trick to ensure that only nodes on the link can lauch ND related attacks (such as advertising bogus routers or bogus prefixes etc). This provides similar robustness as ARP since ARP packets are not forwarded by routers. However, with 6over4 you only restrict the multicast packets (using the admin scope boundary). While 6over4 unicast packets will not leave the 6over4 link there is nothing to prevent somebody from injecting such packets. (This is a variant of the theme "Dangerous to depcasulate packets from unkown sources".) Thus any node on the v4 internet can create a packet with: IPv4 source: real or bogus source address of sender IPv4 destination: my IPv6 node's IPv4 address Protocol 41 IPv6 source: Some random link-local address IPv6 destination: my IPv6 node's IPv6 address hoplimit 255 nexthdr ICMPv6 containing e.g. a bogus router advertisement and/or bogus prefixes. The 6over4 code will, as specified, blindly decapsulate this. The ND code will check the hoplimit and conclude that this packet must have been sent by a neighbor on the (6over4) link, which is incorrect since the decapsulation didn't enforce the boundary of the 6over4 link! Thus when running 6over4 the node is subject to ND/addrconf attacks from anywhere in the Internet. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 28 10:25:30 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id KAA29113 for ipng-dist; Fri, 28 Aug 1998 10:13:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id KAA29105 for ; Fri, 28 Aug 1998 10:13:05 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA20803 for ; Fri, 28 Aug 1998 10:12:46 -0700 Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA18708 for ; Fri, 28 Aug 1998 10:12:41 -0700 (PDT) Received: from classic (mach147.xnet.com [207.227.19.147]) by jazz.viagenie.qc.ca (Viagenie/8.8.8) with SMTP id NAA15526; Fri, 28 Aug 1998 13:06:08 -0400 (EDT) Message-Id: <3.0.5.32.19980828131104.030716f0@mail.viagenie.qc.ca> Prefer-Language: fr, en X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 28 Aug 1998 13:11:04 -0400 To: Jun-ichiro itojun Itoh , ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: (IPng 6371) Re: ietf terminal room: unknown HBH option code? Cc: bzill@microsoft.com In-Reply-To: <1737.904277836@turmeric.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id KAA29106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ok, we found it. I installed the msr ipv6 stack on one of the desktop pcs in the term room. I just verified the mac address and it was it. So, you should exchange with Brian Zill@msr, since it seems to be related to the msr-nt stack. Hope this helps. your ietf-ipv6-support-team ;-))), Marc (and Florent). At 13:17 98-08-28 +0900, Jun-ichiro itojun Itoh wrote: > In IETF terminal room, we see a non-popular HBH code from > fe80::208:c7ff:fe1a:39a9. I would like to know what the code is, > and whose implementation is it... Thanks, > > 0xc7 means: > xxx00111 7 ?? (undefined) > xx0xxxxx non-mutable > 11xxxxxx discard and send ICMP error if the code is unknown > > http://www.isi.edu/in-notes/iana/assignments/ipv6-parameters > has no definition for code 7. > >itojun@kame.net >jun-ichiro itojun itoh > > >--- >13:03:15.388831 fe80::208:c7ff:fe1a:39a9 > ff02::1:ff1a:39a9: HBH (type 199: len=2) icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff1a:39a9 (len 32) > 6000 0000 0020 0001 fe80 0000 0000 0000 > 0208 c7ff fe1a 39a9 ff02 0000 0000 0000 > 0000 0001 ff1a 39a9 3a00 c702 0000 0100 > ~~ > 8300 0cd0 0000 0000 ff02 0000 0000 0000 > 0000 0001 ff1a 39a9 >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp :57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifié, Éditions Logiques, 1997 ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 28 19:25:27 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA29754 for ipng-dist; Fri, 28 Aug 1998 19:16:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA29747 for ; Fri, 28 Aug 1998 19:15:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA04435 for ; Fri, 28 Aug 1998 19:15:49 -0700 Received: from turmeric.itojun.org (pm3-42.ppp.wenet.net [206.15.85.42]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA13179 for ; Fri, 28 Aug 1998 19:15:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turmeric.itojun.org (8.8.5/3.3W3) with ESMTP id LAA27545; Sat, 29 Aug 1998 11:15:08 +0900 (JST) To: Richard Draves cc: ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Fri, 28 Aug 98 09:37:37 MST. <4D0A23B3F74DD111ACCD00805F31D8100AF8119B@RED-MSG-50> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 6373) Re: ietf terminal room: unknown HBH option code? cc: itojun@itojun.org From: Jun-ichiro itojun Itoh Date: Sat, 29 Aug 1998 11:15:08 +0900 Message-ID: <27542.904356908@turmeric.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Our MSR IPv6 1.1 release uses 0xc7 as the code for the Router Alert >hop-by-hop option in MLD packets. I don't know why we used that particular >value, but we had to make up something because (as far as I know) there is >no official value for the Router Alert option. What value are other >implementations using for this option? Thanks for letting me know, KAME uses 0x14 (= 20 in decimal) based on the following comment in draft-ietf-ipngwg-ipv6router-alert-04.txt at this moment. I checked further and it does NOT appear in http://www.isi.edu/in-notes/iana/assignments/ipv6-parameters. So 0x14 is not an official value anyway. 0xc7 looks some strange because it suggests intermediate router to drop the packet and send ICMP6, if the router does not recognize it. itojun@kame.net jun-ichiro itojun itoh --- excerpt from draft-ietf-ipngwg-ipv6router-alert-04.txt 2.1 Syntax The router alert option has the following format: +--------+--------+--------+--------+ |00| TBD |00000010| Value (2 octets)| +--------+--------+--------+--------+ len= 2 "TBD" is the Hop-by-Hop Option Type number (To be allocated by the IANA). [DO WE NEED A NUMBER FROM IANA BEFORE WE CAN SUBMIT THIS? IF SO, I SUGGEST 20.] Nodes not recognizing this option type MUST skip over this option [Page 2] Internet Draft IPv6 Router Alert 13 February 1998 and continue processing the header. This option MUST NOT change en route. There MUST only be one option of this type, regardless of value, per Hop-by-Hop header. Value: A 2 octet code in network byte order with the following values: 0 Datagram contains ICMPv6 Group Membership message. 1 Datagram contains RSVP message. 2 Datagram contains an Active Networks message. 3-65535 Reserved. New value codes must be registered with the IANA. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 28 20:04:57 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id TAA29805 for ipng-dist; Fri, 28 Aug 1998 19:58:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id TAA29798 for ; Fri, 28 Aug 1998 19:58:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA07909 for ; Fri, 28 Aug 1998 19:58:07 -0700 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA23902 for ; Fri, 28 Aug 1998 19:58:07 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.0/8.8.5) with ESMTP id CAA07330; Sat, 29 Aug 1998 02:57:51 GMT Message-Id: <199808290257.CAA07330@inner.net> To: thartric@mentat.com (Tim Hartrick) cc: ipng@sunroof.eng.sun.com Subject: (IPng 6374) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt In-reply-to: Your message of "Mon, 24 Aug 1998 20:13:33 PDT." <199808250313.UAA01250@orna.mentat.com> X-Copyright: Copyright 1998, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 28 Aug 1998 22:56:48 -0300 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199808250313.UAA01250@orna.mentat.com>, you write: >Hmm... I don't really see why the API should even return flow label >information in the sockaddr_in6's returned from recvfrom, recvmsg and >accept. Is there any utility in an application knowing these values? I tend to agree with Tim here. We're building our system to have QoS such that the application requests the QoS properties it wants and the system gives that to the app or returns an error. This may include setup/teardown of flows through the network, which is handled transparently to the application in order to reduce the pain level for application programmers (this is similar to how we handle security associations for IPsec). The application should never play with flow labels because the app has no way of knowing when flows get changed out from under it (much like SPIs with IPsec, which change as SAs expire and get renegotiated). -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 29 06:11:11 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA29980 for ipng-dist; Sat, 29 Aug 1998 06:06:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA29973 for ; Sat, 29 Aug 1998 06:06:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA10812 for ; Sat, 29 Aug 1998 06:06:28 -0700 Received: from dee.inr.ac.ru (dee.inr.ac.ru [193.233.7.82]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA13001 for ; Sat, 29 Aug 1998 06:06:28 -0700 (PDT) Received: (from root@localhost) by dee.inr.ac.ru (8.6.13/ANK+IPv6) id RAA06158; Sat, 29 Aug 1998 17:05:52 +0400 Message-Id: <199808291305.RAA06158@dee.inr.ac.ru> Subject: (IPng 6375) Re: ietf terminal room: unknown HBH option code? To: itojun@iijlab.net (Jun-ichiro itojun Itoh) Date: Sat, 29 Aug 1998 17:05:52 +0400 (MSK DST) Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com, itojun@itojun.org Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <27542.904356908@turmeric.itojun.org> from "Jun-ichiro itojun Itoh" at Aug 29, 98 11:15:08 am From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > KAME uses 0x14 (= 20 in decimal) based on the following comment BTW Linux also uses 20 based on the same comment. Seems, it is inherited from ipv4 router alert (minus copy bit). Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 29 06:16:37 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id GAA29998 for ipng-dist; Sat, 29 Aug 1998 06:14:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id GAA29991 for ; Sat, 29 Aug 1998 06:14:00 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA11250 for ; Sat, 29 Aug 1998 06:13:58 -0700 Received: from dee.inr.ac.ru (dee.inr.ac.ru [193.233.7.82]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA14222 for ; Sat, 29 Aug 1998 06:13:47 -0700 (PDT) Received: (from root@localhost) by dee.inr.ac.ru (8.6.13/ANK+IPv6) id RAA06193; Sat, 29 Aug 1998 17:12:31 +0400 Message-Id: <199808291312.RAA06193@dee.inr.ac.ru> Subject: (IPng 6376) Re: NEW DRAFT: draft-ietf-ipngwg-bsd-api-new-02.txt To: cmetz@inner.net (Craig Metz) Date: Sat, 29 Aug 1998 17:12:31 +0400 (MSK DST) Cc: thartric@mentat.com, ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <199808290257.CAA07330@inner.net> from "Craig Metz" at Aug 28, 98 10:56:48 pm From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > I tend to agree with Tim here. > > We're building our system to have QoS such that the application requests the > QoS properties it wants and the system gives that to the app or returns an > error. "The WG wants this done in the socket address." /jim :-) :-) Alexey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 30 03:59:55 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id DAA00393 for ipng-dist; Sun, 30 Aug 1998 03:39:29 -0700 (PDT) Received: from sunmail1.Sun.COM (sunmail1.Corp.Sun.COM [129.145.1.2]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id DAA00386 for ; Sun, 30 Aug 1998 03:38:51 -0700 (PDT) Received: from earth.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id DAA14938 for ; Sun, 30 Aug 1998 03:38:49 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by earth.sun.com (8.9.1/8.9.1) with SMTP id DAA08127 for ; Sun, 30 Aug 1998 03:38:49 -0700 (PDT) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18132; Sun, 30 Aug 1998 11:38:47 +0100 Received: from hursley.ibm.com (brianh.hursley.ibm.com [9.20.43.84]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA58666; Sun, 30 Aug 1998 11:38:44 +0100 (BST) Message-Id: <35E92A50.5E66556B@hursley.ibm.com> Date: Sun, 30 Aug 1998 11:32:48 +0100 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: Erik Nordmark Cc: cmj@3com.com, ipng@sunroof.Sun.COM Subject: (IPng 6377) Re: Security hole in 6over4 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks. Is there any reason we can't fix this by specifying that a 6over4 router must only decapsulate packets arriving on the interface(s) configured for 6over4? Brian Erik Nordmark wrote: > > I just realized this problem. > > ND uses the hoplimit=255 trick to ensure that only nodes on the link > can lauch ND related attacks (such as advertising bogus routers or > bogus prefixes etc). This provides similar robustness as ARP since > ARP packets are not forwarded by routers. > > However, with 6over4 you only restrict the multicast packets (using > the admin scope boundary). While 6over4 unicast packets will not > leave the 6over4 link there is nothing to prevent somebody from > injecting such packets. (This is a variant of the theme "Dangerous > to depcasulate packets from unkown sources".) > > Thus any node on the v4 internet can create a packet with: > IPv4 source: real or bogus source address of sender > IPv4 destination: my IPv6 node's IPv4 address > Protocol 41 > IPv6 source: Some random link-local address > IPv6 destination: my IPv6 node's IPv6 address > hoplimit 255 > nexthdr ICMPv6 > containing e.g. a bogus router advertisement and/or bogus prefixes. > The 6over4 code will, as specified, blindly decapsulate this. > The ND code will check the hoplimit and conclude that this > packet must have been sent by a neighbor on the (6over4) link, > which is incorrect since the decapsulation didn't enforce the boundary > of the 6over4 link! > > Thus when running 6over4 the node is subject to ND/addrconf attacks from > anywhere in the Internet. > > 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 Sun Aug 30 07:32:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA00529 for ipng-dist; Sun, 30 Aug 1998 07:29:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA00522 for ; Sun, 30 Aug 1998 07:29:43 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA23716; Sun, 30 Aug 1998 07:29:41 -0700 Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA07916; Sun, 30 Aug 1998 07:29:41 -0700 (PDT) Received: from haskin (haskin.ne.mediaone.net [24.128.143.57]) by chmls05.mediaone.net (8.8.7/8.8.7) with SMTP id KAA08948; Sun, 30 Aug 1998 10:29:34 -0400 (EDT) Message-Id: <199808301429.KAA08948@chmls05.mediaone.net> X-Sender: dhaskin@192.168.1.252 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 30 Aug 1998 10:30:20 -0400 To: Brian E Carpenter , Erik Nordmark From: Dimitry Haskin Subject: (IPng 6378) Re: Security hole in 6over4 Cc: ipng@sunroof.eng.sun.com In-Reply-To: <35E92A50.5E66556B@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:32 AM 8/30/98 +0100, Brian E Carpenter wrote: >Thanks. Is there any reason we can't fix this by specifying that >a 6over4 router must only decapsulate packets arriving on the >interface(s) configured for 6over4? > > Brian > A minimally intelligent intruder can easily forge packets such that they would arrive on a 6over4 interface. All is needed to use v4 address of a legitimate router as the source address in the v4 header. IPsec to the rescue.. ;) Dimitry >Erik Nordmark wrote: >> >> I just realized this problem. >> >> ND uses the hoplimit=255 trick to ensure that only nodes on the link >> can lauch ND related attacks (such as advertising bogus routers or >> bogus prefixes etc). This provides similar robustness as ARP since >> ARP packets are not forwarded by routers. >> >> However, with 6over4 you only restrict the multicast packets (using >> the admin scope boundary). While 6over4 unicast packets will not >> leave the 6over4 link there is nothing to prevent somebody from >> injecting such packets. (This is a variant of the theme "Dangerous >> to depcasulate packets from unkown sources".) >> >> Thus any node on the v4 internet can create a packet with: >> IPv4 source: real or bogus source address of sender >> IPv4 destination: my IPv6 node's IPv4 address >> Protocol 41 >> IPv6 source: Some random link-local address >> IPv6 destination: my IPv6 node's IPv6 address >> hoplimit 255 >> nexthdr ICMPv6 >> containing e.g. a bogus router advertisement and/or bogus prefixes. >> The 6over4 code will, as specified, blindly decapsulate this. >> The ND code will check the hoplimit and conclude that this >> packet must have been sent by a neighbor on the (6over4) link, >> which is incorrect since the decapsulation didn't enforce the boundary >> of the 6over4 link! >> >> Thus when running 6over4 the node is subject to ND/addrconf attacks from >> anywhere in the Internet. >> >> 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 Sun Aug 30 07:37:46 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id HAA00546 for ipng-dist; Sun, 30 Aug 1998 07:35:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id HAA00539 for ; Sun, 30 Aug 1998 07:35:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA23980 for ; Sun, 30 Aug 1998 07:35:49 -0700 Received: from send101.yahoomail.com (send101.yahoomail.com [205.180.60.87]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA08777 for ; Sun, 30 Aug 1998 07:35:49 -0700 (PDT) Message-ID: <19980830143458.3303.rocketmail@send101.yahoomail.com> Received: from [209.94.102.26] by send101.yahoomail.com; Sun, 30 Aug 1998 07:34:58 PDT Date: Sun, 30 Aug 1998 07:34:58 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6379) Reg: Raw Sockets To: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi!! Are the raw sockets are supported by all the systems. If so why don't we use the NEXT HEADER field for identifying the RSVP messages rather than using IPv6 route alert option. Thanks -Raghu. == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 30 08:30:24 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id IAA00597 for ipng-dist; Sun, 30 Aug 1998 08:21:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id IAA00590 for ; Sun, 30 Aug 1998 08:21:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26363 for ; Sun, 30 Aug 1998 08:21:24 -0700 Received: from dee.inr.ac.ru (dee.inr.ac.ru [193.233.7.82]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA16836 for ; Sun, 30 Aug 1998 08:21:20 -0700 (PDT) Received: (from root@localhost) by dee.inr.ac.ru (8.6.13/ANK+IPv6) id TAA07785; Sun, 30 Aug 1998 19:20:50 +0400 Message-Id: <199808301520.TAA07785@dee.inr.ac.ru> Subject: (IPng 6380) Re: Reg: Raw Sockets To: iprsvp@yahoo.com (Raghu V.V.J Vadapalli) Date: Sun, 30 Aug 1998 19:20:50 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <19980830143458.3303.rocketmail@send101.yahoomail.com> from "Raghu V.V.J Vadapalli" at Aug 30, 98 07:34:58 am From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > If so why don't we use the NEXT HEADER field for > identifying the RSVP messages rather than using IPv6 > route alert option. 1. Because nexthdr may be not rsvp. 2. Because we do not want to catch any messages but path, path tear and resv conf. Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 30 09:12:34 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA00659 for ipng-dist; Sun, 30 Aug 1998 09:08:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA00649 for ; Sun, 30 Aug 1998 09:08:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA28536 for ; Sun, 30 Aug 1998 09:08:41 -0700 Received: from send1b.yahoomail.com (send1b.yahoomail.com [205.180.60.23]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA24691 for ; Sun, 30 Aug 1998 09:08:41 -0700 (PDT) Message-ID: <19980830160813.4687.rocketmail@send1b.yahoomail.com> Received: from [209.94.102.26] by send1b; Sun, 30 Aug 1998 09:08:13 PDT Date: Sun, 30 Aug 1998 09:08:13 -0700 (PDT) From: "Raghu V.V.J Vadapalli" Subject: (IPng 6382) Re: Reg: Raw Sockets To: kuznet@ms2.inr.ac.ru Cc: ipng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi! As the NEXTHEADER=46 indicates that the next header is RSVP messages. If(NEXTHEADER == 46) then nextheader.type = RSVP. In this way we can identify the RSVP path, resv, tear messages. Am I right. Thanks -Raghu. ---Alexey Kuznetsov wrote: > > Hello! > > > If so why don't we use the NEXT HEADER field for > > identifying the RSVP messages rather than using IPv6 > > route alert option. > > 1. Because nexthdr may be not rsvp. > 2. Because we do not want to catch any messages but > path, path tear and resv conf. > > Alexey Kuznetsov > == ------------------------------------------------------------ _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 30 09:19:38 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA00689 for ipng-dist; Sun, 30 Aug 1998 09:18:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA00682 for ; Sun, 30 Aug 1998 09:18:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA29121 for ; Sun, 30 Aug 1998 09:18:02 -0700 Received: from ms2.inr.ac.ru (minus.inr.ac.ru [193.233.7.97]) by earth.sun.com (8.9.1/8.9.1) with SMTP id JAA26212 for ; Sun, 30 Aug 1998 09:17:59 -0700 (PDT) Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA19424; Sun, 30 Aug 1998 20:17:39 +0400 Message-Id: <199808301617.UAA19424@ms2.inr.ac.ru> Subject: (IPng 6383) Re: Reg: Raw Sockets To: iprsvp@yahoo.com (Raghu V.V.J Vadapalli) Date: Sun, 30 Aug 1998 20:17:39 +0400 (MSK DST) Cc: ipng@sunroof.eng.sun.com Reply-To: kuznet@ms2.inr.ac.ru In-Reply-To: <19980830160813.4687.rocketmail@send1b.yahoomail.com> from "Raghu V.V.J Vadapalli" at Aug 30, 98 09:08:13 am From: inr-lists-ipng@ms2.inr.ac.ru (Alexey Kuznetsov) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello! > If(NEXTHEADER == 46) > then nextheader.type = RSVP. > In this way we can identify the RSVP path, resv, tear > messages. Am I right. Go ahead 8) If you will parse every packet which passes through your router, you will not go very far 8) BTW it would be useful to read rsvp func. specs and router alert option description. They explain where water is sourced and where it flows to. Alexey Kuznetsov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 31 04:26:07 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA01155 for ipng-dist; Mon, 31 Aug 1998 04:21:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA01148 for ; Mon, 31 Aug 1998 04:21:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA12505 for ; Mon, 31 Aug 1998 04:21:42 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA27653 for ; Mon, 31 Aug 1998 04:21:43 -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 HAA16370; Mon, 31 Aug 1998 07:21:40 -0400 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA24724; Mon, 31 Aug 1998 07:21:39 -0400 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA03444; Mon, 31 Aug 1998 07:21:54 -0400 Message-Id: <35EA8752.A4A4C801@raleigh.ibm.com> Date: Mon, 31 Aug 1998 07:21:54 -0400 From: Brian Haberman Organization: Remote Access Products X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Richard Draves Cc: IPng Subject: (IPng 6385) Re: ietf terminal room: unknown HBH option code? References: <4D0A23B3F74DD111ACCD00805F31D8100AF8119B@RED-MSG-50> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves wrote: > > Our MSR IPv6 1.1 release uses 0xc7 as the code for the Router Alert > hop-by-hop option in MLD packets. I don't know why we used that particular > value, but we had to make up something because (as far as I know) there is > no official value for the Router Alert option. What value are other > implementations using for this option? > Rich, We are using 20 also. It looks like the msr implementation is using the IPv4 value for the router alert option. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 31 09:59:22 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id JAA01579 for ipng-dist; Mon, 31 Aug 1998 09:48:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with ESMTP id JAA01572 for ; Mon, 31 Aug 1998 09:48:00 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA05481 for ; Mon, 31 Aug 1998 09:47:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA16495 for ipng@sunroof.eng.sun.com; Mon, 31 Aug 1998 09:46:51 -0700 (PDT) Received: from sunmail1.Sun.COM (sunmail1.Corp.Sun.COM [129.145.1.2]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id JAA01475 for ; Mon, 31 Aug 1998 09:18:11 -0700 (PDT) Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id JAA14797; Mon, 31 Aug 1998 09:18:08 -0700 Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.1b+Sun/8.9.1) with SMTP id JAA01379; Mon, 31 Aug 1998 09:18:08 -0700 (PDT) Date: Mon, 31 Aug 1998 09:18:08 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 6387) Re: Security hole in 6over4 To: Brian E Carpenter Cc: Erik Nordmark , cmj@3com.com, ipng@sunroof.Sun.COM In-Reply-To: "Your message with ID" <35E92A50.5E66556B@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Thanks. Is there any reason we can't fix this by specifying that > a 6over4 router must only decapsulate packets arriving on the > interface(s) configured for 6over4? That interface is "all of IPv4", right? To close this hole I think you have to make sure that the boundary of the 6over4 link doesn't "leak" packets. This can be done by, in addition to configuring the IPv4 multicast routing admin scope boundary, also having a filter (i.e. discard) all IPv4 packets with protocol = 41. This would ensure that no packets can be injected to the 6over4 link by a node outside this boundary. 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 Mon Aug 31 15:19:32 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id PAA02094 for ipng-dist; Mon, 31 Aug 1998 15:07:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id PAA02087 for ; Mon, 31 Aug 1998 15:07:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA08414 for ; Mon, 31 Aug 1998 15:07:12 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA11315 for ; Mon, 31 Aug 1998 15:07:13 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2232.9) id ; Mon, 31 Aug 1998 15:07:11 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF811C8@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" , Brian E Carpenter Cc: cmj@3com.com, ipng@sunroof.eng.sun.com Subject: (IPng 6388) Re: Security hole in 6over4 Date: Mon, 31 Aug 1998 15:07:07 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To close this hole I think you have to make sure that the boundary > of the 6over4 link doesn't "leak" packets. > This can be done by, in addition to configuring the IPv4 > multicast routing > admin scope boundary, also having a filter (i.e. discard) all > IPv4 packets > with protocol = 41. I think this is the simplest solution. The downside of course is that it prevents other v6-over-v4 tunnels from traversing the site boundary. Many administrators might view that as an advantage. 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 Aug 31 21:17:09 1998 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id VAA02350 for ipng-dist; Mon, 31 Aug 1998 21:10:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id VAA02343 for ; Mon, 31 Aug 1998 21:10:27 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA15099 for ; Mon, 31 Aug 1998 21:10:26 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA03129 for ; Mon, 31 Aug 1998 21:10:27 -0700 (PDT) Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail13.digital.com (8.8.8/8.8.8/WV1.0g) with SMTP id AAA10578 for ; Tue, 1 Sep 1998 00:10:26 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19265; Tue, 1 Sep 1998 00:10:26 -0400 Message-Id: <199809010410.AA19265@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 6390) Basic API Status 8/31/98 Date: Tue, 01 Sep 1998 00:10:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I am just about ready to re-release the final draft of the basic API for a final analysis by the authors, and then to the Working Group. Here is what I am waiting for: 1. Mukesh and Craig - Proposed compromised solution on sockaddr_in6 array/structure/storage solution with text. 2. Mukesh and Craig - On issue of support for/against SA_LEN. Mukesh or Craig please send me the changes and we can nail this down and move on )---> thanks for taking this on...................... Changes to the draft I sent out that I will make now are: 1. sin6flow should be zeroed on all recv* calls. May be used on send* operations. 2. Edit and Cleanup of name space changes from getipnodename() and getipnodebyaddr(), and in the macro section. 3. Will clarify that use of sin6_scope_id can be used for Link-Local address, but that it is for further documents to specify the behavior and use of this field, and is beyond the scope of the basic API's intent and timeliness to deliver this specification to the market and particularly to ISVs building IPv6.. 4. Mukesh/Craig results on the above. 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 --------------------------------------------------------------------