From owner-ipng@sunroof.eng.sun.com Sat Jul 1 06:10:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e61D8gj21873 for ipng-dist; Sat, 1 Jul 2000 06:08:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e61D8X621866 for ; Sat, 1 Jul 2000 06:08:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA04422 for ; Sat, 1 Jul 2000 06:08:33 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04235 for ; Sat, 1 Jul 2000 07:08:31 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e61D7N622675; Sat, 1 Jul 2000 15:07:24 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA04023; Sat, 1 Jul 2000 15:07:19 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA29426; Sat, 1 Jul 2000 15:08:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200007011308.PAA29426@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: Thomas Narten , "IPng List (E-mail)" Subject: Re: quick autoconf question In-reply-to: Your message of Fri, 30 Jun 2000 12:47:52 PDT. <4D0A23B3F74DD111ACCD00805F31D81024BCF801@RED-MSG-50> Date: Sat, 01 Jul 2000 15:08:31 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The question has to do with NA & NS where the destination address (== the target address) is tentative. => I have an incredibly simple answer: our code doesn't receive packets to a tentative address! Francis.Dupont@enst-bretagne.fr PS: I've put "our" because this part was rewritten by Jean-Luc Richier (more standard ioctl(), DAD check in user mode and no race condition). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 1 06:30:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e61DST221899 for ipng-dist; Sat, 1 Jul 2000 06:28:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e61DSK621892 for ; Sat, 1 Jul 2000 06:28:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA17458 for ; Sat, 1 Jul 2000 06:28:21 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01994 for ; Sat, 1 Jul 2000 06:28:19 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e61DS6635434; Sat, 1 Jul 2000 15:28:07 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA04190; Sat, 1 Jul 2000 15:28:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA29572; Sat, 1 Jul 2000 15:29:17 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200007011329.PAA29572@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: Brian Haberman , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt In-reply-to: Your message of Fri, 30 Jun 2000 10:03:52 EDT. <4.2.2.20000629174645.01bec200@pop.epilogue.com> Date: Sat, 01 Jul 2000 15:29:17 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think it would be useful for an SNMP manager (or possibly other applications) within a site-local zone to be able to determine which zone ID a zone-boundary router is using to identify the manager's local site. Do we currently have a way to do this? Is anyone working on something like this? => zone ID is local to the node then I think your proposal should go (and get the same answer) with Jean-Luc's one (*). A possible solution would be a new ICMP message that asks for the remote host to return the zone ID indicated by the interface on which the message was received. A message sent to a link-local address would return a link-level zone ID; a message sent to a site-local address would return the site-level zone ID. => ICMP name-lookups are supposed to address all these problems, perhaps we have to add something in the I-D, but I believe we don't need new ICMP message(s). Thanks Francis.Dupont@enst-bretagne.fr PS: Jean-Luc Richier's problem: you'd like to discover the topology of a network, you get the routing table from a router, look at gateway fields of not-direct routes, they give the address of all the downstream routers attached to the first target. Problem: these addresses are in general (ie. there is no reason to not be :-) link-local addresses then you can't use them as destination addresses for SNMP queries. Solution: use ICMP name-lookups in order to get a global address of a router. Exactly what is needed is a proxy service for ICMP name-lookups, PPS: MZAP (RFC 2776) of course can help and its to-come MIB will give the perfect answer to your question. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 01:49:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e628mEU22112 for ipng-dist; Sun, 2 Jul 2000 01:48:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e628m4622105 for ; Sun, 2 Jul 2000 01:48:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA25618 for ; Sun, 2 Jul 2000 01:48:01 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18182 for ; Sun, 2 Jul 2000 02:48:01 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA06695 for ipng@sunroof.eng.sun.com; Sun, 2 Jul 2000 10:48:00 +0200 (MET DST) Date: Sun, 2 Jul 2000 10:48:00 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: Re: Revised IPng Working Group Charter Message-ID: <20000702104800.A4518@theory.cs.uni-bonn.de> References: <200006301525.LAA17869@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200006301525.LAA17869@newdev.harvard.edu>; from sob@harvard.edu on Fri, Jun 30, 2000 at 11:25:36AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Jun 30, 2000 at 11:25:36AM -0400, Scott Bradner wrote: > > if the only thing the redirector does is forward out a special port to > a particular server (or tunnel to the server) and all the servers > are running as if they are using the same IP address this should work - but > many redirectors operate as NAT boxes and fiddle with the IP addresses > in the IP header which breaks IPSec Well, NAT breaks a lot of things which where given in original IPv4 and which hopefully will be possible again with IPv6... Somehow, the original problem of this thread smells like we would want Anycast Adresses as the solution to it. However, I'm not aware they're really implemented already, especially not with TCP. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 04:55:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e62Bs8d22184 for ipng-dist; Sun, 2 Jul 2000 04:54:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e62Brx622177 for ; Sun, 2 Jul 2000 04:53:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA29140 for ; Sun, 2 Jul 2000 04:53:58 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26404 for ; Sun, 2 Jul 2000 04:53:57 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 0C5B5488; Sun, 2 Jul 2000 06:53:57 -0500 (CDT) Received: from sigma.zk3.dec.com (brysigma.zk3.dec.com [16.141.40.6]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4EE4D4F7; Sun, 2 Jul 2000 06:53:56 -0500 (CDT) Received: from localhost by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id HAA0000001269; Sun, 2 Jul 2000 07:53:55 -0400 (EDT) From: Jim Bound Message-Id: <200007021153.HAA0000001269@sigma.zk3.dec.com> X-Authentication-Warning: sigma.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Richard Draves Cc: Thomas Narten , "IPng List (E-mail)" , "Powell, Ken" , bound@zk3.dec.com Subject: Re: quick autoconf question In-reply-to: Your message of "Fri, 30 Jun 2000 13:46:54 PDT." <4D0A23B3F74DD111ACCD00805F31D81024BCF857@RED-MSG-50> Date: Sun, 02 Jul 2000 07:53:55 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk rich, might want to check with UNH too to see if they have interpreted it differently. /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 Sun Jul 2 05:01:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e62Bxt822205 for ipng-dist; Sun, 2 Jul 2000 04:59:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e62Bxk622198 for ; Sun, 2 Jul 2000 04:59:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA17806 for ; Sun, 2 Jul 2000 04:59:45 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26958 for ; Sun, 2 Jul 2000 04:59:45 -0700 (PDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id C55BB5A14; Sun, 2 Jul 2000 07:59:44 -0400 (EDT) Received: from sigma.zk3.dec.com (brysigma.zk3.dec.com [16.141.40.6]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 91CEA59FC; Sun, 2 Jul 2000 07:59:44 -0400 (EDT) Received: from localhost by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id HAA0000015520; Sun, 2 Jul 2000 07:59:44 -0400 (EDT) From: Jim Bound Message-Id: <200007021159.HAA0000015520@sigma.zk3.dec.com> X-Authentication-Warning: sigma.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: IPv6 Flow Label In-reply-to: Your message of "Fri, 30 Jun 2000 16:44:19 PDT." <4.3.2.7.2.20000630164059.026665a0@mailhost.iprg.nokia.com> Date: Sun, 02 Jul 2000 07:59:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi bob, good words of wisdom....also thanks for letting us bring it here if we want to for discussion....like experimental draft... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 3 03:11:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e63A9fr22611 for ipng-dist; Mon, 3 Jul 2000 03:09:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e63A9V622604 for ; Mon, 3 Jul 2000 03:09:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA18525 for ; Mon, 3 Jul 2000 03:09:29 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA16760 for ; Mon, 3 Jul 2000 04:09:15 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id TAA12245; Mon, 3 Jul 2000 19:16:36 +0900 To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: freeaddrinfo(NUL) In-Reply-To: <1943.948962723@coconut.itojun.org> References: <1943.948962723@coconut.itojun.org> X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000703191634R.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Mon, 03 Jul 2000 19:16:34 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for my too late response... In article <1943.948962723@coconut.itojun.org> (at Thu, 27 Jan 2000 17:45:23 +0900), itojun@iijlab.net says: > A question was raised about freeaddrinfo(NULL). > Is it permitted, or should we just SEGV? > My personal preference is to SEGV. I can find no reason to allow it > except NRL compatibilty. I think freeaddrinfo(NULL) and freehostent(NULL) should also be allowed as free(NULL) is allowed; to avoid confusion. If the returned buffer is bulkly malloc()ed, freeaddrinfo() will be: void freeaddrinfo(struct addrinfo *ai){ free(ai); } Similar question: How about getifaddrs()? The getifaddrs(NULL) included in KAME kit doesn't raise an error, does it? Why don't you have it raise a SEGV signal as you do in freeaddrinfo()? void freeifaddrs(struct ifaddrs *ifp){ if (!ifp) raise(SIG_SEGV); free(ifp); } I think freeifaddrs(NULL) should be allowed, too; again, to avoid confusion. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 3 07:31:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e63ET9M22709 for ipng-dist; Mon, 3 Jul 2000 07:29:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e63ESv622702 for ; Mon, 3 Jul 2000 07:28:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA06418 for ; Mon, 3 Jul 2000 07:28:56 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22789 for ; Mon, 3 Jul 2000 07:28:55 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA11317; Mon, 3 Jul 2000 09:28:44 -0500 (CDT) Message-Id: <200007031428.JAA11317@gungnir.fnal.gov> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Resend: icmp-name-lookups-05 In-reply-to: Your message of Sat, 01 Jul 2000 03:18:06 +0900. Date: Mon, 03 Jul 2000 09:28:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the delay; messages which require actual thinking sometimes age in the inbox. The problem you report is that the ICMP code field of a Node Information message is defined to indicate what is in the Data field: an IPv4 or IPv4 address or a DNS name. But one type of message, the NOOP, has an empty Data field. I propose that the fix to the document is to say that the Code field on a NOOP query must be 1 (meaning Data contains a name), and on a NOOP reponse must be 0 (defined to mean success with a Data field that may or may not be empty), and in both cases must be ignored on reception. OK? 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 Jul 4 09:45:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e64GhNb23201 for ipng-dist; Tue, 4 Jul 2000 09:43:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e64GhD623194 for ; Tue, 4 Jul 2000 09:43:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA04441 for ; Tue, 4 Jul 2000 09:43:13 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10893 for ; Tue, 4 Jul 2000 10:43:11 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id BAA29251; Wed, 5 Jul 2000 01:43:09 +0900 To: ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <200006270219.WAA0000721425@anw.zk3.dec.com> References: <20000626184933W.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200006270219.WAA0000721425@anw.zk3.dec.com> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000705014309G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 05 Jul 2000 01:43:09 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 178 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, all, In article <200006270219.WAA0000721425@anw.zk3.dec.com> (at Mon, 26 Jun 2000 22:19:38 -0400), Jim Bound says: > >1. Section 6.4: Protocol-Independent Nodename and Service Name Translation > > >* struct addrinfo{} > > Type of ai_addrlen member should be delcared as socklen_t, > > not size_t. > Hmmm. Works fine for me??? But I do see your point. We are following > XNET lead here see code snippet below and tell me why I will not work > for you? Though it may be ok without a cast operation, it is not clean, is it? > >* All paragraphs: > > All constants related to ai_family should be PF_* as commented in > > the definition of struct addrinfo{}; do not use AF_*. > > I will have to check this in the spec? I thought we had fixed this? > If we missed it it was an edit error. Thanks. RFC2553 is ok but RFC2553-bis has some errors. > >* AI_V4MAPPED > > Note: Currently, the values of AI_* of the GNU C Library are conflicted: > >#define AI_V4MAPPED 1 /* IPv4-mapped addresses are acceptable. */ > >#define AI_ALL 2 /* Return both IPv4 and IPv6 addresses. */ > >#define AI_ADDRCONFIG 4 /* Use configuration of this host to choose > > returned address type. */ > Change GNU library. I sent a bug report to glibc people. BTW, RFC2553 and POSIX do not say AI_* must not conflicted, do they? If they don't, decision of glibc was not illeagal. > >2. Section 6.5: Socket Address Structure to Nodename and Service Name > > >* NI_WITHSCOPEID > > Please define NI_WITHSOCPE. With this flag, getnameinfo() will return > > with scope-identifiers for link-local, site-local, org-local addresses if > > NI_NUMERICHOST is supplied; otherwise, no scope-identifier will be > > returned. Without providing this flag, applications that assumes > > INET6_ADDRSTRLEN maximum length of IPv6 address may be crashed. > > (Even if you re-define the value of INET6_ADDRSTRLEN, we need this > > flag because binaries already compiled may be crashed.) > > Whats wrong with ????? What I want to get as default is (maybe) what you get with NI_WITHOUTSCOPE (for backward compatibility). Note: INET6_ADDRSTRLEN is not large enough to store scoped-address. sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255%4294967295") = 57 > >* If sin6_scope_id is filled and the name for id (interface name for > > link-local addresses), what should we do? > > > Option: raise an error (EAI_NONAME) if called with NI_NAMEREQD; > > otherwise, return numeric scope-id. > > Option: always raise an error (EAI_NONAME) > > Sounds like a fair implementation choice. I would argue it will fail > because one should not be putting link-local addresses in the DNS. I see. > >* I want to have a new value "NI_MAXSCOPE" which indicates maximum length of > > scope-name including scope-delimiter / excluding terminating null-character. > > It already have IF_NAMESIZE for link-local scope-names, but it is not > > sufficient; we also have site-local scope identifiers. > > Why? It can't be larger than uint32_t ???? "No" for numeric identifiers (see below), but yes for non-numeric identifiers (such as link-local ids); and IF_NAMESIZE may be larger than IF_NAMESIZE. > If you define NI_MAXSCOPE to sin6_scope_id length then it will work. Should we locally defined NI_MAXSCOPE as ((int)((sizeof(u_int32_t)*CHAR_BIT+2)/3+1)) or so? > >* I want to have a new flag NI_UNMAPPED not to have "::ffff:127.0.0.1" > > but "127.0.0.1" for mapped-addresses. This is "inverse-function" of > > AI_MAPPED flags. > > I don't agree its the inverse at all? All you do is request PF_INET. ??? getaddrinfo() with AI_MAPPED -----------------------------> IPv4-address string IPv4-mapped sockaddr_in6{} <----------------------------- getnameinfo() with NI_UNMAPPED Please see the following code and imagine ipv4 client 127.0.0.1 connects this socket. void sample(){ int sd, newsd; struct sockaddr_in6 sin6; socklen_t len; char addrbuf[NI_MAXHOST]; memset(&sin6, 0, sizeof(sin6)); sin6.sin6_family = AF_INET6; #ifdef SIN6_LEN sin6.sin6_len = sizeof(sin6); #endif sin6.port = htons(12345); sd = socket(PF_INET6, SOCK_STREAM, 0); bind(sd, (struct sockaddr *)&sin6, sizeof(sin6)); listen(sd, 1); len = sizeof(sin6); newsd = accept(sd, (struct sockaddr *)&sin6, &len); getnameinfo((struct sockaddr *)&sin6, len, addrbuf, sizeof(addrbuf), NULL, 0, NI_NUMERICHOST|NI_NUMERICSCOPE); printf("%s\n", addrbuf); } With NI_UNMAPPED flag to getnameinfo(), we do want to get "127.0.0.1" instead of "::ffff:127.0.0.1". > >> - when we use peer-address for authentication. > > With this, we are free from a lot of painful work to convert > > ipv4-addresses to ipv4-mapped addresses. > > Just use PF_INET? See above. > >3. Others > > > >* I want to have getifaddrs(3) (first implemented by BSDi) standarized > > (or documented); ths function is used to get interface addresses. > > I think this should be done in the advanced API. The reason is > it presents a large set of new problems for scoping this spec > should not be dealing with. I see. > >* Please add "POSIX Consideration" > > Glibc people says declarations for some functions (like > > inet_{pton,ntop}() or getnameinf()) in RFC2553 are conflicted > > with ones in POSIX. > > This we need to check. But realize POSIX will use this spec with XNET > approval. They are out of wack now but are in the process of synching > up. Current XNS spec is strange. Thanks. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 4 09:52:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e64Gowl23227 for ipng-dist; Tue, 4 Jul 2000 09:50:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e64Gol623220 for ; Tue, 4 Jul 2000 09:50:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA24772 for ; Tue, 4 Jul 2000 09:50:47 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17912 for ; Tue, 4 Jul 2000 09:50:45 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA20580; Wed, 5 Jul 2000 01:50:35 +0900 (JST) To: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) cc: ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp In-reply-to: yoshfuji's message of Wed, 05 Jul 2000 01:43:09 JST. <20000705014309G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 From: itojun@iijlab.net Date: Wed, 05 Jul 2000 01:50:35 +0900 Message-ID: <20578.962729435@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >* Please add "POSIX Consideration" >> > Glibc people says declarations for some functions (like >> > inet_{pton,ntop}() or getnameinf()) in RFC2553 are conflicted >> > with ones in POSIX. >> >> This we need to check. But realize POSIX will use this spec with XNET >> approval. They are out of wack now but are in the process of synching >> up. >Current XNS spec is strange. I think I have emailed on this more than twice, for me it seems that glibc people misunderstood what is meant by "socklen_t". I *strongly* object to make this unnecessary change (size_t -> socklen_t for hostnamelen/servnamelen/etc). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 4 10:16:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e64HE2L23259 for ipng-dist; Tue, 4 Jul 2000 10:14:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e64HDr623252 for ; Tue, 4 Jul 2000 10:13:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA06433 for ; Tue, 4 Jul 2000 10:13:53 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19049 for ; Tue, 4 Jul 2000 11:13:52 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id CAA29314; Wed, 5 Jul 2000 02:13:44 +0900 To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <20578.962729435@coconut.itojun.org> References: <20000705014309G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <20578.962729435@coconut.itojun.org> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000705021344G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 05 Jul 2000 02:13:44 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <20578.962729435@coconut.itojun.org> (at Wed, 05 Jul 2000 01:50:35 +0900), itojun@iijlab.net says: > I think I have emailed on this more than twice, for me it seems that > glibc people misunderstood what is meant by "socklen_t". I *strongly* > object to make this unnecessary change (size_t -> socklen_t for > hostnamelen/servnamelen/etc). Yes I know, I know! But they won't change unless XNS changes... (sigh) XNS 5.2: -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 5 04:42:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65Behg23720 for ipng-dist; Wed, 5 Jul 2000 04:40:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65BeW623713 for ; Wed, 5 Jul 2000 04:40:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA27958 for ; Wed, 5 Jul 2000 04:40:26 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11886 for ; Wed, 5 Jul 2000 04:40:25 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id UAA04243; Wed, 5 Jul 2000 20:40:07 +0900 (JST) To: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) cc: ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp In-reply-to: yoshfuji's message of Wed, 05 Jul 2000 02:13:44 JST. <20000705021344G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 From: itojun@iijlab.net Date: Wed, 05 Jul 2000 20:40:07 +0900 Message-ID: <4241.962797207@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I think I have emailed on this more than twice, for me it seems that >> glibc people misunderstood what is meant by "socklen_t". I *strongly* >> object to make this unnecessary change (size_t -> socklen_t for >> hostnamelen/servnamelen/etc). >Yes I know, I know! But they won't change unless XNS changes... (sigh) >XNS 5.2: I'm confused, which people are you trying to convince? Are you trying to change 2553 to use socklen_t for all the arguments, or are you trying to correct glibc? If the latter, the mailing list is a wrong place to ask. Some description on current situation should help you... The XNS-RFC incompatibility will be solved when 2553bis document is finalized. For the current specification, RFC2553 looks more correct (RFC2553 is more closer to 2553bis). For updated specification, words in 2553bis will be directly put into XNS so they will become exactly the same. (correct me if my memory is wrong) As there is no change between RFC2553 and 2553bis on this particular "getnameinfo argument" issue, RFC2553 is the correct specification to look at for this particular issue. Please try to convince glibc guys, quoting the above if necessary. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 5 06:54:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65DqS523855 for ipng-dist; Wed, 5 Jul 2000 06:52:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65DqJ623848 for ; Wed, 5 Jul 2000 06:52:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA07669 for ; Wed, 5 Jul 2000 06:52:14 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05477 for ; Wed, 5 Jul 2000 06:52:12 -0700 (PDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id WAA04105; Wed, 5 Jul 2000 22:52:03 +0900 To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 From: Hideaki YOSHIFUJI In-Reply-To: <4241.962797207@coconut.itojun.org> References: <20000705021344G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <4241.962797207@coconut.itojun.org> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000705225202C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 05 Jul 2000 22:52:02 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, all. In article <4241.962797207@coconut.itojun.org> (at Wed, 05 Jul 2000 20:40:07 +0900), itojun@iijlab.net says: > Are you trying to change 2553 to use socklen_t for all the arguments, > or are you trying to correct glibc? If the latter, the mailing list > is a wrong place to ask. Of course, the latter. > Some description on current situation should help you... > The XNS-RFC incompatibility will be solved when 2553bis document > is finalized. For the current specification, RFC2553 looks > more correct (RFC2553 is more closer to 2553bis). For updated > specification, words in 2553bis will be directly put into XNS so > they will become exactly the same. (correct me if my memory is wrong) When will 2553bis be finalized? If it takes much time, new glibc ships with wrong declaration because they won't respect RFC2553(bis), but XNS. Then, many distributions will ships with incorrect glibc. (bad...) > As there is no change between RFC2553 and 2553bis on this particular > "getnameinfo argument" issue, RFC2553 is the correct specification > to look at for this particular issue. > > Please try to convince glibc guys, quoting the above if necessary. I've raised an official bug-report: We need comments on this from people other than me to convince them. Please, please comment on this directly (not via me) to the glibc people. We really need it. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 5 07:20:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65EJJw23917 for ipng-dist; Wed, 5 Jul 2000 07:19:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65EJ5623910 for ; Wed, 5 Jul 2000 07:19:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA21190 for ; Wed, 5 Jul 2000 07:19:05 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19997 for ; Wed, 5 Jul 2000 07:19:04 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA06821; Wed, 5 Jul 2000 23:19:02 +0900 (JST) To: Hideaki YOSHIFUJI , ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp In-reply-to: itojun's message of Wed, 05 Jul 2000 23:17:47 JST. <6794.962806667@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 From: itojun@iijlab.net Date: Wed, 05 Jul 2000 23:19:02 +0900 Message-ID: <6819.962806742@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> As there is no change between RFC2553 and 2553bis on this particular >>> "getnameinfo argument" issue, RFC2553 is the correct specification >>> to look at for this particular issue. >>> Please try to convince glibc guys, quoting the above if necessary. >> I've raised an official bug-report: >> >> We need comments on this from people other than me to convince them. >> Please, please comment on this directly (not via me) to the >> glibc people. We really need it. > Here's how to append comment onto the above bug report: > send email with the following headers. > To: bugs@gnu.org > Subject: Re: libc/1805 There will be some delay until the bug report gets updated, so DON'T RESEND even if you don't see your email pasted onto the bug report. itojjun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 5 07:20:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65EIBA23908 for ipng-dist; Wed, 5 Jul 2000 07:18:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65EHu623901 for ; Wed, 5 Jul 2000 07:17:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA21113 for ; Wed, 5 Jul 2000 07:17:55 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19333 for ; Wed, 5 Jul 2000 07:17:53 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA06796; Wed, 5 Jul 2000 23:17:47 +0900 (JST) To: Hideaki YOSHIFUJI cc: ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp In-reply-to: yoshfuji's message of Wed, 05 Jul 2000 22:52:02 JST. <20000705225202C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 From: itojun@iijlab.net Date: Wed, 05 Jul 2000 23:17:47 +0900 Message-ID: <6794.962806667@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> As there is no change between RFC2553 and 2553bis on this particular >> "getnameinfo argument" issue, RFC2553 is the correct specification >> to look at for this particular issue. >> Please try to convince glibc guys, quoting the above if necessary. > I've raised an official bug-report: > > We need comments on this from people other than me to convince them. > Please, please comment on this directly (not via me) to the > glibc people. We really need it. Here's how to append comment onto the above bug report: send email with the following headers. To: bugs@gnu.org Subject: Re: libc/1805 itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 5 09:54:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65GqRj24072 for ipng-dist; Wed, 5 Jul 2000 09:52:27 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65GqN624065 for ; Wed, 5 Jul 2000 09:52:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA01227 for ipng@sunroof.eng.sun.com; Wed, 5 Jul 2000 09:50:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e611fw621502 for ; Fri, 30 Jun 2000 18:41:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA08593 for ; Fri, 30 Jun 2000 18:41:57 -0700 (PDT) From: xubo@mail.zte.com.cn Received: from mail.zhongxing.com ([202.103.147.133]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA12895 for ; Fri, 30 Jun 2000 18:41:57 -0700 (PDT) Received: by mail.zhongxing.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 4825690F.00096852 ; Sat, 1 Jul 2000 09:42:45 +0800 X-Lotus-FromDomain: ZTE_LTD To: ipng@sunroof.eng.sun.com Message-ID: <4825690F.0008C182.00@mail.zhongxing.com> Date: Sat, 1 Jul 2000 09:35:38 +0800 Subject: look for information Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I need some information about the possibility to support IP directly over SDH, without passing through ATM. Have you some titles of articles and other references for helping me? Thanks in advance xubo E-mail:xubo@mail.zte.com.cn -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 5 11:17:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65IFDO24171 for ipng-dist; Wed, 5 Jul 2000 11:15:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65IF4624164 for ; Wed, 5 Jul 2000 11:15:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA04806 for ; Wed, 5 Jul 2000 11:15:04 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA06119 for ; Wed, 5 Jul 2000 12:15:02 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 Jul 2000 11:10:33 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Wed, 5 Jul 2000 11:10:33 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024E2453B@RED-MSG-50> From: Richard Draves To: Mohan Parthasarathy , Francis Dupont Cc: Thomas Narten , "IPng List (E-mail)" Subject: RE: quick autoconf question Date: Wed, 5 Jul 2000 11:09:37 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have a different question in the same context. Assume two nodes > node A and node B on the same link. If node A (malicious) does > not do *DAD* and sends out a packet with node B's address as source > address to B, B should drop the packet. But this is not mentioned > in the spec anywhere. It assumes that both nodes A and B does > DAD. If node B does not drop the packet, it could potentially > create a neighbor cache entry with node A's source address > which is itself, with node A's h/w address information. > > Does the spec say anything on the above ? No. I don't see why you would create a neighbor cache entry in this situation. When node B tries to reply to the source address in the packet, which is its own address, won't node B just use its loopback path and not create an NCE? ND does not claim to be secure against malicious nodes on your link. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 5 11:33:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65IVmK24217 for ipng-dist; Wed, 5 Jul 2000 11:31:48 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65IVi624210 for ; Wed, 5 Jul 2000 11:31:44 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA02470 for ipng@sunroof.eng.sun.com; Wed, 5 Jul 2000 11:30:19 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e63K8N622782 for ; Mon, 3 Jul 2000 13:08:23 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id e63K7ZC03850; Mon, 3 Jul 2000 13:07:35 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200007032007.e63K7ZC03850@locked.eng.sun.com> Subject: Re: quick autoconf question In-Reply-To: <200007011308.PAA29426@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Jul 1, 2000 03:08:31 pm" To: Francis Dupont Date: Mon, 3 Jul 2000 13:07:35 -0700 (PDT) CC: Richard Draves , Thomas Narten , "IPng List (E-mail)" X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > The question has to do with NA & NS where the destination address (== the > target address) is tentative. > > => I have an incredibly simple answer: our code doesn't receive packets > to a tentative address! > Ideally one should not recieve packets destined to tentative address as it is not yet assigned to the interface i.e your machine should not pick packets for the tentative address. I have a different question in the same context. Assume two nodes node A and node B on the same link. If node A (malicious) does not do *DAD* and sends out a packet with node B's address as source address to B, B should drop the packet. But this is not mentioned in the spec anywhere. It assumes that both nodes A and B does DAD. If node B does not drop the packet, it could potentially create a neighbor cache entry with node A's source address which is itself, with node A's h/w address information. Does the spec say anything on the above ? -mohan > Francis.Dupont@enst-bretagne.fr > > PS: I've put "our" because this part was rewritten by Jean-Luc Richier > (more standard ioctl(), DAD check in user mode and no race condition). > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 5 11:47:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65Ik7Y24267 for ipng-dist; Wed, 5 Jul 2000 11:46:07 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65Ik2624260 for ; Wed, 5 Jul 2000 11:46:03 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA02690 for ipng@sunroof.eng.sun.com; Wed, 5 Jul 2000 11:44:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65C2q623761 for ; Wed, 5 Jul 2000 05:02:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA27847 for ; Wed, 5 Jul 2000 05:02:51 -0700 (PDT) Received: from smtp1.chello.se (smtp1.chello.se [193.150.195.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18779 for ; Wed, 5 Jul 2000 05:02:50 -0700 (PDT) Received: from thomase ([213.200.160.135]) by smtp1.chello.se (InterMail vK.4.02.00.00 201-232-116 license 0be0198aab3c5c3dfea01242ca021ddf) with SMTP id <20000705120223.BQCY25690.smtp1@thomase>; Wed, 5 Jul 2000 14:02:23 +0200 Message-ID: <005c01bfe678$17ade6c0$87a0c8d5@thomase.chello.se> Reply-To: "Thomas Eklund" From: "Thomas Eklund" To: Cc: Subject: IPv6 Flow label Date: Wed, 5 Jul 2000 13:56:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01BFE688.DB152500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0059_01BFE688.DB152500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have an idea of what to use it for. I'm currently writing a draft about "traffic engineering in ipv6" like I = said to you Bob. A draft proposal is finished quite soon and the intention is to see if = there is some interest to use the flowlabel for traffic engineering and = If you would like to co-author it thats perfect... Anyway I have asked for a slot on the IPng meeting for a couple of weeks = ago and I hope that we can have a good discussion about this at the next = IETf meeting
We have an=20 idea of what to use it for.
I'm currently writing a draft about=20 "traffic engineering in ipv6" like I said to you = Bob.
A draft proposal is finished quite = soon and the=20 intention is to see if there is some interest to use the flowlabel for = traffic=20 engineering and If you would like to co-author it thats = perfect...
 
Anyway I have asked for a slot on = the IPng=20 meeting for a couple of weeks ago and I hope that we can have a good = discussion=20 about this at the next IETf meeting
 
<Thinking about the discussion on = what to do=20 with the IPv6 flow label field,
<I have couple of=20 thoughts.
<
<The discussion about the best working group for = this=20 work is somewhat
<academic until there is a concrete proposal = (i.e, an=20 internet draft) for
<what do with it.
You will have it before the next = meeting as we=20 discussed.
 
Best Regards
 Thomas Eklund
<The = intent of the=20 words in the draft charter was to say that if someone has
<a = concrete=20 proposal for how to use the IPv6 flow label field, they should =
<present=20 it to the IPng w.g.  It will be easy once that happens to move it=20
<to a more appropriate w.g. if it makes = sense.
<
<Just=20 because we have the IPv6 flow label bits "available" it is not = at all=20
<clear we want to do anything with them today.  Our = experience with=20 IPv4 is
<that it would have been very nice to have had some open = bits=20 available for
<future use.  The IP world will change in = unexpected=20 ways.  These bits may
<become very useful 5-10 years from = now. =20 They may be needed for something
<that has not been thought of=20 today.
<
<It might be much better to encourage = experimentation with=20 the flow label
<bits than to standardize something now.  = Lets use=20 them wisely.
<
< Bob
------=_NextPart_000_0059_01BFE688.DB152500-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 5 12:21:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e65JJZ824390 for ipng-dist; Wed, 5 Jul 2000 12:19:35 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65JJU624383 for ; Wed, 5 Jul 2000 12:19:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id MAA03234 for ipng@sunroof.eng.sun.com; Wed, 5 Jul 2000 12:18:05 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e65JHp624354 for ; Wed, 5 Jul 2000 12:17:51 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id e65JH2h05200; Wed, 5 Jul 2000 12:17:02 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200007051917.e65JH2h05200@locked.eng.sun.com> Subject: Re: quick autoconf question In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81024E2453B@RED-MSG-50> from Richard Draves at "Jul 5, 2000 11:09:37 am" To: Richard Draves Date: Wed, 5 Jul 2000 12:17:02 -0700 (PDT) CC: Francis Dupont , Thomas Narten , "IPng List (E-mail)" X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I have a different question in the same context. Assume two nodes > > node A and node B on the same link. If node A (malicious) does > > not do *DAD* and sends out a packet with node B's address as source > > address to B, B should drop the packet. But this is not mentioned > > in the spec anywhere. It assumes that both nodes A and B does > > DAD. If node B does not drop the packet, it could potentially > > create a neighbor cache entry with node A's source address > > which is itself, with node A's h/w address information. > > > > Does the spec say anything on the above ? > > No. > > I don't see why you would create a neighbor cache entry in this situation. > When node B tries to reply to the source address in the packet, which is its > own address, won't node B just use its loopback path and not create an NCE? > >From reading section 7.2.3 Receipt of Neighbor solicitations in RFC2461, it says that one should create or update the neighbor cache entry for source address if the source link layer option is present. > ND does not claim to be secure against malicious nodes on your link. > But this could be a simple enough check to make sure that we are not recieving NS with our own address. -mohan > Rich > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 6 00:01:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e666xbg24716 for ipng-dist; Wed, 5 Jul 2000 23:59:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e666xS624709 for ; Wed, 5 Jul 2000 23:59:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA22212 for ; Wed, 5 Jul 2000 23:59:22 -0700 (PDT) From: ipng@uni-muenster.de Received: from math.uni-muenster.de (MATH.UNI-MUENSTER.DE [128.176.182.85]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA21395 for ; Wed, 5 Jul 2000 23:59:21 -0700 (PDT) Received: from moebius.uni-muenster.de (moebius [128.176.149.11]) by math.uni-muenster.de (8.9.1a/8.9.0) with ESMTP id IAA01595; Thu, 6 Jul 2000 08:59:02 +0200 (MET DST) Message-ID: X-Mailer: XFMail 1.4.4 on Solaris X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <4825690F.0008C182.00@mail.zhongxing.com> Date: Thu, 06 Jul 2000 08:59:01 +0200 (MET DST) Organization: Westfaelische Wilhelms-Universitaet To: xubo@mail.zte.com.cn, ipng@sunroof.eng.sun.com Subject: RE: look for information Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 01-Jul-2000 xubo@mail.zte.com.cn wrote: > > > > Hi, I need some information about the possibility to support IP directly > over SDH, without passing through ATM. > Have you some titles of articles and other references for helping me? > Thanks in advance Hi all! Please direct your answers to this list, I'm interested in this, too. All I found so far are some rfc's (2171-2176) describing Multiple Access Protocol over SDH/SONET (MAPOS). The informational rfc2176 talks about 'IPv4 over MAPOS', but I found nothing similar for IPv6. Regards, Christian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 01:31:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e668Tlv24798 for ipng-dist; Thu, 6 Jul 2000 01:29:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e668SZ624776; Thu, 6 Jul 2000 01:28:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA08450; Thu, 6 Jul 2000 01:28:33 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA22604; Thu, 6 Jul 2000 01:28:32 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id RAA10421; Thu, 6 Jul 2000 17:28:31 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id RAA29191; Thu, 6 Jul 2000 17:28:31 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id RAA00362; Thu, 6 Jul 2000 17:28:30 +0900 (JST) Date: Thu, 06 Jul 2000 17:27:14 +0900 (JST) Message-Id: <20000706.172714.91311805.kazu@Mew.org> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Cc: arano@byd.ocn.ad.jp Subject: Fw: [apnic-announce] IPv6 Policy Document Revision From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b43 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Jul__6_17:27:14_2000_213)--" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----Next_Part(Thu_Jul__6_17:27:14_2000_213)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, It seems to me that RTRs are going a wrong way, changing /48 per site policy. If you think so, please speak up on sig-ipv6@apnic.net now. --Kazu ----Next_Part(Thu_Jul__6_17:27:14_2000_213)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit From: secretariat@apnic.net Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST) X-Sender: paulg@compiler.staff.apnic.net To: apnic-announce@lists.apnic.net Subject: [apnic-announce] IPv6 Policy Document Revision Sender: owner-apnic-announce@lists.apnic.net Reply-To: apnic-talk@apnic.net [Note "reply-to:" field] Summary Both ARIN and the RIPE NCC have had discussions with the Internet communities in their region concerning the size of address prefixes to be assigned to IPv6 end sites. APNIC is now seeking input from the community in the Asia Pacific region on this issue. If you care about this, please read on. Some background The existing IPv6 policy document 'Provisional IPv6 Assignment and Allocation Policy Document' was published in May 1999. Formal revision of the document commenced in October 1999. The existing document is available at: http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html Feedback on the existing document was collected from the Internet community at large facilitated through the regional processes of consultation by the RIRs as well as input from the membership of the 6bone and the IETF IPv6 working groups. The deadline for comments was 31st January 2000. On 29th March, the RIRs, chairs of the IPv6 related IETF working groups and 6bone particpants met in Adelaide. The purpose of the meeting was to expand and elaborate in person on the comments made by the IAB/IETF/6bone concerning the existing policy document. One of the issues of concern that had been previously raised by members is the size of the end-site prefix (the 'SLA ID', currently defined in rfc2374 as 16 bits at a /48). This includes *all* types of end-sites including a single device. A /48 is sufficient address space to create 64K of subnets. The technical motivation for the 16 bit SLA ID field and the 'one size fits all' principle was described in rfc2374 as: "The size of the Site-Level Aggregation Identifier field is 16 bits. This supports 65,535 individual subnets per site. The design goal for the size of this field was to be sufficient for all but the largest of organizations. Organizations which need additional subnets can arrange with the organization they are obtaining Internet service from to obtain additional site identifiers and use this to create additional subnets. The Site-Level Aggregation Identifier field was given a fixed size in order to force the length of all prefixes identifying a particular site to be the same length (i.e., 48 bits). This facilitates movement of sites in the topology (e.g., changing service providers and multi-homing to multiple service providers)." It is possible to imagine in future a variety of types of end-sites being connected to the Internet. Some of these devices will be part of routed networks and others will not. The question proposed is whether 'one size fits all' (the /48) is appropriate for all end-sites? Both the RIPE and ARIN communities have rejected this. APNIC has been asked to consult with the Internet community in the Asia Pacific on this issue. To date, there has been no consensus on what alternatives should be taken, but 3 different approaches have been identified in addition to the 16 bit SLA ID field specified in rfc2374. These are: 1) /64 for single devices (such as mobile phones), /48 for all other sites 2) /64 for single devices, /48 for large end sites which need more than 256 subnets, and /56 for other sites (eg small, domestic/home sites) 3) Assign what is needed for the forseeable needs of the site, as a variable-length prefix of between /48 and /64. (It is important to remember that for any site that becomes multi-homed it is necessary to use equal length prefixes from each provider even in the case where one provider has allocated more prefix space than the other). We are interested in your opinions, so that we may convey this to the other RIRs and to the IETF community. Please direct all follow up discussion and comments to . For details of how to subscribe to this mailing list, please visit our web site at: http://www.apnic.net/general.html#mailing-lists . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * ----Next_Part(Thu_Jul__6_17:27:14_2000_213)---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 05:30:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66CSlK24960 for ipng-dist; Thu, 6 Jul 2000 05:28:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66CSa624953 for ; Thu, 6 Jul 2000 05:28:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA11923 for ; Thu, 6 Jul 2000 05:28:37 -0700 (PDT) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07769 for ; Thu, 6 Jul 2000 06:28:35 -0600 (MDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id IAA03216; Thu, 6 Jul 2000 08:28:21 -0400 Message-Id: <200007061228.IAA03216@hygro.adsl.duke.edu> To: xubo@mail.zte.com.cn cc: ipng@sunroof.eng.sun.com Subject: Re: look for information In-Reply-To: Message from xubo@mail.zte.com.cn of "Sat, 01 Jul 2000 09:35:38 +0800." <4825690F.0008C182.00@mail.zhongxing.com> Date: Thu, 06 Jul 2000 08:28:21 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hi, I need some information about the possibility to support IP directly > over SDH, without passing through ATM. See RFC 2615. IP isn't generally run directly over Sonet/SDH. Rather, people run IP over PPP over Sonet/SDH. The market seems to think this is quite adequate. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 6 10:46:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66Hi9525144 for ipng-dist; Thu, 6 Jul 2000 10:44:09 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66Hi4625137 for ; Thu, 6 Jul 2000 10:44:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA04780 for ipng@sunroof.eng.sun.com; Thu, 6 Jul 2000 10:42:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e666GN624694 for ; Wed, 5 Jul 2000 23:16:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA20148 for ; Wed, 5 Jul 2000 23:16:22 -0700 (PDT) From: core@kame.net Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA09533 for ; Wed, 5 Jul 2000 23:16:22 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA06617 for ; Thu, 6 Jul 2000 15:16:22 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA00551 for ; Thu, 6 Jul 2000 15:16:21 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA22028 for ; Thu, 6 Jul 2000 15:16:21 +0900 (JST) Date: Thu, 06 Jul 2000 15:15:13 +0900 (JST) Message-Id: <20000706.151513.77059243.kazu@Mew.org> To: ipng@sunroof.eng.sun.com Subject: KAME stable 20000704 X-Mailer: Mew version 1.95b43 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As usual, KAME Project has released "stable" packages of IPv6/IPsec network code for the following BSD variants. --- bsdi3 BSDI BSD/OS http://www.bsdi.com/ kernel: BSD/OS 3.1 patchlevel 0 userland: BSD/OS 3.0 patchlevel 0 include: BSD/OS 3.0 patchlevel 0 + ISC BIND 4.9.7 bsdi4 BSDI BSD/OS 4.1 patchlevel 0 http://www.bsdi.com/ freebsd2 FreeBSD 2.2.8-RELEASE http://www.freebsd.org/ freebsd3 FreeBSD 3.4-RELEASE http://www.freebsd.org/ netbsd NetBSD 1.4.2 http://www.netbsd.org/ openbsd OpenBSD 2.7 http://www.openbsd.org/ --- Note: {Free,Net,Open}BSD-current have already merged the KAME source code, from *past* versions of KAME codebase. For differences between KAME kits and *BSD tree, please visit: http://www.kame.net/project-overview.html#release http://www.kame.net/dev/cvsweb.cgi/kame/COVERAGE They are free of charge but absolutely no warranty. They are avaiable from the following web site: http://www.kame.net/ To know the changes from the previous stable package, please refer to the CHANGELOG/RELNOTES file. --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 Thu Jul 6 10:48:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66HlJJ25179 for ipng-dist; Thu, 6 Jul 2000 10:47:19 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66HlE625172 for ; Thu, 6 Jul 2000 10:47:15 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA04816 for ipng@sunroof.eng.sun.com; Thu, 6 Jul 2000 10:45:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66AFj624857 for ; Thu, 6 Jul 2000 03:15:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA14381 for ; Thu, 6 Jul 2000 03:15:43 -0700 (PDT) Received: from boat.mail.pipex.net (our.mail.pipex.net [158.43.128.75]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA01853 for ; Thu, 6 Jul 2000 03:15:28 -0700 (PDT) Received: (qmail 26255 invoked from network); 6 Jul 2000 10:15:26 -0000 Received: from mailhost.puck.pipex.net (HELO mailhost.uk.internal) (194.130.147.54) by our.mail.pipex.net with SMTP; 6 Jul 2000 10:15:26 -0000 Received: (qmail 608 invoked from network); 6 Jul 2000 10:15:26 -0000 Received: from merlin.cam.uk.internal (HELO uk.uu.net) (172.31.3.9) by mailhost.uk.internal with SMTP; 6 Jul 2000 10:15:26 -0000 Message-ID: <39646A02.CACB8F8C@uk.uu.net> Date: Thu, 06 Jul 2000 11:14:11 +0000 From: Stephen Burley Reply-To: stephenb@uk.uu.net Organization: UUNET X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM CC: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <20000706.172714.91311805.kazu@Mew.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Kazu Yamamoto ($B;3K\OBI'(B)" wrote: > Folks, > > It seems to me that RTRs are going a wrong way, changing /48 per site > policy. If you think so, please speak up on sig-ipv6@apnic.net now. > > --Kazu Hi We discussed it at length in the RIPE 36 meeting and the majority not all were not in favour of not fixing the boundries but rather allowing the LIR to decide on merit/justification what amount of space to assign whithin the /48 - /64 boundries. If we fixit to /48 /56 /64 boundries it becomes too rigid, allow the LIR's to dictate their own assignment policy (ie flexible or fixed at 3 points /48 /56 /64) which they can justify to the RIR, in this way it pleases everyone - i garuntee if you fix the boundries it will have to be re-addrressed later on and will not please all. My thoughts Stephen Burley UUNET EMEA Hostmaster > > > ------------------------------------------------------------------------ > > Subject: [apnic-announce] IPv6 Policy Document Revision > Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST) > From: secretariat@apnic.net > Reply-To: apnic-talk@apnic.net > To: apnic-announce@lists.apnic.net > > [Note "reply-to:" field] > > Summary > > Both ARIN and the RIPE NCC have had discussions with the Internet > communities in their region concerning the size of address prefixes > to be assigned to IPv6 end sites. APNIC is now seeking input from > the community in the Asia Pacific region on this issue. If you care > about this, please read on. > > Some background > > The existing IPv6 policy document 'Provisional IPv6 Assignment and > Allocation Policy Document' was published in May 1999. Formal revision > of the document commenced in October 1999. The existing document > is available at: > > http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html > > Feedback on the existing document was collected from the Internet community > at large facilitated through the regional processes of consultation by > the RIRs as well as input from the membership of the 6bone and the > IETF IPv6 working groups. The deadline for comments was 31st January 2000. > > On 29th March, the RIRs, chairs of the IPv6 related IETF working > groups and 6bone particpants met in Adelaide. The purpose of the meeting > was to expand and elaborate in person on the comments made by the > IAB/IETF/6bone concerning the existing policy document. > > One of the issues of concern that had been previously raised by > members is the size of the end-site prefix (the 'SLA ID', currently > defined in rfc2374 as 16 bits at a /48). This includes *all* types > of end-sites including a single device. A /48 is sufficient address > space to create 64K of subnets. > > The technical motivation for the 16 bit SLA ID field and the > 'one size fits all' principle was described in rfc2374 as: > > "The size of the Site-Level Aggregation Identifier field is 16 bits. > This supports 65,535 individual subnets per site. The design goal > for the size of this field was to be sufficient for all but the > largest of organizations. Organizations which need additional > subnets can arrange with the organization they are obtaining Internet > service from to obtain additional site identifiers and use this to > create additional subnets. > > The Site-Level Aggregation Identifier field was given a fixed size in > order to force the length of all prefixes identifying a particular > site to be the same length (i.e., 48 bits). This facilitates > movement of sites in the topology (e.g., changing service providers > and multi-homing to multiple service providers)." > > It is possible to imagine in future a variety of types of end-sites > being connected to the Internet. Some of these devices will be part > of routed networks and others will not. The question proposed is whether > 'one size fits all' (the /48) is appropriate for all end-sites? > > Both the RIPE and ARIN communities have rejected this. > > APNIC has been asked to consult with the Internet community in the > Asia Pacific on this issue. > > To date, there has been no consensus on what alternatives should be > taken, but 3 different approaches have been identified in addition to > the 16 bit SLA ID field specified in rfc2374. > > These are: > > 1) /64 for single devices (such as mobile phones), /48 for all other sites > > 2) /64 for single devices, /48 for large end sites which need more > than 256 subnets, and /56 for other sites (eg small, domestic/home sites) > > 3) Assign what is needed for the forseeable needs of the site, as a > variable-length prefix of between /48 and /64. (It is important to > remember that for any site that becomes multi-homed it is necessary to > use equal length prefixes from each provider even in the case where > one provider has allocated more prefix space than the other). > > We are interested in your opinions, so that we may convey this to the > other RIRs and to the IETF community. Please direct all follow up > discussion and comments to . For details of > how to subscribe to this mailing list, please visit our web site at: > http://www.apnic.net/general.html#mailing-lists . > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > APNIC Secretariat > > Tel: +61-7-3367-0490 > Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 > Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > > * APNIC-ANNOUNCE: Announcements concerning APNIC * > * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life Stephenb@uk.uu.net if you're stupid and willing to wait" ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 10:56:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66Hs8m25221 for ipng-dist; Thu, 6 Jul 2000 10:54:08 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66Hs3625214 for ; Thu, 6 Jul 2000 10:54:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA04857 for ipng@sunroof.eng.sun.com; Thu, 6 Jul 2000 10:52:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66DZb625024 for ; Thu, 6 Jul 2000 06:35:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA15907 for ; Thu, 6 Jul 2000 06:35:37 -0700 (PDT) Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15402 for ; Thu, 6 Jul 2000 06:35:06 -0700 (PDT) Received: from cvis01.gpt.co.uk (cvis01.gpt.co.uk) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 6 Jul 2000 14:24:08 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-27) id OAA25575; Thu, 6 Jul 2000 14:24:03 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256914.00499684 ; Thu, 6 Jul 2000 14:23:46 +0100 X-Lotus-FromDomain: MCSUB2@MCEXT From: "Jonathan Oldroyd" To: xubo@mail.zte.com.cn cc: ipng@sunroof.eng.sun.com Message-ID: <80256914.00499485.00@marconicomms.com> Date: Thu, 6 Jul 2000 14:24:13 +0000 Subject: re: Looking for Information Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Xubo, >Hi, I need some information about the possibility to support IP directly >over SDH, without passing through ATM. >Have you some titles of articles and other references for helping me? > Thanks in advance > > xubo >E-mail:xubo@mail.zte.com.cn Relevant RFCs for supporting IP over SDH can be found in: RFC 1661: The Point-to-Point Protocol (PPP) RFC 1662: PPP in HDLC-like Framing RFC 2615: PPP over SONET/SDH RFC 2472: IP Version 6 over PPP Regards, Jon ____________________________________________________________________________________________ those who are authorised to receive it. If you are not the intended recipient, any disclosure, copying, distribution or action taken in reliance on its contents is prohibited and may be unlawful. In the case of misdirected receipt, please return this E-mail to the sender, destroying any local copies. ___________________________________________________________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 10:57:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66Htix25230 for ipng-dist; Thu, 6 Jul 2000 10:55:44 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66Htc625223 for ; Thu, 6 Jul 2000 10:55:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA04886 for ipng@sunroof.eng.sun.com; Thu, 6 Jul 2000 10:54:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66G7G625092 for ; Thu, 6 Jul 2000 09:07:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA20799 for ; Thu, 6 Jul 2000 09:07:16 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22051 for ; Thu, 6 Jul 2000 10:07:13 -0600 (MDT) Received: from rufsun5.ffm.fgan.de (mailhost.ffm.fgan.de [128.7.2.5]) by mailguard.fgan.de (8.9.3/8.9.3) with ESMTP id SAA04288; Thu, 6 Jul 2000 18:07:05 +0200 Received: from unna.ffm.fgan.de (unna.ffm.fgan.de [128.7.5.14]) by rufsun5.ffm.fgan.de (8.8.6/8.8.8) with ESMTP id SAA24957; Thu, 6 Jul 2000 18:07:04 +0200 (MET DST) Received: from unna.ffm.fgan.de (unna.ffm.fgan.de [128.7.5.14]) by unna.ffm.fgan.de (8.9.1b+Sun/8.9.1) with SMTP id SAA12678; Thu, 6 Jul 2000 18:07:04 +0200 (MET DST) Message-Id: <200007061607.SAA12678@unna.ffm.fgan.de> Date: Thu, 6 Jul 2000 18:07:04 +0200 (MET DST) From: Peter Sevenich Reply-To: Peter Sevenich Subject: Re: IPv6 Flow label To: hinden@iprg.nokia.com, thomas.eklund@chello.se, riechmann@fgan.de Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TGaaW5FAk1U7H7c1QJMICg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, we have two years of experience in using the IPv6-flowlabel to transmit timecritical data (for example vocoded voice) and conventional data at the same time over heterogenouse networks including those of low bandwhith ( in the moment ISDN, GSM, HF, seriel modem, gateway to usual phone etc..). We use the flowlabel to transmit flow_id and QoS-parameters for channel resorce management in any packet. In the moment we have implementationes on Linux Solaris and BSD and start inernational tests. We are interesting in any work around the flowlabel. With RFC 2553 we are unlucky, because it is said that the system sets the (random) value of flowlabel. For us it is important that the aplication can set and read this value. I think a good solution for the flowlabel should include this possibility. We are interesting in any colaboration and discussion to write a draft. Best Regards Peter Thomas Eklund wrote > >We have an idea of what to use it for. >I'm currently writing a draft about "traffic engineering in ipv6" like I said to you Bob. >A draft proposal is finished quite soon and the intention is to see if there is some interest to use the flowlabel for traffic engineering and If you would like to co-author it thats perfect... > >Anyway I have asked for a slot on the IPng meeting for a couple of weeks ago and I hope that we can have a good discussion about this at the next IETf meeting > >< > >You will have it before the next meeting as we discussed. > >Best Regards > Thomas Eklund >< >< >< >< Bob +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Peter Sevenich + + FGAN/FKIE/KOM + + Neuenahrer Str. 20 + + D-53343 Wachtberg-Werthhoven + + Germany + + Phone +49-228-9435-317 + + Fax +49-228-9435-685 + + e-mail sevenich@fgan.de + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 12:17:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66JDvA25377 for ipng-dist; Thu, 6 Jul 2000 12:13:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66JDm625370 for ; Thu, 6 Jul 2000 12:13:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA08012 for ; Thu, 6 Jul 2000 12:13:47 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11398 for ; Thu, 6 Jul 2000 13:13:45 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA69042; Thu, 6 Jul 2000 20:13:31 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA22146; Thu, 6 Jul 2000 20:13:40 +0100 (BST) Message-ID: <3964DA07.317A885A@hursley.ibm.com> Date: Thu, 06 Jul 2000 14:12:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Peter Sevenich CC: hinden@iprg.nokia.com, thomas.eklund@chello.se, riechmann@fgan.de, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Flow label References: <200007061607.SAA12678@unna.ffm.fgan.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Why do you use the flow label for QOS parameters, rather than the traffic class octet that was defined for that purpose in RFC 2474? Brian Peter Sevenich wrote: > > Hi, > we have two years of experience in using the IPv6-flowlabel to transmit > timecritical data (for example vocoded voice) and conventional data at the same > time over heterogenouse networks including those of low bandwhith ( in the > moment ISDN, GSM, HF, seriel modem, gateway to usual phone etc..). > We use the flowlabel to transmit flow_id and QoS-parameters for channel resorce > management in any packet. In the moment we have implementationes on Linux > Solaris and BSD and start inernational tests. > We are interesting in any work around the flowlabel. With RFC 2553 we are > unlucky, because it is said that the system sets the (random) value of > flowlabel. For us it is important that the aplication can set and read this > value. I think a good solution for the flowlabel should include this > possibility. > > We are interesting in any colaboration and discussion to write a draft. > > Best Regards > Peter > > Thomas Eklund wrote > > > >We have an idea of what to use it for. > >I'm currently writing a draft about "traffic engineering in ipv6" like I said > to you Bob. > >A draft proposal is finished quite soon and the intention is to see if there is > some interest to use the flowlabel for traffic engineering and If you would like > to co-author it thats perfect... > > > >Anyway I have asked for a slot on the IPng meeting for a couple of weeks ago > and I hope that we can have a good discussion about this at the next IETf > meeting > > > > > >< > > > > > > >You will have it before the next meeting as we discussed. > > > >Best Regards > > Thomas Eklund > > > > > >< > > > > > > > >< > > > >< > >< Bob > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > + Peter Sevenich + > + FGAN/FKIE/KOM + > + Neuenahrer Str. 20 + > + D-53343 Wachtberg-Werthhoven + > + Germany + > + Phone +49-228-9435-317 + > + Fax +49-228-9435-685 + > + e-mail sevenich@fgan.de + > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 6 12:37:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66JXH225431 for ipng-dist; Thu, 6 Jul 2000 12:33:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66JX4625424; Thu, 6 Jul 2000 12:33:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA01871; Thu, 6 Jul 2000 12:33:02 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23242; Thu, 6 Jul 2000 12:33:00 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id UAA14734; Thu, 6 Jul 2000 20:32:03 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id UAA15040; Thu, 6 Jul 2000 20:32:05 +0100 (BST) Message-ID: <3964DE58.7DB92581@hursley.ibm.com> Date: Thu, 06 Jul 2000 14:30:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: stephenb@uk.uu.net CC: Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen, Can you explain why people think there is any need to allocate anything longer than a /48 in the first place? Brian Stephen Burley wrote: > > "Kazu Yamamoto ($B;3K\OBI'(B)" wrote: > > > Folks, > > > > It seems to me that RTRs are going a wrong way, changing /48 per site > > policy. If you think so, please speak up on sig-ipv6@apnic.net now. > > > > --Kazu > > Hi > We discussed it at length in the RIPE 36 meeting and the majority not all > were not in favour of not fixing the boundries but rather allowing the LIR to > decide on merit/justification what amount of space to assign whithin the /48 - > /64 boundries. If we fixit to /48 /56 /64 boundries it becomes too rigid, allow > > the LIR's to dictate their own assignment policy (ie flexible or fixed at 3 > points /48 /56 /64) which they can justify to the RIR, in this way it pleases > everyone - i garuntee if you fix the boundries it will have to be re-addrressed > > later on and will not please all. > > My thoughts > Stephen Burley > UUNET EMEA Hostmaster > > > > > > > ------------------------------------------------------------------------ > > > > Subject: [apnic-announce] IPv6 Policy Document Revision > > Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST) > > From: secretariat@apnic.net > > Reply-To: apnic-talk@apnic.net > > To: apnic-announce@lists.apnic.net > > > > [Note "reply-to:" field] > > > > Summary > > > > Both ARIN and the RIPE NCC have had discussions with the Internet > > communities in their region concerning the size of address prefixes > > to be assigned to IPv6 end sites. APNIC is now seeking input from > > the community in the Asia Pacific region on this issue. If you care > > about this, please read on. > > > > Some background > > > > The existing IPv6 policy document 'Provisional IPv6 Assignment and > > Allocation Policy Document' was published in May 1999. Formal revision > > of the document commenced in October 1999. The existing document > > is available at: > > > > http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html > > > > Feedback on the existing document was collected from the Internet community > > at large facilitated through the regional processes of consultation by > > the RIRs as well as input from the membership of the 6bone and the > > IETF IPv6 working groups. The deadline for comments was 31st January 2000. > > > > On 29th March, the RIRs, chairs of the IPv6 related IETF working > > groups and 6bone particpants met in Adelaide. The purpose of the meeting > > was to expand and elaborate in person on the comments made by the > > IAB/IETF/6bone concerning the existing policy document. > > > > One of the issues of concern that had been previously raised by > > members is the size of the end-site prefix (the 'SLA ID', currently > > defined in rfc2374 as 16 bits at a /48). This includes *all* types > > of end-sites including a single device. A /48 is sufficient address > > space to create 64K of subnets. > > > > The technical motivation for the 16 bit SLA ID field and the > > 'one size fits all' principle was described in rfc2374 as: > > > > "The size of the Site-Level Aggregation Identifier field is 16 bits. > > This supports 65,535 individual subnets per site. The design goal > > for the size of this field was to be sufficient for all but the > > largest of organizations. Organizations which need additional > > subnets can arrange with the organization they are obtaining Internet > > service from to obtain additional site identifiers and use this to > > create additional subnets. > > > > The Site-Level Aggregation Identifier field was given a fixed size in > > order to force the length of all prefixes identifying a particular > > site to be the same length (i.e., 48 bits). This facilitates > > movement of sites in the topology (e.g., changing service providers > > and multi-homing to multiple service providers)." > > > > It is possible to imagine in future a variety of types of end-sites > > being connected to the Internet. Some of these devices will be part > > of routed networks and others will not. The question proposed is whether > > 'one size fits all' (the /48) is appropriate for all end-sites? > > > > Both the RIPE and ARIN communities have rejected this. > > > > APNIC has been asked to consult with the Internet community in the > > Asia Pacific on this issue. > > > > To date, there has been no consensus on what alternatives should be > > taken, but 3 different approaches have been identified in addition to > > the 16 bit SLA ID field specified in rfc2374. > > > > These are: > > > > 1) /64 for single devices (such as mobile phones), /48 for all other sites > > > > 2) /64 for single devices, /48 for large end sites which need more > > than 256 subnets, and /56 for other sites (eg small, domestic/home sites) > > > > 3) Assign what is needed for the forseeable needs of the site, as a > > variable-length prefix of between /48 and /64. (It is important to > > remember that for any site that becomes multi-homed it is necessary to > > use equal length prefixes from each provider even in the case where > > one provider has allocated more prefix space than the other). > > > > We are interested in your opinions, so that we may convey this to the > > other RIRs and to the IETF community. Please direct all follow up > > discussion and comments to . For details of > > how to subscribe to this mailing list, please visit our web site at: > > http://www.apnic.net/general.html#mailing-lists . > > > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > > APNIC Secretariat > > > > Tel: +61-7-3367-0490 > > Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 > > Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > > > > * APNIC-ANNOUNCE: Announcements concerning APNIC * > > * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * > > -- > ------------------------------------------------------------------------ > Stephen Burley "If patience is a virtue, and ignorance is bliss, > UUNET EMEA Hostmaster you can have a pretty good life > Stephenb@uk.uu.net if you're stupid and willing to wait" > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 6 14:20:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66LHvL25580 for ipng-dist; Thu, 6 Jul 2000 14:17:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66LHl625573 for ; Thu, 6 Jul 2000 14:17:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA26918 for ; Thu, 6 Jul 2000 14:17:47 -0700 (PDT) Received: from smtp2.chello.se (smtp2.chello.se [193.150.195.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27771 for ; Thu, 6 Jul 2000 14:17:46 -0700 (PDT) Received: from thomase ([213.200.160.135]) by smtp2.chello.se (InterMail vK.4.02.00.00 201-232-116 license 0be0198aab3c5c3dfea01242ca021ddf) with SMTP id <20000706211744.ENPG1146.smtp2@thomase>; Thu, 6 Jul 2000 23:17:44 +0200 Message-ID: <00a001bfe78e$c776fee0$87a0c8d5@thomase.chello.se> Reply-To: "Thomas Eklund" From: "Thomas Eklund" To: , "Thomas Narten" Cc: Subject: Re: look for information Date: Thu, 6 Jul 2000 23:11:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk People use to call it Packet over Sonet (PoS) and it is PPP over Sonet/SDH as you say. Note that new operators can choose Gigabit Ethernet instead of an TDM based infrastructure like Sonet/SDH and the result will be 1/10 in the price per port (compare 10 Gigabit Ethernet to PoS OC-192) which is a strong incitament for new operators to choose. This is actually what is happening in Sweden whre Utfors for instance have it backbone running Gigabit Ethernet. /Thomas -----Original Message----- From: Thomas Narten To: xubo@mail.zte.com.cn Cc: ipng@sunroof.eng.sun.com Date: Thursday, July 06, 2000 2:34 PM Subject: Re: look for information >> Hi, I need some information about the possibility to support IP directly >> over SDH, without passing through ATM. > >See RFC 2615. IP isn't generally run directly over Sonet/SDH. Rather, >people run IP over PPP over Sonet/SDH. The market seems to think this >is quite adequate. > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 14:27:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66LPmY25613 for ipng-dist; Thu, 6 Jul 2000 14:25:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66LPa625606; Thu, 6 Jul 2000 14:25:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA08981; Thu, 6 Jul 2000 14:25:37 -0700 (PDT) Received: from roam.psg.com (mg-20425422-112.ricochet.net [204.254.22.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11842; Thu, 6 Jul 2000 15:25:32 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13AJ7o-0000rS-00; Thu, 06 Jul 2000 17:24:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Brian E Carpenter Cc: stephenb@uk.uu.net, Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> Message-Id: Date: Thu, 06 Jul 2000 17:24:00 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Can you explain why people think there is any need to allocate anything > longer than a /48 in the first place? i believe the document restricted it to single-device network allocations. is a /64 too small for a single device? randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 6 15:35:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e66MXc825789 for ipng-dist; Thu, 6 Jul 2000 15:33:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e66MXT625782; Thu, 6 Jul 2000 15:33:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA15467; Thu, 6 Jul 2000 15:33:28 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27148; Thu, 6 Jul 2000 16:33:27 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA54848; Thu, 6 Jul 2000 23:32:31 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA21204; Thu, 6 Jul 2000 23:32:38 +0100 (BST) Message-ID: <39650844.775A46AA@hursley.ibm.com> Date: Thu, 06 Jul 2000 17:29:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Randy Bush CC: stephenb@uk.uu.net, Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, I'm not sure the concept of single device will mean much. For example, assuming we do IPv6 over BlueTooth right, what the phone company thinks is a single device may turn out to be a personal area network. Or a single 3GPP device might turn out to be three LANs inside a car. But fundamentally I'm not sure the RIRs need to even think about it; that question should be well below the horizon for an RIR policy. IMHO. Brian Randy Bush wrote: > > > Can you explain why people think there is any need to allocate anything > > longer than a /48 in the first place? > > i believe the document restricted it to single-device network allocations. > is a /64 too small for a single device? > > randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 00:25:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e677OAo26164 for ipng-dist; Fri, 7 Jul 2000 00:24:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e677Mw626141; Fri, 7 Jul 2000 00:22:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA16215; Fri, 7 Jul 2000 00:22:57 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25193; Fri, 7 Jul 2000 01:22:56 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e677Mh651864; Fri, 7 Jul 2000 09:22:44 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA09833; Fri, 7 Jul 2000 09:22:42 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA52803; Fri, 7 Jul 2000 09:22:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200007070722.JAA52803@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-reply-to: Your message of Thu, 06 Jul 2000 14:30:32 CDT. <3964DE58.7DB92581@hursley.ibm.com> Date: Fri, 07 Jul 2000 09:22:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Can you explain why people think there is any need to allocate anything longer than a /48 in the first place? => many ISPs want to allocate /64 (or worse) to their customers... and shout a /48 per customer is far too large. I believe this is a consequence of the slow^N start, ie. the /35 rule (RIRs trim address space of ISPs, ISPs take back the burden to their customers). The idea is to introduce a small site (/56) for "poor & little" customers and to make it the *default* allocation. IMHO this is an acceptable target. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 05:13:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67CBtm26558 for ipng-dist; Fri, 7 Jul 2000 05:11:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67CBj626551; Fri, 7 Jul 2000 05:11:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA16214; Fri, 7 Jul 2000 05:11:42 -0700 (PDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28239; Fri, 7 Jul 2000 05:11:38 -0700 (PDT) Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id WAA28764; Fri, 7 Jul 2000 22:07:04 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id WAA13723; Fri, 7 Jul 2000 22:08:09 +1000 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <3FW9RWGX>; Fri, 7 Jul 2000 22:07:58 +1000 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB0FF@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Stephen Burley '" , "'Brian E Carpenter '" Cc: "'Kazu@venus.Sun.COM '" , "'Yamamoto@venus.Sun.COM '" , "'ipng@sunroof.eng.sun.com '" , "'ngtrans@sunroof.eng.sun.com '" , "'arano@byd.ocn.ad.jp '" , "'sig-ipv6@apnic.net '" , "'mir@ripe.net '" , "'joao@ripe.net '" Subject: RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Date: Fri, 7 Jul 2000 22:07:56 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE80B.FC30E3D0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFE80B.FC30E3D0 Content-Type: text/plain VERY true IMO Call me oldfashioned but i remember when people thought we had enough space in IPv4 and it would never run out. If you fix the boundry at a /48 it means an ISP will go through their block of addresses way too fast. It also means that out customers do not have to think about what they are deploying as they know they will get a /48 no matter what. So a flexible boundry between /48 and /64 would help us to help customers to think about how they will deploy their address space. A /64 for dialup is also too rigid because the way technology is going a /64 is not going to be enough subnets for what wiill be a dial up connection with a large lan behind it. Just my thoughts. > > Brian > > Stephen Burley wrote: > > > > "Kazu Yamamoto ($B;3K\OBI'(B)" wrote: > > > > > Folks, > > > > > > It seems to me that RTRs are going a wrong way, changing /48 per site > > > policy. If you think so, please speak up on sig-ipv6@apnic.net now. > > > > > > --Kazu > > > > Hi > > We discussed it at length in the RIPE 36 meeting and the majority not all > > were not in favour of not fixing the boundries but rather allowing the LIR to > > decide on merit/justification what amount of space to assign whithin the /48 - > > /64 boundries. If we fixit to /48 /56 /64 boundries it becomes too rigid, allow > > > > the LIR's to dictate their own assignment policy (ie flexible or fixed at 3 > > points /48 /56 /64) which they can justify to the RIR, in this way it pleases > > everyone - i garuntee if you fix the boundries it will have to be re-addrressed > > > > later on and will not please all. > > > > My thoughts > > Stephen Burley > > UUNET EMEA Hostmaster > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > Subject: [apnic-announce] IPv6 Policy Document Revision > > > Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST) > > > From: secretariat@apnic.net > > > Reply-To: apnic-talk@apnic.net > > > To: apnic-announce@lists.apnic.net > > > > > > [Note "reply-to:" field] > > > > > > Summary > > > > > > Both ARIN and the RIPE NCC have had discussions with the Internet > > > communities in their region concerning the size of address prefixes > > > to be assigned to IPv6 end sites. APNIC is now seeking input from > > > the community in the Asia Pacific region on this issue. If you care > > > about this, please read on. > > > > > > Some background > > > > > > The existing IPv6 policy document 'Provisional IPv6 Assignment and > > > Allocation Policy Document' was published in May 1999. Formal revision > > > of the document commenced in October 1999. The existing document > > > is available at: > > > > > > http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html > > > > > > Feedback on the existing document was collected from the Internet community > > > at large facilitated through the regional processes of consultation by > > > the RIRs as well as input from the membership of the 6bone and the > > > IETF IPv6 working groups. The deadline for comments was 31st January 2000. > > > > > > On 29th March, the RIRs, chairs of the IPv6 related IETF working > > > groups and 6bone particpants met in Adelaide. The purpose of the meeting > > > was to expand and elaborate in person on the comments made by the > > > IAB/IETF/6bone concerning the existing policy document. > > > > > > One of the issues of concern that had been previously raised by > > > members is the size of the end-site prefix (the 'SLA ID', currently > > > defined in rfc2374 as 16 bits at a /48). This includes *all* types > > > of end-sites including a single device. A /48 is sufficient address > > > space to create 64K of subnets. > > > > > > The technical motivation for the 16 bit SLA ID field and the > > > 'one size fits all' principle was described in rfc2374 as: > > > > > > "The size of the Site-Level Aggregation Identifier field is 16 bits. > > > This supports 65,535 individual subnets per site. The design goal > > > for the size of this field was to be sufficient for all but the > > > largest of organizations. Organizations which need additional > > > subnets can arrange with the organization they are obtaining Internet > > > service from to obtain additional site identifiers and use this to > > > create additional subnets. > > > > > > The Site-Level Aggregation Identifier field was given a fixed size in > > > order to force the length of all prefixes identifying a particular > > > site to be the same length (i.e., 48 bits). This facilitates > > > movement of sites in the topology (e.g., changing service providers > > > and multi-homing to multiple service providers)." > > > > > > It is possible to imagine in future a variety of types of end-sites > > > being connected to the Internet. Some of these devices will be part > > > of routed networks and others will not. The question proposed is whether > > > 'one size fits all' (the /48) is appropriate for all end-sites? > > > > > > Both the RIPE and ARIN communities have rejected this. > > > > > > APNIC has been asked to consult with the Internet community in the > > > Asia Pacific on this issue. > > > > > > To date, there has been no consensus on what alternatives should be > > > taken, but 3 different approaches have been identified in addition to > > > the 16 bit SLA ID field specified in rfc2374. > > > > > > These are: > > > > > > 1) /64 for single devices (such as mobile phones), /48 for all other sites > > > > > > 2) /64 for single devices, /48 for large end sites which need more > > > than 256 subnets, and /56 for other sites (eg small, domestic/home sites) > > > > > > 3) Assign what is needed for the forseeable needs of the site, as a > > > variable-length prefix of between /48 and /64. (It is important to > > > remember that for any site that becomes multi-homed it is necessary to > > > use equal length prefixes from each provider even in the case where > > > one provider has allocated more prefix space than the other). > > > > > > We are interested in your opinions, so that we may convey this to the > > > other RIRs and to the IETF community. Please direct all follow up > > > discussion and comments to . For details of > > > how to subscribe to this mailing list, please visit our web site at: > > > http://www.apnic.net/general.html#mailing-lists . > > > > > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > > > APNIC Secretariat > > > > > > Tel: +61-7-3367-0490 > > > Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 > > > Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia > > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > > > > > > * APNIC-ANNOUNCE: Announcements concerning APNIC * > > > * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * > > > > -- > > ------------------------------------------------------------------------ > > Stephen Burley "If patience is a virtue, and ignorance is bliss, > > UUNET EMEA Hostmaster you can have a pretty good life > > Stephenb@uk.uu.net if you're stupid and willing to wait" > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------ ------_=_NextPart_001_01BFE80B.FC30E3D0 Content-Type: text/html RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision

VERY true IMO



Call me oldfashioned but i remember when people thought we had enough
space in IPv4
and it would never run out. If you fix the boundry at a /48 it means an
ISP will go
through their block of addresses way too fast. It also means that out
customers do
not have to think about what they are deploying as they know they will
get a /48 no
matter what. So a flexible boundry between /48 and /64 would help us to
help
customers to think about how they will deploy their address space. A /64
for dialup
is also too rigid because the way technology is going a /64 is not going
to be
enough subnets for what wiill be a dial up connection with a large lan
behind it.

Just my thoughts.





>
>    Brian
>
> Stephen Burley wrote:
> >
> > "Kazu Yamamoto ($B;3K\OBI'(B)" wrote:
> >
> > > Folks,
> > >
> > > It seems to me that RTRs are going a wrong way, changing /48 per
site
> > > policy. If you think so, please speak up on sig-ipv6@apnic.net
now.
> > >
> > > --Kazu
> >
> > Hi
> >     We discussed it at length in the RIPE 36 meeting and the
majority not all
> > were not in favour of not fixing the boundries but rather allowing
the LIR to
> > decide on merit/justification what amount of space to assign whithin
the /48 -
> > /64 boundries. If we fixit to /48 /56 /64 boundries it becomes too
rigid, allow
> >
> > the LIR's to dictate their own assignment policy (ie flexible or
fixed at 3
> > points /48 /56 /64) which they can justify to the RIR, in this way
it pleases
> > everyone - i garuntee if you fix the boundries it will have to be
re-addrressed
> >
> > later on and will not please all.
> >
> > My thoughts
> > Stephen Burley
> > UUNET EMEA Hostmaster
> >
> > >
> > >
> > >
------------------------------------------------------------------------
> > >
> > > Subject: [apnic-announce] IPv6 Policy Document Revision
> > > Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST)
> > > From: secretariat@apnic.net
> > > Reply-To: apnic-talk@apnic.net
> > > To: apnic-announce@lists.apnic.net
> > >
> > > [Note "reply-to:" field]
> > >
> > > Summary
> > >
> > > Both ARIN and the RIPE NCC have had discussions with the Internet
> > > communities in their region concerning the size of address
prefixes
> > > to be assigned to IPv6 end sites.  APNIC is now seeking input from
> > > the community in the Asia Pacific region on this issue. If you
care
> > > about this, please read on.
> > >
> > > Some background
> > >
> > > The existing IPv6 policy document 'Provisional IPv6 Assignment and
> > > Allocation Policy Document' was published in May 1999. Formal
revision
> > > of the document commenced in October 1999. The existing document
> > > is available at:
> > >
> > > http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html
> > >
> > > Feedback on the existing document was collected from the Internet
community
> > > at large facilitated through the regional processes of
consultation by
> > > the RIRs as well as input from the membership of the 6bone and the
> > > IETF IPv6 working groups. The deadline for comments was 31st
January 2000.
> > >
> > > On 29th March, the RIRs, chairs of the IPv6 related IETF working
> > > groups and 6bone particpants met in Adelaide. The purpose of the
meeting
> > > was to expand and elaborate in person on the comments made by the
> > > IAB/IETF/6bone concerning the existing policy document.
> > >
> > > One of the issues of concern that had been previously raised by
> > > members is the size of the end-site prefix (the 'SLA ID',
currently
> > > defined in rfc2374 as 16 bits at a /48). This includes *all* types
> > > of end-sites including a single device. A /48 is sufficient
address
> > > space to create 64K of subnets.
> > >
> > > The technical motivation for the 16 bit SLA ID field and the
> > > 'one size fits all' principle was described in rfc2374 as:
> > >
> > >   "The size of the Site-Level Aggregation Identifier field is 16
bits.
> > >    This supports 65,535 individual subnets per site.  The design
goal
> > >    for the size of this field was to be sufficient for all but the
> > >    largest of organizations.  Organizations which need additional
> > >    subnets can arrange with the organization they are obtaining
Internet
> > >    service from to obtain additional site identifiers and use this
to
> > >    create additional subnets.
> > >
> > >    The Site-Level Aggregation Identifier field was given a fixed
size in
> > >    order to force the length of all prefixes identifying a
particular
> > >    site to be the same length (i.e., 48 bits).  This facilitates
> > >    movement of sites in the topology (e.g., changing service
providers
> > >    and multi-homing to multiple service providers)."
> > >
> > > It is possible to imagine in future a variety of types of
end-sites
> > > being connected to the Internet.  Some of these devices will be
part
> > > of routed networks and others will not.  The question proposed is
whether
> > > 'one size fits all' (the /48) is appropriate for all end-sites?
> > >
> > > Both the RIPE and ARIN communities have rejected this.
> > >
> > > APNIC has been asked to consult with the Internet community in the
> > > Asia Pacific on this issue.
> > >
> > > To date, there has been no consensus on what alternatives should
be
> > > taken, but 3 different approaches have been identified in addition
to
> > > the 16 bit SLA ID field specified in rfc2374.
> > >
> > > These are:
> > >
> > > 1) /64 for single devices (such as mobile phones), /48 for all
other sites
> > >
> > > 2) /64 for single devices, /48 for large end sites which need more
> > >    than 256 subnets, and /56 for other sites (eg small,
domestic/home sites)
> > >
> > > 3) Assign what is needed for the forseeable needs of the site, as
a
> > >    variable-length prefix of between /48 and /64. (It is important
to
> > >    remember that for any site that becomes multi-homed it is
necessary to
> > >    use equal length prefixes from each provider even in the case
where
> > >    one provider has allocated more prefix space than the other).
> > >
> > > We are interested in your opinions, so that we may convey this to
the
> > > other RIRs and to the IETF community. Please direct all follow up
> > > discussion and comments to <sig-ipv6@apnic.net>. For details of
> > > how to subscribe to this mailing list, please visit our web site
at:
> > > http://www.apnic.net/general.html#mailing-lists .
> > >
> > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + +
> > > APNIC Secretariat
> > > <secretariat@apnic.net>
> > >                                                      Tel:
+61-7-3367-0490
> > > Asia Pacific Network Information Centre (APNIC) Ltd  Fax:
+61-7-3367-0482
> > > Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia
> > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + +
> > >
> > > *            APNIC-ANNOUNCE: Announcements concerning APNIC
*
> > > * To unsubscribe, send "unsubscribe" to
apnic-announce-request@apnic.net *
> >
> > --
> >
------------------------------------------------------------------------
> > Stephen Burley         "If patience is a virtue, and ignorance is
bliss,
> > UUNET EMEA Hostmaster            you can have a pretty good life
> > Stephenb@uk.uu.net            if you're stupid and willing to wait"
> >
------------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPng Working Group Mailing List
> > IPng Home Page:                     http://playground.sun.com/ipng
> > FTP archive:                     ftp://playground.sun.com/pub/ipng
> > Direct all administrative requests to majordomo@sunroof.eng.sun.com
> > --------------------------------------------------------------------

--
------------------------------------------------------------------------
Stephen Burley         "If patience is a virtue, and ignorance is bliss,
UUNET EMEA Hostmaster            you can have a pretty good life
[SB855-RIPE]                 if you're stupid and willing to wait"
------------------------------------------------------------------------


------_=_NextPart_001_01BFE80B.FC30E3D0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 05:58:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67Cuqw26626 for ipng-dist; Fri, 7 Jul 2000 05:56:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67Cuf626619; Fri, 7 Jul 2000 05:56:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA07249; Fri, 7 Jul 2000 05:56:41 -0700 (PDT) Received: from roam.psg.com (cnri-2-112.cnri.reston.va.us [132.151.2.112]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA15338; Fri, 7 Jul 2000 05:56:41 -0700 (PDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13AXgH-0001FT-00; Fri, 07 Jul 2000 08:56:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Francis Dupont Cc: Brian E Carpenter , stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <3964DE58.7DB92581@hursley.ibm.com> <200007070722.JAA52803@givry.rennes.enst-bretagne.fr> Message-Id: Date: Fri, 07 Jul 2000 08:56:33 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => many ISPs want to allocate /64 (or worse) to their customers... and > shout a /48 per customer is far too large. I believe this is a consequence > of the slow^N start, ie. the /35 rule (RIRs trim address space of ISPs, > ISPs take back the burden to their customers). someone who gets it! the /35 game sucks. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 08:01:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67Ewx226809 for ipng-dist; Fri, 7 Jul 2000 07:58:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67Evf626787; Fri, 7 Jul 2000 07:57:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA06030; Fri, 7 Jul 2000 07:57:40 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03473; Fri, 7 Jul 2000 08:57:39 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id HAA12583; Fri, 7 Jul 2000 07:49:47 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Fri, 7 Jul 2000 07:51:19 -0700 To: Tim Chown From: Steve Deering Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Cc: Francis Dupont , Brian E Carpenter , stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:57 PM +0100 7/7/00, Tim Chown wrote: >In the case of a national educational network (my particular interest) >we currently have just 13 bits of network space to allocate to >institutions, if the institutions (Universities) get a /48 each. Tim, /48 was intended to be the *minimum* allocation to a subscriber's site, not the *maximum*. Those exceptional subscribers for whom a /48 is too small are free to request larger blocks from their ISPs. >At the same time it is bizarre that a University might get the same address >space as a small end customer. It's only "bizarre" if address space is a scarce resource; the purpose and design of IPv6 was to make it a non-scarce resource. >The last thing we want is end users running IPv6 NAT. I think (hope) we all agree on that, and that is one of the reasons to oppose variable-length allocations to (all but the largest) subscribers. IPv4 history indicates that ISPs would charge more money for shorter prefixes, thus creating an economic incentive for many customers to buy only the smallest amount of address space and use a NAT to expand it locally. 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 Jul 7 08:34:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67FWKE26937 for ipng-dist; Fri, 7 Jul 2000 08:32:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67FWB626930; Fri, 7 Jul 2000 08:32:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA13744; Fri, 7 Jul 2000 08:32:10 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08247; Fri, 7 Jul 2000 08:32:07 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id QAA173712; Fri, 7 Jul 2000 16:31:06 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id QAA21864; Fri, 7 Jul 2000 16:31:15 +0100 (BST) Message-ID: <3965F75D.E9B4FF6A@hursley.ibm.com> Date: Fri, 07 Jul 2000 10:29:33 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Stephen Burley CC: Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> <3965A5F0.8505E7BA@uk.uu.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen Burley wrote: > > Brian E Carpenter wrote: > > > Stephen, > > > > Can you explain why people think there is any need to allocate anything > > longer than a /48 in the first place? > > > > Call me oldfashioned but i remember when people thought we had enough space in IPv4 > and it would never run out. If you fix the boundry at a /48 it means an ISP will go > through their block of addresses way too fast. Please define "way too fast" in terms of a world population of say 15 billion people, compared with the number of /48s available. > It also means that out customers do > not have to think about what they are deploying as they know they will get a /48 no > matter what. Indeed. This would be a *big* advantage. Why do think it is a problem? > So a flexible boundry between /48 and /64 would help us to help > customers to think about how they will deploy their address space. But it will also set us back by ten years in route aggregation. > A /64 for dialup > is also too rigid because the way technology is going a /64 is not going to be > enough subnets for what wiill be a dial up connection with a large lan behind it. Indeed. But that isn't an issue the RIRs need to think about. 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 Jul 7 09:00:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67FwDm27040 for ipng-dist; Fri, 7 Jul 2000 08:58:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67Fux627018; Fri, 7 Jul 2000 08:56:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA00336; Fri, 7 Jul 2000 08:56:58 -0700 (PDT) Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23902; Fri, 7 Jul 2000 08:56:57 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id JAA01092; Fri, 7 Jul 2000 09:56:23 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200007071556.JAA01092@hunkular.glarp.com> To: Steve Deering cc: Tim Chown , Francis Dupont , Brian E Carpenter , stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: Your message of "Fri, 07 Jul 2000 07:51:19 PDT." Date: Fri, 07 Jul 2000 09:56:23 -0600 From: Brad Huntting Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It's only "bizarre" if address space is a scarce resource; the purpose and > design of IPv6 was to make it a non-scarce resource. IMHO, the problem lies with using /64 for the default subnet size; /80 would probably be more than enough for any conceivable "layer 2" protocol. brad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 09:19:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67GHab27119 for ipng-dist; Fri, 7 Jul 2000 09:17:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67GGG627094; Fri, 7 Jul 2000 09:16:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA05629; Fri, 7 Jul 2000 09:16:16 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA05783; Fri, 7 Jul 2000 09:16:11 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA29127; Sat, 8 Jul 2000 02:15:58 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Brad Huntting Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: Your message of "Fri, 07 Jul 2000 09:56:23 CST." <200007071556.JAA01092@hunkular.glarp.com> Date: Sat, 08 Jul 2000 02:15:57 +1000 Message-Id: <16970.962986557@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 07 Jul 2000 09:56:23 -0600 From: Brad Huntting Message-ID: <200007071556.JAA01092@hunkular.glarp.com> | IMHO, the problem lies with using /64 for the default subnet size; There is no real "problem". No-one who has ever actually looked at the numbers believes there is a problem with /48 allocations to sites (though I personally have no problem considering a pool of dial in users to be a single site if they have no need for more than a /64 each). The "we have to conserve those 2^48 numbers" comes from the same kind of philosophy as the people who bought a 2 bedroom house, then had 3 kids, and all of them had to share a bedroom. That was a problem, so then they bought a 500 room hotel - but still made the kids share a room, because they ran out before, and they were going to make certain that would never happen again. | /80 would probably be more than enough for any conceivable "layer | 2" protocol. Except that IEEE has created 64 bit MAC identifiers for use by its new protocols, and /80 would kill easy autoconf. For sure, /80 (even /96) leaves way too many addresses for any conceivable subnet to ever use them all - but making things fit in less is more work that it is worth. 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 Jul 7 09:26:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67GPWu27177 for ipng-dist; Fri, 7 Jul 2000 09:25:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67GPM627170; Fri, 7 Jul 2000 09:25:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA13536; Fri, 7 Jul 2000 09:25:21 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11039; Fri, 7 Jul 2000 09:25:20 -0700 (PDT) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA22528; Fri, 7 Jul 2000 17:25:09 +0100 (BST) Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id RAA26604; Fri, 7 Jul 2000 17:25:08 +0100 (BST) Date: Fri, 7 Jul 2000 17:25:08 +0100 (BST) From: Tim Chown To: Steve Deering cc: Francis Dupont , Brian E Carpenter , stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 7 Jul 2000, Steve Deering wrote: > /48 was intended to be the *minimum* allocation to a subscriber's site, not > the *maximum*. Those exceptional subscribers for whom a /48 is too small > are free to request larger blocks from their ISPs. But that's where the /35 "pressure" applies because if (say) UKERNA wanted to offer a /40 to each University it would at present be looking at being able to connect just 32 Universities. By 2001 there will be over 800 University and further education colleges online under the UK JANET network. Of course they're not all big, varying from maybe 4,000 to 40,000 people, so most could live under a /48. At least with the current technology that lives around us. I would be interested to know what the addressing requirements of a mobile provider would be, in terms of scale and subnetting. What would the "home prefix" of 1,000,000 Vodaphone customers be, for example? I've not yet seen a draft IPv6 allocation policy for a mobile provider. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 09:45:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67GhQq27260 for ipng-dist; Fri, 7 Jul 2000 09:43:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67GhG627253; Fri, 7 Jul 2000 09:43:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25513; Fri, 7 Jul 2000 09:43:15 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21852; Fri, 7 Jul 2000 09:43:13 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA21626; Fri, 7 Jul 2000 17:42:15 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA24104; Fri, 7 Jul 2000 17:42:25 +0100 (BST) Message-ID: <39660803.C8EECA45@hursley.ibm.com> Date: Fri, 07 Jul 2000 11:40:35 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Tim Chown CC: Steve Deering , Francis Dupont , stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: ... > I would be interested to know what the addressing requirements of a mobile > provider would be, in terms of scale and subnetting. What would the > "home prefix" of 1,000,000 Vodaphone customers be, for example? I've > not yet seen a draft IPv6 allocation policy for a mobile provider. Good question but it's certainly not a problem unless needlessly restrictive allocation policies make it so. 1M is a small number in IPv6 land. 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 Jul 7 09:48:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67GlAc27312 for ipng-dist; Fri, 7 Jul 2000 09:47:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67Gjo627277; Fri, 7 Jul 2000 09:45:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA18008; Fri, 7 Jul 2000 09:45:45 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17508; Fri, 7 Jul 2000 10:45:43 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id BAA14012; Sat, 8 Jul 2000 01:45:41 +0900 (JST) To: Tim Chown cc: Steve Deering , Francis Dupont , Brian E Carpenter , stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net In-reply-to: tjc's message of Fri, 07 Jul 2000 17:25:08 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision From: itojun@iijlab.net Date: Sat, 08 Jul 2000 01:45:41 +0900 Message-ID: <14010.962988341@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> /48 was intended to be the *minimum* allocation to a subscriber's site, not >> the *maximum*. Those exceptional subscribers for whom a /48 is too small >> are free to request larger blocks from their ISPs. >But that's where the /35 "pressure" applies because if (say) UKERNA wanted >to offer a /40 to each University it would at present be looking at being >able to connect just 32 Universities. By 2001 there will be over 800 >University and further education colleges online under the UK JANET network. While I understand the problem you have, I would like t know why you'd like to offer /40 to every universities. Are there any reason not to do /48 for universities, or couple of /48s? We (WIDE) offer /48 for leaf sites (an organization which has no plan to have sub-organization, i.e. universities and companies, not an ISP), and /40 to non-leaf downstream sites (an organization which has plan t have sub-organization, i.e. an ISP). Once a leaf site use up /48, they'd be able to get another /48 from us. Until now we saw no problem with it. "/48 allocation to everyone" is just fine for me (or us). We cannot predict the future growth of leaf site. We don't want to, we don't need to. SOHO can evolve into multinational company. We have more important problem to tackle. The problem lies elsewhere, I believe. Once our network grows into /29, and to /16, we'd need to carry 2^(48-29) or 2^(48-16) routes in a TLA. It's like having the whole IPv4 space in one ISP. We need to have a very careful plan on inner-TLA topology, so that we can aggregate internal routes nicely. We may need more experiences/standards in hierarchical interior routing operation. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 09:51:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67Gnhi27377 for ipng-dist; Fri, 7 Jul 2000 09:49:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67GmW627330; Fri, 7 Jul 2000 09:48:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA27157; Fri, 7 Jul 2000 09:48:31 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA19516; Fri, 7 Jul 2000 10:48:27 -0600 (MDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA29554; Sat, 8 Jul 2000 02:48:11 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Tim Chown Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: Your message of "Fri, 07 Jul 2000 17:25:08 +0100." Date: Sat, 08 Jul 2000 02:48:10 +1000 Message-Id: <17347.962988490@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 7 Jul 2000 17:25:08 +0100 (BST) From: Tim Chown Message-ID: | But that's where the /35 "pressure" applies because if (say) UKERNA wanted | to offer a /40 to each University Why would i want to do that? /48 to everyone is what should be offered. If a site is truly *huge* (that is, is so big an IPv4 class A net isn't enough for it) then perhaps it gets a /47 - or even a /46. Why would anyone routinely be allocating /40? | Of course they're not all big, varying from maybe 4,000 to 40,000 people, | so most could live under a /48. All of those could live in a /48. | I would be interested to know what the addressing requirements of a mobile | provider would be, in terms of scale and subnetting. If one assumes (which would probably be wrong) that all the mobile nodes are sharing some kind of switched link level, then one /64 would be enough for all of that ... Of course, that would make for pretty huge tables, so some degree of subnetting might be appropriate. But a /48 is probably going to be enough, even for that size site. And of course, some of the mobiles might be gateways to other local nets in which case those nets would be getting their own /48 (or if they really don't need it, perhaps just /64). 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 Jul 7 09:59:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67GvL727499 for ipng-dist; Fri, 7 Jul 2000 09:57:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67Gu2627468; Fri, 7 Jul 2000 09:56:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA28981; Fri, 7 Jul 2000 09:56:01 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00072; Fri, 7 Jul 2000 09:56:00 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id BAA14149; Sat, 8 Jul 2000 01:55:58 +0900 (JST) To: Kazu Yamamoto (=?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net In-reply-to: kazu's message of Thu, 06 Jul 2000 17:27:14 JST. <20000706.172714.91311805.kazu@Mew.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision From: itojun@iijlab.net Date: Sat, 08 Jul 2000 01:55:58 +0900 Message-ID: <14147.962988958@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry for too much cross-posting. I think the following part in the APNIC text is slightly unclear. >These are: >1) /64 for single devices (such as mobile phones), /48 for all other sites >2) /64 for single devices, /48 for large end sites which need more > than 256 subnets, and /56 for other sites (eg small, domestic/home sites) Does /64 mean "address behind the device", or "address for the ppp link"? (1) (2) ISP router ISP router |link local only |link local and global | | <--- /64 is here |link local only |link local and global customer router customer device |link local and global ==+=== <--- /64 is here Note that it is legal and possible to run routing protocol on diagram (1). All of IPv6 routing protocol is written this way (and static routing is possible too). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 09:59:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67GwJ827521 for ipng-dist; Fri, 7 Jul 2000 09:58:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67Gvs627501; Fri, 7 Jul 2000 09:57:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA29549; Fri, 7 Jul 2000 09:57:53 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01241; Fri, 7 Jul 2000 09:57:52 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id SAA18164; Fri, 7 Jul 2000 18:57:50 +0200 (MET DST) Date: Fri, 7 Jul 2000 18:57:50 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Message-ID: <20000707185750.C25625@theory.cs.uni-bonn.de> References: <200007071556.JAA01092@hunkular.glarp.com> <16970.962986557@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <16970.962986557@mundamutti.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Sat, Jul 08, 2000 at 02:15:57AM +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Jul 08, 2000 at 02:15:57AM +1000, Robert Elz wrote: > Except that IEEE has created 64 bit MAC identifiers for use by its > new protocols, and /80 would kill easy autoconf. Of course. > For sure, /80 > (even /96) leaves way too many addresses for any conceivable subnet > to ever use them all - For traditional subnets, you're right, but... assuming everybody could afford (at least) on phone, IP(v6) over the NMBA network called "the world-wide phone system" already would need more then 2^32 addresses, right? /80 would be a problem even for all phones in Germany. Regards, Ignatios -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 10:04:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67H3aw27580 for ipng-dist; Fri, 7 Jul 2000 10:03:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67H3R627573; Fri, 7 Jul 2000 10:03:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA01076; Fri, 7 Jul 2000 10:03:26 -0700 (PDT) From: Ronald.vanderPol@surfnet.nl Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01328; Fri, 7 Jul 2000 11:03:24 -0600 (MDT) Received: from spock.ncc-1701.surfnet.nl ([192.87.111.34]) by survis.surfnet.nl with ESMTP (exPP) id 13AbX7-0005Fo-00; Fri, 7 Jul 2000 19:03:22 +0200 Date: Fri, 7 Jul 2000 19:04:47 +0200 (CEST) X-Sender: rvdp@spock.ncc-1701.surfnet.nl To: Robert Elz cc: Tim Chown , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: <17347.962988490@mundamutti.cs.mu.OZ.AU> Message-ID: Organisation: SURFnet bv Address: "Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL" Phone: +31 302 305 305 Telefax: +31 302 305 329 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 8 Jul 2000, Robert Elz wrote: >| But that's where the /35 "pressure" applies because if (say) UKERNA wanted >| to offer a /40 to each University > > Why would i want to do that? /48 to everyone is what should be offered. A university might have a dialup service for its employees and students. I think they should get a /48 at home. So the university needs many /48s. With a /40 they can have no more than 256 students/employees :-) rvdp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 10:07:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67H5Lc27622 for ipng-dist; Fri, 7 Jul 2000 10:05:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67H4k627598; Fri, 7 Jul 2000 10:04:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA23159; Fri, 7 Jul 2000 10:04:45 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05632; Fri, 7 Jul 2000 10:04:44 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id TAA20679; Fri, 7 Jul 2000 19:04:34 +0200 (MET DST) Date: Fri, 7 Jul 2000 19:04:34 +0200 From: Ignatios Souvatzis To: Tim Chown Cc: Steve Deering , Francis Dupont , Brian E Carpenter , stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Message-ID: <20000707190434.D25625@theory.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from tjc@ecs.soton.ac.uk on Fri, Jul 07, 2000 at 05:25:08PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Jul 07, 2000 at 05:25:08PM +0100, Tim Chown wrote: > On Fri, 7 Jul 2000, Steve Deering wrote: > > > /48 was intended to be the *minimum* allocation to a subscriber's site, not > > the *maximum*. Those exceptional subscribers for whom a /48 is too small > > are free to request larger blocks from their ISPs. > > But that's where the /35 "pressure" applies because if (say) UKERNA wanted > to offer a /40 to each University it would at present be looking at being > able to connect just 32 Universities. Hm... but... a /48 (2^16 networks) is already more than any University (I know of) has today in v4-land. This will allow for quite some growth. So there is no need to given them a /40 _now_. Sparsely - allocated /48 are fine, can be extended if needed, unless filled up, in which case renumbering is easy. At least much easier than in v4-world. Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 10:23:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67HLk127766 for ipng-dist; Fri, 7 Jul 2000 10:21:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67HLS627750; Fri, 7 Jul 2000 10:21:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA25895; Fri, 7 Jul 2000 10:21:27 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16913; Fri, 7 Jul 2000 10:21:25 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id TAA25495; Fri, 7 Jul 2000 19:17:48 +0200 (MET DST) Date: Fri, 7 Jul 2000 19:17:48 +0200 From: Ignatios Souvatzis To: Ronald.vanderPol@surfnet.nl Cc: Robert Elz , Tim Chown , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Message-ID: <20000707191748.A24200@theory.cs.uni-bonn.de> References: <17347.962988490@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from Ronald.vanderPol@surfnet.nl on Fri, Jul 07, 2000 at 07:04:47PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Jul 07, 2000 at 07:04:47PM +0200, Ronald.vanderPol@surfnet.nl wrote: > On Sat, 8 Jul 2000, Robert Elz wrote: > > >| But that's where the /35 "pressure" applies because if (say) UKERNA wanted > >| to offer a /40 to each University > > > > Why would i want to do that? /48 to everyone is what should be offered. > > A university might have a dialup service for its employees and students. > I think they should get a /48 at home. So the university needs many /48s. > With a /40 they can have no more than 256 students/employees :-) Not necessarily. They would be counted as part of the site, and get less than a /48. However, assuming all of them are connected at the same time (!!!), /48 would not be enough, and they'd need something bigger, maybe a /44. Regards, -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 10:44:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67HgX027814 for ipng-dist; Fri, 7 Jul 2000 10:42:33 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67HgP627807 for ; Fri, 7 Jul 2000 10:42:25 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05753 for ipng@sunroof.eng.sun.com; Fri, 7 Jul 2000 10:40:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e678E8626291; Fri, 7 Jul 2000 01:14:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA01865; Fri, 7 Jul 2000 01:14:05 -0700 (PDT) From: matthew.ford@bt.com Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03980; Fri, 7 Jul 2000 01:14:03 -0700 (PDT) Received: from cbtlipnt01.btlabs.bt.co.uk by gollum (local) with ESMTP; Fri, 7 Jul 2000 09:14:20 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLQPGR0>; Fri, 7 Jul 2000 09:13:07 +0100 Message-ID: To: Francis.Dupont@enst-bretagne.fr Cc: stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net, brian@hursley.ibm.com, jonathan.2.stevens@bt.com, peter.hovell@bt.com Subject: RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Date: Fri, 7 Jul 2000 09:12:38 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If /56 can be agreed upon as a default then that is not too bad IMO. However, the RIRs seem to be veering towards allowing LIRs to allocate whatever they choose between /48 and /64 - a movable boundary which will scupper the technical objectives of multihoming and simplified site-renumbering. I believe the idea of a movable boundary should be strongly opposed for this reason. Regards, Mat Ford. -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] Sent: 07 July 2000 08:22 To: Brian E Carpenter Cc: stephenb@uk.uu.net; ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com; arano@byd.ocn.ad.jp; sig-ipv6@apnic.net; mir@ripe.net; joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In your previous mail you wrote: Can you explain why people think there is any need to allocate anything longer than a /48 in the first place? => many ISPs want to allocate /64 (or worse) to their customers... and shout a /48 per customer is far too large. I believe this is a consequence of the slow^N start, ie. the /35 rule (RIRs trim address space of ISPs, ISPs take back the burden to their customers). The idea is to introduce a small site (/56) for "poor & little" customers and to make it the *default* allocation. IMHO this is an acceptable target. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 10:46:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67Hih427834 for ipng-dist; Fri, 7 Jul 2000 10:44:43 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67HiX627826 for ; Fri, 7 Jul 2000 10:44:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05782 for ipng@sunroof.eng.sun.com; Fri, 7 Jul 2000 10:43:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e678hS626386 for ; Fri, 7 Jul 2000 01:43:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA24638 for ; Fri, 7 Jul 2000 01:43:26 -0700 (PDT) Received: from boat.mail.pipex.net (our.mail.pipex.net [158.43.128.75]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA24952 for ; Fri, 7 Jul 2000 02:43:26 -0600 (MDT) Received: (qmail 28071 invoked from network); 7 Jul 2000 08:43:25 -0000 Received: from mailhost.puck.pipex.net (HELO mailhost.uk.internal) (194.130.147.54) by our.mail.pipex.net with SMTP; 7 Jul 2000 08:43:25 -0000 Received: (qmail 7831 invoked from network); 7 Jul 2000 08:43:19 -0000 Received: from merlin.cam.uk.internal (HELO uk.uu.net) (172.31.3.9) by mailhost.uk.internal with SMTP; 7 Jul 2000 08:43:19 -0000 Message-ID: <3965A5F0.8505E7BA@uk.uu.net> Date: Fri, 07 Jul 2000 09:42:08 +0000 From: Stephen Burley Reply-To: stephenb@uk.uu.net Organization: UUNET X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Stephen, > > Can you explain why people think there is any need to allocate anything > longer than a /48 in the first place? > Call me oldfashioned but i remember when people thought we had enough space in IPv4 and it would never run out. If you fix the boundry at a /48 it means an ISP will go through their block of addresses way too fast. It also means that out customers do not have to think about what they are deploying as they know they will get a /48 no matter what. So a flexible boundry between /48 and /64 would help us to help customers to think about how they will deploy their address space. A /64 for dialup is also too rigid because the way technology is going a /64 is not going to be enough subnets for what wiill be a dial up connection with a large lan behind it. Just my thoughts. > > Brian > > Stephen Burley wrote: > > > > "Kazu Yamamoto ($B;3K\OBI'(B)" wrote: > > > > > Folks, > > > > > > It seems to me that RTRs are going a wrong way, changing /48 per site > > > policy. If you think so, please speak up on sig-ipv6@apnic.net now. > > > > > > --Kazu > > > > Hi > > We discussed it at length in the RIPE 36 meeting and the majority not all > > were not in favour of not fixing the boundries but rather allowing the LIR to > > decide on merit/justification what amount of space to assign whithin the /48 - > > /64 boundries. If we fixit to /48 /56 /64 boundries it becomes too rigid, allow > > > > the LIR's to dictate their own assignment policy (ie flexible or fixed at 3 > > points /48 /56 /64) which they can justify to the RIR, in this way it pleases > > everyone - i garuntee if you fix the boundries it will have to be re-addrressed > > > > later on and will not please all. > > > > My thoughts > > Stephen Burley > > UUNET EMEA Hostmaster > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > Subject: [apnic-announce] IPv6 Policy Document Revision > > > Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST) > > > From: secretariat@apnic.net > > > Reply-To: apnic-talk@apnic.net > > > To: apnic-announce@lists.apnic.net > > > > > > [Note "reply-to:" field] > > > > > > Summary > > > > > > Both ARIN and the RIPE NCC have had discussions with the Internet > > > communities in their region concerning the size of address prefixes > > > to be assigned to IPv6 end sites. APNIC is now seeking input from > > > the community in the Asia Pacific region on this issue. If you care > > > about this, please read on. > > > > > > Some background > > > > > > The existing IPv6 policy document 'Provisional IPv6 Assignment and > > > Allocation Policy Document' was published in May 1999. Formal revision > > > of the document commenced in October 1999. The existing document > > > is available at: > > > > > > http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html > > > > > > Feedback on the existing document was collected from the Internet community > > > at large facilitated through the regional processes of consultation by > > > the RIRs as well as input from the membership of the 6bone and the > > > IETF IPv6 working groups. The deadline for comments was 31st January 2000. > > > > > > On 29th March, the RIRs, chairs of the IPv6 related IETF working > > > groups and 6bone particpants met in Adelaide. The purpose of the meeting > > > was to expand and elaborate in person on the comments made by the > > > IAB/IETF/6bone concerning the existing policy document. > > > > > > One of the issues of concern that had been previously raised by > > > members is the size of the end-site prefix (the 'SLA ID', currently > > > defined in rfc2374 as 16 bits at a /48). This includes *all* types > > > of end-sites including a single device. A /48 is sufficient address > > > space to create 64K of subnets. > > > > > > The technical motivation for the 16 bit SLA ID field and the > > > 'one size fits all' principle was described in rfc2374 as: > > > > > > "The size of the Site-Level Aggregation Identifier field is 16 bits. > > > This supports 65,535 individual subnets per site. The design goal > > > for the size of this field was to be sufficient for all but the > > > largest of organizations. Organizations which need additional > > > subnets can arrange with the organization they are obtaining Internet > > > service from to obtain additional site identifiers and use this to > > > create additional subnets. > > > > > > The Site-Level Aggregation Identifier field was given a fixed size in > > > order to force the length of all prefixes identifying a particular > > > site to be the same length (i.e., 48 bits). This facilitates > > > movement of sites in the topology (e.g., changing service providers > > > and multi-homing to multiple service providers)." > > > > > > It is possible to imagine in future a variety of types of end-sites > > > being connected to the Internet. Some of these devices will be part > > > of routed networks and others will not. The question proposed is whether > > > 'one size fits all' (the /48) is appropriate for all end-sites? > > > > > > Both the RIPE and ARIN communities have rejected this. > > > > > > APNIC has been asked to consult with the Internet community in the > > > Asia Pacific on this issue. > > > > > > To date, there has been no consensus on what alternatives should be > > > taken, but 3 different approaches have been identified in addition to > > > the 16 bit SLA ID field specified in rfc2374. > > > > > > These are: > > > > > > 1) /64 for single devices (such as mobile phones), /48 for all other sites > > > > > > 2) /64 for single devices, /48 for large end sites which need more > > > than 256 subnets, and /56 for other sites (eg small, domestic/home sites) > > > > > > 3) Assign what is needed for the forseeable needs of the site, as a > > > variable-length prefix of between /48 and /64. (It is important to > > > remember that for any site that becomes multi-homed it is necessary to > > > use equal length prefixes from each provider even in the case where > > > one provider has allocated more prefix space than the other). > > > > > > We are interested in your opinions, so that we may convey this to the > > > other RIRs and to the IETF community. Please direct all follow up > > > discussion and comments to . For details of > > > how to subscribe to this mailing list, please visit our web site at: > > > http://www.apnic.net/general.html#mailing-lists . > > > > > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > > > APNIC Secretariat > > > > > > Tel: +61-7-3367-0490 > > > Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 > > > Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia > > > + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + > > > > > > * APNIC-ANNOUNCE: Announcements concerning APNIC * > > > * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * > > > > -- > > ------------------------------------------------------------------------ > > Stephen Burley "If patience is a virtue, and ignorance is bliss, > > UUNET EMEA Hostmaster you can have a pretty good life > > Stephenb@uk.uu.net if you're stupid and willing to wait" > > ------------------------------------------------------------------------ > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 10:46:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67Hifb27833 for ipng-dist; Fri, 7 Jul 2000 10:44:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67HiO627816 for ; Fri, 7 Jul 2000 10:44:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA03397 for ; Fri, 7 Jul 2000 10:44:23 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA02656 for ; Fri, 7 Jul 2000 11:44:22 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Jul 2000 10:44:20 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Fri, 7 Jul 2000 10:44:18 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81024E24D88@RED-MSG-50> From: Richard Draves To: "IPng List (E-mail)" Subject: RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Date: Fri, 7 Jul 2000 10:44:14 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > IMHO, the problem lies with using /64 for the default subnet size; I was thinking something similar... if an ISP gave me a /64, I would just modify the stateless addr conf code to allow it to be subnetted. Once you have code to support pseudo-random interface identifiers (for the privacy draft), allowing variable sized interface identifiers is pretty easy. 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 Jul 7 10:53:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67HpnN27912 for ipng-dist; Fri, 7 Jul 2000 10:51:49 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67Hpi627905 for ; Fri, 7 Jul 2000 10:51:44 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05812 for ipng@sunroof.eng.sun.com; Fri, 7 Jul 2000 10:50:18 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM (efra05-home.Germany.Sun.COM [129.157.43.5] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67BOI626520 for ; Fri, 7 Jul 2000 04:24:19 -0700 (PDT) Received: from vayne (muc-isdn-15 [129.157.164.115]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id NAA22464; Fri, 7 Jul 2000 13:24:13 +0200 (MET DST) Date: Fri, 7 Jul 2000 13:33:08 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: SVRLOC WG last call: draft-ietf-svrloc-ipv6-09.txt To: srvloc@srvloc.org, ipng@sunroof.eng.sun.com Cc: erik.guttman@germany.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following specification is in working group last call: Service Location Protocol Modifications for IPv6 draft-ietf-svrloc-ipv6-09.txt Please send comments before July 21, 2000. Of interest are rules which prevent the locations of services from being discovered where they cannot be reached. For example, a service with a link-local scope address can only be discovered on the same link. Since the specification concerns IPv6, the WG last call notice has been sent to the IPng list. Please reply to the SVRLOC WG list. Erik Guttman SVRLOC WG Chair -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 10:55:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67HrOh27947 for ipng-dist; Fri, 7 Jul 2000 10:53:24 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67HrH627940 for ; Fri, 7 Jul 2000 10:53:18 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05841 for ipng@sunroof.eng.sun.com; Fri, 7 Jul 2000 10:51:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67Cw7626629; Fri, 7 Jul 2000 05:58:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA19341; Fri, 7 Jul 2000 05:58:07 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA15870; Fri, 7 Jul 2000 05:58:06 -0700 (PDT) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA21372; Fri, 7 Jul 2000 13:57:31 +0100 (BST) Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id NAA22006; Fri, 7 Jul 2000 13:57:31 +0100 (BST) Date: Fri, 7 Jul 2000 13:57:30 +0100 (BST) From: Tim Chown To: Francis Dupont cc: Brian E Carpenter , stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: <200007070722.JAA52803@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Francis' comment on the /35 allocations. If the /29 allocations were made in full from the outset there would be less pressure at the other end... In the case of a national educational network (my particular interest) we currently have just 13 bits of network space to allocate to institutions, if the institutions (Universities) get a /48 each. At the same time it is bizarre that a University might get the same address space as a small end customer. It is also likely that some Universities will command more than one /48, particularly if highly distributed. If we have single (or multiple) subnets per room (at worst a cheap wireless access point per room), that /48 will look small very fast. At present, the foreseeable allocations seem to offer little room for the second-layer ISPs (e.g. the Universities). It's almost as if we're being painted into a corner by the initial 2001:: allocation and the committment (rightly or wrongly) by the registries to ensure there are only 8K (13 bits) of top level routes in the DFZ, while at the same time hedging their bets via the /35 strategy. The last thing we want is end users running IPv6 NAT. tim On Fri, 7 Jul 2000, Francis Dupont wrote: > In your previous mail you wrote: > > => many ISPs want to allocate /64 (or worse) to their customers... and > shout a /48 per customer is far too large. I believe this is a consequence > of the slow^N start, ie. the /35 rule (RIRs trim address space of ISPs, > ISPs take back the burden to their customers). > The idea is to introduce a small site (/56) for "poor & little" customers > and to make it the *default* allocation. IMHO this is an acceptable target. > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 11:04:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67I2Gx28094 for ipng-dist; Fri, 7 Jul 2000 11:02:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67I13628050; Fri, 7 Jul 2000 11:01:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA15589; Fri, 7 Jul 2000 11:01:01 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA11611; Fri, 7 Jul 2000 11:00:56 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA30400; Sat, 8 Jul 2000 04:00:43 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: Your message of "Fri, 07 Jul 2000 18:57:50 +0200." <20000707185750.C25625@theory.cs.uni-bonn.de> Date: Sat, 08 Jul 2000 04:00:43 +1000 Message-Id: <19698.962992843@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 7 Jul 2000 18:57:50 +0200 From: Ignatios Souvatzis Message-ID: <20000707185750.C25625@theory.cs.uni-bonn.de> This is a non-issue, because we're not doing this, but ... | assuming everybody could afford (at least) on phone, IP(v6) over the NMBA | network called "the world-wide phone system" already would need more then | 2^32 addresses, right? That's going to depend upon whether there is internal structure in that numbering, aside from what is in the phone numbers already. 2^32 is probably too small for that particular subnet, but ... | /80 would be a problem even for all phones in Germany. Germany really has more than 2^48 phones? Or even more than a 2^48 phone number space? That's a 15 (decimal) digit phone number space. In any case, the 2^64 space allocated for subnets is easily going to be big enough to map the POTS number space, should anyone actually want to do that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 7 11:08:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67I6Z828189 for ipng-dist; Fri, 7 Jul 2000 11:06:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67I4W628139; Fri, 7 Jul 2000 11:04:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA07963; Fri, 7 Jul 2000 11:04:31 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA13999; Fri, 7 Jul 2000 11:04:26 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA30462; Sat, 8 Jul 2000 04:03:55 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Ronald.vanderPol@surfnet.nl Cc: Tim Chown , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: Your message of "Fri, 07 Jul 2000 19:04:47 +0200." Date: Sat, 08 Jul 2000 04:03:55 +1000 Message-Id: <19742.962993035@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 7 Jul 2000 19:04:47 +0200 (CEST) From: Ronald.vanderPol@surfnet.nl Message-ID: | A university might have a dialup service for its employees and students. If they're really acting as an ISP, then they should be treated as an ISP, and get an ISP sized number space. On the other hand, many universities do this kind of thing now (in fact, I am using such a link right now) and the numbering is just taken from part of the university's number space . That should work just the same for IPv6. 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 Jul 7 11:16:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67IEcl28249 for ipng-dist; Fri, 7 Jul 2000 11:14:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67IET628242; Fri, 7 Jul 2000 11:14:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA24778; Fri, 7 Jul 2000 11:14:28 -0700 (PDT) Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20345; Fri, 7 Jul 2000 11:14:27 -0700 (PDT) Received: from [192.87.111.36] (helo=bones.ncc-1701.surfnet.nl) by survis.surfnet.nl with SMTP (exPP) id 13Acdt-0005PL-00; Fri, 7 Jul 2000 20:14:25 +0200 Date: Fri, 7 Jul 2000 20:09:41 +0200 (CDT) From: Ronald van der Pol To: Robert Elz cc: Tim Chown , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: <19742.962993035@mundamutti.cs.mu.OZ.AU> Message-ID: Organisation: SURFnet bv Address: "Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL" Phone: +31 302 305 305 Telefax: +31 302 305 329 X-X-Sender: rvdp@zuurtje.surfnet.nl MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 8 Jul 2000, Robert Elz wrote: > If they're really acting as an ISP, then they should be treated as > an ISP, and get an ISP sized number space. That is what Tim was saying. Universities might be assigned a /40. > On the other hand, many universities do this kind of thing now > (in fact, I am using such a link right now) and the numbering is > just taken from part of the university's number space . That > should work just the same for IPv6. Yes, it will work. But I think it's strange when you get a /48 from a commercial ISP and a longer prefix from your university. Maybe you will have both and have two (differently sized) prefixes. A nightmare! rvdp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 11:25:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67IN4Z28369 for ipng-dist; Fri, 7 Jul 2000 11:23:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67ILw628335; Fri, 7 Jul 2000 11:21:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA26774; Fri, 7 Jul 2000 11:21:58 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25095; Fri, 7 Jul 2000 11:21:55 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id NAA08379; Fri, 7 Jul 2000 13:21:54 -0500 (CDT) Message-Id: <200007071821.NAA08379@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net From: "Matt Crawford" Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-reply-to: Your message of Sat, 08 Jul 2000 02:15:57 +1000. <16970.962986557@mundamutti.cs.mu.OZ.AU> Date: Fri, 07 Jul 2000 13:21:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The question to answer is, for a liberal estimate of the number of "sites" required 50 years from now, how efficiently (how non-wastefully) do assignments need to be made to fit within available space? An extremely liberal estimate of the number of sites required would be one per person. Taking the upper range of the year 2050 population projection from http://www.popin.org/pop1998/ ... World population currently stands at 5.9 billion persons and is growing at 1.33 per cent per year, or an annual net addition of 78 million people. World population in the mid 21st century is expected to be in the range of 7.3 to 10.7 billion. The medium-fertility projection, which is usually considered as "most likely", indicates that world population will reach 8.9 billion in 2050. tells us to reckon on 11 billion sites. The available space for assignment of /48 site identifiers is 45 bits worth if we confine ourselves to one three-bit Format Prefix. (Six more such are potentially available.) Using the H-ratio of RFC 1715 to compute the required efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22. This is less than the efficiencies of telephone numbers and DECnetIV or IPv4 addresses shown in RFC 1715*. Coupled with the generous assumption of a site per person, the reasonable expectation of easier renumbering for IPv6 than IPv4 or the telephone, and the availability of 6x more unicast address space, I can't see any way to justify a claim that a /48 per site can't be supported. Matt Crawford (* Actually, RFC 1715 understates the efficiency of phone number allocation by using the number of nodes /before/ an increase in numbering space was made but counting the bits /after/ the increase.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 11:34:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67IX8W28507 for ipng-dist; Fri, 7 Jul 2000 11:33:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67IWx628500; Fri, 7 Jul 2000 11:32:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA00034; Fri, 7 Jul 2000 11:32:59 -0700 (PDT) From: Ronald.vanderPol@surfnet.nl Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11160; Fri, 7 Jul 2000 12:32:54 -0600 (MDT) Received: from spock.ncc-1701.surfnet.nl ([192.87.111.34]) by survis.surfnet.nl with ESMTP (exPP) id 13Acvk-0005TM-00; Fri, 7 Jul 2000 20:32:52 +0200 Date: Fri, 7 Jul 2000 20:34:22 +0200 (CEST) X-Sender: rvdp@spock.ncc-1701.surfnet.nl To: Matt Crawford cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-Reply-To: <200007071821.NAA08379@gungnir.fnal.gov> Message-ID: Organisation: SURFnet bv Address: "Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL" Phone: +31 302 305 305 Telefax: +31 302 305 329 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 7 Jul 2000, Matt Crawford wrote: > efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22. What does this mean? Do sites (/48) on average have 0.22*2^16= 14417 networks (/64s)? rvdp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 7 12:00:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67IwYf28594 for ipng-dist; Fri, 7 Jul 2000 11:58:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67IvG628572; Fri, 7 Jul 2000 11:57:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA21703; Fri, 7 Jul 2000 11:57:14 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29486; Fri, 7 Jul 2000 12:57:13 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id NAA08653; Fri, 7 Jul 2000 13:57:11 -0500 (CDT) Message-Id: <200007071857.NAA08653@gungnir.fnal.gov> To: Ronald.vanderPol@surfnet.nl Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net From: "Matt Crawford" Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-reply-to: Your message of Fri, 07 Jul 2000 20:34:22 +0200. Date: Fri, 07 Jul 2000 13:57:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22. > > What does this mean? Do sites (/48) on average have 0.22*2^16= > 14417 networks (/64s)? This means that if they want to have more than 10^(0.22 * 16) = 3311 subnets, they must assign them more efficiently (more densely) than site identifiers are assigned. This should not be difficult to do, since they would have no need to do variable-length subnet masks like we're doing at this site in IPv4. (Our subnets range in size from /28 to /21.) 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 Fri Jul 7 12:07:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e67J6MA28676 for ipng-dist; Fri, 7 Jul 2000 12:06:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e67J5S628654; Fri, 7 Jul 2000 12:05:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA23772; Fri, 7 Jul 2000 12:05:27 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22225; Fri, 7 Jul 2000 12:05:27 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id MAA24784; Fri, 7 Jul 2000 12:04:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Fri, 7 Jul 2000 12:04:52 -0700 To: Ronald.vanderPol@surfnet.nl From: Steve Deering Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Cc: Matt Crawford , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:34 PM +0200 7/7/00, Ronald.vanderPol@surfnet.nl wrote: > > efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22. > >What does this mean? Do sites (/48) on average have 0.22*2^16= >14417 networks (/64s)? No. You really need to read RFC 1715 to understand it. The H ratio is a measure of the assignment efficiency of an address space, which takes into account the inevitable wastage that you get when the addresses must have hierarchical structure. In this particular case, the H Ratio that Matt computed applies to the efficiency of allocation of the high-order /48 (a 45 bit space, when you exclude the format prefix). It says nothing about the usage of the low- order 80 bits (which is irrelevant, for the point that Matt is making). 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 Jul 9 08:20:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e69FIMQ29757 for ipng-dist; Sun, 9 Jul 2000 08:18:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e69FID629750 for ; Sun, 9 Jul 2000 08:18:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA16364 for ; Sun, 9 Jul 2000 08:18:13 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22046 for ; Sun, 9 Jul 2000 09:18:09 -0600 (MDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA08152; Mon, 10 Jul 2000 00:03:02 +0900 (JST) Date: Mon, 10 Jul 2000 00:14:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: yoshfuji@ecei.tohoku.ac.jp Cc: ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 In-Reply-To: In your message of "Wed, 05 Jul 2000 01:43:09 +0900" <20000705014309G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> References: <20000626184933W.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200006270219.WAA0000721425@anw.zk3.dec.com> <20000705014309G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 71 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 05 Jul 2000 01:43:09 +0900, >>>>> Hideaki YOSHIFUJI said: >> >2. Section 6.5: Socket Address Structure to Nodename and Service Name >> >> >* NI_WITHSCOPEID >> > Please define NI_WITHSOCPE. With this flag, getnameinfo() will return >> > with scope-identifiers for link-local, site-local, org-local addresses if >> > NI_NUMERICHOST is supplied; otherwise, no scope-identifier will be >> > returned. Without providing this flag, applications that assumes >> > INET6_ADDRSTRLEN maximum length of IPv6 address may be crashed. >> > (Even if you re-define the value of INET6_ADDRSTRLEN, we need this >> > flag because binaries already compiled may be crashed.) >> >> Whats wrong with ????? > What I want to get as default is (maybe) what you get with NI_WITHOUTSCOPE > (for backward compatibility). > Note: INET6_ADDRSTRLEN is not large enough to store scoped-address. > sizeof("ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255%4294967295") = 57 I can understand your motivation, but I personally think that if an application calls getnameinfo() with sockaddr_in6, NI_NUMERICHOST, and a hostname buffer of INET6_ADDRSTRLEN in length, the possible breakage is the application's own fault; it should not assume such a protocol specific limitation for a protocol independent library function like getnameinfo(). KAME's implementation locally defines NI_WITHSCOPEID, but I'm not sure if it sould be incorporated into rfc2553bis. BTW, I remeber there was a discussion about how getnameinfo() should do when a given buffer size is too small to store a hostname. But I don't remember the conclusion (if any)...was this already clarified? >> >* I want to have a new value "NI_MAXSCOPE" which indicates maximum length of >> > scope-name including scope-delimiter / excluding terminating null-character. >> > It already have IF_NAMESIZE for link-local scope-names, but it is not >> > sufficient; we also have site-local scope identifiers. (Although this is not directly related to this issue, but) you seem to be a bit confused about the relationship between the interface scope and the link scope. According to draft-ietf-ipngwg-scoping-arch-01, the interface scope is (conceptually) smaller than the link scope. However, in KAME's implementation, we intentionally assume a one-to-one mapping between interfaces and links, and thus we use interface names for link identifiers. But we should not mix up interfaces with links when we make a general discussion. (Actually, there is some confusion on this point in rfc2553bis-00, too. But this is another issue. I'll raise it up later.) >> Why? It can't be larger than uint32_t ???? > "No" for numeric identifiers (see below), > but yes for non-numeric identifiers (such as link-local ids); > and IF_NAMESIZE may be larger than IF_NAMESIZE. >> If you define NI_MAXSCOPE to sin6_scope_id length then it will work. > Should we locally defined NI_MAXSCOPE as > ((int)((sizeof(u_int32_t)*CHAR_BIT+2)/3+1)) or so? NI_MAXSCOPE might be useful, but I personally think NI_MAXHOST is sufficient. And, in any case, we should clarify how getnameinfo() should do with a short buffer (if we haven't). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 9 09:12:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e69GBMr29808 for ipng-dist; Sun, 9 Jul 2000 09:11:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e69GBD629801 for ; Sun, 9 Jul 2000 09:11:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA15518 for ; Sun, 9 Jul 2000 09:11:13 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01535 for ; Sun, 9 Jul 2000 10:11:11 -0600 (MDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id AAA08265; Mon, 10 Jul 2000 00:56:06 +0900 (JST) Date: Mon, 10 Jul 2000 01:07:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: yoshfuji@ecei.tohoku.ac.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: freeaddrinfo(NUL) In-Reply-To: In your message of "Mon, 03 Jul 2000 19:16:34 +0900" <20000703191634R.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> References: <1943.948962723@coconut.itojun.org> <20000703191634R.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This issue may not be suitable for this list, but I kept ccing for the moment. >>>>> On Mon, 03 Jul 2000 19:16:34 +0900, >>>>> Hideaki YOSHIFUJI said: > Similar question: How about getifaddrs()? > The getifaddrs(NULL) included in KAME kit doesn't raise an error, does it? No. > Why don't you have it raise a SEGV signal as you do in freeaddrinfo()? > void freeifaddrs(struct ifaddrs *ifp){ > if (!ifp) raise(SIG_SEGV); > free(ifp); > } Just for clarfication: the current KAME's code of freeaddrinfo() does not explicitly raise the SEGV signal against the NULL pointer. It simply omits validation for the argument. SEGV is just a consequence of this behavior. From this standpoint, there's no difference between KAME's freeaddrinfo() and KAME's freeifaddrs(). The latter also just assumes that the argument is a simple (valid) pointer, and just frees the pointer without validation. > I think freeifaddrs(NULL) should be allowed, too; again, to avoid confusion. I don't have a strong opinion about particular behavior (including whether the two functions should do the same reaction against the NULL pointer). But, IMO, the most important thing is to document the behavior, and, if possible, it would be better to standardize it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 9 09:26:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e69GOmj29841 for ipng-dist; Sun, 9 Jul 2000 09:24:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e69GOd629834 for ; Sun, 9 Jul 2000 09:24:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA19811 for ; Sun, 9 Jul 2000 09:24:40 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29154 for ; Sun, 9 Jul 2000 09:24:38 -0700 (PDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA08303; Mon, 10 Jul 2000 01:09:37 +0900 (JST) Date: Mon, 10 Jul 2000 01:20:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: yoshfuji@ecei.tohoku.ac.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: freeaddrinfo(NUL) In-Reply-To: In your message of "Mon, 10 Jul 2000 01:07:19 +0900" References: <1943.948962723@coconut.itojun.org> <20000703191634R.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 10 Jul 2000 01:07:19 +0900, >>>>> JINMEI Tatuya said: > This issue may not be suitable for this list, but I kept ccing for > the moment. ditto... >> Similar question: How about getifaddrs()? >> The getifaddrs(NULL) included in KAME kit doesn't raise an error, does it? > No. Ummm...I might have misunderstood...did you really mean getifaddrs(NULL) here, or did you mistype "getifaddrs" instead of "freeifaddrs"? If you really meant the getifaddrs(NULL) case, the current KAME's implementation would raise the SEGV signal. However, again, it's just a consequence of the fact that the function omits validation of the argument. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 9 10:21:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e69HJmp29883 for ipng-dist; Sun, 9 Jul 2000 10:19:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e69HJb629876 for ; Sun, 9 Jul 2000 10:19:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA09498 for ; Sun, 9 Jul 2000 10:19:37 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12056 for ; Sun, 9 Jul 2000 11:19:36 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA05168; Mon, 10 Jul 2000 02:19:27 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: yoshfuji@ecei.tohoku.ac.jp, ipng@sunroof.eng.sun.com, linux-ipv6-jp@linux.or.jp In-reply-to: jinmei's message of Mon, 10 Jul 2000 00:14:15 JST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00 From: itojun@iijlab.net Date: Mon, 10 Jul 2000 02:19:27 +0900 Message-ID: <5166.963163167@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >BTW, I remeber there was a discussion about how getnameinfo() should >do when a given buffer size is too small to store a hostname. But I >don't remember the conclusion (if any)...was this already clarified? the consensus was to raise error (instead of give truncated result). 2553bis is rather silent about it, it should have more comment on it. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 9 10:28:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e69HROe29910 for ipng-dist; Sun, 9 Jul 2000 10:27:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e69HRF629903; Sun, 9 Jul 2000 10:27:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA10140; Sun, 9 Jul 2000 10:27:14 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13290; Sun, 9 Jul 2000 11:27:13 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id SAA14380; Sun, 9 Jul 2000 18:26:11 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id SAA16470; Sun, 9 Jul 2000 18:26:16 +0100 (BST) Message-ID: <3968909A.E0C7E977@hursley.ibm.com> Date: Sun, 09 Jul 2000 09:47:54 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: matthew.ford@bt.com CC: Francis.Dupont@enst-bretagne.fr, stephenb@uk.uu.net, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net, jonathan.2.stevens@bt.com, peter.hovell@bt.com Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mat, Exactly. A movable boundary (and its consequence, asking registries to make judgement calls) is a proven enemy of route aggregation, renumbering, and multi-homing. The lack of IPv4 addresses forced us into this situation, as per RFC 2050. As Matt Crawford's calculation proves, there is nothing forcing us into such a situation with IPv6. It's simple arithmetic. Just allocate /48s. Brian matthew.ford@bt.com wrote: > > If /56 can be agreed upon as a default then that is not too bad IMO. > However, the RIRs seem to be veering towards allowing LIRs to allocate > whatever they choose between /48 and /64 - a movable boundary which will > scupper the technical objectives of multihoming and simplified > site-renumbering. I believe the idea of a movable boundary should be > strongly opposed for this reason. > > Regards, > > Mat Ford. > > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: 07 July 2000 08:22 > To: Brian E Carpenter > Cc: stephenb@uk.uu.net; ipng@sunroof.eng.sun.com; > ngtrans@sunroof.eng.sun.com; arano@byd.ocn.ad.jp; sig-ipv6@apnic.net; > mir@ripe.net; joao@ripe.net > Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document > Revision > > In your previous mail you wrote: > > Can you explain why people think there is any need to allocate anything > longer than a /48 in the first place? > > => many ISPs want to allocate /64 (or worse) to their customers... and > shout a /48 per customer is far too large. I believe this is a consequence > of the slow^N start, ie. the /35 rule (RIRs trim address space of ISPs, > ISPs take back the burden to their customers). > The idea is to introduce a small site (/56) for "poor & little" customers > and to make it the *default* allocation. IMHO this is an acceptable target. > > Regards > > Francis.Dupont@enst-bretagne.fr > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 9 10:30:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e69HSsf29931 for ipng-dist; Sun, 9 Jul 2000 10:28:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e69HSU629914 for ; Sun, 9 Jul 2000 10:28:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA18672 for ; Sun, 9 Jul 2000 10:28:30 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13524 for ; Sun, 9 Jul 2000 11:28:28 -0600 (MDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA08575; Mon, 10 Jul 2000 02:13:17 +0900 (JST) Date: Mon, 10 Jul 2000 02:24:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com Subject: Re: Resend: icmp-name-lookups-05 In-Reply-To: In your message of "Mon, 03 Jul 2000 09:28:44 -0500" <200007031428.JAA11317@gungnir.fnal.gov> References: <200007031428.JAA11317@gungnir.fnal.gov> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, >>>>> On Mon, 03 Jul 2000 09:28:44 -0500, >>>>> "Matt Crawford" said: > Sorry for the delay; messages which require actual thinking sometimes > age in the inbox. Thanks for the answer, and I apologize for this delayed response. > The problem you report is that the ICMP code field of a Node > Information message is defined to indicate what is in the Data field: > an IPv4 or IPv4 address or a DNS name. But one type of message, the > NOOP, has an empty Data field. > I propose that the fix to the document is to say that the Code field > on a NOOP query must be 1 (meaning Data contains a name), and on a > NOOP reponse must be 0 (defined to mean success with a Data field > that may or may not be empty), and in both cases must be ignored on > reception. Hmm..."Data contains a name" might be a bit confusing for an empty data field, but at least the text is clear enough. I personally think it is okay. itojun, who is the original querier of this issue, might have a different opinion, though. (He might also want answers to the rest of his questions...) Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 9 19:03:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6A21rD00185 for ipng-dist; Sun, 9 Jul 2000 19:01:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6A21g600178 for ; Sun, 9 Jul 2000 19:01:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA12654 for ; Sun, 9 Jul 2000 19:01:40 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA02834 for ; Sun, 9 Jul 2000 19:01:37 -0700 (PDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id LAA03393; Mon, 10 Jul 2000 11:00:57 +0900 To: jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: freeaddrinfo(NUL) From: Hideaki YOSHIFUJI In-Reply-To: References: <20000703191634R.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710110056V.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Mon, 10 Jul 2000 11:00:56 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article (at Mon, 10 Jul 2000 01:20:49 +0900), JINMEI Tatuya says: > >> Similar question: How about getifaddrs()? > > >> The getifaddrs(NULL) included in KAME kit doesn't raise an error, does it? > > > No. > > Ummm...I might have misunderstood...did you really mean > getifaddrs(NULL) here, or did you mistype "getifaddrs" instead of > "freeifaddrs"? Sorry, freeifaddrs(). -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 10 01:04:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6A82do00274 for ipng-dist; Mon, 10 Jul 2000 01:02:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6A82K600250; Mon, 10 Jul 2000 01:02:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA27673; Mon, 10 Jul 2000 01:02:17 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA13957; Mon, 10 Jul 2000 01:02:14 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id JAA16007; Mon, 10 Jul 2000 09:57:23 +0200 (MET DST) Date: Mon, 10 Jul 2000 09:57:23 +0200 From: Ignatios Souvatzis To: Robert Elz Cc: Ignatios Souvatzis , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, mir@ripe.net, joao@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Message-ID: <20000710095723.A14952@theory.cs.uni-bonn.de> References: <20000707185750.C25625@theory.cs.uni-bonn.de> <19698.962992843@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19698.962992843@mundamutti.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Sat, Jul 08, 2000 at 04:00:43AM +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Jul 08, 2000 at 04:00:43AM +1000, Robert Elz wrote: > Date: Fri, 7 Jul 2000 18:57:50 +0200 > From: Ignatios Souvatzis > Message-ID: <20000707185750.C25625@theory.cs.uni-bonn.de> > > This is a non-issue, because we're not doing this, but ... > > | assuming everybody could afford (at least) on phone, IP(v6) over the NMBA > | network called "the world-wide phone system" already would need more then > | 2^32 addresses, right? > > That's going to depend upon whether there is internal structure in that > numbering, aside from what is in the phone numbers already. 2^32 is > probably too small for that particular subnet, but ... > > | /80 would be a problem even for all phones in Germany. > > Germany really has more than 2^48 phones? Or even more than a 2^48 > phone number space? That's a 15 (decimal) digit phone number space. more than 2^16 phones. Oops. Of course, the phone would be a single device. I shouldn't post on Fridays. Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 10 03:50:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AAmU200470 for ipng-dist; Mon, 10 Jul 2000 03:48:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AAmL600463; Mon, 10 Jul 2000 03:48:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA10785; Mon, 10 Jul 2000 03:48:19 -0700 (PDT) From: Heikki.Waris@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13720; Mon, 10 Jul 2000 03:48:18 -0700 (PDT) Received: from esvir02nok.ntc.nokia.com (esvir02nok.ntc.nokia.com [131.228.10.151]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id NAA16974; Mon, 10 Jul 2000 13:48:15 +0300 (EETDST) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 10 Jul 2000 13:48:14 +0300 Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Mon, 10 Jul 2000 13:48:12 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1021673D3@eseis04nok> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net Subject: RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Date: Mon, 10 Jul 2000 13:43:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) 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 e6AAmM700464 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to contribute my view on this prefix length issue. If we start by trying to estimate the total amount of routers required at the edge of the network, this whole conversation will gain some perspective. Let's make a quick calculation, assuming that there are 500 million well-to-do people in mainly industrialized countries with enough financial resources who healthily envy their neighbors with more gadgets and gizmos (and therefore need to have those themselves): offices/corporate sites 50M (small separate units, subnet per avg. 5-10 employees) personal 2G/3G terminals 5M (1 base station serves 1000 people, 10 overlapping operators) WLAN access points etc. 50M (covering all rural areas, avg. 10 users within the radius) Bluetooth etc. local networks 500M (ubiqutous, offer routing mainly in business environment) personal mobile routers 500M (for connecting wearable equipment, personal subnet) houses/apartments 500M vehicles 500M ===== ca. 2100M Make this available to total active population worldwide, multiply 10x. Then we add another decade due to the human tendency of hoarding resources and not freeing address subnets that are no longer used. Then assume that the total efficiency in assigning the subnet space will be close to 10% due to (30% efficiency at two levels, or 47% at three levels of hierarchical providers) So we need 2*10^12 subnets just for currently foreseeable uses. Or in terms of address space, consumption of 41 bits. If we leave out the 3 bit format prefix, this leaves us with 20 bits to waste (if subnets are /64). If the default subnet is /48, we only have 4 bits to waste. And that's not much. Organizations can be worried about not getting enough continuous address space that they can autonomously manage. This is not an excuse for sloppy address allocation. Why not instead suggest providers to initially assign only every 8th or 16th SLA ID for growing organizations? This would leave the provider address space in semi-allocated state (could hamper reaching the 90% mark) but leave some back doors for those that require it. Solving the preferences or problems of individual organizations with case-by-case negotiations instead of generalized rules that may have wider consequences seems to me like a reasonable approach. Heikki Waris > -----Original Message----- > From: EXT Matt Crawford [mailto:crawdad@fnal.gov] > Sent: 7. heinäkuuta 2000 21:22 > To: ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com; > sig-ipv6@apnic.net; mir@ripe.net; joao@ripe.net > Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document > Revision > > > The question to answer is, for a liberal estimate of the number of > "sites" required 50 years from now, how efficiently (how > non-wastefully) > do assignments need to be made to fit within available space? > > An extremely liberal estimate of the number of sites required would be > one per person. Taking the upper range of the year 2050 population > projection from http://www.popin.org/pop1998/ ... > > World population currently stands at 5.9 billion persons and > is growing at 1.33 per cent per year, or an annual net > addition of 78 million people. World population in the mid > 21st century is expected to be in the range of 7.3 to 10.7 > billion. The medium-fertility projection, which is usually > considered as "most likely", indicates that world population > will reach 8.9 billion in 2050. > > tells us to reckon on 11 billion sites. The available space for > assignment of /48 site identifiers is 45 bits worth if we confine > ourselves to one three-bit Format Prefix. (Six more such are > potentially > available.) Using the H-ratio of RFC 1715 to compute the required > efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22. > This is less > than the efficiencies of telephone numbers and DECnetIV or > IPv4 addresses > shown in RFC 1715*. Coupled with the generous assumption of > a site per > person, the reasonable expectation of easier renumbering for IPv6 than > IPv4 or the telephone, and the availability of 6x more unicast address > space, I can't see any way to justify a claim that a /48 per > site can't > be supported. > Matt Crawford > > (* Actually, RFC 1715 understates the efficiency of phone number > allocation by using the number of nodes /before/ an increase in > numbering space was made but counting the bits /after/ the increase.) > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 10 07:32:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AEUgK00593 for ipng-dist; Mon, 10 Jul 2000 07:30:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AETP600571; Mon, 10 Jul 2000 07:29:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA28217; Mon, 10 Jul 2000 07:29:24 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00657; Mon, 10 Jul 2000 08:29:19 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA25294; Mon, 10 Jul 2000 09:28:38 -0500 (CDT) Message-Id: <200007101428.JAA25294@gungnir.fnal.gov> To: Heikki.Waris@nokia.com Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net From: "Matt Crawford" Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-reply-to: Your message of Mon, 10 Jul 2000 13:43:25 +0300. <01D91AFB08B6D211BFD00008C7EABAE1021673D3@eseis04nok> Date: Mon, 10 Jul 2000 09:28:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So we need 2*10^12 subnets just for currently foreseeable uses. Or in terms > of address space, consumption of 41 bits. If we leave out the 3 bit format > prefix, this leaves us with 20 bits to waste (if subnets are /64). If the > default subnet is /48, we only have 4 bits to waste. And that's not much. Point 1: Subnets (under format prefix 001 binary) *are* 64 bits, not 48. That is not under any sort of argument by anyone, as far as I know. The question the registries are trying to open is how many subnets get assigned in a block to a "site". Point 2: You've already built in a 90% "waste" into your numbers, so saying that you are left with "only n bits to waste" is pure deception. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 10 09:26:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AGP8J00751 for ipng-dist; Mon, 10 Jul 2000 09:25:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AGOD600729; Mon, 10 Jul 2000 09:24:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA03182; Mon, 10 Jul 2000 09:24:13 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11460; Mon, 10 Jul 2000 10:24:09 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA26207; Mon, 10 Jul 2000 11:24:03 -0500 (CDT) Message-Id: <200007101624.LAA26207@gungnir.fnal.gov> To: Heikki.Waris@nokia.com Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net From: "Matt Crawford" Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision In-reply-to: Your message of Mon, 10 Jul 2000 18:12:49 +0300. <01D91AFB08B6D211BFD00008C7EABAE1021673D4@eseis04nok> Date: Mon, 10 Jul 2000 11:24:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, sorry about that ambiguous use of terminology. But as you see from the > calculation, most of the sites are consumed by individual entities (be it > persons, vehicles, fixed locations or such) instead of traditional provider > type large organizations ... I don't know if I'd call a table of made-up numbers a "calculation", but yes, you assumed that each "wealthy, envious" person would have a lot of address space. Then you multiplied by 10 to include everyone, then you made an extremely dubious second multiplication by 10 to say that everyone would "take" address assignments ten times over without "giving back" their old assignments. That idea just won't survive contact with the IPv6 operational model of provider-based assignment and renumbering at need. > and therefore it is crucial that the assignment is > done in blocks of /64 subnets. Even with your dubious multiplicative factors, you still came up with more than a factor of 10 to spare with assignment of /48s everywhere. (Even to personal Bluetooth networks that can hold less than 10 devices!) This falls considerably short of "crucial." > And see that with some carefully chosen parameters we can "Extravagantly", not "carefully". > get close to exhausting the IPv6 address space (ok, within 7 bits > to the limit) In other words, a safety factor of more than 100. > even with nowadays recognizable uses. > Besides, that 90% waste resulting from suboptimal provider > allocation is just due to the fact that there may be small scale > providers down in the hierarchy that will never grow so big that > their initial address space runs out. Unless we also aggregate the > providers with mega-mergers... "Providers down in the hierarchy" are to get their address space from higher up in the hierarchy. I wonder if you're familiar with the addressing and assignment architecture. > The bottom line is that we shouldn't be absolutely confident that > there's enough IPv6 addresses unless we take caution in the ways > that we allocate them. One form of caution is to make sure that a site can easily change its prefix if it connects to a different point in the topology. making all the leaf-site blocks the same side IS a cautionary measure to make this possible. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 10 10:03:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AH1WV00796 for ipng-dist; Mon, 10 Jul 2000 10:01:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AH1N600789; Mon, 10 Jul 2000 10:01:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA16649; Mon, 10 Jul 2000 10:01:22 -0700 (PDT) From: Heikki.Waris@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23303; Mon, 10 Jul 2000 10:01:20 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nok.ntc.nokia.com [131.228.10.153]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA12959; Mon, 10 Jul 2000 18:12:51 +0300 (EETDST) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 10 Jul 2000 18:12:51 +0300 Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Mon, 10 Jul 2000 18:12:51 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1021673D4@eseis04nok> To: crawdad@fnal.gov Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net Subject: RE: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Date: Mon, 10 Jul 2000 18:12:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > So we need 2*10^12 subnets just for currently foreseeable > uses. Or in terms > > of address space, consumption of 41 bits. If we leave out > the 3 bit format > > prefix, this leaves us with 20 bits to waste (if subnets > are /64). If the > > default subnet is /48, we only have 4 bits to waste. And > that's not much. > > Point 1: Subnets (under format prefix 001 binary) *are* 64 bits, not > 48. That is not under any sort of argument by anyone, as far as I > know. The question the registries are trying to open is how many > subnets get assigned in a block to a "site". Yes, sorry about that ambiguous use of terminology. But as you see from the calculation, most of the sites are consumed by individual entities (be it persons, vehicles, fixed locations or such) instead of traditional provider type large organizations and therefore it is crucial that the assignment is done in blocks of /64 subnets. Real organizations could be eligible for /56 or /48 prefixes but this should not force the above mentioned entities to get the same prefix lengths by default. So I still see some relevance in this point. > Point 2: You've already built in a 90% "waste" into your numbers, so > saying that you are left with "only n bits to waste" is pure > deception. Buffers on top of buffers, but it is nevertheless useful to look at the issue from a different angle. And see that with some carefully chosen parameters we can get close to exhausting the IPv6 address space (ok, within 7 bits to the limit) even with nowadays recognizable uses. Besides, that 90% waste resulting from suboptimal provider allocation is just due to the fact that there may be small scale providers down in the hierarchy that will never grow so big that their initial address space runs out. Unless we also aggregate the providers with mega-mergers... The bottom line is that we shouldn't be absolutely confident that there's enough IPv6 addresses unless we take caution in the ways that we allocate them. Keeping to the default /64 block at least initially is a good start. Heikki Waris > > Matt Crawford > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 10 11:33:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AIVxl00991 for ipng-dist; Mon, 10 Jul 2000 11:31:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AIVn600984; Mon, 10 Jul 2000 11:31:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA24526; Mon, 10 Jul 2000 11:31:47 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00201; Mon, 10 Jul 2000 12:31:22 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA44420; Mon, 10 Jul 2000 19:28:39 +0100 Received: from hursley.ibm.com (lig32-225-4-144.us.lig-dial.ibm.com [32.225.4.144]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA23122; Mon, 10 Jul 2000 19:28:50 +0100 (BST) Message-ID: <396A0179.241F756D@hursley.ibm.com> Date: Mon, 10 Jul 2000 12:01:45 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Heikki.Waris@nokia.com CC: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <01D91AFB08B6D211BFD00008C7EABAE1021673D3@eseis04nok> 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 e6AIVo700985 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Heikki, Matt's calculation is based on Huitema's H-ratio which is based on actual experience, not theory. Brian Heikki.Waris@nokia.com wrote: > > I'd like to contribute my view on this prefix length issue. > > If we start by trying to estimate the total amount of routers required at > the edge of the network, this whole conversation will gain some perspective. > Let's make a quick calculation, assuming that there are 500 million > well-to-do people in mainly industrialized countries with enough financial > resources who healthily envy their neighbors with more gadgets and gizmos > (and therefore need to have those themselves): > > offices/corporate sites 50M > (small separate units, subnet per avg. 5-10 employees) > personal 2G/3G terminals 5M > (1 base station serves 1000 people, 10 overlapping operators) > WLAN access points etc. 50M > (covering all rural areas, avg. 10 users within the radius) > Bluetooth etc. local networks 500M > (ubiqutous, offer routing mainly in business environment) > personal mobile routers 500M > (for connecting wearable equipment, personal subnet) > houses/apartments 500M > vehicles 500M > ===== > ca. 2100M > > Make this available to total active population worldwide, multiply 10x. > Then we add another decade due to the human tendency of hoarding resources > and not freeing address subnets that are no longer used. > Then assume that the total efficiency in assigning the subnet space will be > close to 10% due to (30% efficiency at two levels, or 47% at three levels of > hierarchical providers) > > So we need 2*10^12 subnets just for currently foreseeable uses. Or in terms > of address space, consumption of 41 bits. If we leave out the 3 bit format > prefix, this leaves us with 20 bits to waste (if subnets are /64). If the > default subnet is /48, we only have 4 bits to waste. And that's not much. > > Organizations can be worried about not getting enough continuous address > space that they can autonomously manage. This is not an excuse for sloppy > address allocation. Why not instead suggest providers to initially assign > only every 8th or 16th SLA ID for growing organizations? This would leave > the provider address space in semi-allocated state (could hamper reaching > the 90% mark) but leave some back doors for those that require it. Solving > the preferences or problems of individual organizations with case-by-case > negotiations instead of generalized rules that may have wider consequences > seems to me like a reasonable approach. > > Heikki Waris > > > -----Original Message----- > > From: EXT Matt Crawford [mailto:crawdad@fnal.gov] > > Sent: 7. heinäkuuta 2000 21:22 > > To: ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com; > > sig-ipv6@apnic.net; mir@ripe.net; joao@ripe.net > > Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document > > Revision > > > > > > The question to answer is, for a liberal estimate of the number of > > "sites" required 50 years from now, how efficiently (how > > non-wastefully) > > do assignments need to be made to fit within available space? > > > > An extremely liberal estimate of the number of sites required would be > > one per person. Taking the upper range of the year 2050 population > > projection from http://www.popin.org/pop1998/ ... > > > > World population currently stands at 5.9 billion persons and > > is growing at 1.33 per cent per year, or an annual net > > addition of 78 million people. World population in the mid > > 21st century is expected to be in the range of 7.3 to 10.7 > > billion. The medium-fertility projection, which is usually > > considered as "most likely", indicates that world population > > will reach 8.9 billion in 2050. > > > > tells us to reckon on 11 billion sites. The available space for > > assignment of /48 site identifiers is 45 bits worth if we confine > > ourselves to one three-bit Format Prefix. (Six more such are > > potentially > > available.) Using the H-ratio of RFC 1715 to compute the required > > efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22. > > This is less > > than the efficiencies of telephone numbers and DECnetIV or > > IPv4 addresses > > shown in RFC 1715*. Coupled with the generous assumption of > > a site per > > person, the reasonable expectation of easier renumbering for IPv6 than > > IPv4 or the telephone, and the availability of 6x more unicast address > > space, I can't see any way to justify a claim that a /48 per > > site can't > > be supported. > > Matt Crawford > > > > (* Actually, RFC 1715 understates the efficiency of phone number > > allocation by using the number of nodes /before/ an increase in > > numbering space was made but counting the bits /after/ the increase.) > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 10 11:39:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AIbAP01028 for ipng-dist; Mon, 10 Jul 2000 11:37:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AIb0601021; Mon, 10 Jul 2000 11:37:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA12082; Mon, 10 Jul 2000 11:36:58 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06238; Mon, 10 Jul 2000 12:36:49 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA145598; Mon, 10 Jul 2000 19:28:33 +0100 Received: from hursley.ibm.com (lig32-225-4-144.us.lig-dial.ibm.com [32.225.4.144]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA21830; Mon, 10 Jul 2000 19:28:40 +0100 (BST) Message-ID: <396A00F4.7C95A15D@hursley.ibm.com> Date: Mon, 10 Jul 2000 11:59:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Joao Luis Silva Damas CC: Stephen Burley , Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, ipv6-wg@ripe.net, richardj@arin.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> <3965A5F0.8505E7BA@uk.uu.net> <3965F75D.E9B4FF6A@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Of course we should talk, the next opportunity is the Pittsburgh IETF. However, let's be careful about deducing general policy from what today's ISPs believe, based on IPv4 experience. Things are truly different in IPv6. Brian Joao Luis Silva Damas wrote: > > Brian, > > At 10:29 -0500 7/7/00, Brian E Carpenter wrote: > ...snip... > > > A /64 for dialup > >> is also too rigid because the way technology is going a /64 is not > >>going to be > >> enough subnets for what wiill be a dial up connection with a large > >>lan behind it. > > > >Indeed. But that isn't an issue the RIRs need to think about. > > It is not the RIRs trying to force variable length prefixes. At the > RIPE meeting in Budapest and the ARIN meeting in Calgary we reported > what the outcome of conversations with IETF people was (the /48, /56, > /64 options for allocation). > This seemed to be a reasonable way of doing it for the IPv6/ngtrans > IETF people and to the RIR people present in Adelaide. > > At both the ARIN and RIPE meetings, ISPs (the people who will use the > address space, after all) were the ones that suggested variable > length prefixes for allocation and the RIRs must go by the community > consensus (BTW, at the RIPE meeting no consensus was reached, with > both the variable length and the 3 fixed lengths having supporters). > > A second issue is to think about a way of getting the IETF IPv6 > people and the 3 RIR communities to talk to each other at the same, > otherwise we are entering a loop, with at least 4 separate > discussions and each dependant on the other 3. > > Joao > > > 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 Jul 10 12:48:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AJfBc01307 for ipng-dist; Mon, 10 Jul 2000 12:41:11 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AJf4601300 for ; Mon, 10 Jul 2000 12:41:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id MAA06981 for ipng@sunroof.eng.sun.com; Mon, 10 Jul 2000 12:39:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AAak600424; Mon, 10 Jul 2000 03:36:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA26259; Mon, 10 Jul 2000 03:36:44 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10196; Mon, 10 Jul 2000 03:36:43 -0700 (PDT) Received: from [193.0.1.195] (dhcp195.ripe.net [193.0.1.195]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id MAA17909; Mon, 10 Jul 2000 12:36:28 +0200 (CEST) Mime-Version: 1.0 X-Sender: joao@mailhost.ripe.net (Unverified) Message-Id: In-Reply-To: <3965F75D.E9B4FF6A@hursley.ibm.com> References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> <3965A5F0.8505E7BA@uk.uu.net> <3965F75D.E9B4FF6A@hursley.ibm.com> Date: Mon, 10 Jul 2000 12:36:04 +0200 To: Brian E Carpenter , Stephen Burley From: Joao Luis Silva Damas Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Cc: Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, ipv6-wg@ripe.net, richardj@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, At 10:29 -0500 7/7/00, Brian E Carpenter wrote: ...snip... > > A /64 for dialup >> is also too rigid because the way technology is going a /64 is not >>going to be >> enough subnets for what wiill be a dial up connection with a large >>lan behind it. > >Indeed. But that isn't an issue the RIRs need to think about. It is not the RIRs trying to force variable length prefixes. At the RIPE meeting in Budapest and the ARIN meeting in Calgary we reported what the outcome of conversations with IETF people was (the /48, /56, /64 options for allocation). This seemed to be a reasonable way of doing it for the IPv6/ngtrans IETF people and to the RIR people present in Adelaide. At both the ARIN and RIPE meetings, ISPs (the people who will use the address space, after all) were the ones that suggested variable length prefixes for allocation and the RIRs must go by the community consensus (BTW, at the RIPE meeting no consensus was reached, with both the variable length and the 3 fixed lengths having supporters). A second issue is to think about a way of getting the IETF IPv6 people and the 3 RIR communities to talk to each other at the same, otherwise we are entering a loop, with at least 4 separate discussions and each dependant on the other 3. Joao > 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 Jul 10 12:48:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AJk0301334 for ipng-dist; Mon, 10 Jul 2000 12:46:00 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AJjq601327 for ; Mon, 10 Jul 2000 12:45:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id MAA07010 for ipng@sunroof.eng.sun.com; Mon, 10 Jul 2000 12:44:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AGEO600685; Mon, 10 Jul 2000 09:14:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA01255; Mon, 10 Jul 2000 09:14:23 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02693; Mon, 10 Jul 2000 10:14:19 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 612394CE50; Mon, 10 Jul 2000 12:14:13 -0400 (EDT) Received: from research.att.com (pc-crk.research.att.com [135.207.17.83]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA15897; Mon, 10 Jul 2000 12:14:11 -0400 (EDT) Message-ID: <3969F4FA.3CB7B8EF@research.att.com> Date: Mon, 10 Jul 2000 12:08:26 -0400 From: "C. R. Kalmanek" X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We need to do anything we can to facilitate aggregation, since (assuming there are enough addresses) this will be the thing that most hinders scalability. I don't know where we stand today with respect to being able to handle all the routes in the default free zone, but we don't want to make things worse. Since there appear to be enough addresses, either the current option (/48 only) or an option that allows either /48 or /56 seem like the best choices. Having an movable boundary anywhere between /48 and /64 will definitely hurt aggregation and site mobility. That said, with the current option, having 64K subnets for the network in my car seems like a bit of overkill. This is a case that seems to stretch the definition of a "site" in the current addressing architecture... chuck -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 10 13:18:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AKFGj01472 for ipng-dist; Mon, 10 Jul 2000 13:15:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AKF6601465; Mon, 10 Jul 2000 13:15:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA26101; Mon, 10 Jul 2000 13:14:57 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20747; Mon, 10 Jul 2000 13:14:54 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA17862; Mon, 10 Jul 2000 21:14:28 +0100 Received: from hursley.ibm.com (lig32-225-3-132.us.lig-dial.ibm.com [32.225.3.132]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA23258; Mon, 10 Jul 2000 21:14:40 +0100 (BST) Message-ID: <396A2DA6.7F503EFE@hursley.ibm.com> Date: Mon, 10 Jul 2000 15:10:14 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Heikki.Waris@nokia.com CC: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <01D91AFB08B6D211BFD00008C7EABAE1021673D4@eseis04nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Heikki.Waris@nokia.com wrote: > The bottom line is that we shouldn't be absolutely confident that there's > enough IPv6 addresses unless we take caution in the ways that we allocate > them. Keeping to the default /64 block at least initially is a good start. Just to be 100% clear, I disagree. In the IPv6 world we can and must push the balance further in favour of aggregation, away from conservation, and keeping to the default /48 block is a good start. 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 Jul 10 15:33:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AMVaA01812 for ipng-dist; Mon, 10 Jul 2000 15:31:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AMVP601805; Mon, 10 Jul 2000 15:31:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA21337; Mon, 10 Jul 2000 15:31:24 -0700 (PDT) From: dancer@zeor.simegen.com Received: from keon.simegen.com (gw.simegen.com [203.2.135.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14896; Mon, 10 Jul 2000 15:31:19 -0700 (PDT) Received: from anaconda.simegen.com [203.28.9.32] by keon.simegen.com with esmtp (Exim 3.12 #1 (Debian)) id 13Bm4F-0003at-00; Tue, 11 Jul 2000 08:30:24 +1000 Received: from localhost ([127.0.0.1] helo=zeor.simegen.com) by anaconda.simegen.com with esmtp (Exim 3.12 #1 (Debian)) id 13Bm4A-0000Ml-00; Tue, 11 Jul 2000 08:30:18 +1000 Message-ID: <396A4E79.AB70AB07@zeor.simegen.com> Date: Tue, 11 Jul 2000 08:30:18 +1000 X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test1-ac21 i586) X-Accept-Language: en MIME-Version: 1.0 To: Joao Luis Silva Damas CC: Brian E Carpenter , Stephen Burley , Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, ipv6-wg@ripe.net, richardj@arin.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> <3965A5F0.8505E7BA@uk.uu.net> <3965F75D.E9B4FF6A@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joao Luis Silva Damas wrote: > Brian, > > At 10:29 -0500 7/7/00, Brian E Carpenter wrote: > ...snip... > > > A /64 for dialup > >> is also too rigid because the way technology is going a /64 is not > >>going to be > >> enough subnets for what wiill be a dial up connection with a large > >>lan behind it. > > > >Indeed. But that isn't an issue the RIRs need to think about. > > It is not the RIRs trying to force variable length prefixes. At the > RIPE meeting in Budapest and the ARIN meeting in Calgary we reported > what the outcome of conversations with IETF people was (the /48, /56, > /64 options for allocation). > This seemed to be a reasonable way of doing it for the IPv6/ngtrans > IETF people and to the RIR people present in Adelaide. > > At both the ARIN and RIPE meetings, ISPs (the people who will use the > address space, after all) were the ones that suggested variable > length prefixes for allocation and the RIRs must go by the community > consensus (BTW, at the RIPE meeting no consensus was reached, with > both the variable length and the 3 fixed lengths having supporters). > > A second issue is to think about a way of getting the IETF IPv6 > people and the 3 RIR communities to talk to each other at the same, > otherwise we are entering a loop, with at least 4 separate > discussions and each dependant on the other 3. The only practical reason I can see for variable-length prefixes is for the ISP to charge more money for allocation of any prefix shorter than a /64. Guaranteed, the average ISP (no, I won't tar you all with the same brush) if permitted to allocate a /64 won't allocate anything shorter unless lubricated with many times the amount of cash. Perhaps it sounds cynical, but that's based on my experiences with ISPs. Under IPv4, I can see how a scarce resource falls under the supply/demand paradigm. Let's not falsely inflate the value of a /48 to the end-user by making longer prefixes available. Those longer prefixes will simply become the norm, which was not our intent, was it? D -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 10 15:42:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6AMfUm01869 for ipng-dist; Mon, 10 Jul 2000 15:41:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6AMfL601862 for ; Mon, 10 Jul 2000 15:41:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13486 for ; Mon, 10 Jul 2000 15:41:21 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20290 for ; Mon, 10 Jul 2000 15:41:19 -0700 (PDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13BmEm-0004wI-00; Mon, 10 Jul 2000 18:41:16 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA01749; Mon, 10 Jul 00 18:39:00 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA02913; Mon, 10 Jul 2000 18:44:22 -0400 Message-Id: <396A5175.BB1FAF70@txc.com> Date: Mon, 10 Jul 2000 18:43:01 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Peter Tam Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Thanks for a more detailed list of comments. Your reviewing is going to be acknowledged in the I-D. As I am preparing the text for a new version of the draft, my thoughts related to your comments are: Regarding your first suggestion, whose ramifications I understand now better than before: > >... > > >> Currently, the draft does not restrict the types of addresses > within the Source/Target Address Lists in the IND > Solicitation/Advertisement messages. Thus, it implies that both > unicast and multicast addresses are legitimate. This address > information is used to build the Neighbor cache, which I believe > can contain only unicast addresses.If unicast-only addresses are > imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should > discard IND messages containing multicast addresses, so that they > will not be entered into the cache. After all, resolution should > be between link layer addresses and unicast network addresses. > the text in the current draft is aligned with the original intentions in specifying the protocol: - do not make strong implementation requirements the I-D specifies that the Neighbor Discovery Cache MAY be populated with address information acquired via IND. Which is to say strongly that the Protocol for populating the ND cache is and remains ND. - allow a certain level of generality and flexibility to the address discovery mechanism, which may be useful for the type of links to which the protocol applies. for links that do not have an algorithmic mapping of IP multicast addresses into link addresses, there is - I think - a need for storing/caching the address information used in resolution. What is, or how the place for storing multicast address information is called, is an implementation issue. A mechanism to convey the information used in resolution is also useful . In saying this, as I did in the I-D, I am trying to stay away though from making implementation suggestions. As I still do not see any particular bad side effects, I think the original goals as followed by the text are worth maintaining, In that sense, I think, RFC 2390 sets also an example. > >.... > > > 1. Appendix A: Frame Relay (FR) as a link-layer address. But > it > > should have a note up front that the DLCI applies to the > member > > DLCI in the case of a Multi-link Frame Relay. > > > > The appendix was intended to contain one simple example to > illustrate > the use of the protocol. Some particular details of the link in > the > example were considered out of scope. > >> Out-of/in scope is an artificial line. In this case, all it > takes is only 1 line of clarification. > Let me rephrase my thoughts on this: the example in Appendix A is not a Multi-link Frame Relay example, and Multi-link Frame Relay is not mentioned at all. If Multi-link would have been mentioned, in one way or another, then I could have better seen a reason for confusion, and a need for clarification, but without that, this is a way to not extend the scope beyond what was intended, and also minimize the number of words or sentences. Thanks again for your input. and regards, Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 10 19:15:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6B2DBF02156 for ipng-dist; Mon, 10 Jul 2000 19:13:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6B2Bt602133; Mon, 10 Jul 2000 19:11:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA22562; Mon, 10 Jul 2000 19:11:53 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA28805; Mon, 10 Jul 2000 19:11:38 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA10270; Tue, 11 Jul 2000 11:11:29 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA11686; Tue, 11 Jul 2000 11:11:28 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA17810; Tue, 11 Jul 2000 11:11:27 +0900 (JST) Date: Tue, 11 Jul 2000 11:10:27 +0900 (JST) Message-Id: <20000711.111027.41646408.kazu@Mew.org> To: joao@ripe.net Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, ipv6-wg@ripe.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <3965A5F0.8505E7BA@uk.uu.net> <3965F75D.E9B4FF6A@hursley.ibm.com> X-Mailer: Mew version 1.95b45 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Joao Luis Silva Damas Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision > A second issue is to think about a way of getting the IETF IPv6 > people and the 3 RIR communities to talk to each other at the same, > otherwise we are entering a loop, with at least 4 separate > discussions and each dependant on the other 3. Please make the way. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 11 07:44:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6BEgKQ02497 for ipng-dist; Tue, 11 Jul 2000 07:42:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6BEgA602489; Tue, 11 Jul 2000 07:42:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11803; Tue, 11 Jul 2000 07:42:10 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15176; Tue, 11 Jul 2000 07:42:06 -0700 (PDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id PAA114430; Tue, 11 Jul 2000 15:40:59 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id PAA17600; Tue, 11 Jul 2000 15:41:08 +0100 (BST) Message-ID: <396B313F.644AE1E5@hursley.ibm.com> Date: Tue, 11 Jul 2000 09:37:51 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Daniel Karrenberg CC: Joao Luis Silva Damas , Stephen Burley , Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, ipv6-wg@ripe.net, richardj@arin.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy DocumentRevision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> <3965A5F0.8505E7BA@uk.uu.net> <3965F75D.E9B4FF6A@hursley.ibm.com> <4.3.2.7.2.20000711102210.00d18220@localhost.ripe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Daniel Karrenberg wrote: > > At 06:59 PM 7/10/00, Brian E Carpenter wrote: > >Of course we should talk, the next opportunity is the Pittsburgh IETF. > > > >However, let's be careful about deducing general policy from what today's > >ISPs believe, based on IPv4 experience. Things are truly different > >in IPv6. > > > > Brian > > Brian, > > we - the RIRs - are in no position to tell the ISPs that they are stupid and > that they "don't understand". I think even the mighty IAB should be a little > careful before going that route; it is the ISPs, after all, who convert > integers to address space by routing traffic based on it. > > Policies will change as we go along and all those involved understand more and > get more comfortable with things. Indeed, my words that you quote were written to avoid insulting the ISP's intelligence and experience... but IPv6 is truly different. 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 Tue Jul 11 08:15:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6BFD7u02551 for ipng-dist; Tue, 11 Jul 2000 08:13:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6BFCt602544; Tue, 11 Jul 2000 08:12:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA06394; Tue, 11 Jul 2000 08:12:52 -0700 (PDT) Received: from roam.psg.com (mg-206253200-166.ricochet.net [206.253.200.166]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27836; Tue, 11 Jul 2000 09:12:44 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13C1he-0000yU-00; Tue, 11 Jul 2000 08:12:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Brian E Carpenter Cc: Daniel Karrenberg , Joao Luis Silva Damas , Stephen Burley , Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, ipv6-wg@ripe.net, richardj@arin.net Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy DocumentRevision References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> <3965A5F0.8505E7BA@uk.uu.net> <3965F75D.E9B4FF6A@hursley.ibm.com> <4.3.2.7.2.20000711102210.00d18220@localhost.ripe.net> <396B313F.644AE1E5@hursley.ibm.com> Message-Id: Date: Tue, 11 Jul 2000 08:12:06 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Indeed, my words that you quote were written to avoid insulting the ISP's > intelligence and experience... but IPv6 is truly different. yes. it's not deployed. and to get it deployed, as bernard just said well on the ietf list, we need to make it *significantly* more attractive than the status quo, like five times as attractive. one attraction could be address space. and ipv6 has a lot of it, though, having been through some decades in this game it is hard to believe that this year's effectively-infinite will not be next year's (or decade's) joke. so it would be nice if we could have an ipv6 address space allocation policy which allowed users to perceive the benefits of the larger address space. and, imiho, we should err on the side of generosity. but we should not forget that we have four more wonderful marvels of ipv6 to find if we want it to sell. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 11 11:36:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6BIY5S02731 for ipng-dist; Tue, 11 Jul 2000 11:34:06 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6BIXv602724 for ; Tue, 11 Jul 2000 11:33:57 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA18719 for ipng@sunroof.eng.sun.com; Tue, 11 Jul 2000 11:32:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6B8SS602343 for ; Tue, 11 Jul 2000 01:28:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA28469 for ; Tue, 11 Jul 2000 01:28:28 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA11274 for ; Tue, 11 Jul 2000 02:28:27 -0600 (MDT) Received: (qmail 24942 invoked by uid 0); 11 Jul 2000 08:28:24 -0000 Received: from kantoor.ripe.net (HELO laptoy-dfk.ripe.net) (193.0.1.98) by postman.ripe.net with SMTP; 11 Jul 2000 08:28:24 -0000 Message-Id: <4.3.2.7.2.20000711102210.00d18220@localhost.ripe.net> X-Sender: dfk@localhost.ripe.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Jul 2000 10:28:01 +0200 To: Brian E Carpenter From: Daniel Karrenberg Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision Cc: Joao Luis Silva Damas , Stephen Burley , Kazu@venus.Sun.COM, Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net, mir@ripe.net, ipv6-wg@ripe.net, richardj@arin.net In-Reply-To: <396A00F4.7C95A15D@hursley.ibm.com> References: <20000706.172714.91311805.kazu@Mew.org> <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com> <3965A5F0.8505E7BA@uk.uu.net> <3965F75D.E9B4FF6A@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:59 PM 7/10/00, Brian E Carpenter wrote: >Of course we should talk, the next opportunity is the Pittsburgh IETF. > >However, let's be careful about deducing general policy from what today's >ISPs believe, based on IPv4 experience. Things are truly different >in IPv6. > > Brian Brian, we - the RIRs - are in no position to tell the ISPs that they are stupid and that they "don't understand". I think even the mighty IAB should be a little careful before going that route; it is the ISPs, after all, who convert integers to address space by routing traffic based on it. Policies will change as we go along and all those involved understand more and get more comfortable with things. Daniel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 11 13:24:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6BKKx802868 for ipng-dist; Tue, 11 Jul 2000 13:20:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6BKKo602861 for ; Tue, 11 Jul 2000 13:20:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA01862 for ; Tue, 11 Jul 2000 13:20:48 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA25297 for ; Tue, 11 Jul 2000 13:19:53 -0700 (PDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Jul 2000 13:14:55 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id <3ND1XBV9>; Tue, 11 Jul 2000 13:14:54 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8102511DE46@RED-MSG-50> From: Richard Draves To: msa@hemuli.tte.vtt.fi Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Source address selection.. Date: Tue, 11 Jul 2000 13:14:44 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A second belated response... > Just throwing some ideas and questions... the draft > > draft-ietf-ipngwg-default-addr-select-00.txt > > uses at one stage CommonPrefixLen(SA, D) as a comparison value to > select between candidate source addresses (prefixes). This is simple > common bits counted from left ("most significant end"), right? Yes. > In our code we use following ComparisonValue(SA, D), returns > > prefixlength, if the common bits covers the prefix, > and > (common bits - prefixlength), when match is less (e.g. this value is > always negative) > > This prefers the longest prefix that matches fully. If none matches, > it prefers the prefix with least differing bits in the "routing > part". > > "My version" differs only when none of the prefixes match fully. For > example, if D=xxxyyy... (x = 4bit unit) > > SA= xxxzzzz/32 CommonPrefixLen=12 ComparisonValue= -20 > SB= xxz/12 CommonPrefixlen=8 ComparisonValue= -4 > > CommonPrefix would select SA, ComparisonValue would select SB. If I understand this correctly, it sounds like your implementation maintains a prefix length associated with each unicast address that is assigned to an interface. This is why you can speak about SA having a 32 bit prefix length. This is not universal among IPv6 implementations. There is no specification that requires or uses such a prefix length. So I don't want to put anything in the src/dst address selection spec that relies on such a prefix length. Restricting our attention to implementations that do maintain such a prefix length associated with unicast addresses, I still don't understand your motivation. For autoconfigured addresses, wouldn't this prefix length always be 64? And then if I understand your rule correctly, in most cases it would prefer exactly the wrong source address - it would prefer the one that has fewest bits in common with the destination. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 11 13:29:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6BKRoV02887 for ipng-dist; Tue, 11 Jul 2000 13:27:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6BKRa602880 for ; Tue, 11 Jul 2000 13:27:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA02045 for ; Tue, 11 Jul 2000 13:27:36 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA02457 for ; Tue, 11 Jul 2000 13:26:39 -0700 (PDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Jul 2000 13:25:59 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Tue, 11 Jul 2000 13:14:48 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8102511DE45@RED-MSG-50> From: Richard Draves To: ipng@sunroof.eng.sun.com Subject: RE: comments to src/dst selection Date: Tue, 11 Jul 2000 13:14:44 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm working on revisions to draft-ietf-ipngwg-default-addr-select-00.txt, based on feedback at the Adelaide IETF and my implementation experience. Unfortunately we don't have much operational experience yet, and that's what it will take to know if the policy mechanism is providing the right kinds of flexibility, making the right tradeoffs between flexibility & complexity, and if the default policies are reasonable. There have been a couple messages to the list since Adelaide that I haven't responded to, and I want to catch up. First: > -----Original Message----- > From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net] > Sent: Tuesday, March 28, 2000 4:45 PM > To: Richard Draves > Cc: ipng@sunroof.eng.sun.com > Subject: comments to src/dst selection > > > I had no time to comment on it in meeting so I email it to you. > > How do we lookup policy table, when we are on scope boundary? > > (If I'm wrong please corret) policy table should have scope with > addreseses so that we can handle cases for scope > boundary (or zone > boundary) router. scope id must always meet whenever they are > specified. I think the prefix policies could have scope ids. So the lookup rule to find a policy is that if a policy for a scoped prefix has a non-zero scope-id, then the scope-id must match. If the policy has a zero scope-id, then it's a wildcard. I think this level of flexibility should be optional, because I'm having trouble coming up with scenarios where an administrator would want to take advantage of this. For example, on a multi-sited node, it would let you have a policy saying that site-local addresses in one site are preferred over global addresses, but global addresses are preferred over site-local addresses in a second site. Is this flexibility that all implementations SHOULD have? 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 Jul 11 15:49:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6BMl7C03037 for ipng-dist; Tue, 11 Jul 2000 15:47:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6BMkw603030 for ; Tue, 11 Jul 2000 15:46:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA10220 for ; Tue, 11 Jul 2000 15:46:58 -0700 (PDT) Received: from zrtps06s.us.nortel.com ([47.140.48.50]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17369 for ; Tue, 11 Jul 2000 15:46:57 -0700 (PDT) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 11 Jul 2000 18:46:00 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jul 2000 18:46:00 -0400 Message-ID: From: "Peter Tam" To: Alex Conta Cc: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" Date: Tue, 11 Jul 2000 18:45:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEB89.C819D4EA" X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFEB89.C819D4EA Content-Type: text/plain; charset="iso-8859-1" Alex: I can live with your clarifications. Thanks ...Peter -----Original Message----- From: Alex Conta [SMTP:aconta@txc.com] Sent: Monday, July 10, 2000 6:43 PM To: Tam, Peter [NORSE:6L73:EXCH] Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" Peter, Thanks for a more detailed list of comments. Your reviewing is going to be acknowledged in the I-D. As I am preparing the text for a new version of the draft, my thoughts related to your comments are: Regarding your first suggestion, whose ramifications I understand now better than before: > >... > > >> Currently, the draft does not restrict the types of addresses > within the Source/Target Address Lists in the IND > Solicitation/Advertisement messages. Thus, it implies that both > unicast and multicast addresses are legitimate. This address > information is used to build the Neighbor cache, which I believe > can contain only unicast addresses.If unicast-only addresses are > imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should > discard IND messages containing multicast addresses, so that they > will not be entered into the cache. After all, resolution should > be between link layer addresses and unicast network addresses. > the text in the current draft is aligned with the original intentions in specifying the protocol: - do not make strong implementation requirements the I-D specifies that the Neighbor Discovery Cache MAY be populated with address information acquired via IND. Which is to say strongly that the Protocol for populating the ND cache is and remains ND. - allow a certain level of generality and flexibility to the address discovery mechanism, which may be useful for the type of links to which the protocol applies. for links that do not have an algorithmic mapping of IP multicast addresses into link addresses, there is - I think - a need for storing/caching the address information used in resolution. What is, or how the place for storing multicast address information is called, is an implementation issue. A mechanism to convey the information used in resolution is also useful . In saying this, as I did in the I-D, I am trying to stay away though from making implementation suggestions. As I still do not see any particular bad side effects, I think the original goals as followed by the text are worth maintaining, In that sense, I think, RFC 2390 sets also an example. > >.... > > > 1. Appendix A: Frame Relay (FR) as a link-layer address. But > it > > should have a note up front that the DLCI applies to the > member > > DLCI in the case of a Multi-link Frame Relay. > > > > The appendix was intended to contain one simple example to > illustrate > the use of the protocol. Some particular details of the link in > the > example were considered out of scope. > >> Out-of/in scope is an artificial line. In this case, all it > takes is only 1 line of clarification. > Let me rephrase my thoughts on this: the example in Appendix A is not a Multi-link Frame Relay example, and Multi-link Frame Relay is not mentioned at all. If Multi-link would have been mentioned, in one way or another, then I could have better seen a reason for confusion, and a need for clarification, but without that, this is a way to not extend the scope beyond what was intended, and also minimize the number of words or sentences. Thanks again for your input. and regards, Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01BFEB89.C819D4EA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: W.G. Last Call on "Extensions to IPv6 Neighbor = Discovery for Inverse Discovery Specification"

Alex:

I can live with your clarifications. = Thanks ...Peter

    -----Original = Message-----
    From:   Alex Conta = [SMTP:aconta@txc.com]
    Sent:   Monday, July 10, 2000 6:43 PM
    To:     Tam, Peter [NORSE:6L73:EXCH]
    Cc:     ipng@sunroof.eng.sun.com
    Subject:       = Re: W.G. Last Call on = "Extensions to IPv6 Neighbor Discovery for  Inverse Discovery = Specification"

    Peter,

    Thanks for a more detailed list of = comments. Your reviewing is going to
    be acknowledged in the I-D.

    As I am preparing the text for a new = version of the draft,  my thoughts
    related to your comments are:

    Regarding your first suggestion, whose = ramifications I understand now
    better than before:

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

    the text in the current draft is = aligned with the original intentions in
    specifying the protocol:

      - do not make strong = implementation requirements


         the I-D = specifies that  the Neighbor Discovery Cache MAY be
         populated = with address information acquired via IND.  Which is
         to say = strongly that the Protocol for populating the ND cache
         is and = remains ND.

      - allow a certain level of = generality and flexibility to the address
    discovery mechanism, which may be = useful for the type of links to which
    the protocol applies.


          for = links that do not have an algorithmic mapping of  IP
         multicast = addresses into link addresses, there is - I think -
         a need for = storing/caching the address information used in
         resolution. = What is, or how  the place for storing multicast
         address = information is called, is an implementation issue.  A
         mechanism to = convey the information used in resolution is also
         useful . In = saying this, as I did in the I-D,  I am trying to
         stay away = though from making implementation suggestions.

    As I still do not see any particular = bad side effects, I think the
    original goals as followed by the = text are worth maintaining,  In that
    sense,  I think,  RFC 2390 = sets also an example.


    >      = >....
    >
    >      = >   1. Appendix A: Frame Relay (FR) as a link-layer = address. But
    >      = it
    >      = >      should have a note up front that the = DLCI applies to the
    >      = member
    >      = >      DLCI in the case of a Multi-link = Frame Relay.
    >      = >
    >
    >      = The appendix was intended to contain one simple example to
    >      = illustrate
    >      = the use of the protocol. Some particular details of the link in
    >      = the
    >      = example were considered out of scope.
    >      = >> Out-of/in scope is an artificial line. In this case, all = it
    >      = takes is only 1 line of clarification.
    >

    Let me rephrase my thoughts on = this:

    the example in Appendix A is not a = Multi-link Frame Relay example, and
    Multi-link Frame Relay is not = mentioned at all. If Multi-link would have
    been mentioned, in one way or = another, then I could have better seen a
    reason for confusion, and a need for = clarification, but without that,
    this is a way to not extend the scope = beyond what was intended, and also
    minimize the number of words or = sentences.

    Thanks again for your input.
    and regards,
    Alex

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

------_=_NextPart_001_01BFEB89.C819D4EA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 12 06:54:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6CDqlD03481 for ipng-dist; Wed, 12 Jul 2000 06:52:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6CDqc603474 for ; Wed, 12 Jul 2000 06:52:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA07588 for ; Wed, 12 Jul 2000 06:52:38 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26612 for ; Wed, 12 Jul 2000 06:52:26 -0700 (PDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13CMvx-0000KD-00; Wed, 12 Jul 2000 09:52:17 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA13039; Wed, 12 Jul 00 09:50:02 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id JAA18911; Wed, 12 Jul 2000 09:55:23 -0400 Message-Id: <396C786F.C5F317C0@txc.com> Date: Wed, 12 Jul 2000 09:53:51 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Peter Tam Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Thank you again for your feedback. Alex Peter Tam wrote: > > > Alex: > > I can live with your clarifications. Thanks ...Peter > > -----Original Message----- > From: Alex Conta [SMTP:aconta@txc.com] > Sent: Monday, July 10, 2000 6:43 PM > To: Tam, Peter [NORSE:6L73:EXCH] > Cc: ipng@sunroof.eng.sun.com > Subject: Re: W.G. Last Call on "Extensions to IPv6 > Neighbor Discovery for Inverse Discovery Specification" > > Peter, > > Thanks for a more detailed list of comments. Your reviewing is > going to > be acknowledged in the I-D. > > As I am preparing the text for a new version of the draft, my > thoughts > related to your comments are: > > Regarding your first suggestion, whose ramifications I understand > now > better than before: > > > >... > > > > >> Currently, the draft does not restrict the types of > addresses > > within the Source/Target Address Lists in the IND > > Solicitation/Advertisement messages. Thus, it implies that > both > > unicast and multicast addresses are legitimate. This > address > > information is used to build the Neighbor cache, which I > believe > > can contain only unicast addresses.If unicast-only > addresses are > > imposed (as I suggested), then Sections 4.3.1 and 4.3.2 > should > > discard IND messages containing multicast addresses, so > that they > > will not be entered into the cache. After all, resolution > should > > be between link layer addresses and unicast network > addresses. > > > > the text in the current draft is aligned with the original > intentions in > specifying the protocol: > > - do not make strong implementation requirements > > the I-D specifies that the Neighbor Discovery Cache MAY be > populated with address information acquired via IND. Which > is > to say strongly that the Protocol for populating the ND > cache > is and remains ND. > > - allow a certain level of generality and flexibility to the > address > discovery mechanism, which may be useful for the type of links to > which > the protocol applies. > > for links that do not have an algorithmic mapping of IP > multicast addresses into link addresses, there is - I think > - > a need for storing/caching the address information used in > resolution. What is, or how the place for storing multicast > > address information is called, is an implementation issue. > A > mechanism to convey the information used in resolution is > also > useful . In saying this, as I did in the I-D, I am trying > to > stay away though from making implementation suggestions. > > As I still do not see any particular bad side effects, I think > the > original goals as followed by the text are worth maintaining, In > that > sense, I think, RFC 2390 sets also an example. > > > >.... > > > > > 1. Appendix A: Frame Relay (FR) as a link-layer > address. But > > it > > > should have a note up front that the DLCI applies > to the > > member > > > DLCI in the case of a Multi-link Frame Relay. > > > > > > > The appendix was intended to contain one simple example to > > > illustrate > > the use of the protocol. Some particular details of the > link in > > the > > example were considered out of scope. > > >> Out-of/in scope is an artificial line. In this case, > all it > > takes is only 1 line of clarification. > > > > Let me rephrase my thoughts on this: > > the example in Appendix A is not a Multi-link Frame Relay > example, and > Multi-link Frame Relay is not mentioned at all. If Multi-link > would have > been mentioned, in one way or another, then I could have better > seen a > reason for confusion, and a need for clarification, but without > that, > this is a way to not extend the scope beyond what was intended, > and also > minimize the number of words or sentences. > > Thanks again for your input. > and regards, > Alex > > > ------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > ------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 12 07:08:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6CE6Ow03516 for ipng-dist; Wed, 12 Jul 2000 07:06:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6CE6E603509 for ; Wed, 12 Jul 2000 07:06:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA22469 for ; Wed, 12 Jul 2000 07:06:15 -0700 (PDT) Received: from nbv.cistron.nl (nbv.cistron.nl [195.64.71.191]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05113 for ; Wed, 12 Jul 2000 07:06:07 -0700 (PDT) Received: by nbv.cistron.nl (Postfix, from userid 1023) id 41ADA9A22; Wed, 12 Jul 2000 16:06:06 +0200 (CEST) Delivered-To: mreader@nbv.cistron.nl Received: from troi.cistron.net (troi.cistron.net [195.64.65.9]) by nbv.cistron.nl (Postfix) with ESMTP id D62779A19 for ; Wed, 12 Jul 2000 16:06:03 +0200 (CEST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by troi.cistron.net (8.9.1a/8.9.1/Debian/GNU) with ESMTP id QAA21245 for ; Wed, 12 Jul 2000 16:04:24 +0200 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03857; Wed, 12 Jul 2000 06:57:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA09745; Wed, 12 Jul 2000 06:57:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6CDqlD03481 for ipng-dist; Wed, 12 Jul 2000 06:52:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6CDqc603474 for ; Wed, 12 Jul 2000 06:52:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA07588 for ; Wed, 12 Jul 2000 06:52:38 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26612 for ; Wed, 12 Jul 2000 06:52:26 -0700 (PDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13CMvx-0000KD-00; Wed, 12 Jul 2000 09:52:17 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA13039; Wed, 12 Jul 00 09:50:02 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id JAA18911; Wed, 12 Jul 2000 09:55:23 -0400 Message-Id: <396C786F.C5F317C0@txc.com> Date: Wed, 12 Jul 2000 09:53:51 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Peter Tam Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Thank you again for your feedback. Alex Peter Tam wrote: > > > Alex: > > I can live with your clarifications. Thanks ...Peter > > -----Original Message----- > From: Alex Conta [SMTP:aconta@txc.com] > Sent: Monday, July 10, 2000 6:43 PM > To: Tam, Peter [NORSE:6L73:EXCH] > Cc: ipng@sunroof.eng.sun.com > Subject: Re: W.G. Last Call on "Extensions to IPv6 > Neighbor Discovery for Inverse Discovery Specification" > > Peter, > > Thanks for a more detailed list of comments. Your reviewing is > going to > be acknowledged in the I-D. > > As I am preparing the text for a new version of the draft, my > thoughts > related to your comments are: > > Regarding your first suggestion, whose ramifications I understand > now > better than before: > > > >... > > > > >> Currently, the draft does not restrict the types of > addresses > > within the Source/Target Address Lists in the IND > > Solicitation/Advertisement messages. Thus, it implies that > both > > unicast and multicast addresses are legitimate. This > address > > information is used to build the Neighbor cache, which I > believe > > can contain only unicast addresses.If unicast-only > addresses are > > imposed (as I suggested), then Sections 4.3.1 and 4.3.2 > should > > discard IND messages containing multicast addresses, so > that they > > will not be entered into the cache. After all, resolution > should > > be between link layer addresses and unicast network > addresses. > > > > the text in the current draft is aligned with the original > intentions in > specifying the protocol: > > - do not make strong implementation requirements > > the I-D specifies that the Neighbor Discovery Cache MAY be > populated with address information acquired via IND. Which > is > to say strongly that the Protocol for populating the ND > cache > is and remains ND. > > - allow a certain level of generality and flexibility to the > address > discovery mechanism, which may be useful for the type of links to > which > the protocol applies. > > for links that do not have an algorithmic mapping of IP > multicast addresses into link addresses, there is - I think > - > a need for storing/caching the address information used in > resolution. What is, or how the place for storing multicast > > address information is called, is an implementation issue. > A > mechanism to convey the information used in resolution is > also > useful . In saying this, as I did in the I-D, I am trying > to > stay away though from making implementation suggestions. > > As I still do not see any particular bad side effects, I think > the > original goals as followed by the text are worth maintaining, In > that > sense, I think, RFC 2390 sets also an example. > > > >.... > > > > > 1. Appendix A: Frame Relay (FR) as a link-layer > address. But > > it > > > should have a note up front that the DLCI applies > to the > > member > > > DLCI in the case of a Multi-link Frame Relay. > > > > > > > The appendix was intended to contain one simple example to > > > illustrate > > the use of the protocol. Some particular details of the > link in > > the > > example were considered out of scope. > > >> Out-of/in scope is an artificial line. In this case, > all it > > takes is only 1 line of clarification. > > > > Let me rephrase my thoughts on this: > > the example in Appendix A is not a Multi-link Frame Relay > example, and > Multi-link Frame Relay is not mentioned at all. If Multi-link > would have > been mentioned, in one way or another, then I could have better > seen a > reason for confusion, and a need for clarification, but without > that, > this is a way to not extend the scope beyond what was intended, > and also > minimize the number of words or sentences. > > Thanks again for your input. > and regards, > Alex > > > ------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > IPng Home Page: > http://playground.sun.com/ipng > FTP archive: > ftp://playground.sun.com/pub/ipng > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > ------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 12 09:10:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6CG87Q04242 for ipng-dist; Wed, 12 Jul 2000 09:08:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6CG7w604235 for ; Wed, 12 Jul 2000 09:07:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA20165 for ; Wed, 12 Jul 2000 09:07:58 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09625 for ; Wed, 12 Jul 2000 10:07:56 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA12859 for ; Wed, 12 Jul 2000 09:07:54 -0700 (MST)] Received: [from m-zuk02-r1.mot.com (m-zuk02-r1.mot.com [140.101.234.21]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA12645 for ; Wed, 12 Jul 2000 09:07:53 -0700 (MST)] Received: from [140.101.173.9] by m-zuk02-r1.mot.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Jul 2000 09:07:48 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id SAA22165 for ipng@sunroof.eng.sun.com.DELIVER; Wed, 12 Jul 2000 18:07:50 +0200 (METDST) Received: from crm.mot.com (cedric.crm.mot.com [140.101.173.77]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id SAA22135 for ; Wed, 12 Jul 2000 18:07:49 +0200 (METDST) Message-Id: <396C97C5.C29A8F87@crm.mot.com> Date: Wed, 12 Jul 2000 18:07:33 +0200 From: Christophe Janneteau Reply-To: Christophe Janneteau-ACJ006 Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: multicast address type? Content-Type: multipart/mixed; boundary="------------D2CBCCCFF09FB99DF9EE6A91" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------D2CBCCCFF09FB99DF9EE6A91 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, I am wondering if there exist (in IPv6) a well-known multicast address type that would allow a host in subnet 'A' to send an IP packet to all nodes in a subnet 'B'. I am aware of the link-local all-node multicast address but what I am looking for is the same support when the sender is not attached to that link. Thanks for your help. Christophe. --------------D2CBCCCFF09FB99DF9EE6A91 Content-Type: text/x-vcard; charset=us-ascii; name="Christophe.Janneteau.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Christophe Janneteau Content-Disposition: attachment; filename="Christophe.Janneteau.vcf" begin:vcard n:Janneteau;Christophe tel;fax:+33 1 69 35 25 01 tel;work:+33 1 69 35 25 00 x-mozilla-html:FALSE org:MOTOROLA LABS version:2.1 email;internet:Christophe.Janneteau@crm.mot.com adr;quoted-printable:;;Centre de Recherche de Motorola - Paris=0D=0AEspace technologique - St Aubin=0D=0A;Gif sur Yvette;;91193;France fn:Christophe Janneteau end:vcard --------------D2CBCCCFF09FB99DF9EE6A91-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 12 13:18:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6CKFfU04535 for ipng-dist; Wed, 12 Jul 2000 13:15:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6CKF2604528 for ; Wed, 12 Jul 2000 13:15:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA11060 for ; Wed, 12 Jul 2000 13:15:00 -0700 (PDT) Received: from mailscan2.idt.net (smtp.corp.idt.net [207.202.32.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA25977 for ; Wed, 12 Jul 2000 14:14:57 -0600 (MDT) Received: from 207.202.32.33 by mailscan2.idt.net (InterScan E-Mail VirusWall NT); Wed, 12 Jul 2000 16:11:44 -0400 (Eastern Daylight Time) Received: from [169.132.191.15] [169.132.191.15] by mail.corp.idt.net with ESMTP (SMTPD32-6.03) id A1DD93AC00F2; Wed, 12 Jul 2000 16:15:28 -0400 User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Wed, 12 Jul 2000 16:15:26 -0400 Subject: IPv6 Wireless From: Brian Barnes To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk List members, I'm writing an article addressing the significance of IPv6 as it relates to wireless Internet access. If anyone would be interested in an e-mail interview and possible publication of your responses, please e-mail me privately. Thanks in advance, ------------- Brian Barnes Managing Editor Internet Industry Magazine PH: (212) 977-3800 FAX: (212) 977-4545 http://www.internetindustry.com http://www.netventure2000.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 12 21:45:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6D4hR904861 for ipng-dist; Wed, 12 Jul 2000 21:43:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6D4hI604854 for ; Wed, 12 Jul 2000 21:43:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA14819 for ; Wed, 12 Jul 2000 21:43:18 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11961 for ; Wed, 12 Jul 2000 21:43:12 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id NAA04367; Thu, 13 Jul 2000 13:27:45 +0900 (JST) Date: Thu, 13 Jul 2000 13:38:20 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Christophe_Janneteau-ACJ006@email.mot.com Cc: ipng@sunroof.eng.sun.com Subject: Re: multicast address type? In-Reply-To: In your message of "Wed, 12 Jul 2000 18:07:33 +0200" <396C97C5.C29A8F87@crm.mot.com> References: <396C97C5.C29A8F87@crm.mot.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 12 Jul 2000 18:07:33 +0200, >>>>> Christophe Janneteau said: > I am wondering if there exist (in IPv6) a well-known multicast address > type that would allow a host in subnet 'A' to send an IP packet to all > nodes in a subnet 'B'. I am aware of the link-local all-node multicast > address but what I am looking for is the same support when the sender is > not attached to that link. I guess you mean equivalents of subnet broadcast addresses in IPv4. In my understanding, there are no such address types in IPv6 (correct me if I'm wrong). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 12 21:46:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6D4jPo04872 for ipng-dist; Wed, 12 Jul 2000 21:45:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6D4j9604863 for ; Wed, 12 Jul 2000 21:45:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA01351 for ; Wed, 12 Jul 2000 21:45:08 -0700 (PDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA28156 for ; Wed, 12 Jul 2000 22:45:07 -0600 (MDT) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id NAA19830 for ; Thu, 13 Jul 2000 13:45:06 +0900 (JST) (envelope-from eguchi.makoto@lab.ntt.co.jp) Received: from ime.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/07/11/00) with ESMTP id NAA26583 for ; Thu, 13 Jul 2000 13:45:05 +0900 (JST) (envelope-from eguchi.makoto@lab.ntt.co.jp) Received: from lab.ntt.co.jp (silvia5.pflab.ecl.ntt.co.jp [129.60.16.46]) by ime.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA26281 for ; Thu, 13 Jul 2000 13:45:05 +0900 (JST) Message-ID: <396D4950.5B4E405C@lab.ntt.co.jp> Date: Thu, 13 Jul 2000 13:45:04 +0900 From: Makoto EGUCHI X-Mailer: Mozilla 4.7 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: current status of "Default Address Selection for IPv6" Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello. I'm Makoto Eguchi. I'd like to know the current status of "Default Address Selection for IPv6". As far as know "Default Address Selection for IPv6" has not been published as an RFC, but the latest draft "draft-ietf-ipngwg-default-addr-select-00.txt" has already expired (May 2000). How is status of this document? Which document should I refer to now? Thank you. -- Makoto EGUCHI NTT Information Sharing Platform Lab. E-mail:eguchi.makoto@lab.ntt.co.jp Tel:+81-422-59-4993 Fax:+81-422-37-7463 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 12 22:11:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6D59jD04902 for ipng-dist; Wed, 12 Jul 2000 22:09:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6D59a604895 for ; Wed, 12 Jul 2000 22:09:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA08946 for ; Wed, 12 Jul 2000 22:09:34 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA21005 for ; Wed, 12 Jul 2000 22:09:34 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Jul 2000 22:09:35 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id <3NA4RK58>; Wed, 12 Jul 2000 22:09:35 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8102511E4DC@RED-MSG-50> From: Richard Draves To: Makoto EGUCHI , ipng@sunroof.eng.sun.com Subject: RE: current status of "Default Address Selection for IPv6" Date: Wed, 12 Jul 2000 22:09:31 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I plan to submit an update this week. Thanks, Rich > -----Original Message----- > From: Makoto EGUCHI [mailto:eguchi.makoto@lab.ntt.co.jp] > Sent: Wednesday, July 12, 2000 9:45 PM > To: ipng@sunroof.eng.sun.com > Subject: current status of "Default Address Selection for IPv6" > > > Hello. > > I'm Makoto Eguchi. > > I'd like to know the current status of "Default Address Selection for > IPv6". > As far as know "Default Address Selection for IPv6" has not been > published > as an RFC, but the latest draft > "draft-ietf-ipngwg-default-addr-select-00.txt" > has already expired (May 2000). > > How is status of this document? > Which document should I refer to now? > > Thank you. > > -- > Makoto EGUCHI > NTT Information Sharing Platform Lab. > E-mail:eguchi.makoto@lab.ntt.co.jp > Tel:+81-422-59-4993 > Fax:+81-422-37-7463 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 13 05:37:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6DCZvR05198 for ipng-dist; Thu, 13 Jul 2000 05:35:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6DCYq605176; Thu, 13 Jul 2000 05:34:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA18061; Thu, 13 Jul 2000 05:34:52 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00899; Thu, 13 Jul 2000 05:34:50 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA23527; Thu, 13 Jul 2000 21:34:49 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA10875; Thu, 13 Jul 2000 21:34:49 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA11735; Thu, 13 Jul 2000 21:34:48 +0900 (JST) Date: Thu, 13 Jul 2000 21:33:53 +0900 (JST) Message-Id: <20000713.213353.104059320.kazu@Mew.org> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) IPv6 stuff on INET 2000 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <20000615.174254.15194874.kazu@Mew.org> References: <20000615.174254.15194874.kazu@Mew.org> X-Mailer: Mew version 1.95b46 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Kazu Yamamoto ($B;3K\OBI'(B) Subject: (ngtrans) IPv6 stuff on INET 2000 > I would like to summarize the current status of IPv6 stuff on INET > 2000: > > (1) Network Training Workshop (NTW) at Keio Univ. (not at Hokoyama), > 7/10-14 > > I'm now negotiating with some track leaders whether or not we will be > able to take time to give IPv6 tutorial for students from developing > countries. Itojun and Kazu have committed to be tutors. We (itojun & kazu) have finished this jobs both for track 1 and track 2. The material is now available from: http://playground.iijlab.net/material/kazu-ntw-presen/ See you in Yokohama. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 13 14:18:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6DLGST05517 for ipng-dist; Thu, 13 Jul 2000 14:16:28 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6DLGM605510 for ; Thu, 13 Jul 2000 14:16:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id OAA20709 for ipng@sunroof.eng.sun.com; Thu, 13 Jul 2000 14:14:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6DEpM605261; Thu, 13 Jul 2000 07:51:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA03858; Thu, 13 Jul 2000 07:51:21 -0700 (PDT) From: stuart.prevost@bt.com Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15723; Thu, 13 Jul 2000 07:51:19 -0700 (PDT) Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 13 Jul 2000 15:49:28 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLQTNG3>; Thu, 13 Jul 2000 15:49:25 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB207413A2D@mbtlipnt02.btlabs.bt.co.uk> To: ngtrans@sunroof.eng.sun.com, ipv6-wg@ripe.net, mir@ripe.net, ipng@sunroof.eng.sun.com, sig-ipv6@apnic.net, richardj@arin.net, Daniel.Karrenberg@ripe.net, joao@ripe.net Subject: IPv6 Policy Document Revision suggestion Date: Thu, 13 Jul 2000 15:47:30 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, From reading all the emails it seems that the /48 approach as the *minimum* allocation is the way the IETF would like IPv6 deployment to proceed. However, as it has been demonstrated, the /35 allocations today would only allow for 8,192 /48 per subTLA, and this is assuming that the subTLA holder hasn't split up the NLA block so they can allocate to other providers, in which case this figure could be as small as 256 or lower!!!! I see this as the reason why ISPs consider /48 for a home customer as too large, and hence the sliding-window & /56 discussion at the last RIPE meeting. Now, if the /48 allocation is the way to proceed, I feel that all initial /35 allocations should be initially changed to /29 as the first step. This can be done easily as all allocations have the /29 reserved to ensure a contiguous block. However a /29 allows for 524,288 /48, again if the whole subTLA is used. So at the same time the 80% utilisation section of the document needs to be worded correctly to allow ISPs to apply for subsequent subTLA's. Also I would like to ask the following question: How do we move from the current allocations of /29 & /35 to RFC2374 (IPv6 Aggregatable Global Unicast Address Format) and at what stage will this happen? Otherwise I can see organisations holding multiple subTLA before moving to the address structure in RFC2374, and more renumbering pain. Regards, Stuart Stuart Prevost --------------------------------------------------- IP Specialist, Futures Testbed Tel: +44 1473 646891 Fax: +44 1473 643906 Mobile: +44 7801 977290 Email: stuart.prevost@bt.com Addr: B29/136 - Adastral Park, Martlesham Heath, Ipswich. Suffolk. IP5 3RE -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 14:22:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6DLKWZ05544 for ipng-dist; Thu, 13 Jul 2000 14:20:32 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6DLKR605537 for ; Thu, 13 Jul 2000 14:20:27 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id OAA20772 for ipng@sunroof.eng.sun.com; Thu, 13 Jul 2000 14:18:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6DGXm605304 for ; Thu, 13 Jul 2000 09:33:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA19784 for ; Thu, 13 Jul 2000 09:33:48 -0700 (PDT) Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA26658 for ; Thu, 13 Jul 2000 09:33:46 -0700 (PDT) Received: (qmail 63213 invoked by uid 1007); 13 Jul 2000 16:33:43 -0000 Date: Thu, 13 Jul 2000 18:33:43 +0200 From: Gert Doering To: stuart.prevost@bt.com Cc: ngtrans@sunroof.eng.sun.com, ipv6-wg@ripe.net, mir@ripe.net, ipng@sunroof.eng.sun.com, sig-ipv6@apnic.net, richardj@arin.net, Daniel.Karrenberg@ripe.net, joao@ripe.net Subject: Re: IPv6 Policy Document Revision suggestion Message-ID: <20000713183343.P89890@Space.Net> References: <5104D4DBC598D211B5FE0000F8FE7EB207413A2D@mbtlipnt02.btlabs.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <5104D4DBC598D211B5FE0000F8FE7EB207413A2D@mbtlipnt02.btlabs.bt.co.uk>; from stuart.prevost@bt.com on Thu, Jul 13, 2000 at 03:47:30PM +0100 X-NCC-RegID: de.space Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, On Thu, Jul 13, 2000 at 03:47:30PM +0100, stuart.prevost@bt.com wrote: > From reading all the emails it seems that the /48 approach as the > *minimum* allocation is the way the IETF would like IPv6 deployment to > proceed. However, as it has been demonstrated, the /35 allocations today > would only allow for 8,192 /48 per subTLA, and this is assuming that the > subTLA holder hasn't split up the NLA block so they can allocate to other > providers, in which case this figure could be as small as 256 or lower!!!! > > I see this as the reason why ISPs consider /48 for a home customer > as too large, and hence the sliding-window & /56 discussion at the last RIPE > meeting. Exactly this was the reason from our side for welcoming the /48, /56, /64 suggestion: having more "elbow space" in the /35 allocated to us, being able to do reasobale NLA structuring (to our resellers, and to *their* resellers). regards, Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 14:32:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6DLUlp05601 for ipng-dist; Thu, 13 Jul 2000 14:30:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6DLUc605594 for ; Thu, 13 Jul 2000 14:30:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA07619 for ; Thu, 13 Jul 2000 14:30:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04664 for ; Thu, 13 Jul 2000 15:30:08 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA25395; Thu, 13 Jul 2000 14:27:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA11848; Thu, 13 Jul 2000 14:27:40 -0700 X-Virus-Scanned: Thu, 13 Jul 2000 14:27:40 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpde5hSvk; Thu, 13 Jul 2000 14:27:37 PDT Message-Id: <4.3.2.7.2.20000713142500.0254f0b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jul 2000 14:25:13 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: New "IP Version 6 Addressing Architecture" draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted a new version of "IP Version 6 Addressing Architecture" to be an internet draft. Until is available in the ID directories it can be found at: ftp://playground.sun.com/pub/hinden/draft-ietf-ipngwg-addr-arch-v3-01.txt The changes in this draft resolve issues raised in the w.g. last call for Draft Standard, removed the appendix defining ABNF description of text representations because it was not correct, and unassigning the IPX address block because there does not appear to be any current or planned usage. Overall the changes from RFC2373 are: - Removed the ABNF Description of Text Representations Appendix. - Changed the address block reserved for IPX addresses to unassigned. - Multicast scope name changes: o Changed name of scope value 1 from "node-local" to "interface-local" o Reserved scope value 3 for "subnet-local" for multi-link subnets o Defined scope value 4 as "admin-local" - Clarified text describing Exchanges. - Corrected reference to RFC1933 and updated references. - Several minor textual clarifications. Once the new draft is out, it will be sent to the IESG for Draft Standard. This document will replace RFC2373. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 13 14:53:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6DLp8w05663 for ipng-dist; Thu, 13 Jul 2000 14:51:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6DLnt605641; Thu, 13 Jul 2000 14:49:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA09915; Thu, 13 Jul 2000 14:49:56 -0700 (PDT) From: george.tsirtsis@bt.com Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20314; Thu, 13 Jul 2000 15:49:54 -0600 (MDT) Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 13 Jul 2000 22:49:38 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GKHCJ9G>; Thu, 13 Jul 2000 22:49:35 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2078A59F9@mbtlipnt02.btlabs.bt.co.uk> To: stuart.prevost@bt.com, ngtrans@sunroof.eng.sun.com, ipv6-wg@ripe.net, mir@ripe.net, ipng@sunroof.eng.sun.com, sig-ipv6@apnic.net, richardj@arin.net, Daniel.Karrenberg@ripe.net, joao@ripe.net Subject: RE: (ngtrans) IPv6 Policy Document Revision suggestion Date: Thu, 13 Jul 2000 22:47:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just to complement Stuart's position > -----Original Message----- > From: stuart.prevost@bt.com [SMTP:stuart.prevost@bt.com] > Sent: Thursday, July 13, 2000 3:48 PM > To: ngtrans@sunroof.eng.sun.com; ipv6-wg@ripe.net; mir@ripe.net; > ipng@sunroof.eng.sun.com; sig-ipv6@apnic.net; richardj@arin.net; > Daniel.Karrenberg@ripe.net; joao@ripe.net > Subject: (ngtrans) IPv6 Policy Document Revision suggestion > From reading all the emails it seems that the /48 approach as the *minimum* allocation is the way the IETF would like IPv6 deployment to proceed. However, as it has been demonstrated, the /35 allocations today would only allow for 8,192 /48 per subTLA, and this is assuming that the subTLA holder hasn't split up the NLA block so they can allocate to other providers, in which case this figure could be as small as 256 or lower!!!! > I see this as the reason why ISPs consider /48 for a home customer > as too large, and hence the sliding-window & /56 discussion at the last > RIPE > meeting. > > Note that we recognise the benefits of /48 for multihoming/rehomeing and maybe more importantly to make sure that IPv6 NAT will *never* become a reality! Thus, as an ISP, we support /48 allocations if can be confident that we can get enough of them; i.e.: we get /29s instead of /35s. > Now, if the /48 allocation is the way to proceed, I feel that all > initial /35 allocations should be initially changed to /29 as the first > step. This can be done easily as all allocations have the /29 reserved to > ensure a contiguous block. However a /29 allows for 524,288 /48, again if > the whole subTLA is used. So at the same time the 80% utilisation section > of the document needs to be worded correctly to allow ISPs to apply for > subsequent subTLA's. > That is: the 80% (or whatever utilisation) to refer to the number of /48s in a subTLA since ISPs will have no control over how and when our customers, home users, SOHOs, mobile users are going to utilise their /48 prefix! Regards George -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 13 14:54:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6DLqrq05687 for ipng-dist; Thu, 13 Jul 2000 14:52:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6DLpf605665; Thu, 13 Jul 2000 14:51:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25920; Thu, 13 Jul 2000 14:51:42 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21534; Thu, 13 Jul 2000 15:51:40 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA32046; Thu, 13 Jul 2000 22:50:35 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA18482; Thu, 13 Jul 2000 22:50:54 +0100 (BST) Message-ID: <396E3123.20A1BCE0@hursley.ibm.com> Date: Thu, 13 Jul 2000 16:14:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Gert Doering CC: stuart.prevost@bt.com, ngtrans@sunroof.eng.sun.com, ipv6-wg@ripe.net, mir@ripe.net, ipng@sunroof.eng.sun.com, sig-ipv6@apnic.net, richardj@arin.net, Daniel.Karrenberg@ripe.net, joao@ripe.net Subject: Re: IPv6 Policy Document Revision suggestion References: <5104D4DBC598D211B5FE0000F8FE7EB207413A2D@mbtlipnt02.btlabs.bt.co.uk> <20000713183343.P89890@Space.Net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Now we're getting to the point I think. We are messing around doing slow start and sub-allocations inside sub-TLAs, ignoring that fact that all the sub-TLAs together only eat up one TLA, and we have thousands of TLAs available. There is no need to impose these artificial constraints on the ISPs. Brian Gert Doering wrote: > > Hi, > > On Thu, Jul 13, 2000 at 03:47:30PM +0100, stuart.prevost@bt.com wrote: > > From reading all the emails it seems that the /48 approach as the > > *minimum* allocation is the way the IETF would like IPv6 deployment to > > proceed. However, as it has been demonstrated, the /35 allocations today > > would only allow for 8,192 /48 per subTLA, and this is assuming that the > > subTLA holder hasn't split up the NLA block so they can allocate to other > > providers, in which case this figure could be as small as 256 or lower!!!! > > > > I see this as the reason why ISPs consider /48 for a home customer > > as too large, and hence the sliding-window & /56 discussion at the last RIPE > > meeting. > > Exactly this was the reason from our side for welcoming the /48, /56, /64 > suggestion: having more "elbow space" in the /35 allocated to us, being > able to do reasobale NLA structuring (to our resellers, and to *their* > resellers). > > regards, > > Gert Doering > -- NetMaster > -- > SpaceNet GmbH Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 14 03:52:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6EAp0f05977 for ipng-dist; Fri, 14 Jul 2000 03:51:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6EAon605970 for ; Fri, 14 Jul 2000 03:50:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA08388 for ; Fri, 14 Jul 2000 03:50:49 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20494 for ; Fri, 14 Jul 2000 04:50:47 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08933; Fri, 14 Jul 2000 06:50:47 -0400 (EDT) Message-Id: <200007141050.GAA08933@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-ipv6-ind-04.txt Date: Fri, 14 Jul 2000 06:50:46 -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 : Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification Author(s) : A. Conta Filename : draft-ietf-ion-ipv6-ind-04.txt Pages : 21 Date : 13-Jul-00 This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to solicit and be advertised an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. They specifically apply to Frame Relay networks but they may also apply to other networks with similar behavior. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ion-ipv6-ind-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-ipv6-ind-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ion-ipv6-ind-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: <20000713145209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-ipv6-ind-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-ipv6-ind-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145209.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 Jul 14 09:14:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6EGDNY06113 for ipng-dist; Fri, 14 Jul 2000 09:13:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6EGDE606106 for ; Fri, 14 Jul 2000 09:13:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA16172 for ; Fri, 14 Jul 2000 09:13:14 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15574 for ; Fri, 14 Jul 2000 09:13:09 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id C9445496; Fri, 14 Jul 2000 12:13:02 -0400 (EDT) Received: from yquarry.zk3.dec.com (byquarry.zk3.dec.com [16.140.96.30]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 807984AD; Fri, 14 Jul 2000 12:13:02 -0400 (EDT) Received: from hunch.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id MAA0000025941; Fri, 14 Jul 2000 12:13:02 -0400 (EDT) Received: by hunch.zk3.dec.com (8.9.3/1.1.20.6/21Apr99-0623AM) id MAA0000295164; Fri, 14 Jul 2000 12:13:01 -0400 (EDT) Date: Fri, 14 Jul 2000 12:13:01 -0400 (EDT) From: Jack McCann Message-Id: <200007141613.MAA0000295164@hunch.zk3.dec.com> To: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft Cc: mccann@hunch.zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk During w.g. last call, I suggested a change of wording in the definition of IPv4-mapped addresses (mail attached below). I see the suggestion was not incorporated in addr-arch-v3-01. Let me offer an example of what motivated my suggestion. Suppose we have 2 IPv6/IPv4 nodes: Node A has IPv6 address A::A and IPv4 address 1.2.3.4. Node B has IPv6 address B::B and IPv4 address 5.6.7.8. Node A is running a server which is listening for both IPv4 and IPv6 connections on an AF_INET6 socket. A client on node B connects to node A's IPv4 address (1.2.3.4), with packets sourced from B's IPv4 address (5.6.7.8). (Why does the client use A's IPv4 address? Perhaps it is an AF_INET application that has not yet been upgraded, or perhaps the user entered 1.2.3.4.) The server on node A accepts the connection, and because it is using AF_INET6 sockets, accept() returns B's IPv4 address as ::FFFF:5.6.7.8. In this example, an IPv4-mapped address (::FFFF:5.6.7.8) is used to represent the address of an IPv6/IPv4 node (B). Is this correct usage of IPv4-mapped addresses? Or is it a violation of the architecture? - Jack ------------------------------------------------------------ From owner-ipng@sunroof.eng.sun.com Thu Mar 30 13:22:09 2000 Date: Thu, 30 Mar 2000 13:16:21 -0500 (EST) From: Jack McCann To: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" IPv4-mapped addresses are defined as: A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address is used to represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address"... IPv4-mapped addresses are not limited to IPv4-only nodes. They can also be used to represent the IPv4 address of an IPv6/IPv4 node, or more generally, to represent any IPv4 address in an IPv6 address format. I suggest replacing this sentence: This address is used to represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. with something like this: This address is used to represent an IPv4 address (for example, the IPv4 address of an IPv4-only or IPv6/IPv4 node) in an IPv6 address format. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 11:43:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6EIfF006206 for ipng-dist; Fri, 14 Jul 2000 11:41:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6EIf4606199 for ; Fri, 14 Jul 2000 11:41:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA00140 for ; Fri, 14 Jul 2000 11:41:02 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19322 for ; Fri, 14 Jul 2000 11:41:00 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id NAA04156; Fri, 14 Jul 2000 13:40:51 -0500 (CDT) Message-Id: <200007141840.NAA04156@gungnir.fnal.gov> To: Jun-ichiro itojun Hagino , jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: icmp-name-lookups-05.txt>: NOOP In-reply-to: Your message of Wed, 10 May 2000 00:30:26 +0900. <5017.957886226@lychee.itojun.org> Date: Fri, 14 Jul 2000 13:40:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I jave just submitted a revision of ICMP Name Lookups which addresses most of Tatuya's and Itojun's concerns. Not addressed was this: > also, we may have scope issue here. What should happen in the > following cases: > - if you got node information query from/to global IPv6 address, > with link-local subject address for your node > - if we got query from/to link-local address on interface A, with > link-local subject address for interface B Which, unless there's very strong feeling to the contrary, I'd like to consider as covered already by this existing text: Next, the Responder should decide whether to refuse an answer, based on local policy not addressed in this document. Also not addressed was: - if your (receiving) node node offers proxy service, and you've got scoped subject address in a query packet, how should we interpret the subject address? This, I think, could either be subtle or obvious depending on the implementation of the proxy. I think it's clear that a proxy node information server has to be in a position to receive any query meant for the node it's standing in for, so it has to be attached to that node's link. Everything follows from that unless difficult cases are deliberately constructed. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 14 14:42:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6ELc5l06464 for ipng-dist; Fri, 14 Jul 2000 14:38:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6ELbv606457 for ; Fri, 14 Jul 2000 14:37:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA23135 for ; Fri, 14 Jul 2000 14:37:57 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28068 for ; Fri, 14 Jul 2000 15:37:57 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id OAA29927; Fri, 14 Jul 2000 14:37:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81024BCF700@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81024BCF700@RED-MSG-50> Date: Fri, 14 Jul 2000 14:39:01 -0700 To: Richard Draves From: Steve Deering Subject: RE: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:52 AM -0700 6/30/00, Richard Draves wrote: >My first reaction is I think your suggestions (reproduced below) are logical >& consistent, but I do worry about one thing. Two weeks late in answering (better than usual for me)... > If I understand correctly, you're saying that a user could say > ping6 fec0::1%3 >where 3 could be an interface index. On a multi-sited node, this would say >"I mean fec0::1 in the site that interface 3 belongs to". But it would not >constrain the packet to actually being sent out interface 3. It could be >sent via any interface belonging to the same site as interface 3. Yes, that's exactly what I was suggesting. > My worry is that this would be rather confusing & nonintuitive for users. Indeed. My only reason for suggesting it is to provide backwards compatibility for implementations that are already using interface IDs (instead of link zone IDs) in the sin6_scope_id field for link-local addresses. Perhaps this backwards compatibility goal could be met in a different way, e.g., applying the "non-intuitive" semantics described above only to link-local addresses, or saying that interface IDs can serve as link zone IDs iff a node is attached to one link per interface (by far the dominant case). That latter suggestion is kinda the opposite of Dave Thaler's suggestion that for scopes that have not locally been assigned zone IDs, an app can use the IDs of a larger zone; in this case, we would be saying that an app can use the IDs of a smaller zone. My *preference* would be to say that sin6_scope_id must contain a zone ID of the same scope as the accompanying address. But I anticipate opposition to that. 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 Jul 14 14:57:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6ELt5406524 for ipng-dist; Fri, 14 Jul 2000 14:55:05 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6ELst606517 for ; Fri, 14 Jul 2000 14:54:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA18264 for ; Fri, 14 Jul 2000 14:54:55 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08485 for ; Fri, 14 Jul 2000 15:54:55 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id OAA01041; Fri, 14 Jul 2000 14:53:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: References: <200006270805.KAA05747@givry.rennes.enst-bretagne.fr> Date: Fri, 14 Jul 2000 14:55:24 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: rfc2553bis comments Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:52 AM +0900 7/1/00, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >Hmm...this is surely a candidate that we can compromise, but please >let me ask you some questions about this model: > >- In this model, we still interpret sin6_scope_id as a single space > (over all scopes), right? Right. >- Are we tring to allow users to specify broader scopes than > interfaces in in6_pktinfo? (Note that the in6_pktinfo structure > specifies an *interface* index according to RFC2292: > struct in6_pktinfo { > struct in6_addr ipi6_addr; /* src/dst IPv6 address */ > unsigned int ipi6_ifindex; /* send/recv interface index */ > }; > There's no ambiguity in this point, so if the answer is yes, then we > are trying to make an extension to the advanced API.) The answer is yes. >- If the answer to the previous question is yes, the interpretation of > in6_pktinfo.ipi6_ifindex can be differrent between the sending side > and the receiving side; for the sending side, we allow all type of > zone identifier (as far as it is valid according to the > corresponding address). For the receiving side, it is always > interpreted as an interface index. It's not just "interpreted" as an interface index; it is an interface index. Other than that, yes, your understanding of my proposal is correct: the sender can use the ipi6_ifindex field to specify any interface or zone ID (which assumes a single numbering space for interfaces plus zones); the receiver can discover the arrival interface from the ipi6_ifindex field (from which the receiver can also derive which zones the packet arrived from, one for each scope). >- What if we specify a zone ID of a broader scope than interface for > IPV6_JOIN_GROUP? Does this mean we're listening to the multicast > group on all the interfaces of the zone? No. If a broader zone ID is specified, the IP layer is free to choose one interface within that zone on which to enable multicast reception. This is a generalization of the notion of a "default" multicast reception interface. >Regardless of the answers to the questions, I think I have to consider >the model more carefully...personally, I still think we should go with >a simpler way (i.e the traditional way), but I may be wrong. Could you briefly describe the "traditional way"? 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 Jul 14 15:00:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6ELxdI06547 for ipng-dist; Fri, 14 Jul 2000 14:59:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6ELxU606540 for ; Fri, 14 Jul 2000 14:59:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA15082 for ; Fri, 14 Jul 2000 14:59:31 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA09269 for ; Fri, 14 Jul 2000 14:59:27 -0700 (PDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Jul 2000 15:00:41 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id <36ZZAZ4W>; Fri, 14 Jul 2000 15:00:35 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810253772DA@RED-MSG-50> From: Richard Draves To: "IPng List (E-mail)" Subject: draft-ietf-ipngwg-default-addr-select-01.txt Date: Fri, 14 Jul 2000 15:00:39 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I sent this in earlier today. I believe this revision resolves all the open issues. ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngwg-default-addr -select-01.txt. The main changes from the previous version: Changed the candidate set definition so that the strong host model is recommended but not required. Added a rule to source address selection to prefer addresses assigned to the outgoing interface. Simplified the destination address selection algorithm, by having it use source address selection as a subroutine. Added a rule to source address selection to handle anonymous/public addresses. Added a rule to source address selection to handle home/care-of addresses. Changed to allow destination address selection to sort both IPv6 and IPv4 addresses. Added entries in the default policy table for IPv4- mapped addresses. Changed default precedences, so v4-compatible addresses have lower precedence than 6to4 addresses. As usual, comments welcomed... 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 Jul 17 03:40:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6HAdOP07350 for ipng-dist; Mon, 17 Jul 2000 03:39:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6HAdC607343 for ; Mon, 17 Jul 2000 03:39:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA14783 for ; Mon, 17 Jul 2000 03:39:10 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06381 for ; Mon, 17 Jul 2000 04:39:09 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24629; Mon, 17 Jul 2000 06:39:08 -0400 (EDT) Message-Id: <200007171039.GAA24629@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-01.txt Date: Mon, 17 Jul 2000 06:39:08 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-01.txt Pages : 25 Date : 14-Jul-00 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v3-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-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: <20000714142545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714142545.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 Jul 17 04:39:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6HBbnh07376 for ipng-dist; Mon, 17 Jul 2000 04:37:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6HBbe607369 for ; Mon, 17 Jul 2000 04:37:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA18200 for ; Mon, 17 Jul 2000 04:37:39 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA16522 for ; Mon, 17 Jul 2000 04:37:38 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 17 Jul 2000 05:36:10 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 17 Jul 2000 05:35:59 -0600 From: "Narsimharao Nagampalli" To: Subject: TCP Connection Identifiers in IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e6HBbf607370 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In IPv4 a TCP connection was uniquely distinguished with the help of the 4 tuple. Does this hold good with IPv6? I can think of the following scenario caused by scoping, where such a identification might fail. In IPv6 scenario, if a node with multiple links having same link local addresses on both the interfaces exists, then it is possible that the 4 tuple is no longer sufficient to determine a connection uniquely. There has to be an interface identifier added as the 5th element to now distinguish across connections. Any comments/suggestions? Thanks, Narsi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 17 08:10:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6HF9Nx07535 for ipng-dist; Mon, 17 Jul 2000 08:09:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6HF9E607528 for ; Mon, 17 Jul 2000 08:09:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA18337 for ; Mon, 17 Jul 2000 08:09:14 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28381 for ; Mon, 17 Jul 2000 08:09:10 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA21370; Mon, 17 Jul 2000 23:53:54 +0900 (JST) Date: Tue, 18 Jul 2000 00:04:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis comments In-Reply-To: In your message of "Fri, 14 Jul 2000 14:55:24 -0700" References: <200006270805.KAA05747@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 14 Jul 2000 14:55:24 -0700, >>>>> Steve Deering said: >> - If the answer to the previous question is yes, the interpretation of >> in6_pktinfo.ipi6_ifindex can be differrent between the sending side >> and the receiving side; for the sending side, we allow all type of >> zone identifier (as far as it is valid according to the >> corresponding address). For the receiving side, it is always >> interpreted as an interface index. > It's not just "interpreted" as an interface index; it is an interface > index. Okay, actually, my intention was that "it *was* an interface index". Sorry for the confusing wording. >> Regardless of the answers to the questions, I think I have to consider >> the model more carefully...personally, I still think we should go with >> a simpler way (i.e the traditional way), but I may be wrong. > Could you briefly describe the "traditional way"? - in6_pktinfo.ipi6_ifindex takes/returns interface indices only. - IPV6_MULTICAST_IF, IPV6_JOIN_GROUP, IPV6_LEAVE_GROUP etc. take interface indices only. Also, I prefer - the sin6_scope_id field takes/returns zone indices of the same scope as the corresponding address specified in the sin6_addr field. (e.g. if sin6_addr is "fec0::1" or "ff05::a", then the corresponding sin6_scope_id field MUST be a site ID) although we can't say this "traditional" yet. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 17 08:10:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6HF9kP07544 for ipng-dist; Mon, 17 Jul 2000 08:09:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6HF9Z607537 for ; Mon, 17 Jul 2000 08:09:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA24335 for ; Mon, 17 Jul 2000 08:09:35 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19109 for ; Mon, 17 Jul 2000 09:09:31 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA21373; Mon, 17 Jul 2000 23:54:05 +0900 (JST) Date: Tue, 18 Jul 2000 00:04:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: RE: rfc2553bis comments In-Reply-To: In your message of "Fri, 14 Jul 2000 14:39:01 -0700" References: <4D0A23B3F74DD111ACCD00805F31D81024BCF700@RED-MSG-50> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 14 Jul 2000 14:39:01 -0700, >>>>> Steve Deering said: >> My worry is that this would be rather confusing & nonintuitive for users. > Indeed. My only reason for suggesting it is to provide backwards > compatibility for implementations that are already using interface IDs > (instead of link zone IDs) in the sin6_scope_id field for link-local > addresses. Perhaps this backwards compatibility goal could be met in a > different way, e.g., applying the "non-intuitive" semantics described > above only to link-local addresses, or saying that interface IDs can > serve as link zone IDs iff a node is attached to one link per interface > (by far the dominant case). I prefer the latter, (which is the intention of KAME's current implementation.) > That latter suggestion is kinda the opposite > of Dave Thaler's suggestion that for scopes that have not locally been > assigned zone IDs, an app can use the IDs of a larger zone; in this case, > we would be saying that an app can use the IDs of a smaller zone. > My *preference* would be to say that sin6_scope_id must contain a zone > ID of the same scope as the accompanying address. Me too. And if we take this way, is there any strong reason to define a single space shared by all scopes? (I don't necessarily oppose the idea for now, but I'm just wondering.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 17 09:43:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6HGfaY07686 for ipng-dist; Mon, 17 Jul 2000 09:41:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6HGfR607679 for ; Mon, 17 Jul 2000 09:41:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA12871 for ; Mon, 17 Jul 2000 09:41:27 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA18260 for ; Mon, 17 Jul 2000 10:41:25 -0600 (MDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jul 2000 09:32:37 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Mon, 17 Jul 2000 09:41:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4408.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF00D.CB0D7A84" Subject: RE: TCP Connection Identifiers in IPv6 Date: Mon, 17 Jul 2000 09:41:02 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690D8CEFB6@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP Connection Identifiers in IPv6 Thread-Index: Ab/v4/bAr8BqWv9lSNanbVpQGDNBBwAKZtkw From: "Dave Thaler" To: "Narsimharao Nagampalli" , X-OriginalArrivalTime: 17 Jul 2000 16:41:06.0887 (UTC) FILETIME=[CDDF5570:01BFF00D] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFF00D.CB0D7A84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This can be true in IPv4 as well... for example, if the IPv4 stack allows multiple interfaces to have=20 the same "autonet" (169.254...) addresses, which are roughly equivalent to link-local addresses. -Dave -----Original Message----- From: Narsimharao Nagampalli [mailto:NNARASIMHARAO@novell.com] Sent: Monday, July 17, 2000 4:36 AM To: ipng@sunroof.eng.sun.com Subject: TCP Connection Identifiers in IPv6 Hi, In IPv4 a TCP connection was uniquely distinguished with the help of the 4 tuple. Does this hold good with IPv6? I can think of the following scenario caused by scoping, where such a identification might fail. In IPv6 scenario, if a node with multiple links having same link local addresses on both the interfaces exists, then it is possible that the 4 tuple is no longer sufficient to determine a connection uniquely. There has to be an interface identifier added as the 5th element to now distinguish across connections.=20 Any comments/suggestions? Thanks, Narsi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01BFF00D.CB0D7A84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: TCP Connection Identifiers in IPv6

This can be true in IPv4 as well...  for = example,
if the IPv4 stack allows multiple interfaces to have =
the same "autonet" (169.254...) addresses, = which
are roughly equivalent to link-local = addresses.

-Dave

-----Original Message-----
From: Narsimharao Nagampalli [mailto:NNARASIMHARAO@novell.com<= /A>]
Sent: Monday, July 17, 2000 4:36 AM
To: ipng@sunroof.eng.sun.com
Subject: TCP Connection Identifiers in IPv6

Hi,

In IPv4 a TCP connection was uniquely distinguished = with the help of  the 4 tuple.  Does this hold good with IPv6? = I can think of the following scenario caused by scoping, where such a = identification might fail.

In IPv6 scenario, if a  node with multiple links = having same link local addresses on both the interfaces exists, then it = is possible that the 4 tuple is no longer sufficient to determine a = connection uniquely. There has to be an interface identifier added as = the 5th element to now distinguish across connections.

Any comments/suggestions?

Thanks,
Narsi

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

------_=_NextPart_001_01BFF00D.CB0D7A84-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 17 10:27:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6HHPxr07744 for ipng-dist; Mon, 17 Jul 2000 10:25:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6HHPn607734 for ; Mon, 17 Jul 2000 10:25:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA12520 for ; Mon, 17 Jul 2000 10:25:46 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04220 for ; Mon, 17 Jul 2000 10:25:41 -0700 (PDT) Received: from [171.68.181.48] (sj-dial-4-113.cisco.com [171.68.181.242]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id KAA17892; Mon, 17 Jul 2000 10:24:19 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: References: <4D0A23B3F74DD111ACCD00805F31D81024BCF700@RED-MSG-50> Date: Mon, 17 Jul 2000 10:24:57 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: RE: rfc2553bis comments Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:04 AM +0900 7/18/00, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Fri, 14 Jul 2000 14:39:01 -0700, > >>>>> Steve Deering said: > > My *preference* would be to say that sin6_scope_id must contain a zone > > ID of the same scope as the accompanying address. > >Me too. And if we take this way, is there any strong reason to define >a single space shared by all scopes? (I don't necessarily oppose the >idea for now, but I'm just wondering.) Two reasons: (a) to allow both interface IDs and link IDs to be used to identify the zone of a link-local address (for backwards compatibility with current practice). (b) for use in in6_pktinfo.ipi6_ifindex, to restrict the set of outgoing interfaces to a zone less than that implied by the destination address. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 17 19:59:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6I2wRC08240 for ipng-dist; Mon, 17 Jul 2000 19:58:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6I2wG608233 for ; Mon, 17 Jul 2000 19:58:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA05357 for ; Mon, 17 Jul 2000 19:58:15 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA02233 for ; Mon, 17 Jul 2000 19:58:15 -0700 (PDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Jul 2000 19:58:11 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id <38Z6H0RB>; Mon, 17 Jul 2000 19:58:10 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF010FFD@red-msg-24.redmond.corp.microsoft.com> From: Brian Zill To: "'Narsimharao Nagampalli'" , ipng@sunroof.eng.sun.com Subject: RE: TCP Connection Identifiers in IPv6 Date: Mon, 17 Jul 2000 19:58:05 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, you need to do this in order to support link-local (and also site-local) addresses properly. To be more general, it is best to tag incoming packets with appropriate scope id values based upon their arrival interface and address scopes. And then add those to the connection lookup criteria. This is what we do in our implementation. --Brian > -----Original Message----- > From: Narsimharao Nagampalli [mailto:NNARASIMHARAO@novell.com] > Sent: Monday, 17 July, 2000 04:36 > To: ipng@sunroof.eng.sun.com > Subject: TCP Connection Identifiers in IPv6 > > > Hi, > > In IPv4 a TCP connection was uniquely distinguished with the > help of the 4 tuple. Does this hold good with IPv6? I can > think of the following scenario caused by scoping, where such > a identification might fail. > > In IPv6 scenario, if a node with multiple links having same > link local addresses on both the interfaces exists, then it > is possible that the 4 tuple is no longer sufficient to > determine a connection uniquely. There has to be an interface > identifier added as the 5th element to now distinguish across > connections. > > Any comments/suggestions? > > Thanks, > Narsi > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 18 04:24:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6IBMi808522 for ipng-dist; Tue, 18 Jul 2000 04:22:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6IBMY608515 for ; Tue, 18 Jul 2000 04:22:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA17127 for ; Tue, 18 Jul 2000 04:22:33 -0700 (PDT) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25169 for ; Tue, 18 Jul 2000 04:22:32 -0700 (PDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id HAA01376 for ; Tue, 18 Jul 2000 07:23:13 -0400 Message-Id: <200007181123.HAA01376@hygro.adsl.duke.edu> To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-addrconf-privacy-02.txt Date: Tue, 18 Jul 2000 07:23:13 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich & I managed to get draft-ietf-ipngwg-addrconf-privacy-xx.txt revised before the cutoff. The main changes are to address the issues raised in Rich's mail to the ipng list on 6/6/2000. Specifically: 1) When a site has multiple active prefixes (e.g., is multihomed) it generates an anonymous address for each of those prefixes from the same random interface identifier. This reduces the number of solicited-node multicast addresses a node must join. 2) Public addresses are not deprecated as in -01. Instead, draft-ietf-ipngwg-default-addr-select-xx.txt was updated (and is in the publication queue) to give precedence to anonymous addresses. Note that this places a normative dependency from this document to default-addr-select. One advantage of this change is that the set of public addresses (and their associated liftimes) will be the same whether or not anonymous addresses are in use. Previously, the public address was deprecated (preferred lifetime set to 0) in order to ensure that it was not selected for outgoing communication. 3) Additional rules have been specified to ensure that when RAs update the lifetime of public addresses, the corresponding lifetimes of associated anonymous addresses are also updated. RAs can only shorten the lifetimes of anonymous addresses, not lengthen them. In the previous version of this draft, the lifetimes of anonymous addresses were not properly adjusted downward in some circumstances. For those who can't wait for the official draft, an advance copy is available at ftp://ftp.cs.duke.edu/pub/narten/ietf/draft-ietf-ipngwg-addrconf-privacy-02.txt Thomas & 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 Jul 18 04:53:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6IBplJ08550 for ipng-dist; Tue, 18 Jul 2000 04:51:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6IBpc608543 for ; Tue, 18 Jul 2000 04:51:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA00543 for ; Tue, 18 Jul 2000 04:51:35 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA29796 for ; Tue, 18 Jul 2000 05:51:36 -0600 (MDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 18 Jul 2000 05:51:23 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 18 Jul 2000 05:51:02 -0600 From: "Narsimharao Nagampalli" To: , , Cc: Subject: IPv6 Scoped Address Architecture (RFC 2710) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e6IBpd608544 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In the RFC (2710) on the scoped address architecture, we seem to consider scenarios where source address can be smaller scope than the destination address. I have two concerns regarding the same and also would be interested to know of scenarios where such a feature is useful. Fragmentation One concern is regarding IPv6 fragmentation. There we use the source address followed by a unique ID generated at the source to define a fragmentation sequence. Now, consider the case where two link local addressed sources are sending fragments to a site-local address and happen to use the same ID's. I can not see a way in which the destination can re-assemble these two train of fragments properly. Flow Label Same issue like fragment ID. Flow label ID and Src address again are used together to identify a flow. In the above scenario again, there could be issues in distinguishing across flows. Any comments/Insights? Thanks and Regards Narsi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 18 05:32:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6ICVW608579 for ipng-dist; Tue, 18 Jul 2000 05:31:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6ICVN608572 for ; Tue, 18 Jul 2000 05:31:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA21838 for ; Tue, 18 Jul 2000 05:31:24 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA18653 for ; Tue, 18 Jul 2000 05:31:24 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 18 Jul 2000 06:29:18 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 18 Jul 2000 06:28:58 -0600 From: "Narsimharao Nagampalli" To: , , , "Narsimharao Nagampalli" Cc: Subject: Re: IPv6 Scoped Address Architecture (RFC 2710) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e6ICVO608573 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am sorry, I referred a wrong RFC Number. It was the draft on IPv6 Scoped Architecture. Regards Narsi >>> "Narsimharao Nagampalli" 07/18/00 05:21PM >>> Hi, In the RFC (2710) on the scoped address architecture, we seem to consider scenarios where source address can be smaller scope than the destination address. I have two concerns regarding the same and also would be interested to know of scenarios where such a feature is useful. Fragmentation One concern is regarding IPv6 fragmentation. There we use the source address followed by a unique ID generated at the source to define a fragmentation sequence. Now, consider the case where two link local addressed sources are sending fragments to a site-local address and happen to use the same ID's. I can not see a way in which the destination can re-assemble these two train of fragments properly. Flow Label Same issue like fragment ID. Flow label ID and Src address again are used together to identify a flow. In the above scenario again, there could be issues in distinguishing across flows. Any comments/Insights? Thanks and Regards Narsi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 18 09:14:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6IGCgG08738 for ipng-dist; Tue, 18 Jul 2000 09:12:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6IGCX608731 for ; Tue, 18 Jul 2000 09:12:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA15122 for ; Tue, 18 Jul 2000 09:12:32 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24463 for ; Tue, 18 Jul 2000 09:12:30 -0700 (PDT) Received: from [171.68.181.115] (sj-dial-4-106.cisco.com [171.68.181.235]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id JAA05760; Tue, 18 Jul 2000 09:11:41 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: References: Date: Tue, 18 Jul 2000 09:12:22 -0700 To: "Narsimharao Nagampalli" From: Steve Deering Subject: Re: IPv6 Scoped Address Architecture (RFC 2710) Cc: , , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:51 AM -0600 7/18/00, Narsimharao Nagampalli wrote: >Fragmentation >One concern is regarding IPv6 fragmentation. There we use the source address followed by a unique ID generated at the source to define a fragmentation sequence. Now, consider the case where two link local addressed sources are sending fragments to a site-local address and happen to use the same ID's. I can not see a way in which the destination can re-assemble these two train of fragments properly. > >Flow Label >Same issue like fragment ID. Flow label ID and Src address again are used together to identify a flow. In the above scenario again, there could be issues in distinguishing across flows. Narsi, A packet is not permitted to leave the zone of uniqueness of its source address (see section 9 of the scoped architecture draft, second bullet), so your example problems ought not to arise. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 18 16:10:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6IN8qR09193 for ipng-dist; Tue, 18 Jul 2000 16:08:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6IN8h609186 for ; Tue, 18 Jul 2000 16:08:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA03197 for ; Tue, 18 Jul 2000 16:08:42 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16556 for ; Tue, 18 Jul 2000 17:08:39 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id IAA08327; Wed, 19 Jul 2000 08:08:32 +0900 To: linux-ipv6-jp@linux.or.jp CC: ipng@sunroof.eng.sun.com Subject: Re: Some Comments on draft-ietf-ipngwg-rfc2553bis-00: Fw: Re: libc/1635: Values of AI_* are conflicted From: Hideaki YOSHIFUJI X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Jul_19_08:03:37_2000_167)--" Content-Transfer-Encoding: 7bit Message-Id: <20000719080832L.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 19 Jul 2000 08:08:32 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 55 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----Next_Part(Wed_Jul_19_08:03:37_2000_167)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit One problem lives in glibc have been solved. Please note we still have to check if they are conflicted to detect wheter we can use new semantics (for source compatibility). -- Hideaki YOSHIFUJI @ USAGI Project Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 ----Next_Part(Wed_Jul_19_08:03:37_2000_167)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Return-Path: Return-Path: Received: from ecei.tohoku.ac.jp (eimail.ecei.tohoku.ac.jp [130.34.195.2]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id HAA08283 for ; Wed, 19 Jul 2000 07:29:21 +0900 X-Authentication-Warning: cerberus.nemoto.ecei.tohoku.ac.jp: Host eimail.ecei.tohoku.ac.jp [130.34.195.2] claimed to be ecei.tohoku.ac.jp Received: from v6.linux.or.jp (daemon@chiharu.not.v6.linux.or.jp [210.157.158.25]) by ecei.tohoku.ac.jp (8.9.3/3.7W) with ESMTP id HAA12809 for ; Wed, 19 Jul 2000 07:29:21 +0900 (JST) Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144] (may be forged)) by v6.linux.or.jp (8.9.3+3.2W/3.7W) with ESMTP id HAA30408 for ; Wed, 19 Jul 2000 07:32:35 +0900 (envelope-from kettenis@wins.uva.nl) Received: from delius.kettenis.local ([213.46.27.170]) by relay01.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 2ee4e7c625482f2f2a1950a80f6c8d58) with ESMTP id <20000718223015.FOKM18313.relay01@delius.kettenis.local>; Wed, 19 Jul 2000 00:30:15 +0200 Received: (from kettenis@localhost) by delius.kettenis.local (8.10.1/8.10.1) id e6IMT1Q07968; Wed, 19 Jul 2000 00:29:01 +0200 Date: Wed, 19 Jul 2000 00:29:01 +0200 From: Mark Kettenis Message-Id: <200007182229.e6IMT1Q07968@delius.kettenis.local> To: yoshfuji@v6.linux.or.jp CC: bugs@gnu.org Subject: Re: libc/1635: Values of AI_* are conflicted MIME-Version: 1.0 The conflicting AI_* valies have been renumbered. We could still change them since there hasn't been any official glibc release that contained getipnodebyname() yet (and even in the development version it isn't exported yet). I'll close the report soonish. Mark ----Next_Part(Wed_Jul_19_08:03:37_2000_167)---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 18 21:35:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6J4Y4J09438 for ipng-dist; Tue, 18 Jul 2000 21:34:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6J4Xu609431 for ; Tue, 18 Jul 2000 21:33:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA16302 for ; Tue, 18 Jul 2000 21:33:54 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA24799 for ; Tue, 18 Jul 2000 21:33:54 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 18 Jul 2000 22:33:34 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 18 Jul 2000 22:33:17 -0600 From: "Narsimharao Nagampalli" To: Cc: , , Subject: Re: IPv6 Scoped Address Architecture (RFC 2710) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e6J4Xu609432 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Thanks for the clarificaiton and I totally agree that the behavior explained in section 9 would avoid the issues I have mentioned. But, following is a reference from section 7 (last paragraph of the section) of the draft which has got me confused. " One possible reason for such behavior is that the source address chosen by the upper-layer is of smaller scope than the destination, e.g., when using a link-local source address and a site-local destination address. " Thanks and Regards Narsi >>Narsi, >>A packet is not permitted to leave the zone of uniqueness of its source >>address (see section 9 of the scoped architecture draft, second bullet), >>so your example problems ought not to arise. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 18 22:09:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6J54Xs09466 for ipng-dist; Tue, 18 Jul 2000 22:04:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6J54F609459 for ; Tue, 18 Jul 2000 22:04:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA07617 for ; Tue, 18 Jul 2000 22:04:13 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA04478 for ; Tue, 18 Jul 2000 22:04:13 -0700 (PDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Jul 2000 22:03:29 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Tue, 18 Jul 2000 22:03:29 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF010FFF@red-msg-24.redmond.corp.microsoft.com> From: Brian Zill To: "'Narsimharao Nagampalli'" , deering@cisco.com Cc: haberman@nortelnetworks.com, ipng@sunroof.eng.sun.com Subject: RE: IPv6 Scoped Address Architecture (RFC 2710) Date: Tue, 18 Jul 2000 22:03:25 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Narsi, > But, following is a reference from section 7 (last paragraph > of the section) of the draft which has got me confused. > > " One possible reason for such behavior is that the source > address chosen by the upper-layer is of smaller scope than the > destination, e.g., when using a link-local source address and a > site-local destination address. " You can legitimately form a packet where the source address is of a smaller scope than the destination address. Due to the forwarding rule of section 9 that Steve noted, this packet will only get to the destination if it resides in zone of the smaller scoped address. For the example above, this packet with the link-local source address will get to its destination if (and only if) the site-local destination resides on the same link. This allows a node that only has a link-local address to talk to other nodes on its link even when it only knows their site-local addresses. Granted, this example will probably be rare. But the same applies for sending from a site-local source address to a global destination. You want the communication to succeed if the global address resides in your site. And the forwarding rules will cause a router to drop the packet (and send an ICMP message back to the sender) if it tries to leave the site. Hope this helps, --Brian > > Thanks and Regards > Narsi > > > >>Narsi, > > >>A packet is not permitted to leave the zone of uniqueness > of its source > >>address (see section 9 of the scoped architecture draft, > second bullet), > >>so your example problems ought not to arise. > > Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 19 15:57:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6JMtix10002 for ipng-dist; Wed, 19 Jul 2000 15:55:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6JMtW609995 for ; Wed, 19 Jul 2000 15:55:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA00677 for ; Wed, 19 Jul 2000 15:55:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01366 for ; Wed, 19 Jul 2000 16:55:32 -0600 (MDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA13526; Wed, 19 Jul 2000 15:55:30 -0700 (PDT) Message-Id: <200007192255.PAA13526@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2874 on IPv6 DNS Cc: rfc-ed@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 19 Jul 2000 15:55:30 -0700 From: RFC Editor Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2874 Title: DNS Extensions to Support IPv6 Address Aggregation and Renumbering Author(s): M. Crawford, C. Huitema, S. Thomson Status: Standards Track Date: July 2000 Mailbox: crawdad@fnal.gov, huitema@research.telcordia.com, set@research.telcordia.com Pages: 20 Characters: 44204 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipngwg-dns-lookups-08.txt URL: ftp://ftp.isi.edu/in-notes/rfc2874.txt This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering 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 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. This document is a product of the IPNG Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000719155317.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2874 --OtherAccess Content-Type: Message/External-body; name="rfc2874.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000719155317.RFC@RFC-EDITOR.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 Jul 21 00:02:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6L70eP11054 for ipng-dist; Fri, 21 Jul 2000 00:00:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6L70V611047 for ; Fri, 21 Jul 2000 00:00:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA03200 for ; Fri, 21 Jul 2000 00:00:30 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03562 for ; Fri, 21 Jul 2000 01:00:29 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id PAA06849 for ; Fri, 21 Jul 2000 15:45:36 +0900 (JST) Date: Fri, 21 Jul 2000 15:55:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: In your message of "Thu, 13 Jul 2000 14:25:13 -0700" <4.3.2.7.2.20000713142500.0254f0b0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20000713142500.0254f0b0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 13 Jul 2000 14:25:13 -0700, >>>>> Bob Hinden said: > - Multicast scope name changes: > o Changed name of scope value 1 from "node-local" to > "interface-local" > o Reserved scope value 3 for "subnet-local" for multi-link > subnets > o Defined scope value 4 as "admin-local" What is the "admin-local" scope? Is it an IPv6 version of "Administratively Scoped Multicast"? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 04:20:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LBJ2O11275 for ipng-dist; Fri, 21 Jul 2000 04:19:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LBIl611268 for ; Fri, 21 Jul 2000 04:18:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA02341 for ; Fri, 21 Jul 2000 04:18:45 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA17464 for ; Fri, 21 Jul 2000 04:18:43 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id UAA05655; Fri, 21 Jul 2000 20:18:19 +0900 (JST) To: Jack McCann cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-reply-to: mccann's message of Fri, 14 Jul 2000 12:13:01 -0400. <200007141613.MAA0000295164@hunch.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Fri, 21 Jul 2000 20:18:19 +0900 Message-ID: <5653.964178299@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >During w.g. last call, I suggested a change of wording in the >definition of IPv4-mapped addresses (mail attached below). I >see the suggestion was not incorporated in addr-arch-v3-01. >Let me offer an example of what motivated my suggestion. maybe it is too late, but I do have a comment on addr-arch-v3-01. I presented the issue at the previous IETF. addr-arch-v3-01 is silent about what is the legal use of IPv4 mapped address. RFC2553 suggests to use it as node-internal identifier for IPv4 destination, and SIIT draft suggests to use it on the wire in IPv6 headers. because the address can be used for two meaning, we have possible security issue if we try to support RFC2553 AF_INET6 special behavior. please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically section 3. my suggestion is to forbid IPv4 mapped address in the IPv6 headers, and remove ambiguity from the dual use. itojun --- excerpt 3. Abuse of IPv4 mapped address 3.1. Problems IPv6 basic socket API [Gilligan, 1999] defines the use of IPv4 mapped address with AF_INET6 sockets. IPv4 mapped address is used to handle inbound IPv4 traffic toward AF_INET6 sockets, and outbound IPv4 traffic from AF_INET6 sockets. Inbound case has higher probability of abuse, while outbound case contributes to the abuse as well. Here we briefly describe the kernel behavior in inbound case. When we have an AF_INET6 socket bound to IPv6 unspecified address (::), IPv4 traffic, as well as IPv6 traffic, will be captured by the socket. The kernel will present the address of the IPv4 peer to the userland program by using IPv4 mapped address. For example, if an IPv4 traffic from 10.1.1.1 is captured by an AF_INET6 socket, the userland program will think that the peer is at ::ffff:10.1.1.1. The userland program can manipulate IPv4 mapped address just like it would do against normal IPv6 unicast address. We have three problems with the specification. First, IPv4 mapped address support complicates IPv4 access control mechanisms. For example, if you would like to reject accesses from IPv4 clients to a certain transport layer service, it is not enough to reject accesses to AF_INET socket. You will need to check AF_INET6 socket for accesses from IPv4 clients (seen as accesses from IPv4 mapped address) as well. Secondly, malicious party may be able to use IPv6 packets with IPv4 mapped address, to bypass access control. Consider the following scenario: o Attacker throws unencapsulated IPv6 packets, with ::ffff:127.0.0.1 as source address. o The access control code in the server thinks that this is from localhost, and grants accesses. Lastly, malicious party can make servers generate unexpected IPv4 traffic. This can be accomplished by sending IPv6 packet with IPv4 mapped address as a source (similar to abuse of IPv4 compatible address), or by presenting IPv4 mapped address to servers (like FTP bounce attack [Allman, 1999] from IPv6 to IPv4). The problem is slightly different from the problems with IPv4 compatible addresses and 6to4 addresses, since it does not make use of tunnels. It makes use of certain behavior of userland applications. The confusion came from the dual use of IPv4 mapped address, for node- internal representation for remote IPv4 destination/source, and for real IPv6 destination/source. 3.2. Possible solutions o In IPv6 addressing architecutre document [Hinden, 1998] , disallow the use of IPv4 mapped addresses on the wire. The change will conflict with SIIT [Nordmark, 2000] , which is the only protocol which tries to use IPv4 mapped address on IPv6 native packet. The dual use of IPv4 mapped address (as a host-internal representation of IPv4 destinations, and as a real IPv6 address) is the prime source of the problem. o Reject IPv6 packets, if it has IPv4 mapped address in IPv6 header fields. Note that we may need to check extension headers such as routing headers, as well. IPv4 mapped address is internal representation in a node, so doing this will raise no conflicts with existing protocols. We recommend to check the condition in IPv6 input packet processing, and transport layer processing (TCP input and UDP input) to be sure. o Reject DNS replies, or other host name database replies, which contain IPv4 mapped address. Again, IPv4 mapped address is internal represntation in a node and should never appear on external host name databases. o Do not route inbound IPv4 traffic to AF_INET6 sockets. When an application would like to accept IPv4 traffic, it should explicitly open AF_INET sockets. You may want to run two applications instead, one for an AF_INET socket, and another for an AF_INET6 socket. Or you may want to make the functionality optional, off by default, and let the userland applications explicitly enable it. This greatly simplifies access control issues. This approach conflicts with what IPv6 basic API document says, however, it should raise no problem with properly-written IPv6 applications. It only affects server programs, ported by assuming the behavior of AF_INET6 listening socket against IPv4 traffic. o When implementing TCP or UDP stack, explicitly record the wire packet format (IPv4 or IPv6) into connection table. It is unwise to guess the wire packet format, by existence of IPv6 mapped address in the address pair. o We should separately fix problems like FTP bounce attack. o Applications should always check if the connection to AF_INET6 socket is from an IPv4 node (IPv4 mapped address), or IPv6 node. It should then treat the connection as from IPv4 node (not from IPv6 node with special adderss), or reject the connection. This is, however, dangerous to assume that every application implementers are aware of the issue. The solution is not recommended (this is not a solution actually). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 05:52:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LCpRp11373 for ipng-dist; Fri, 21 Jul 2000 05:51:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LCpI611366 for ; Fri, 21 Jul 2000 05:51:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA07614 for ; Fri, 21 Jul 2000 05:51:18 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA20811 for ; Fri, 21 Jul 2000 05:51:17 -0700 (PDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Fri, 21 Jul 2000 08:50:41 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id PHQ9VMYZ; Fri, 21 Jul 2000 08:50:40 -0400 Received: from nortelnetworks.com (CLEMSON [132.245.252.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id P1S0NTQ3; Fri, 21 Jul 2000 08:50:36 -0400 Message-ID: <3978462D.BA263D3E@nortelnetworks.com> Date: Fri, 21 Jul 2000 08:46:37 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft References: <4.3.2.7.2.20000713142500.0254f0b0@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tatuya, Yes, it is equivalent to the "local scope" defined in RFC 2365 and RFC 2730. It should be noted that those documents refer to IPv6 scope 3 currently, but will need to be changed to scope 4. Brian JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >>>>> On Thu, 13 Jul 2000 14:25:13 -0700, > >>>>> Bob Hinden said: > > > - Multicast scope name changes: > > o Changed name of scope value 1 from "node-local" to > > "interface-local" > > o Reserved scope value 3 for "subnet-local" for multi-link > > subnets > > o Defined scope value 4 as "admin-local" > > What is the "admin-local" scope? Is it an IPv6 version of > "Administratively Scoped Multicast"? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Brian Haberman Nortel Networks haberman@nortelnetworks.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 06:09:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LD7Ox11420 for ipng-dist; Fri, 21 Jul 2000 06:07:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LD7A611405 for ; Fri, 21 Jul 2000 06:07:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA18894 for ; Fri, 21 Jul 2000 06:07:10 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21879 for ; Fri, 21 Jul 2000 07:07:09 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07652; Fri, 21 Jul 2000 09:07:07 -0400 (EDT) Message-Id: <200007211307.JAA07652@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-default-addr-select-01.txt Date: Fri, 21 Jul 2000 09:07:07 -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 : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-01.txt Pages : 12 Date : 20-Jul-00 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-default-addr-select-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-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: <20000720141410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-default-addr-select-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141410.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 Jul 21 06:09:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LD7Wl11421 for ipng-dist; Fri, 21 Jul 2000 06:07:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LD7H611413 for ; Fri, 21 Jul 2000 06:07:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA10699 for ; Fri, 21 Jul 2000 06:07:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28375 for ; Fri, 21 Jul 2000 06:07:16 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07720; Fri, 21 Jul 2000 09:07:14 -0400 (EDT) Message-Id: <200007211307.JAA07720@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-06.txt Date: Fri, 21 Jul 2000 09:07:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-06.txt Pages : 14 Date : 20-Jul-00 This document describes an experimental protocol for asking an IPv6 node to supply certain network information, such as its fully- qualified domain name. IPv6 implementation experience has shown that direct queries for FQDN are useful, and a direct query mechanism for other information has been requested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000720141420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141420.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 Jul 21 06:14:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LDDj611477 for ipng-dist; Fri, 21 Jul 2000 06:13:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LDDa611470 for ; Fri, 21 Jul 2000 06:13:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA09695 for ; Fri, 21 Jul 2000 06:13:37 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25227 for ; Fri, 21 Jul 2000 07:13:34 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id VAA07854; Fri, 21 Jul 2000 21:57:41 +0900 (JST) Date: Fri, 21 Jul 2000 22:07:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: NNARASIMHARAO@novell.com, bzill@microsoft.com, haberman@nortelnetworks.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Address Architecture (RFC 2710) In-Reply-To: In your message of "Tue, 18 Jul 2000 09:12:22 -0700" References: User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 18 Jul 2000 09:12:22 -0700, >>>>> Steve Deering said: >> Fragmentation >> One concern is regarding IPv6 fragmentation. There we use the source address followed by a unique ID generated at the source to define a fragmentation sequence. Now, consider the case where two link local addressed sources are sending fragments to a site-local address and happen to use the same ID's. I can not see a way in which the destination can re-assemble these two train of fragments properly. >> >> Flow Label >> Same issue like fragment ID. Flow label ID and Src address again are used together to identify a flow. In the above scenario again, there could be issues in distinguishing across flows. > Narsi, > A packet is not permitted to leave the zone of uniqueness of its source > address (see section 9 of the scoped architecture draft, second bullet), > so your example problems ought not to arise. Correct, but I recall another (or a related) issue triggered by the original question. Consider the following topology: nodeA-----------------nodeB------------------nodeC fe80::1 fe80::2 fe80::2 fe80::1 This is valid if the link between A and B is different from the link between B and C. Then suppose that nodeA and nodeC are sending fragmented packets to nodeB using a same fragment ID at the same time. A poor implementation would be confused when reassembling the packets. So, implmentations should care the zone of received fragments as well as the source and destination addresses (and fragment ID) when reassembling. This may be a trivial requirement and needs not to be documented, though. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 06:28:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LDQf511527 for ipng-dist; Fri, 21 Jul 2000 06:26:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LDQU611520 for ; Fri, 21 Jul 2000 06:26:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA00327 for ; Fri, 21 Jul 2000 06:26:29 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02090 for ; Fri, 21 Jul 2000 07:26:29 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11897; Fri, 21 Jul 2000 09:26:24 -0400 (EDT) Message-Id: <200007211326.JAA11897@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: Initial IPv6 Sub-TLA ID Assignments to Informational Date: Fri, 21 Jul 2000 09:26:24 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Initial IPv6 Sub-TLA ID Assignments' as an Informational RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Note to RFC Editor: 1) Remove the last paragraph in Section 1, the one defining MUST/MAY/SHOULD terminology. In addition, remove the reference to RFC 2119 in the references section. 2) Insert the following paragraph as the first paragraph in the Introduction section: This document was originally developed to provide advice to IANA in the fall of 1998 and is being published at this time for the historical record. The IAB subsequently requested that the IANA delegate these assignments to the Address Registries. The IANA did this and the Address Registries are now using them to assign IPv6 addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 08:28:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LFQoD11658 for ipng-dist; Fri, 21 Jul 2000 08:26:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LFQf611651 for ; Fri, 21 Jul 2000 08:26:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA26892 for ; Fri, 21 Jul 2000 08:26:39 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18817 for ; Fri, 21 Jul 2000 08:26:39 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id C77EF608; Fri, 21 Jul 2000 11:26:37 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9CC67605; Fri, 21 Jul 2000 11:26:37 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0000757425; Fri, 21 Jul 2000 11:26:29 -0400 (EDT) From: Jim Bound Message-Id: <200007211526.LAA0000757425@anw.zk3.dec.com> To: itojun@iijlab.net Cc: Jack McCann , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-reply-to: Your message of "Fri, 21 Jul 2000 20:18:19 +0900." <5653.964178299@coconut.itojun.org> Date: Fri, 21 Jul 2000 11:26:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, I am not commenting on IPv4 Mapped addresses on the wire. What I do or don't do with them in userland is NONE of yours or anyone elses business or what I do with them in my implementation. The BASE API and Addr Spec define them and they exist. The only place they show up on the wire are in SIIT. But I do want to see Bob's response to Jacks question which I am concerned has not gotten a response yet? I intend to read your input before the IETF and maybe we should talk offline together as I think you have an implementation problem and I am open to helping you fix this in the Kame code base if necessary or explain it to you. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 09:35:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LGXWm11766 for ipng-dist; Fri, 21 Jul 2000 09:33:32 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LGXF611751 for ; Fri, 21 Jul 2000 09:33:16 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6LGXFI482598; Fri, 21 Jul 2000 09:33:15 -0700 (PDT) Date: Fri, 21 Jul 2000 09:33:12 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: New "IP Version 6 Addressing Architecture" draft To: itojun@iijlab.net Cc: Jack McCann , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5653.964178299@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically > section 3. my suggestion is to forbid IPv4 mapped address in the IPv6 > headers, and remove ambiguity from the dual use. Itojun, The implication of your recommendation is that we remove SIIT (at least as currently specified) from the RFC directories, since the SIIT RFC assumes that IPv4-mapped addresses can be sent in IPv6 headers and SIIT can't work without this. Is this really what you are proposing? 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 Jul 21 10:07:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LH5jT11828 for ipng-dist; Fri, 21 Jul 2000 10:05:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LH5a611821 for ; Fri, 21 Jul 2000 10:05:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA01821 for ; Fri, 21 Jul 2000 10:05:35 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25497 for ; Fri, 21 Jul 2000 10:05:34 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id E786A610; Fri, 21 Jul 2000 12:05:31 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id EA26344A; Fri, 21 Jul 2000 12:05:30 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0000773814; Fri, 21 Jul 2000 13:05:30 -0400 (EDT) From: Jim Bound Message-Id: <200007211705.NAA0000773814@anw.zk3.dec.com> To: Erik Nordmark Cc: itojun@iijlab.net, Jack McCann , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-reply-to: Your message of "Fri, 21 Jul 2000 09:33:12 PDT." Date: Fri, 21 Jul 2000 13:05:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, >> please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically >> section 3. my suggestion is to forbid IPv4 mapped address in the IPv6 >> headers, and remove ambiguity from the dual use. > >Itojun, > >The implication of your recommendation is that we remove SIIT (at least >as currently specified) from the RFC directories, since the SIIT RFC >assumes that IPv4-mapped addresses can be sent in IPv6 headers and SIIT >can't work without this. > >Is this really what you are proposing? I hope not or I am against the proposal. But I think we have to address Jack's question too. Right now its unclear whether SIIT is "legal" per the wording in the arch spec. regards, /jim 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 Fri Jul 21 11:10:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LI8mp11916 for ipng-dist; Fri, 21 Jul 2000 11:08:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LI8d611909 for ; Fri, 21 Jul 2000 11:08:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA17894 for ; Fri, 21 Jul 2000 11:08:38 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07974 for ; Fri, 21 Jul 2000 11:08:20 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.20.151.148) by smtp2.libero.it; 21 Jul 2000 20:07:51 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 0636F4C530; Fri, 21 Jul 2000 18:31:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 01FCE4C52F for ; Fri, 21 Jul 2000 18:31:25 +0200 (CEST) Date: Fri, 21 Jul 2000 18:31:25 +0200 (CEST) From: Mauro Tortonesi To: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: <5653.964178299@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 21 Jul 2000 itojun@iijlab.net wrote: > o Do not route inbound IPv4 traffic to AF_INET6 sockets. When an > application would like to accept IPv4 traffic, it should explicitly > open AF_INET sockets. You may want to run two applications instead, > one for an AF_INET socket, and another for an AF_INET6 socket. Or you > may want to make the functionality optional, off by default, and let > the userland applications explicitly enable it. This greatly > simplifies access control issues. This approach conflicts with what > IPv6 basic API document says, however, it should raise no problem with > properly-written IPv6 applications. It only affects server programs, > ported by assuming the behavior of AF_INET6 listening socket against > IPv4 traffic. i am not a software engineer - only a student and a developer - and i am new of this list, so i don't even know if i am allowed to speak here. but if you want to hear my opinion i think you shouldn't take such a decision too easily. this would mean that nearly ALL ipv6 servers and kernel implementations should be rewritten. that would a considerable step back in the development of ipv6 software. imho there is also a contradiction with the development of draft-rfc2553bis towards a protocol-indipendent api. as mr. itoh says, the best solution is probably to forbid every use of ipv4 mapped addresses except for node representation. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 12:11:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LJ9Pn12003 for ipng-dist; Fri, 21 Jul 2000 12:09:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LJ9G611996 for ; Fri, 21 Jul 2000 12:09:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA26715 for ; Fri, 21 Jul 2000 12:09:14 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12198 for ; Fri, 21 Jul 2000 13:09:14 -0600 (MDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 22D2F4C5; Fri, 21 Jul 2000 14:09:12 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id BB447425; Fri, 21 Jul 2000 14:09:11 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000791976; Fri, 21 Jul 2000 15:08:40 -0400 (EDT) From: Jim Bound Message-Id: <200007211908.PAA0000791976@anw.zk3.dec.com> To: Mauro Tortonesi Cc: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-reply-to: Your message of "Fri, 21 Jul 2000 18:31:25 +0200." Date: Fri, 21 Jul 2000 15:08:40 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk anyone can speak here and this is valuable. the apis will work in 2553bis. what one does with their implementation and how they pass ipv4 or ipv6 to the app and the apis is not anyones business in a standards community or anywhere else. if one has an issue with the API thats fine but not with how implementors build their stack. a v4 packet in can become a mapped packet in an implementation. when presented to an af_inet. Or it can be presented as an af_inet6 (as a mapped address). likewise going out. rfc2553bis permit this behavior for the api and should and has for 5 years so thats a done deal and not really an IETF standard but an informational rfc so the API for IPv6 is NOT AN IETF STANDARD. It will standardized by the IEEE committees and XNET. As far as v4 mapped on the wire for protocols thats a different discussion. I personally support that it is OK and support what SIIT has done and ready for that discussion if someone does not believe it is a good idea. but what I will react very badly too in my mail is any implementor that cannot get something to work and that is what is driving their concern and its not a standards issue for this forum, but this forum is being used to change implementation folkways for IPv6. but v4 mapped does not affect the ISV porting effort at all and in fact makes their job much easier if the platform they are porting to supports that paradigm. do you have an example where you see the problem? /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 Jul 21 14:04:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LL3FP12262 for ipng-dist; Fri, 21 Jul 2000 14:03:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LL34612255 for ; Fri, 21 Jul 2000 14:03:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA00973 for ; Fri, 21 Jul 2000 14:03:02 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29280 for ; Fri, 21 Jul 2000 15:03:02 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA21314 for ; Fri, 21 Jul 2000 14:03:28 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA13131 for ; Fri, 21 Jul 2000 14:03:29 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id OAA03289 for ipng@sunroof.eng.sun.com; Fri, 21 Jul 2000 14:07:28 -0700 (PDT) Date: Fri, 21 Jul 2000 14:07:28 -0700 (PDT) From: Tim Hartrick Message-Id: <200007212107.OAA03289@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, I just gave draft-itojun-ipv6-transition-abuse-01.txt a quick read. It notes some legitimate problems with some of the transition strategies. At least some of these problems can be addressed by simply using good implementation techniques. For example the problem noted in 1.1 can be addressed by simply making sure that known bad addresses aren't used as the destination address of an encapsulating IPv4 header. Itojun says that this isn't sufficient but I am not sure that it isn't. It is certainly true that someone can send you a datagram sourced from the a subnet broadcast IPv4 compatible IPv6 address and trick a server into responding to that address. Un- fortunately, they don't need to be that creative since they could just send a straight IPv4 datagram using the subnet broadcast address as the source and get the same result. With regard to the use of mapped addresses. I think it would be a HUGE mistake to attempt to disallow the use of mapped addresses as a way to allow a single AF_INET6 both IPv6 and IPv4 transport traffic. One of the major selling points that we have tried to make to ISVs is that they can make minimal changes to there existing code base and have it be able to service both IPv4 and IPv6. If we require seperate sockets for AF_INET and AF_INET6 that makes ISVs jobs much more complicated. If application level access control software like tcp wrappers needs to be updated to understand IPv4 mapped IPv6 addresses then so be it. They will need to be updated for IPv6 anyway and I don't see how adding support for mapped address makes that job substantially more complicated. Further, selecting a different address format to use with SIIT won't obviate the need to update this filtering software. It will just make it necessary for the software to understand the translatable format along with the mapped and compatible formats. It seems like SIIT should have had its own translatable address format but I don't see it as a showstopper problem that it doesn't. Or at least I don't see any showstopper problems in draft-itojun-ipv6-transition- abuse-01.txt. 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 Fri Jul 21 14:40:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LLcma12330 for ipng-dist; Fri, 21 Jul 2000 14:38:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LLcc612323 for ; Fri, 21 Jul 2000 14:38:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA09464 for ; Fri, 21 Jul 2000 14:38:37 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA23584 for ; Fri, 21 Jul 2000 15:38:37 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Jul 2000 14:37:09 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Fri, 21 Jul 2000 14:37:08 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01101B@red-msg-24.redmond.corp.microsoft.com> From: Brian Zill To: "'itojun@iijlab.net'" , "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: New "IP Version 6 Addressing Architecture" draft Date: Fri, 21 Jul 2000 14:36:55 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Jim that we shouldn't break how IPv4-mapped addresses are used in the basic API spec, nor should we forbid their use on the wire as SIIT requires today. The security issues Itojun raises look to me to be internal implementation-specific issues. Let's look at his examples: > We have three problems with the specification. First, > IPv4 mapped address support complicates IPv4 access > control mechanisms. For example, if you would like to > reject accesses from IPv4 clients to a certain transport > layer service, it is not enough to reject accesses to > AF_INET socket. You will need to check AF_INET6 socket > for accesses from IPv4 clients (seen as accesses from > IPv4 mapped address) as well. Isn't this obvious? What's the problem? And how would preventing IPv4-mapped addresses on the wire protect against this anyway? > Secondly, malicious party may be able to use IPv6 > packets with IPv4 mapped address, to bypass access > control. Consider the following scenario: > > o Attacker throws unencapsulated IPv6 packets, with > ::ffff:127.0.0.1 as source address. > > o The access control code in the server thinks that > this is from localhost, and grants accesses. This is just broken access control code in the host. If you want to protect against this, you need similar checks in any decapsulator as well, right? Why is this any different? > Lastly, malicious party can make servers generate > unexpected IPv4 traffic. This can be accomplished by > sending IPv6 packet with IPv4 mapped address as a source > (similar to abuse of IPv4 compatible address), or by > presenting IPv4 mapped address to servers (like FTP > bounce attack [Allman, 1999] from IPv6 to IPv4). The > problem is slightly different from the problems with > IPv4 compatible addresses and 6to4 addresses, since it > does not make use of tunnels. It makes use of > certain behavior of userland applications. As you note, there are similar problems with IPv4-compatible addresses and 6to4 addresses. Again, why is adding checks to protect against one any different than adding checks to prevent against the other? I'm against dropping useful features of the protocol just to ease development of a particular implementation. Leaving the examples... > The confusion came from the dual use of IPv4 mapped > address, for node-internal representation for remote > IPv4 destination/source, and for real IPv6 > destination/source. Personally, I consider this to be a feature. To apps, a host with a hybrid-stack should look exactly the same as a host that sits behind a translator, shouldn't it? Hmm, maybe it would be best for an implementation to internally map source addresses of incoming IPv4 packets to IPv4-mapped addresses and destination addresses to IPv4-translated addresses (and vice-versa on send). > 3.2. Possible solutions > > o When implementing TCP or UDP stack, explicitly record > the wire packet format (IPv4 or IPv6) into connection > table. It is unwise to guess the wire packet format, > by existence of IPv6 mapped address in the address pair. If an implementation decides that it really needs to know whether a packet came in as a real IPv4 packet or as an IPv6 packet with mapped/translated/compatible addresses, then it could do this. Why is this a bad solution? Put another way, why should we waste a portion of the IPv6 address space on node-internal information? --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 Jul 21 15:54:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LMrU012366 for ipng-dist; Fri, 21 Jul 2000 15:53:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LMrJ612359 for ; Fri, 21 Jul 2000 15:53:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA28371 for ; Fri, 21 Jul 2000 15:53:18 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16690 for ; Fri, 21 Jul 2000 15:53:17 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id HAA12737; Sat, 22 Jul 2000 07:53:01 +0900 (JST) To: Brian Zill cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com In-reply-to: bzill's message of Fri, 21 Jul 2000 14:36:55 MST. <2E3FA0558747934A8F753CC533A3F6DF01101B@red-msg-24.redmond.corp.microsoft.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sat, 22 Jul 2000 07:53:01 +0900 Message-ID: <12735.964219981@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I agree with Jim that we shouldn't break how IPv4-mapped addresses are used >in the basic API spec, nor should we forbid their use on the wire as SIIT >requires today. >The security issues Itojun raises look to me to be internal >implementation-specific issues. Let's look at his examples: no, this is not an implementation-specific issue. first I need to be very clear: I have couple of options to solve this security issue. major routes are: - change addressing architecutre and forbid native-ipv4-mapped CONS: application writers are asked to check RFC2553-inbound cases, which is not that trivial when seeing the spec CONS: SIIT cannot be used - change RFC2553 API to disable RFC2553-inbound PROS: applications gets simplified very well, AF_INET6 is always IPv6, AF_INET is always IPv4 (good for security) PROS: RFC2553-inbound case is gone, application writers do not need to care about RFC2553-inbound cases CONS: SIIT itself is okay, but now unnatural - change RFC2553/2292 API to pass protocol version on the wire to the userland, to allow applications to distinguish between RFC2553-inbound and native-ipv4-mapped PROS: no impact to SIIT CONS: too much complexity is left, bad for security now we are talking about the first one. taking both 1st and 2nd one is my favorite, actually. here i try to define acronym for clarification: RFC2553-inbound: inbound IPv4 traffic goes into AF_INET6 wildcard socket RFC2553-outbound: outbound AF_INET6 packet with IPv4 mapped address goes to IPv4 native-ipv4-mapped: IPv6 packet with IPv4 mapped address in src/dst address field in IPv6 header >> We have three problems with the specification. First, >> IPv4 mapped address support complicates IPv4 access >> control mechanisms. For example, if you would like to >> reject accesses from IPv4 clients to a certain transport >> layer service, it is not enough to reject accesses to >> AF_INET socket. You will need to check AF_INET6 socket >> for accesses from IPv4 clients (seen as accesses from >> IPv4 mapped address) as well. >Isn't this obvious? What's the problem? And how would preventing >IPv4-mapped addresses on the wire protect against this anyway? you right, this one does not directly solved by prohibiting native-ipv4-mapped. i have seen and made improvements to many ported applications. almost none of them have the proper access control logic with consideration to RFC2553-inbound. for security, complexity is a bad thing. >> Secondly, malicious party may be able to use IPv6 >> packets with IPv4 mapped address, to bypass access >> control. Consider the following scenario: >> o Attacker throws unencapsulated IPv6 packets, with >> ::ffff:127.0.0.1 as source address. >> o The access control code in the server thinks that >> this is from localhost, and grants accesses. >This is just broken access control code in the host. If you want to protect >against this, you need similar checks in any decapsulator as well, right? >Why is this any different? no, this is not the access control code that is broken. the problem is, under RFC2553, you have no way to distinguish between native-ipv4-mapped and RFC2553-inbound packet, in the userland. both of them have ::ffff:127.0.0.1 as the result of getpeername (or getsockname), both of them appear on AF_INET6 socket, if you would like to permit accesses from IPv4 127.0.0.1, and even if you would like to reject native-ipv4-mapped with ::ffff:127.0.0.1, you can't do that. In the solutions I listed, I missed one option: extend API to give application some idea about the IP version (native-ipv4-mapped or RFC2553-inbound). >> Lastly, malicious party can make servers generate >> unexpected IPv4 traffic. This can be accomplished by >> sending IPv6 packet with IPv4 mapped address as a source >> (similar to abuse of IPv4 compatible address), or by >> presenting IPv4 mapped address to servers (like FTP >> bounce attack [Allman, 1999] from IPv6 to IPv4). The >> problem is slightly different from the problems with >> IPv4 compatible addresses and 6to4 addresses, since it >> does not make use of tunnels. It makes use of >> certain behavior of userland applications. >As you note, there are similar problems with IPv4-compatible addresses and >6to4 addresses. Again, why is adding checks to protect against one any >different than adding checks to prevent against the other? I'm against >dropping useful features of the protocol just to ease development of a >particular implementation. the problem is that people can inject malicious packets more easily than before. they can inject malicious IPv6 packet from remote places (by wrapping it into IPv4 packet). they can let us relay malicious packets by abusing normal IPv6 routers, auto-tunnel capable IPv6 routers, and 6to4 relay routers. it will be much harder to track than normal IP packets we are seeing. >> The confusion came from the dual use of IPv4 mapped >> address, for node-internal representation for remote >> IPv4 destination/source, and for real IPv6 >> destination/source. >Personally, I consider this to be a feature. To apps, a host with a >hybrid-stack should look exactly the same as a host that sits behind a >translator, shouldn't it? >Hmm, maybe it would be best for an implementation to internally map source >addresses of incoming IPv4 packets to IPv4-mapped addresses and destination >addresses to IPv4-translated addresses (and vice-versa on send). SIIT requires the dual use of IPv4 mapped address (native-ipv4-mapped and RFC2553-inbound). this is a feature of SIIT, not the other documents. (see the earliest part of the email for possible other routers to take) >> 3.2. Possible solutions >> o When implementing TCP or UDP stack, explicitly record >> the wire packet format (IPv4 or IPv6) into connection >> table. It is unwise to guess the wire packet format, >> by existence of IPv6 mapped address in the address pair. >If an implementation decides that it really needs to know whether a packet >came in as a real IPv4 packet or as an IPv6 packet with >mapped/translated/compatible addresses, then it could do this. Why is this >a bad solution? ~~~~ maybe my text is rather unclear, but what part are you referring to by the underlined "this"? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 15:58:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LMvvt12388 for ipng-dist; Fri, 21 Jul 2000 15:57:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LMvl612381 for ; Fri, 21 Jul 2000 15:57:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA29427 for ; Fri, 21 Jul 2000 15:57:46 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18725 for ; Fri, 21 Jul 2000 15:57:46 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id HAA12786; Sat, 22 Jul 2000 07:57:37 +0900 (JST) To: Tim Hartrick cc: ipng@sunroof.eng.sun.com In-reply-to: tim's message of Fri, 21 Jul 2000 14:07:28 MST. <200007212107.OAA03289@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sat, 22 Jul 2000 07:57:37 +0900 Message-ID: <12784.964220257@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For example the problem noted in 1.1 can be addressed by simply >making sure that known bad addresses aren't used as the destination address >of an encapsulating IPv4 header. Itojun says that this isn't sufficient >but I am not sure that it isn't. It is certainly true that someone can >send you a datagram sourced from the a subnet broadcast IPv4 compatible >IPv6 address and trick a server into responding to that address. Un- >fortunately, they don't need to be that creative since they could just send >a straight IPv4 datagram using the subnet broadcast address as the source >and get the same result. the point i would like to make was that: - it is much easier to inject malicious packet from remote, with bypassing normal access control imposed by normal routers inbetween - it is much harder to track the source down, as malicious party can use many relays (6to4 relays, auto-tunnel routers, whatever) to anonymize his traffic. this is just like smtp case: tracking the source of spam is very hard due to smtp relays. sorry if it was unclear. > If application level access control software like tcp wrappers >needs to be updated to understand IPv4 mapped IPv6 addresses then so be it. >They will need to be updated for IPv6 anyway and I don't see how adding >support for mapped address makes that job substantially more complicated. there's no way for the current API to recognize IPv4 traffic on top of AF_INET6 socket (appears as IPv4 mapped address), and native IPv6 traffic with IPv4 mapped address in the header). at least we need to provide the functionality. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 16:08:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LN6n812414 for ipng-dist; Fri, 21 Jul 2000 16:06:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LN6c612407 for ; Fri, 21 Jul 2000 16:06:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA23078 for ; Fri, 21 Jul 2000 16:06:38 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23148 for ; Fri, 21 Jul 2000 16:06:36 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA12933; Sat, 22 Jul 2000 08:06:15 +0900 (JST) To: Jim Bound cc: Jack McCann , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-reply-to: bound's message of Fri, 21 Jul 2000 11:26:29 -0400. <200007211526.LAA0000757425@anw.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sat, 22 Jul 2000 08:06:15 +0900 Message-ID: <12931.964220775@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am not commenting on IPv4 Mapped addresses on the wire. >What I do or don't do with them in userland is NONE of yours or anyone >elses business or what I do with them in my implementation. The BASE >API and Addr Spec define them and they exist. i too would like to see uniform API everywhere, possibly with enough simplicity to avoid applications writers misuse. i have multiple routes to take with the issue i raised. >I intend to read your input before the IETF and maybe we should talk >offline together as I think you have an implementation problem and I am >open to helping you fix this in the Kame code base if necessary or >explain it to you. thank you for the offer, but i don't think we have problem in our code. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 16:11:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6LNAFm12432 for ipng-dist; Fri, 21 Jul 2000 16:10:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6LNA4612425 for ; Fri, 21 Jul 2000 16:10:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA02657; Fri, 21 Jul 2000 16:09:57 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA24797; Fri, 21 Jul 2000 16:09:56 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA12992; Sat, 22 Jul 2000 08:09:51 +0900 (JST) To: Erik Nordmark cc: Jack McCann , hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Fri, 21 Jul 2000 09:33:12 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sat, 22 Jul 2000 08:09:51 +0900 Message-ID: <12990.964220991@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> please refer to draft-itojun-ipv6-transition-abuse-01.txt, specifically >> section 3. my suggestion is to forbid IPv4 mapped address in the IPv6 >> headers, and remove ambiguity from the dual use. >The implication of your recommendation is that we remove SIIT (at least >as currently specified) from the RFC directories, since the SIIT RFC >assumes that IPv4-mapped addresses can be sent in IPv6 headers and SIIT >can't work without this. >Is this really what you are proposing? as i wrote in the reply to Brian (Zill), i have multiple routes to pick from. some of them is friendly with SIIT, however, if we take a route that is friendly SIIT, i think we leave too much complexity in the code/address arch, and we will see future security issues (complexity = possibility for security issue). i'm not sure if removal is necessary/required. there are many RFCs that conflicts with each other, or RFCs requiring updates to old ones. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 17:07:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M05Kf12529 for ipng-dist; Fri, 21 Jul 2000 17:05:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M057612522 for ; Fri, 21 Jul 2000 17:05:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA07376 for ; Fri, 21 Jul 2000 17:05:05 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA14888 for ; Fri, 21 Jul 2000 18:05:04 -0600 (MDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Jul 2000 17:04:11 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 21 Jul 2000 17:04:10 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF01101E@red-msg-24.redmond.corp.microsoft.com> From: Brian Zill To: "'itojun@iijlab.net'" Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: RE: New "IP Version 6 Addressing Architecture" draft Date: Fri, 21 Jul 2000 17:03:19 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, I am unwilling to give up SIIT. Changing the architecture to forbid IPv4-mapped addresses on the wire is unacceptable in my opinion. I'm far from convinced that there is a real problem here. Your examples are contrived. You already agreed I was right about the first one, so let's look at the second again: > >> Secondly, malicious party may be able to use IPv6 > >> packets with IPv4 mapped address, to bypass access > >> control. Consider the following scenario: > >> o Attacker throws unencapsulated IPv6 packets, with > >> ::ffff:127.0.0.1 as source address. > >> o The access control code in the server thinks that > >> this is from localhost, and grants accesses. > >This is just broken access control code in the host. > >If you want to protect against this, you need similar > >checks in any decapsulator as well, right? > >Why is this any different? > > no, this is not the access control code that is broken. > the problem is, under RFC2553, you have no way to > distinguish between native-ipv4-mapped and > RFC2553-inbound packet, in the userland. Nor do you need to if you (the stack writer) only allow the same set of native-ipv4-mapped addresses to show up where you'd allow them as RFC2553-inbound addresses. > both of them have ::ffff:127.0.0.1 as the result of > getpeername (or getsockname), both of them appear on > AF_INET6 socket, if you would like to permit accesses > from IPv4 127.0.0.1, and even if you would like to > reject native-ipv4-mapped with ::ffff:127.0.0.1, you > can't do that. If an IPv4 packet arrived at your machine with a source address of 127.0.0.1, what would your kernel do? Now if an IPv6 packet arrives at your machine with a source address of ::ffff:127.0.0.1, what does your kernel do? If it does the same thing in both cases, why should user-land care how it got there? If it doesn't do the same thing, why not? > >> Lastly, malicious party can make servers generate > >> unexpected IPv4 traffic. This can be accomplished > >> by sending IPv6 packet with IPv4 mapped address as > >> a source (similar to abuse of IPv4 compatible > >> address), That's not unexpected IPv4 traffic -- that's *expected* IPv4 traffic! > >> or by presenting IPv4 mapped address to servers > >> (like FTP bounce attack [Allman, 1999] from IPv6 > >> to IPv4). The problem is slightly different from > >> the problems with IPv4 compatible addresses and > >> 6to4 addresses, since it does not make use of > >> tunnels. It makes use of certain behavior of > >> userland applications. But isn't that "certain behavior" more commonly known as "incorrect behavior"? > >As you note, there are similar problems with > >IPv4-compatible addresses and 6to4 addresses. > >Again, why is adding checks to protect against > >one any different than adding checks to prevent > >against the other? > > the problem is that people can inject malicious > packets more easily than before. they can inject > malicious IPv6 packet from remote places (by > wrapping it into IPv4 packet). What does this have to do with v4-mapped addresses? > they can let us relay malicious packets by abusing > normal IPv6 routers, auto-tunnel capable IPv6 > routers, and 6to4 relay routers. it will be much > harder to track than normal IP packets we are seeing. These are all tunnelling issues. Nobody is suggesting getting rid of tunnels to fix them - they're suggesting appropriate security checks. I ask again, why is adding checks to protect against v4-mapped address misuse any different? > SIIT requires the dual use of IPv4 mapped address > (native-ipv4-mapped and RFC2553-inbound). this is > a feature of SIIT, not the other documents. No, SIIT doesn't require user-level programs to receive IPv4 packets on AF_INET6 socekts. It only requires that IPv6 packets (with v4-mapped addresses) are received on AF_INET6 sockets. Machines living on the v6 side of the translator only need to speak v6! > >> 3.2. Possible solutions > >> o When implementing TCP or UDP stack, explicitly > >> record the wire packet format (IPv4 or IPv6) > >> into connection table. It is unwise to guess > >> the wire packet format, by existence of IPv6 > >> mapped address in the address pair. > >If an implementation decides that it really needs > >to know whether a packet came in as a real IPv4 > >packet or as an IPv6 packet with mapped/translated/ > >compatible addresses, then it could do this. > >Why is this a bad solution? > > maybe my text is rather unclear, but what part are > you referring to by the underlined "this"? This = recording the wire packet format in the connection table. If you really insist that user-land needs to know the difference for some reason, I suppose you could do this and find some way for the kernel to pass it up (ammend scope id behavior?). I still don't see the need though. This transparency still strikes me as a feature, not a bug. --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 Jul 21 17:07:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M04PJ12520 for ipng-dist; Fri, 21 Jul 2000 17:04:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M04E612513 for ; Fri, 21 Jul 2000 17:04:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA18193 for ; Fri, 21 Jul 2000 17:04:13 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14511 for ; Fri, 21 Jul 2000 18:04:12 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA21961 for ; Fri, 21 Jul 2000 17:04:35 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA17331 for ; Fri, 21 Jul 2000 17:04:36 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id RAA03430 for ipng@sunroof.eng.sun.com; Fri, 21 Jul 2000 17:08:34 -0700 (PDT) Date: Fri, 21 Jul 2000 17:08:34 -0700 (PDT) From: Tim Hartrick Message-Id: <200007220008.RAA03430@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > the point i would like to make was that: > - it is much easier to inject malicious packet from remote, > with bypassing normal access control imposed by normal routers > inbetween For the specific example you noted, use of subnet broadcast addresses in the source address field, I don't see how it would bypass normal router or firewall checks. The bogus address will be placed in the destination address field of the encapsulating IPv4 datagram. When that datagram arrives at the ingress point of the target network it would/should be filtered just like a IPv4 datagram with a UDP payload would be filtered. Can you elaborate on how an IPv4 datagram encapsulating an IPv6 datagram is going to be treated differently than a IPv6 datagram encapsulating a UDP payload? > - it is much harder to track the source down, as malicious party can use > many relays (6to4 relays, auto-tunnel routers, whatever) to > anonymize his traffic. this is just like smtp case: tracking the > source of spam is very hard due to smtp relays. That may be but I would need some concrete examples of this that don't assume that the nodes involved are not filtering the obvious cases like 0.0.0.0, 255.255.255.255, 127.x.y.z, and 224.x.y.z. > > > If application level access control software like tcp wrappers > >needs to be updated to understand IPv4 mapped IPv6 addresses then so be it. > >They will need to be updated for IPv6 anyway and I don't see how adding > >support for mapped address makes that job substantially more complicated. > > there's no way for the current API to recognize IPv4 traffic on top > of AF_INET6 socket (appears as IPv4 mapped address), and native > IPv6 traffic with IPv4 mapped address in the header). at least > we need to provide the functionality. > Why does there need to be a distinction? In either case the communication is with an IPv4 host. I don't understand why, from a policy point of view, it matters to the target host whether the packet was routed directly using IPv4 or translated into IPv6 from IPv4 by a SIIT box. The initiating host is an IPv4 host by virtue of the fact that the address is a IPv4 mapped IPv6 address. That is not to say that there are not some fairly nasty details to be worked out from an implementation point of view. Dealing with both flavors of mapped address could be interesting. But from a policy enforcement point of view, an IPv4 peer is an IPv4 peer regardless of how the datagram arrived or even what kind of datagram it was (IPv4 or IPv6) that brought the upper layer protocol payload. Can you elaborate on why it matters to policy enforcement code like TCP wrappers or other such application level access filters? Maybe I am missing some subtle point of how SIIT is supposed to work. 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 Fri Jul 21 18:12:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M1BAO12610 for ipng-dist; Fri, 21 Jul 2000 18:11:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M1B1612603 for ; Fri, 21 Jul 2000 18:11:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA28142 for ; Fri, 21 Jul 2000 18:11:00 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA09813 for ; Fri, 21 Jul 2000 19:10:59 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id CAA18920; Sat, 22 Jul 2000 02:10:24 +0100 Received: from hursley.ibm.com (lig32-233-34-88.ap.lig-dial.ibm.com [32.233.34.88]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id CAA21850; Sat, 22 Jul 2000 02:10:47 +0100 (BST) Message-ID: <3978F410.B1F994D@hursley.ibm.com> Date: Fri, 21 Jul 2000 20:08:32 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Brian Zill CC: "'itojun@iijlab.net'" , "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft References: <2E3FA0558747934A8F753CC533A3F6DF01101E@red-msg-24.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Zill wrote: > > Itojun, > > I am unwilling to give up SIIT. Changing the architecture to forbid > IPv4-mapped addresses on the wire is unacceptable in my opinion. Absolutely. I *hate* translators and always have done, but unfortunately we will need them for the next ten or fifteen years. Another 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 Jul 21 18:49:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M1llc12715 for ipng-dist; Fri, 21 Jul 2000 18:47:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M1lb612708 for ; Fri, 21 Jul 2000 18:47:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA20873 for ; Fri, 21 Jul 2000 18:47:35 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA20009 for ; Fri, 21 Jul 2000 19:47:34 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA14143; Sat, 22 Jul 2000 10:47:26 +0900 (JST) To: Hideaki YOSHIFUJI cc: bzill@microsoft.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-reply-to: yoshfuji's message of Sat, 22 Jul 2000 10:10:21 JST. <20000722101021L.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sat, 22 Jul 2000 10:47:26 +0900 Message-ID: <14141.964230446@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> No, SIIT doesn't require user-level programs to receive IPv4 packets on >> AF_INET6 socekts. It only requires that IPv6 packets (with v4-mapped >> addresses) are received on AF_INET6 sockets. Machines living on the v6 side >> of the translator only need to speak v6! >Yes, SIIT is for IPv6 node that is not IPv4 capable. >And you can drop packet that have encapsulated ipv4 source >address belongs to local subnet (a.b.c.d/n) from outside: > subnet +----------+ outside (IPv6, IPv4) >---------------| SIIT Box |---------------------- > (a.b.c.d/n) +----------+ >And, leaf nodes should drops packets from ::ffff:127.0.0.0/104 from subnet >as we want to drop 127.0.0.0/8 on ipv4 nodes: >+-----------+ subnet >| ipv6 node |--------------------------------- >+-----------+ (IPv6 capable, don't care IPv4) though this is not the original issue I raised... do you require all the nodes in SIIT cloud to be IPv6-only? (meaning that no IPv4 support in the kernel, not just "no IPv4 configuration") I think that SIIT RFC is vague about what "IPv6-only" means. if SIIT asks all the nodes in the SIIT cloud to remove IPv4 support from the kernel, that is way far from reality. For most of the operating systems I look into, we cannot remove IPv4 support in the kernel. >Itojun, issues/examples you raised are not problems >(at RFC2553 or addressing-architecture level). >You should raise new examples again to convince us. okay guys, i still believe this is very serious issue, but you still do not agree with me. I drop comment about the address architecture, for now. i need to convince you with real example. i'll need to come up with test program that transmits malicious packet, and talk with CERT/ bugtraq guys if necessary... itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 19:10:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M29U412798 for ipng-dist; Fri, 21 Jul 2000 19:09:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M29J612791 for ; Fri, 21 Jul 2000 19:09:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA22750 for ; Fri, 21 Jul 2000 19:09:17 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA23215 for ; Fri, 21 Jul 2000 19:09:16 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA14295; Sat, 22 Jul 2000 11:09:04 +0900 (JST) To: Brian Zill cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com In-reply-to: bzill's message of Fri, 21 Jul 2000 17:03:19 MST. <2E3FA0558747934A8F753CC533A3F6DF01101E@red-msg-24.redmond.corp.microsoft.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sat, 22 Jul 2000 11:09:04 +0900 Message-ID: <14293.964231744@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'm far from convinced that there is a real problem here. Your examples are >contrived. You already agreed I was right about the first one, so let's >look at the second again: as i wrote in my reply to yoshfuji's email, - i still think it is real serious issue - i'll drop the comment to address architecture, for now - i'll come up with sample program, to show you that it's real. hope we can test it in pittsburgh. >> no, this is not the access control code that is broken. >> the problem is, under RFC2553, you have no way to >> distinguish between native-ipv4-mapped and >> RFC2553-inbound packet, in the userland. >Nor do you need to if you (the stack writer) only allow the same set of >native-ipv4-mapped addresses to show up where you'd allow them as >RFC2553-inbound addresses. i don't understand what you mean here... you say that, if the stack accepts RFC2553-inbound case, you need to accept native-ipv4-mapped? >> both of them have ::ffff:127.0.0.1 as the result of >> getpeername (or getsockname), both of them appear on >> AF_INET6 socket, if you would like to permit accesses >> from IPv4 127.0.0.1, and even if you would like to >> reject native-ipv4-mapped with ::ffff:127.0.0.1, you >> can't do that. >If an IPv4 packet arrived at your machine with a source address of >127.0.0.1, what would your kernel do? Now if an IPv6 packet arrives at your >machine with a source address of ::ffff:127.0.0.1, what does your kernel do? >If it does the same thing in both cases, why should user-land care how it >got there? If it doesn't do the same thing, why not? 127.0.0.1 may be a special case, but i try to outline it here. "normal" userland program will do the following. struct sockaddr_storage ss; struct sockaddr_in6 *sin6; socklen_t salen; salen = sizeof(ss); getpeername(s, (struct sockaddr *)&ss, &salen); switch (ss.ss_family) { case AF_INET: /* it is always IPv4 packet, IPv4 access control */ break; case AF_INET6: sin6 = (struct sockaddr_in6 *)&ss; if (IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr)) /* IPv4 access control */ else /* IPv6 access control */ break; } - if we got an IPv4 packet with 127.0.0.1 in the source, and it was from outside, it should be dropped by the kernel. (RFC1812 p48 (e)) many kernel do not drop it, though. if the packet comes upward to AF_INET6 socket, it will be presented as ::ffff:127.0.0.1, and normal userland program will think that it is from IPv4 source 127.0.0.1. - if we got an IPv6 packet with ::ffff:127.0.0.1 in the source, and it was from outside, the kernel does not drop it for the sake of SIIT (too-clever SIIT enabled client may try to drop it because of IPv4 rules) if the packet comes upward to AF_INET6 socket, it will be presented as ::ffff:127.0.0.1, and normal userland program will think that it is from IPv4 source 127.0.0.1. for addresses other than 127.0.0.1, story goes mostly the same, except that we do not have RFC1812 rule. >> >> Lastly, malicious party can make servers generate >> >> unexpected IPv4 traffic. This can be accomplished >> >> by sending IPv6 packet with IPv4 mapped address as >> >> a source (similar to abuse of IPv4 compatible >> >> address), >That's not unexpected IPv4 traffic -- that's *expected* IPv4 traffic! do you say the following packet trace is the expected behavior? i hope you do not mean this... A: bad guy, using remote IPv4 address z.z.z.z B: has an IPv4 address 10.1.1.1/24, has auto tunnel support. (the use of private address is just for example) MAC address A -> MAC address B: IPv4 (src=z.z.z.z, dst=10.1.1.1) IPv6 (src=::ffff:10.1.1.2, dst=::10.1.1.1) UDP (src port=X, dst port=53) DNS query as RFC1933/1933bis does not limit IPv6 source on auto tunnel traffic, the packet will go all the way to the IPv6 transport capable DNS server via AF_INET6 socket, and gets replied. MAC address B -> MAC address A: IPv4 (src=10.1.1.1, dst=10.1.1.2) UDP (src port=53, dst port=X) DNS reply >> >> or by presenting IPv4 mapped address to servers >> >> (like FTP bounce attack [Allman, 1999] from IPv6 >> >> to IPv4). The problem is slightly different from >> >> the problems with IPv4 compatible addresses and >> >> 6to4 addresses, since it does not make use of >> >> tunnels. It makes use of certain behavior of >> >> userland applications. >But isn't that "certain behavior" more commonly known as "incorrect >behavior"? for FTP bounce attack case, you are right (TCP is harder to forge). please think about DNS query example above. >> the problem is that people can inject malicious >> packets more easily than before. they can inject >> malicious IPv6 packet from remote places (by >> wrapping it into IPv4 packet). >What does this have to do with v4-mapped addresses? again, just like shown in the above. >> they can let us relay malicious packets by abusing >> normal IPv6 routers, auto-tunnel capable IPv6 >> routers, and 6to4 relay routers. it will be much >> harder to track than normal IP packets we are seeing. >These are all tunnelling issues. Nobody is suggesting getting rid of >tunnels to fix them - they're suggesting appropriate security checks. I ask >again, why is adding checks to protect against v4-mapped address misuse any >different? what i'm saying is, this is real hard to get it right. there are many tunnelling technologies and transition technology. for a given tunnelling/transition technology Ti, we need to make sure that we make proper checks against all the transition technologies, T{1..n}. >No, SIIT doesn't require user-level programs to receive IPv4 packets on >AF_INET6 socekts. It only requires that IPv6 packets (with v4-mapped >addresses) are received on AF_INET6 sockets. Machines living on the v6 side >of the translator only need to speak v6! see my reply to yoshfuji. >> >> 3.2. Possible solutions >> >> o When implementing TCP or UDP stack, explicitly >> >> record the wire packet format (IPv4 or IPv6) >> >> into connection table. It is unwise to guess >> >> the wire packet format, by existence of IPv6 >> >> mapped address in the address pair. >> >If an implementation decides that it really needs >> >to know whether a packet came in as a real IPv4 >> >packet or as an IPv6 packet with mapped/translated/ >> >compatible addresses, then it could do this. >> >Why is this a bad solution? >> maybe my text is rather unclear, but what part are >> you referring to by the underlined "this"? >This = recording the wire packet format in the connection table. If you >really insist that user-land needs to know the difference for some reason, I >suppose you could do this and find some way for the kernel to pass it up >(ammend scope id behavior?). I still don't see the need though. This >transparency still strikes me as a feature, not a bug. i'm suggesting, in the draft, to record wire packet format in the connecdtion table. i'm objecting to guess wire packet format from address format, for example: if (IN6_IS_ADDR_V4MAPPED) wire format is IPv4 else wire format is IPv6 i think my english was not good enough. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 19:16:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M2Eie12821 for ipng-dist; Fri, 21 Jul 2000 19:14:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M2EY612814 for ; Fri, 21 Jul 2000 19:14:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA00739 for ; Fri, 21 Jul 2000 19:14:32 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24240 for ; Fri, 21 Jul 2000 19:14:32 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA14364; Sat, 22 Jul 2000 11:14:29 +0900 (JST) To: Brian Zill , ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Sat, 22 Jul 2000 11:09:04 JST. <14293.964231744@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sat, 22 Jul 2000 11:14:29 +0900 Message-ID: <14362.964232069@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > do you say the following packet trace is the expected behavior? > i hope you do not mean this... in the example, please ignore "MAC address" portion. i was making example where A and B are on the same link, and forgot to fix the portion. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 20:17:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M3FaE12869 for ipng-dist; Fri, 21 Jul 2000 20:15:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M3FG612862 for ; Fri, 21 Jul 2000 20:15:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA07866 for ; Fri, 21 Jul 2000 20:15:11 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA10673 for ; Fri, 21 Jul 2000 21:15:11 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id MAA02177; Sat, 22 Jul 2000 12:14:18 +0900 To: itojun@iijlab.net Cc: bzill@microsoft.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <14293.964231744@coconut.itojun.org> References: <2E3FA0558747934A8F753CC533A3F6DF01101E@red-msg-24.redmond.corp.microsoft.com> <14293.964231744@coconut.itojun.org> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000722121417J.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Sat, 22 Jul 2000 12:14:17 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <14293.964231744@coconut.itojun.org> (at Sat, 22 Jul 2000 11:09:04 +0900), itojun@iijlab.net says: > - if we got an IPv6 packet with ::ffff:127.0.0.1 in the source, > and it was from outside, the kernel does not drop it for the sake of > SIIT (too-clever SIIT enabled client may try to drop it because of > IPv4 rules) Not too-clever. SIIT should drop packets whose source address is ::ffff:a.b.c.d/(96+n) (assuming figure in my previous mail). Nodes in SIIT cloud should drop packets whose source address is ::ffff:127.0.0.0/104 and ::ffff:a.b.c.d/(96+n) from outside. Nodes not in SIIT cloud should drop ::ffff:0:0/96 from outside. Anyway, issues seems to be administrative problem. -- Hideaki YOSHIFUJI @ USAGI Project Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 20:30:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M3TVn12904 for ipng-dist; Fri, 21 Jul 2000 20:29:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M3TK612897 for ; Fri, 21 Jul 2000 20:29:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA28189 for ; Fri, 21 Jul 2000 20:29:19 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA13340 for ; Fri, 21 Jul 2000 21:29:17 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA14978; Sat, 22 Jul 2000 12:28:55 +0900 (JST) To: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) cc: bzill@microsoft.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-reply-to: yoshfuji's message of Sat, 22 Jul 2000 12:14:17 JST. <20000722121417J.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sat, 22 Jul 2000 12:28:55 +0900 Message-ID: <14976.964236535@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> and it was from outside, the kernel does not drop it for the sake of >> SIIT (too-clever SIIT enabled client may try to drop it because of >> IPv4 rules) > Not too-clever. i don't see any of your wording on RFC2765. i took your email as a suggestion to RFC2765, am I right? your suggestion does not protect nodes that are outside of SIIT cloud (which is more common setup today). how do you intend to secure those nodes? i think you are making separate discussion thread here. > SIIT should drop packets whose source address is > ::ffff:a.b.c.d/(96+n) (assuming figure in my previous mail). you mean the SIIT box ([SIIT] in the following figure) should drop the packet, when the packet tryes to go into the SIIT cloud? drop it ___________ <----- ___________ / \ / \ [IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host] \___________/ | \___________/ (pool of IPv4 addresses) > Nodes in SIIT cloud should drop packets whose source > address is ::ffff:127.0.0.0/104 and ::ffff:a.b.c.d/(96+n) from > outside. i don't think this is workable, as this requires every nodes in SIIT cloud to know about the IPv4 address pool configured to the SIIT cloud. From seeing RFC2765 section 5, I think that the nodes in SIIT cloud is unaware of the existence of SIIT box (or it does not know if it is inside SIIT cloud or not). > Nodes not in SIIT cloud should drop ::ffff:0:0/96 from outside. > Anyway, issues seems to be administrative problem. i think, for an end node in SIIT cloud, it is impossible to determine if the traffic is from the outside, or from inside. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 21 21:48:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6M4lc613072 for ipng-dist; Fri, 21 Jul 2000 21:47:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6M4lR613065 for ; Fri, 21 Jul 2000 21:47:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA09515 for ; Fri, 21 Jul 2000 21:47:23 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA28155 for ; Fri, 21 Jul 2000 22:47:23 -0600 (MDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 21 Jul 2000 21:45:37 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 21 Jul 2000 21:45:37 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF011021@red-msg-24.redmond.corp.microsoft.com> From: Brian Zill To: "'itojun@iijlab.net'" Cc: ipng@sunroof.eng.sun.com Subject: RE: New "IP Version 6 Addressing Architecture" draft Date: Fri, 21 Jul 2000 21:44:36 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, > as i wrote in my reply to yoshfuji's email, > - i still think it is real serious issue Oh, I believe that there are many serious security issues involved with a number of the transition mechanisms that are either proposed or in current use today. And I applaud you for taking the time to look into them. I just don't believe that forbidding IPv4-mapped addresses from appearing on the wire is necessary. I'm not even sure it's a viable solution, much less a good one. > - i'll come up with sample program, to show you > that it's real. Scenarios are fine, programs not required. > >Nor do you need to if you (the stack writer) > >only allow the same set of native-ipv4-mapped > >addresses to show up where you'd allow them as > >RFC2553-inbound addresses. > > i don't understand what you mean here... you say > that, if the stack accepts RFC2553-inbound case, > you need to accept native-ipv4-mapped? I'm saying that the stack should use the same criteria when deciding whether to accept an IPv6 packet with mapped addresses that it would use for the equivalent IPv4 packet. In the example mentioned, if you refuse to accept an IPv4 packet because it has a 127.0.0.1 source address, then you should refuse to accept an IPv6 packet with a ::ffff:127.0.0.1 source address. > - if we got an IPv4 packet with 127.0.0.1 in the > source, and it was from outside, it should be > dropped by the kernel. Okay, reasonable policy. > - if we got an IPv6 packet with ::ffff:127.0.0.1 > in the source, and it was from outside, the > kernel does not drop it for the sake of SIIT Huh? The policy should be the same. Drop the packet. SIIT doesn't have anything to do with it. SIIT doesn't require you to accept packets that an IPv4 host in place of the SIIT/v6-only host combination wouldn't accept. A combination SIIT box and IPv6 only host should look to the other side of the SIIT exactly like an IPv4 host. Likewise, it should look to the user-land API exactly like a hybrid v6/v4 stack host (it doesn't exactly because of IPv6 translated addresses, but that's why I suggested in my previous email that a hybrid host might want to present it's own v4 addresses as v4-translated addresses and remote addresses as v4-mapped addresses. But that's a nit). > do you say the following packet trace is the > expected behavior? > i hope you do not mean this... > > A: bad guy, using remote IPv4 address z.z.z.z > B: has an IPv4 address 10.1.1.1/24, has auto tunnel > support. (the use of private address is just > for example) > > IPv4 (src=z.z.z.z, dst=10.1.1.1) > IPv6 (src=::ffff:10.1.1.2, dst=::10.1.1.1) > UDP (src port=X, dst port=53) > DNS query > > as RFC1933/1933bis does not limit IPv6 source on auto > tunnel traffic, the packet will go all the way to the > IPv6 transport capable DNS server via AF_INET6 socket, > and gets replied. > > IPv4 (src=10.1.1.1, dst=10.1.1.2) > UDP (src port=53, dst port=X) > DNS reply Yes, that is exactly what I'd expect to happen. How does this differ from A sending an ordinary IPv4 packet with a spoofed source address of 10.1.1.2 to B? If it does differ, then the point at which it differs is where the security problem that needs to be fixed lies. > what i'm saying is, this is real hard to get it right. > there are many tunnelling technologies and transition > technology. for a given tunnelling/transition > technology Ti, we need to make sure that we make proper > checks against all the transition technologies, T{1..n}. I agree completely. Again, I'm glad you're looking into these issues. What I disagree with is your desire to remove a useful transition technology instead of making all the proper checks that would prevent its misuse. > i'm suggesting, in the draft, to record wire packet > format in the connecdtion table. i'm objecting to > guess wire packet format from address format, for > example: > if (IN6_IS_ADDR_V4MAPPED) > wire format is IPv4 > else > wire format is IPv6 > i think my english was not good enough. Your English is fine, and much better than my Japanese. What I'm saying is that I don't see why you'd ever need to guess. It shouldn't matter to the user-land program how the packet got there. The kernel should ensure that you get a v4-mapped packet with wire format of IPv6 if and only if it would have let you get the same packet with a wire format of IPv4. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 22 06:26:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6MDOam13270 for ipng-dist; Sat, 22 Jul 2000 06:24:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6MDOR613263 for ; Sat, 22 Jul 2000 06:24:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA23926 for ; Sat, 22 Jul 2000 06:24:28 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10277 for ; Sat, 22 Jul 2000 06:24:27 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.20.150.202) by smtp3.libero.it; 22 Jul 2000 15:24:23 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 1DDA24C62E; Sat, 22 Jul 2000 15:22:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 198124C62C for ; Sat, 22 Jul 2000 15:22:07 +0200 (CEST) Date: Sat, 22 Jul 2000 15:22:07 +0200 (CEST) From: Mauro Tortonesi To: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: <200007211908.PAA0000791976@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 21 Jul 2000, Jim Bound wrote: > but v4 mapped does not affect the ISV porting effort at all and in fact > makes their job much easier if the platform they are porting to supports > that paradigm. you are absolutely right. my concern was about api issues. a modification in the behaviour of af_inet6 passive socket, so that they are not allowed to accept connections from af_inet sockets, would have imho nightmarish effects. there has been a misunderstanding. i wanted to say that forbidding the use of ipv4 mapped address "on the wire" would surely eliminate all security problems. as someone has pointed out, this is not acceptable - and i am also of this opinion. but itojun is certainly right when he says that rfcs and drafts should be precise, clear and not contradictory when dealing with important matters that can become a security issue. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Sat Jul 22 21:23:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6N4Lpe13466 for ipng-dist; Sat, 22 Jul 2000 21:21:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6N4Le613459 for ; Sat, 22 Jul 2000 21:21:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA06762 for ; Sat, 22 Jul 2000 21:21:32 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA03798 for ; Sat, 22 Jul 2000 22:21:32 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id NAA23587; Sun, 23 Jul 2000 13:21:28 +0900 (JST) To: Brian Zill cc: ipng@sunroof.eng.sun.com In-reply-to: bzill's message of Fri, 21 Jul 2000 21:44:36 MST. <2E3FA0558747934A8F753CC533A3F6DF011021@red-msg-24.redmond.corp.microsoft.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Sun, 23 Jul 2000 13:21:27 +0900 Message-ID: <23585.964326087@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> as i wrote in my reply to yoshfuji's email, >> - i still think it is real serious issue >Oh, I believe that there are many serious security issues involved with a >number of the transition mechanisms that are either proposed or in current >use today. And I applaud you for taking the time to look into them. I just >don't believe that forbidding IPv4-mapped addresses from appearing on the >wire is necessary. I'm not even sure it's a viable solution, much less a >good one. if you have other suggestion to solve this particular issue (how to deal with unexpected native-ipv4-mapped packets), could you describe that briefly? i'm trying to understand your mindset, and it looks like as follows (correct me if i'm wrong): - IPv4 packet on the wire, and native-ipv4-mapped packet on the wire, must go through the same set of accept/deny policy in the kernel. (I believe this is not correct understanding of RFC2553 section 3.7. see below) - this is applications' responsibility to deal with native-ipv4-mapped packet. (this is close to impossible, from what RFC2553 provides) >> do you say the following packet trace is the >> expected behavior? >> i hope you do not mean this... >> >> A: bad guy, using remote IPv4 address z.z.z.z >> B: has an IPv4 address 10.1.1.1/24, has auto tunnel >> support. (the use of private address is just >> for example) >> >> IPv4 (src=z.z.z.z, dst=10.1.1.1) >> IPv6 (src=::ffff:10.1.1.2, dst=::10.1.1.1) >> UDP (src port=X, dst port=53) >> DNS query >> >> as RFC1933/1933bis does not limit IPv6 source on auto >> tunnel traffic, the packet will go all the way to the >> IPv6 transport capable DNS server via AF_INET6 socket, >> and gets replied. >> >> IPv4 (src=10.1.1.1, dst=10.1.1.2) >> UDP (src port=53, dst port=X) >> DNS reply > >Yes, that is exactly what I'd expect to happen. my understanding was, for a dual stack node outside of SIIT cloud, native-ipv4-mapped packets are unexpected and malicious. i now see you are not agreeing with me here. there is no specification that says "native-ipv4-mapped packet is effectively the same as native IPv4 packet". this is defined only in RFC2553, and SIIT document. RFC2553 explicitly states that IPv4 mapped address is used to identify real IPv4 peer. from this fact, if we are outside of SIIT cloud, I understand that native-ipv4-mapped should be dealt differently from normal IPv4 packets, and are indeed malicious (as someone is trying to inpersonate IPv4 peer). i think all other differences in understanding started from here (so i did not comment on other parts of the previous email from you). do you disagree with my thinking in the above? >How does this differ from A >sending an ordinary IPv4 packet with a spoofed source address of 10.1.1.2 to >B? - This is much harder to track down the source, or cause of the packet (partly because of tunnel, but you may say that this is a separate issue) - normal IPv4 ingress filter does not work (again, you can say it is tunnel issue - we are not in SIIT cloud, it is not expected to get native-ipv4-mapped packet and it is malicious. >If it does differ, then the point at which it differs is where the >security problem that needs to be fixed lies. this effectively saying that it is responsibility of userland program to protect against inpersonateing guys. however, there's not much userland application can do. this is partly because RFC2553 provides no way to understand which wire format was used. >> what i'm saying is, this is real hard to get it right. >> there are many tunnelling technologies and transition >> technology. for a given tunnelling/transition >> technology Ti, we need to make sure that we make proper >> checks against all the transition technologies, T{1..n}. >I agree completely. Again, I'm glad you're looking into these issues. What >I disagree with is your desire to remove a useful transition technology >instead of making all the proper checks that would prevent its misuse. do you think that every application writers can handle this complex checks? we at least need a guideline on "how to port your servers onto ipv6 without compromising security". once we go into total agreement i volunteer to start it. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 22 22:45:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6N5hiI13529 for ipng-dist; Sat, 22 Jul 2000 22:43:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6N5hX613522 for ; Sat, 22 Jul 2000 22:43:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA09859 for ; Sat, 22 Jul 2000 22:43:27 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA09016 for ; Sat, 22 Jul 2000 22:43:27 -0700 (PDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id OAA28568; Sun, 23 Jul 2000 14:43:16 +0900 To: itojun@iijlab.net Cc: bzill@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <23585.964326087@coconut.itojun.org> References: <2E3FA0558747934A8F753CC533A3F6DF011021@red-msg-24.redmond.corp.microsoft.com> <23585.964326087@coconut.itojun.org> X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000723144315O.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Sun, 23 Jul 2000 14:43:15 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <23585.964326087@coconut.itojun.org> (at Sun, 23 Jul 2000 13:21:27 +0900), itojun@iijlab.net says: > that briefly? i'm trying to understand your mindset, and it looks > like as follows (correct me if i'm wrong): > - IPv4 packet on the wire, and native-ipv4-mapped packet on the wire, > must go through the same set of accept/deny policy in the kernel. > (I believe this is not correct understanding of RFC2553 section 3.7. > see below) > - this is applications' responsibility to deal with native-ipv4-mapped > packet. (this is close to impossible, from what RFC2553 provides) I think: - IPv4 packet on the wire, and native-ipv4-mapped packet on the wire, should be handled by the same set of accept/deny policy in APPLICATIONs. - this is KERNEL's responsibility to deal with native-ipv4-mapped packet. KERNEL should drop malicious packet from outside. You too, Brian (Zill)? -- Hideaki YOSHIFUJI @ USAGI Project Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 06:24:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6NDNR413656 for ipng-dist; Sun, 23 Jul 2000 06:23:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6NDNH613649 for ; Sun, 23 Jul 2000 06:23:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA26698 for ; Sun, 23 Jul 2000 06:23:17 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07005 for ; Sun, 23 Jul 2000 07:23:16 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.20.153.230) by smtp2.libero.it; 23 Jul 2000 15:23:05 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id DC5934BEB0; Sun, 23 Jul 2000 14:36:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 9E19A4BE94; Sun, 23 Jul 2000 14:36:24 +0200 (CEST) Date: Sun, 23 Jul 2000 14:36:23 +0200 (CEST) From: Mauro Tortonesi To: ipng@sunroof.eng.sun.com, itojun@iijlab.net Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: <23585.964326087@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 23 Jul 2000 itojun@iijlab.net wrote: > do you think that every application writers can handle this complex > checks? we at least need a guideline on "how to port your servers > onto ipv6 without compromising security". once we go into total > agreement i volunteer to start it. this would be great. why not to write a guideline on "how to port your servers to ipv6", then? security should be the most interesting argument, but some other informations and usable code would be nice. i've read your article "implementing af-indipendent applications" and i've found it very interesting (i was about to write an updated version of it, with some code examples) - it could be an excellent starting point. if you are looking for help, i am into it ;-) -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Sun Jul 23 10:46:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6NHjPx13721 for ipng-dist; Sun, 23 Jul 2000 10:45:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6NHjG613714 for ; Sun, 23 Jul 2000 10:45:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA17168 for ; Sun, 23 Jul 2000 10:45:16 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17058 for ; Sun, 23 Jul 2000 10:45:11 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA15587; Mon, 24 Jul 2000 02:30:04 +0900 (JST) Date: Mon, 24 Jul 2000 02:40:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: haberman@nortelnetworks.com Cc: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: In your message of "Fri, 21 Jul 2000 08:46:37 -0400" <3978462D.BA263D3E@nortelnetworks.com> References: <4.3.2.7.2.20000713142500.0254f0b0@mailhost.iprg.nokia.com> <3978462D.BA263D3E@nortelnetworks.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 21 Jul 2000 08:46:37 -0400, >>>>> "Brian Haberman" said: > Yes, it is equivalent to the "local scope" defined in > RFC 2365 and RFC 2730. It should be noted that those documents > refer to IPv6 scope 3 currently, but will need to be changed > to scope 4. I see. Then I'd like to ask how large the admin-local scope is. Is there any relationship between other scopes? In fact, draft-ietf-ipngwg-scoping-arch-01.txt says as follows: o for multicast scopes, scopes with lesser values in the "scop" subfield of the multicast address [RFC 2373, section 2.7] are smaller than scopes with greater values, with node-local being the smallest and global being the According to this description, admin-local is larger than link-local and smaller than site-local. Is my understanding correct? And if so, is the definition really reasonable? (Although it depends on the definition of "site"). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 24 03:36:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6OAZRV14136 for ipng-dist; Mon, 24 Jul 2000 03:35:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OAZH614129 for ; Mon, 24 Jul 2000 03:35:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA08893 for ; Mon, 24 Jul 2000 03:35:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA17135 for ; Mon, 24 Jul 2000 04:35:15 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07941; Mon, 24 Jul 2000 06:35:14 -0400 (EDT) Message-Id: <200007241035.GAA07941@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addrconf-privacy-02.txt Date: Mon, 24 Jul 2000 06:35:14 -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 : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, R. Draves Filename : draft-ietf-ipngwg-addrconf-privacy-02.txt Pages : 16 Date : 21-Jul-00 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a DHCP server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an optional extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global- scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addrconf-privacy-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addrconf-privacy-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: <20000721171705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addrconf-privacy-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addrconf-privacy-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171705.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 Jul 24 05:03:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6OC1km14203 for ipng-dist; Mon, 24 Jul 2000 05:01:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OC1Z614196 for ; Mon, 24 Jul 2000 05:01:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA13139 for ; Mon, 24 Jul 2000 05:01:33 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04451 for ; Mon, 24 Jul 2000 05:01:32 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA11419; Mon, 24 Jul 2000 21:01:26 +0900 (JST) To: Tim Hartrick cc: ipng@sunroof.eng.sun.com In-reply-to: tim's message of Fri, 21 Jul 2000 17:08:34 MST. <200007220008.RAA03430@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Mon, 24 Jul 2000 21:01:26 +0900 Message-ID: <11417.964440086@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think most of the items are replied in reply to Brian. >> there's no way for the current API to recognize IPv4 traffic on top >> of AF_INET6 socket (appears as IPv4 mapped address), and native >> IPv6 traffic with IPv4 mapped address in the header). at least >> we need to provide the functionality. >Why does there need to be a distinction? In either case the communication >is with an IPv4 host. I don't understand why, from a policy point of view, >it matters to the target host whether the packet was routed directly >using IPv4 or translated into IPv6 from IPv4 by a SIIT box. The initiating >host is an IPv4 host by virtue of the fact that the address is a IPv4 mapped >IPv6 address. What i'm worrying about is, - when we are outside of SIIT cloud and - when we got an IPv6 packet with IPv4 mapped address as src/dst. This is the third case in the following chart. Sorry if I was not clear enough. For the case, I can do nothing but consider the packet as malicious, as no specification gives me any interpretation, and the packet is indeed usable to inpersonate some IPv4 peer. Just to be clear, documents are like below. - RFC2373 is silent about this case, RFC2373 only says that the IPv4 mapped address indicates IPv4 peer. in the third case, however, this does not really indicate IPv4 peer. - RFC2553 is also silent about this case, it talks about how real IPv4 peer is presented on AF_INET6 API. - SIIT is not the document to look at. in/out of IP version/src/dst what does the getpeername sees SIIT cloud of packet src represents? --- --- --- --- inside IPv6, IPv4 mapped SIIT-translated IPv4 mapped IPv4 peer on AF_INET6 inside IPv4 shouldn't happen can't accept it (IPv6 only) outside IPv6, IPv4 mapped inpersonater IPv4 mapped on (IMHO) AF_INET6 outside IPv4 real IPv4 peer IPv4 mapped on AF_INET6 (2553 behavior) or IPv4 on AF_INET itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 24 05:52:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6OColw14251 for ipng-dist; Mon, 24 Jul 2000 05:50:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OCod614244 for ; Mon, 24 Jul 2000 05:50:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA17323 for ; Mon, 24 Jul 2000 05:50:39 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA23730 for ; Mon, 24 Jul 2000 05:50:37 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 88A4869E; Mon, 24 Jul 2000 08:50:37 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5145D7C3; Mon, 24 Jul 2000 08:50:37 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id IAA0000740949; Mon, 24 Jul 2000 08:48:23 -0400 (EDT) From: Jim Bound Message-Id: <200007241248.IAA0000740949@anw.zk3.dec.com> To: Mauro Tortonesi Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-reply-to: Your message of "Sat, 22 Jul 2000 15:22:07 +0200." Date: Mon, 24 Jul 2000 08:48:23 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mauro, >> but v4 mapped does not affect the ISV porting effort at all and in fact >> makes their job much easier if the platform they are porting to supports >> that paradigm. >you are absolutely right. my concern was about api issues. a modification >in the behaviour of af_inet6 passive socket, so that they are not allowed >to accept connections from af_inet sockets, would have imho nightmarish >effects. An af_inet6 socket should not accept a connection for an af_inet socket. Any implementation specific code path in a hybrid stack (different from a dual stack I think you know??) that does this or neglects the issue will have problems as you state. If an implementation does this it is broken, the market will fix the correction. Also we have never had this problem at any test event. Also early on I have run ftp, telnet, etc at the same time and have not seen any bugs. In fact what you ask is a test at present. No where in any spec do we (the IETF or the XNET TBD API we are buildin the base for here on ipng group) require how one uses mapped, compatible, or native IPv6 addresses. Nor should we other than to define them and make them available to applications via the API. >there has been a misunderstanding. i wanted to say that forbidding the use >of ipv4 mapped address "on the wire" would surely eliminate all security >problems. as someone has pointed out, this is not acceptable - and i am >also of this opinion. but itojun is certainly right when he says that rfcs >and drafts should be precise, clear and not contradictory when dealing >with important matters that can become a security issue. If we could ever achieve perfection with any spec anywhere in the IETF we would never ship a spec. We go with what we can get done within in a reasonable amount of time and test the implementations. The market has already started to port to IPv6 and ISPs are putting it in their RFPs as other suppliers. I see no change to rfc2553bis API for this dicussion. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 24 06:21:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6ODKDq14287 for ipng-dist; Mon, 24 Jul 2000 06:20:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6ODK3614280 for ; Mon, 24 Jul 2000 06:20:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA20191 for ; Mon, 24 Jul 2000 06:20:02 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07546 for ; Mon, 24 Jul 2000 06:20:02 -0700 (PDT) Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com; Mon, 24 Jul 2000 08:14:41 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id PK70AQQR; Mon, 24 Jul 2000 06:18:11 -0700 Received: from nortelnetworks.com (CLEMSON [132.245.252.108]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id P1S0N4S4; Mon, 24 Jul 2000 09:18:10 -0400 Message-ID: <397C4129.A434EDAB@nortelnetworks.com> Date: Mon, 24 Jul 2000 09:14:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jinmei@isl.rdc.toshiba.co.jp CC: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft References: <4.3.2.7.2.20000713142500.0254f0b0@mailhost.iprg.nokia.com> <3978462D.BA263D3E@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >>>>> On Fri, 21 Jul 2000 08:46:37 -0400, > >>>>> "Brian Haberman" said: > > > Yes, it is equivalent to the "local scope" defined in > > RFC 2365 and RFC 2730. It should be noted that those documents > > refer to IPv6 scope 3 currently, but will need to be changed > > to scope 4. > > I see. Then I'd like to ask how large the admin-local scope is. Is > there any relationship between other scopes? > > In fact, draft-ietf-ipngwg-scoping-arch-01.txt says as follows: > > o for multicast scopes, scopes with lesser values in the > "scop" subfield of the multicast address [RFC 2373, > section 2.7] are smaller than scopes with greater values, > with node-local being the smallest and global being the > > According to this description, admin-local is larger than link-local > and smaller than site-local. Is my understanding correct? And if so, > is the definition really reasonable? (Although it depends on the > definition of "site"). > Your understanding is correct (link-local <= scope 3 <= scope 4 <= site-local). Is it reasonable? I believe so. Several of us discussed this issue in relation to RFC 2365 and determined that scope 4 allows for more flexibility in the use of admin scoped multicast. Brian -- Brian Haberman Nortel Networks haberman@nortelnetworks.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 24 11:11:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6OI9TB14583 for ipng-dist; Mon, 24 Jul 2000 11:09:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OI9K614576 for ; Mon, 24 Jul 2000 11:09:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA19061 for ; Mon, 24 Jul 2000 11:09:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01009 for ; Mon, 24 Jul 2000 12:09:17 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA00403; Mon, 24 Jul 2000 11:07:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA27774; Mon, 24 Jul 2000 11:07:53 -0700 X-Virus-Scanned: Mon, 24 Jul 2000 11:07:53 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdTezcW8; Mon, 24 Jul 2000 11:07:50 PDT Message-Id: <4.3.2.7.2.20000724095640.025dc980@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 11:05:09 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Proposed IPng Agenda for Pittsburgh IETF Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the proposed agenda for the IPng w.g. sessions at the Pittsburgh IETF. The IPng working group will have two sessions. There will also be a joint IPng / Mobile IP session on Tuesday. The agenda for that session will be sent out separately. Please send us changes, additions, and corrections. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------- WEDNESDAY, August 2, 2000 1300-1500 (120 min) Introduction / S. Deering (5 min) Review Agenda / S. Deering (10 min) Document Status / R. Hinden (10 min) Updated Working Group Charter / R. Hinden (10 min) Summary of joint IPng / MobileIP session / T. Narten (10 min) Enabling/disabling mapped addresses on a socket / D. Thaler (5 min) Enabling/disabling IPv4/IPv6 on the same listening socket / D. Thaler (5 min) Use of the scope_id field with multicast addresses / D. Thaler (5 min) Source/Destination address selection / R. Draves, S. Deering (30 min) IPv6 Multihoming support at site exit routers / J. I. Hagino (10 min) IPv6 Multihoming with Route Aggregation / J. Yu (10 min) EDNS0 for the IPv6 environment / K. Yamamoto, S. Deering (10 min) THURSDAY, August 3, 2000 1300-1500 (120 min) Scoped Address Architecture / S. Deering (45 min) Privacy Extensions for Stateless Address Autoconfig / T. Narten (15 min) Transmission of IPv6 Packets over IEEE 1394 Networks / A. Onoe (15 min) PPP Dialup Drafts / J. I. Hagino (20 min) Bi-Directional Tunneling / A. Conta (10 min) Internet v6 General Packet Radio Service / H. Afifi, C. Perkins (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 Mon Jul 24 13:55:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6OKpst14862 for ipng-dist; Mon, 24 Jul 2000 13:51:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OKpj614855 for ; Mon, 24 Jul 2000 13:51:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA28108 for ; Mon, 24 Jul 2000 13:51:44 -0700 (PDT) Received: from motgate3.mot.com ([144.189.100.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05318 for ; Mon, 24 Jul 2000 13:51:43 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA03929 for ; Mon, 24 Jul 2000 13:50:08 -0700 (MST)] Received: [from ilms02.cig.mot.com (ilms02.cig.mot.com [136.182.15.12]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id NAA02808 for ; Mon, 24 Jul 2000 13:51:30 -0700 (MST)] Received: from em.cig.mot.com ([160.44.128.5]) by ilms02.cig.mot.com (Netscape Messaging Server 3.6) with SMTP id AAA5522; Mon, 24 Jul 2000 15:51:29 -0500 Received: by em.cig.mot.com (SMI-8.6/SMI-SVR4) id PAA06857; Mon, 24 Jul 2000 15:51:28 -0500 Date: Mon, 24 Jul 2000 15:51:28 -0500 Message-Id: <200007242051.PAA06857@em.cig.mot.com> To: ipng@sunroof.eng.sun.com CC: mauro@ferrara.linux.it, bound@zk3.dec.com, randall@stewart.chicago.il.us, SIGTRAN@STANDARDS.NORTELNETWORKS.COM In-reply-to: <200007241248.IAA0000740949@anw.zk3.dec.com> (message from Jim Bound on Mon, 24 Jul 2000 08:48:23 -0400) Subject: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: "La Monte Henry Piggy Yarroll" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The discussion below raises concerns with our proposed draft for an SCTP sockets API. SCTP is a reliable datagram transport developed by SIGTRAN to carry telephony signaling information. One distinctive feature of SCTP is direct support for multi-homed hosts. SCTP has the notion of a "primary address" to which it sends most packets. It may optionally send heartbeat messages to other addresses of a correspondent node. If the primary fails SCTP switches to a different correspondent address. The issue is that a single host may have both IPv4 AND IPv6 interfaces. SCTP allows a single association (connection) to span both kinds of interface. In our API draft we have suggested af_inet6 as the socket type for associations with mixed address types. Effectively, we can create a passive socket which listens for connections on both af_inet and af_inet6 ports. Jim Bound's comment appears to claim this is a bad idea: >An af_inet6 socket should not accept a connection for an af_inet socket. May I invite you to read draft-stewart-sctpsocket-sigtran-00.txt and comment? Have we missed a critical IPv6 consideration? -- Put no trust in extortion, La Monte Henry Piggy Yarroll set no vain hope in plunder; NIC Handle LY if riches increase, do not set your heart upon them. Jim Bound writes: >Mauro, > >>> but v4 mapped does not affect the ISV porting effort at all and in fact >>> makes their job much easier if the platform they are porting to supports >>> that paradigm. > >>you are absolutely right. my concern was about api issues. a modification >>in the behaviour of af_inet6 passive socket, so that they are not allowed >>to accept connections from af_inet sockets, would have imho nightmarish >>effects. > >An af_inet6 socket should not accept a connection for an af_inet socket. >Any implementation specific code path in a hybrid stack (different from >a dual stack I think you know??) that does this or neglects the issue >will have problems as you state. If an implementation does this it is >broken, the market will fix the correction. Also we have never had this >problem at any test event. Also early on I have run ftp, telnet, etc at >the same time and have not seen any bugs. In fact what you ask is a >test at present. > >No where in any spec do we (the IETF or the XNET TBD API we are buildin >the base for here on ipng group) require how one uses mapped, >compatible, or native IPv6 addresses. Nor should we other than to >define them and make them available to applications via the API. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 24 15:18:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6OMGYU14978 for ipng-dist; Mon, 24 Jul 2000 15:16:34 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OMGT614971 for ; Mon, 24 Jul 2000 15:16:29 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id PAA09904 for ipng@sunroof.eng.sun.com; Mon, 24 Jul 2000 15:14:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6OMB1614940 for ; Mon, 24 Jul 2000 15:11:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA22420 for ; Mon, 24 Jul 2000 15:11:02 -0700 (PDT) Received: from stewart.chicago.il.us (3ff83343.dsl.flashcom.net [63.248.51.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02852 for ; Mon, 24 Jul 2000 15:10:55 -0700 (PDT) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id RAA07073; Mon, 24 Jul 2000 17:00:21 -0500 Message-ID: <397CBC74.BA25DE0D@stewart.chicago.il.us> Date: Mon, 24 Jul 2000 17:00:20 -0500 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: La Monte Henry Piggy Yarroll CC: ipng@sunroof.eng.sun.com, mauro@ferrara.linux.it, bound@zk3.dec.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) References: <200007242051.PAA06857@em.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All: One note to all you readers.. this draft is a very very early first cut. We rushed it out to get it in to the drafts editor and thus it requires quite a bit of work yet :-> I did not get Jim's original email so I have a hard time reading the snippet below and making sense of it... I can see a "Tcp compatible issue" in that it may be a bit strange to listen on a "compatible" type socket and get a connection to one that is only IPv4.. This may just be a issue of NOT allowing it on the "TCP compatability type" socket... The new interface I think should work fine ..I don't see issues with it. I would be glad to note comments on these and other items... as I said it is rough I am sure there are all sorts of spelling and grammer problems yet to be fixed .. Regards R La Monte Henry Piggy Yarroll wrote: > > The discussion below raises concerns with our proposed draft for > an SCTP sockets API. SCTP is a reliable datagram transport developed > by SIGTRAN to carry telephony signaling information. > > One distinctive feature of SCTP is direct support for multi-homed > hosts. SCTP has the notion of a "primary address" to which it sends > most packets. It may optionally send heartbeat messages to other > addresses of a correspondent node. If the primary fails SCTP switches > to a different correspondent address. > > The issue is that a single host may have both IPv4 AND IPv6 > interfaces. SCTP allows a single association (connection) to span > both kinds of interface. In our API draft we have suggested af_inet6 > as the socket type for associations with mixed address types. > Effectively, we can create a passive socket which listens for > connections on both af_inet and af_inet6 ports. > > Jim Bound's comment appears to claim this is a bad idea: > >An af_inet6 socket should not accept a connection for an af_inet socket. > > May I invite you to read draft-stewart-sctpsocket-sigtran-00.txt and > comment? Have we missed a critical IPv6 consideration? > -- > Put no trust in extortion, La Monte Henry Piggy Yarroll > set no vain hope in plunder; NIC Handle LY > if riches increase, > do not set your heart upon them. > > Jim Bound writes: > >Mauro, > > > >>> but v4 mapped does not affect the ISV porting effort at all and in fact > >>> makes their job much easier if the platform they are porting to supports > >>> that paradigm. > > > >>you are absolutely right. my concern was about api issues. a modification > >>in the behaviour of af_inet6 passive socket, so that they are not allowed > >>to accept connections from af_inet sockets, would have imho nightmarish > >>effects. > > > >An af_inet6 socket should not accept a connection for an af_inet socket. > >Any implementation specific code path in a hybrid stack (different from > >a dual stack I think you know??) that does this or neglects the issue > >will have problems as you state. If an implementation does this it is > >broken, the market will fix the correction. Also we have never had this > >problem at any test event. Also early on I have run ftp, telnet, etc at > >the same time and have not seen any bugs. In fact what you ask is a > >test at present. > > > >No where in any spec do we (the IETF or the XNET TBD API we are buildin > >the base for here on ipng group) require how one uses mapped, > >compatible, or native IPv6 addresses. Nor should we other than to > >define them and make them available to applications via the API. -- Randall R. Stewart randall@stewart.chicago.il.us -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 24 20:39:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6P3cKR15207 for ipng-dist; Mon, 24 Jul 2000 20:38:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6P3cB615200 for ; Mon, 24 Jul 2000 20:38:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA08748 for ; Mon, 24 Jul 2000 20:38:09 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA24456 for ; Mon, 24 Jul 2000 20:38:09 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 0D55B526; Mon, 24 Jul 2000 23:38:09 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 737CF6A3; Mon, 24 Jul 2000 23:38:08 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000616731; Mon, 24 Jul 2000 23:36:39 -0400 (EDT) From: Jim Bound Message-Id: <200007250336.XAA0000616731@anw.zk3.dec.com> To: "La Monte Henry Piggy Yarroll" Cc: ipng@sunroof.eng.sun.com, mauro@ferrara.linux.it, bound@zk3.dec.com, randall@stewart.chicago.il.us, SIGTRAN@STANDARDS.NORTELNETWORKS.COM Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) In-reply-to: Your message of "Mon, 24 Jul 2000 15:51:28 CDT." <200007242051.PAA06857@em.cig.mot.com> Date: Mon, 24 Jul 2000 23:36:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think I may have been misunderstood. Let me see if the response clears it up? >The discussion below raises concerns with our proposed draft for >an SCTP sockets API. SCTP is a reliable datagram transport developed >by SIGTRAN to carry telephony signaling information. >One distinctive feature of SCTP is direct support for multi-homed >hosts. SCTP has the notion of a "primary address" to which it sends >most packets. It may optionally send heartbeat messages to other >addresses of a correspondent node. If the primary fails SCTP switches >to a different correspondent address. >The issue is that a single host may have both IPv4 AND IPv6 >interfaces. SCTP allows a single association (connection) to span >both kinds of interface. In our API draft we have suggested af_inet6 >as the socket type for associations with mixed address types. This is a good idea and why I believe a hybrid stack is far superior to a pure dual stack implementation. This paradigm is also inline with the IPv6 deployment message which is IPv4/IPv6 Integration not Migration. So I am real happy to hear SCTP is thinking that way too. >Effectively, we can create a passive socket which listens for >connections on both af_inet and af_inet6 ports. Yes. >Jim Bound's comment appears to claim this is a bad idea: >>An af_inet6 socket should not accept a connection for an af_inet socket. If there is a v4 listener and a v6 listener then that is fine. the af_inet connect in should go to the v4 listener and an af_inet6 connect in should go to the v6 listener. But it is perfectly valid for a v6 listener to accept connections from af_inet and af_inet6 incoming connections, where af_inet will be mapped addresses. An ISV server app can port to IPv6 supporting both v4 and v6, using af_inet6. Above what I am saying is if a v4 listener and a v6 listener exist, then af_inet incoming connections should be sent to the v4 listener. Good catch I made to many assumptions about after the preposition "for" and it was too terse. But that is what I mean't by the prep phase "for an af_inet socket". Meaning let the v4 listner have that connection, not the v6 listener. Sorry. There is an issue for the case where an app that is only doing v6 listener for both incoming af_inet and af_inet6, where the app may want to not receive any connections from v4. Bill Sommerfield pointed this out to me offline. The issue is that the v6 socket binds before a v4 bind and the v6 socket receives the v4 address as v4mapped. What we probably want to do is have a setsockopt in rfc2553bis that says DON"T ACCEPT V4MAPPED connections (there are other ways to do this but the socket level option is the cleanest). But the idea is to not have applications have to run two instances for v4 and v6, but only one instance (e.g. telnet, ftp, NFS, sctp app, oracle app). It also permits ISVs to ship one code base and if the user does not even use IPv6 the app still works, until the user turns on IPv6 ---> Integration. This will come up at ipng meeting via Dave Thaler agenda item. >May I invite you to read draft-stewart-sctpsocket-sigtran-00.txt and >comment? Have we missed a critical IPv6 consideration? Its on my plate to read. I for one will try to respond to you privately and any other authors (as I am not on sigtran and trying to avoid that) before next Monday a.m. Do you want me to respond to the list if I see holes? Your call? thanks for listening, /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 Jul 25 09:12:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PGAgg15514 for ipng-dist; Tue, 25 Jul 2000 09:10:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PGAX615507 for ; Tue, 25 Jul 2000 09:10:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA22632 for ; Tue, 25 Jul 2000 09:10:33 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16048 for ; Tue, 25 Jul 2000 10:10:26 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.20.136.231) by smtp3.libero.it; 25 Jul 2000 18:10:16 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 07E8C4C4B8; Tue, 25 Jul 2000 17:46:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id D823C4BD62; Tue, 25 Jul 2000 17:46:13 +0200 (CEST) Date: Tue, 25 Jul 2000 17:46:13 +0200 (CEST) From: Mauro Tortonesi To: Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: <200007241248.IAA0000740949@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 24 Jul 2000, Jim Bound wrote: > >you are absolutely right. my concern was about api issues. a modification > >in the behaviour of af_inet6 passive socket, so that they are not allowed > >to accept connections from af_inet sockets, would have imho nightmarish ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ sorry, my english is poor - let me explain better. suppose we have an ipv6 passive socket waiting for an incoming connection. it must be able to recognise requests from ipv4 nodes and present them to the "accept" syscall as af_inet6 socket with an ipv4-mapped address. imho this behaviour, which is specified in rfc2553, should not be modified. > An af_inet6 socket should not accept a connection for an af_inet socket. you are right. they should open another af_inet socket and fall back to an ipv4 connection. however, rfc2553 does not even suggest this behaviour. quoting from draft-ietf-ipngwg-rfc2553bis-00.txt, section 3.7: - 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.7, is - provided. let me understand, when an af_inet6 socket opens a connection with another af_inet6 socket with ipv4-mapped address, the communication established is in ipv4, isn't it? so ipv4-mapped addresses are not only used for node representation (as they are returned from getaddrinfo and getipnodebyname), but also to establish a connection to an ipv4 host. so the only protocol that requires ipv4-mapped addresses "on the wire" is SIIT. if SIIT is not used, then the kernel can reject all connection from outside with an ipv4-mapped address, for security issues - like itojun has explained us very well. by the way, can you point me to a rfc which explains the difference between a hybrid stack and a dual stack? i have not read them all - maybe i have missed an important one. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Jul 25 09:41:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PGdcA15580 for ipng-dist; Tue, 25 Jul 2000 09:39:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PGdS615573 for ; Tue, 25 Jul 2000 09:39:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA29152 for ; Tue, 25 Jul 2000 09:39:27 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08308 for ; Tue, 25 Jul 2000 10:39:26 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA05257 for ; Tue, 25 Jul 2000 09:38:50 -0700 (MST)] Received: [from ilms03.cig.mot.com (ilms03.cig.mot.com [136.182.15.13]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA05211 for ; Tue, 25 Jul 2000 09:38:49 -0700 (MST)] Received: from em.cig.mot.com ([160.44.128.5]) by ilms03.cig.mot.com (Netscape Messaging Server 3.01) with SMTP id AAA24133; Tue, 25 Jul 2000 11:38:48 -0500 Received: by em.cig.mot.com (SMI-8.6/SMI-SVR4) id LAA09292; Tue, 25 Jul 2000 11:38:48 -0500 Date: Tue, 25 Jul 2000 11:38:48 -0500 Message-Id: <200007251638.LAA09292@em.cig.mot.com> To: bound@zk3.dec.com CC: ipng@sunroof.eng.sun.com, mauro@ferrara.linux.it, bound@zk3.dec.com, randall@stewart.chicago.il.us, SIGTRAN@STANDARDS.NORTELNETWORKS.COM In-reply-to: <200007250336.XAA0000616731@anw.zk3.dec.com> (message from Jim Bound on Mon, 24 Jul 2000 23:36:38 -0400) Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: "La Monte Henry Piggy Yarroll" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound writes: >I think I may have been misunderstood. Let me see if the response clears it >up? ... >[piggy wrote:] >> The issue is that a single host may have both IPv4 AND IPv6 >> interfaces. SCTP allows a single association (connection) to span >> both kinds of interface. In our API draft we have suggested >> af_inet6 as the socket type for associations with mixed address >> types. > > This is a good idea and why I believe a hybrid stack is far superior > to a pure dual stack implementation. This paradigm is also inline > with the IPv6 deployment message which is IPv4/IPv6 Integration not > Migration. So I am real happy to hear SCTP is thinking that way > too. Good. I think I now understand your distinction between a hybrid stack and a dual stack. >> Effectively, we can create a passive socket which listens for >> connections on both af_inet and af_inet6 ports. > > Yes. > >> Jim Bound's comment appears to claim this is a bad idea: >>> An af_inet6 socket should not accept a connection for an af_inet socket. > > If there is a v4 listener and a v6 listener then that is fine. ... > Above what I am saying is if a v4 listener and a v6 listener exist, > then af_inet incoming connections should be sent to the v4 listener. Is this v4 listener listening on INADDR_ANY and the v6 listener listening on in6addr_any for the same port? IMHO this should be illegal. The second listener should get an EBUSY when attempting to bind. > Good catch I made to many assumptions about after the preposition "for" > and it was too terse. But that is what I mean't by the prep phase > "for an af_inet socket". Meaning let the v4 listner have that > connection, not the v6 listener. Sorry. > There is an issue for the case where an app that is only doing v6 > listener for both incoming af_inet and af_inet6, where the app may want > to not receive any connections from v4. Bill Sommerfield pointed this > out to me offline. The issue is that the v6 socket binds before a v4 > bind and the v6 socket receives the v4 address as v4mapped. What we > probably want to do is have a setsockopt in rfc2553bis that says DON"T > ACCEPT V4MAPPED connections (there are other ways to do this but the > socket level option is the cleanest). Blech! In SCTP we need to allow binding on arbitrary subsets of addresses. Our solution is to allow multiple calls to bind(). There is nothing special about the sets "all IPv4 addresses" and "all IPv6 addresses" (well, there shouldn't be...). > But the idea is to not have applications have to run two instances > for v4 and v6, but only one instance (e.g. telnet, ftp, NFS, sctp > app, oracle app). It also permits ISVs to ship one code base and if > the user does not even use IPv6 the app still works, until the user > turns on IPv6 ---> Integration. This is definately the way to go. I shouldn't even have to "turn on IPv6 Integration". If all of my interfaces are ifconfig'd with v4 addresses, then I don't do IPv6... > This will come up at ipng meeting via Dave Thaler agenda item. I'll make a point of attending, thanks. -- Put no trust in extortion, La Monte Henry Piggy Yarroll set no vain hope in plunder; NIC Handle LY if riches increase, do not set your heart upon them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 10:53:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PHqEY15843 for ipng-dist; Tue, 25 Jul 2000 10:52:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PHq5615836 for ; Tue, 25 Jul 2000 10:52:06 -0700 (PDT) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA26514 for ; Tue, 25 Jul 2000 10:52:05 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04993 for ; Tue, 25 Jul 2000 10:51:53 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 1BD175E31; Tue, 25 Jul 2000 13:50:06 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BBF315F22; Tue, 25 Jul 2000 13:50:05 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0000717700; Tue, 25 Jul 2000 13:49:26 -0400 (EDT) From: Jim Bound Message-Id: <200007251749.NAA0000717700@anw.zk3.dec.com> To: Mauro Tortonesi Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-reply-to: Your message of "Tue, 25 Jul 2000 17:46:13 +0200." Date: Tue, 25 Jul 2000 13:49:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mauro, hey your bringing out important stuff here that needs to be understood. thanks...it is just so busy before an ietf meeting on the lists... >> >you are absolutely right. my concern was about api issues. a modification >> >in the behaviour of af_inet6 passive socket, so that they are not allowed >> >to accept connections from af_inet sockets, would have imho nightmarish ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >sorry, my english is poor - let me explain better. suppose we have an ipv6 >passive socket waiting for an incoming connection. it must be able to >recognise requests from ipv4 nodes and present them to the "accept" >syscall as af_inet6 socket with an ipv4-mapped address. >imho this behaviour, which is specified in rfc2553, should not be modified. Great. Your english is fine. Mine has been bad here because I am so busy I am typing in terse mode which I have stopped now, on this trhead anyway. Sorry. >> An af_inet6 socket should not accept a connection for an af_inet socket. > >you are right. they should open another af_inet socket and fall back to >an ipv4 connection. however, rfc2553 does not even suggest this behaviour. >quoting from draft-ietf-ipngwg-rfc2553bis-00.txt, section 3.7: OK I explained this in mail last night my "for" statement implied to much for any reader. Assume you have that mail? >- 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.7, is >- provided. > >let me understand, when an af_inet6 socket opens a connection with >another af_inet6 socket with ipv4-mapped address, the communication >established is in ipv4, isn't it? so ipv4-mapped addresses are not only >used for node representation (as they are returned from getaddrinfo and >getipnodebyname), but also to establish a connection to an ipv4 host. This is permissible but not required. The API can ask for just plain old IPv4 addresses too using af_inet with the API. How thats implemented in the stack is none of the standards groups business. >so the only protocol that requires ipv4-mapped addresses "on the wire" >is SIIT. if SIIT is not used, then the kernel can reject all connection >from outside with an ipv4-mapped address, for security issues - like >itojun has explained us very well. This should be permissable and I think we need to add a socket level option for af_inet6 that states do not accept v4mapped connections, for af_inet6 listeners. This would be reflected in the next iteration (hopefully last call) in rfc2553bis. >by the way, can you point me to a rfc which explains the difference >between a hybrid stack and a dual stack? i have not read them all - maybe >i have missed an important one. Hmmm. There really is no rfc for this but you might want to do a search on "hybrid stacks" on the web. You can look at rfc1006, rfc1001/1002 which is very very old but is the key point of a hybrid stack. Roughly let me try to explain without going off the deep end of networking computer science derivations of how to build network stacks. A dual stack typically means that each stack is fully implemented completely for a networking protocol. So for example using IP (can apply to any network protocol) using BSD as a model. There would be ip_input4.c and ip_input6.c and tcp_userreq4.c and tcpuserreq6.c. I don't think anyone has done anything like that I hope as that is pure kernel bloat for the networking subsystem and to much duplication at least for a product focused IP stack. Another approach is to build a dual IP layer, common transport layer, and a dual API layer, but the IPv6 API layer can handle both v4 and v6 (like DNS as an example). This means that after the IP layer all IP datastructures are 16bytes, hence, IPv4 is represented as v4mapped. A hybrid stack integrates those parts of the stack where Ipv4 and Ipv6 can perform code reuse, avoid duplication of datastructures, but at the same time avoid excessive conditional primitives within the stack implementation. For Ipv4 and IPv6 many of us were able to do this (probably in different ways) and maintain the performance and compatibility of IPv4 binaries. To keep performance is a lot of work but the integration of Ipv4 and IPv6 is worth the work from a "product perspective". What we have done in the IETF is use the term Dual Stack in most specs to mean that an implementation can support both IPv4 and IPv6. But most of us have not built pure dual stacks but hybrid stacks. If you look at the basic transition mechanisms from Erik Nordmark and Bob Gilligan you will see reference to "dual IP layer" draft-ietf-ngtrans-mech-06.txt and I think far more appropriate than saying dual stack. Even in one of my co-author'd specs I am guilty of abusing dual stack draft-ietf-ngtrans-dstm-02.txt. But we live with the misnomer in IPng. It would be to much work and discussion to fix it. But it always raises its ugly head when we discuss the implementation of the APIs. Also one of the advantages of IPv6 when it was first presented as an IPng within the IETF was that we would be able to build a clean hybrid IPv4+IPv6 stack, which in opinion would not have been possible with the competing proposals back in 1993-1994 for IPng in the IETF. You can also look at something we did disclosing our IPv6 Prototype implementation details for a good discussion of what I allude to above, but realize the paper is now old and whether we update it is TBD but it is a good point of reference for you and open to the public to view. http://www.digital.com/DTJN01/DTJN01HM.HTM regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 25 11:02:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PI0xg15883 for ipng-dist; Tue, 25 Jul 2000 11:00:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PI0o615876 for ; Tue, 25 Jul 2000 11:00:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA23106 for ; Tue, 25 Jul 2000 11:00:49 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08921 for ; Tue, 25 Jul 2000 11:00:47 -0700 (PDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id E237A1857; Tue, 25 Jul 2000 13:00:44 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 2057E1A05; Tue, 25 Jul 2000 13:00:44 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id OAA0000722692; Tue, 25 Jul 2000 14:00:36 -0400 (EDT) From: Jim Bound Message-Id: <200007251800.OAA0000722692@anw.zk3.dec.com> To: "La Monte Henry Piggy Yarroll" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, mauro@ferrara.linux.it, randall@stewart.chicago.il.us, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, bound@zk3.dec.com Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) In-reply-to: Your message of "Tue, 25 Jul 2000 11:38:48 CDT." <200007251638.LAA09292@em.cig.mot.com> Date: Tue, 25 Jul 2000 14:00:35 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> This is a good idea and why I believe a hybrid stack is far superior >> to a pure dual stack implementation. This paradigm is also inline >> with the IPv6 deployment message which is IPv4/IPv6 Integration not >> Migration. So I am real happy to hear SCTP is thinking that way >> too. > >Good. I think I now understand your distinction between a hybrid >stack and a dual stack. Great. See my last mail to Mauro too just sent I go into more detail on the principle (or is that principal :----)) >>> Effectively, we can create a passive socket which listens for >>> connections on both af_inet and af_inet6 ports. >> >> Yes. >> >>> Jim Bound's comment appears to claim this is a bad idea: >>>> An af_inet6 socket should not accept a connection for an af_inet socket. >> >> If there is a v4 listener and a v6 listener then that is fine. >... >> Above what I am saying is if a v4 listener and a v6 listener exist, >> then af_inet incoming connections should be sent to the v4 listener. >Is this v4 listener listening on INADDR_ANY and the v6 listener >listening on in6addr_any for the same port? IMHO this should be >illegal. The second listener should get an EBUSY when attempting to >bind. I think it should be illegal too. Its like running telnetv4 and telnetv6 on the same node. Pretty stupid IMO. But if we have a socket level option to not accept v4mapped for af_inet6 it will let it happen in theory (not that I believe we should). >> Good catch I made to many assumptions about after the preposition "for" >> and it was too terse. But that is what I mean't by the prep phase >> "for an af_inet socket". Meaning let the v4 listner have that >> connection, not the v6 listener. Sorry. > >> There is an issue for the case where an app that is only doing v6 >> listener for both incoming af_inet and af_inet6, where the app may want >> to not receive any connections from v4. Bill Sommerfield pointed this >> out to me offline. The issue is that the v6 socket binds before a v4 >> bind and the v6 socket receives the v4 address as v4mapped. What we >> probably want to do is have a setsockopt in rfc2553bis that says DON"T >> ACCEPT V4MAPPED connections (there are other ways to do this but the >> socket level option is the cleanest). >Blech! In SCTP we need to allow binding on arbitrary subsets of >addresses. Our solution is to allow multiple calls to bind(). There >is nothing special about the sets "all IPv4 addresses" and "all IPv6 >addresses" (well, there shouldn't be...). I agree so an sctp app in this case would not set the socket level option. >> But the idea is to not have applications have to run two instances >> for v4 and v6, but only one instance (e.g. telnet, ftp, NFS, sctp >> app, oracle app). It also permits ISVs to ship one code base and if >> the user does not even use IPv6 the app still works, until the user >> turns on IPv6 ---> Integration. >This is definately the way to go. I shouldn't even have to "turn on >IPv6 Integration". If all of my interfaces are ifconfig'd with v4 >addresses, then I don't do IPv6... I agree. Simple is beautiful to most users. >> This will come up at ipng meeting via Dave Thaler agenda item. > >I'll make a point of attending, thanks. That would be good as your one of those **real** users of this API we need to hear from. /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 Jul 25 11:20:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PIJCA15920 for ipng-dist; Tue, 25 Jul 2000 11:19:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PIJ2615913 for ; Tue, 25 Jul 2000 11:19:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA28132 for ; Tue, 25 Jul 2000 11:19:00 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22652 for ; Tue, 25 Jul 2000 11:18:55 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id D8907921; Tue, 25 Jul 2000 13:18:51 -0500 (CDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 35BFD840; Tue, 25 Jul 2000 13:18:51 -0500 (CDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id OAA0000024608; Tue, 25 Jul 2000 14:18:50 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA22313; Tue, 25 Jul 2000 14:18:49 -0400 Message-Id: <397DDA08.465C8DEB@zk3.dec.com> Date: Tue, 25 Jul 2000 14:18:49 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: aconta@txc.com, deering@cisco.com Cc: IPNG Working Group Subject: Tunnel Encapsulation Limit Option in rfc2473 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello After discussing this with a colleague who is trying to implement this spec I believe there may be a problem with defining Tunnel Encapsulation Limit Option as a Destination Option. When the packet is fragmented, the destination option header can be placed in the fragment if no routing header is present in the packet. Now, if you have nested tunnels, entry point for each tunnel will be doing fragmentation. So, the first tunnel entry point will encapsulate the original packet, add the destination option, and then fragment to path MTU, palcing the destination option in one of the fragments. For the inner tunnel to correctly process the Tunnel Encapsulation Limit Option, the inner tunnel entry points will have to reassemble the packet, but there is no guarantee that it will have all the framents. There are 3 solutions to this that I can see. 1. Each entry point will have to add a routing header. - this is not very clean. 2. Use Hop by Hop option. 3. Invent another tunnel specific extension header that will be placed in every fragment. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 11:56:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PItJt15994 for ipng-dist; Tue, 25 Jul 2000 11:55:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PItA615987 for ; Tue, 25 Jul 2000 11:55:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA02723 for ; Tue, 25 Jul 2000 11:55:09 -0700 (PDT) Received: from dopey.usu.edu (dopey.usu.edu [129.123.1.118]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25464 for ; Tue, 25 Jul 2000 12:55:08 -0600 (MDT) Received: from EBONY ("port 1137"@ebony.cs.usu.edu [129.123.7.242]) by cc.usu.edu (PMDF V5.2-32 #39375) with SMTP id <01JS6O07JZXKAC3EOJ@cc.usu.edu> for ipng@sunroof.eng.sun.com; Tue, 25 Jul 2000 12:55:07 MDT Date: Tue, 25 Jul 2000 12:56:24 -0600 From: Akshay Kumar Sreeramoju Subject: testing To: ipng@sunroof.eng.sun.com Message-id: <015401bff66a$078e5d40$f2077b81@usu.edu> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: multipart/alternative; boundary="----=_NextPart_000_0151_01BFF637.BCEAC580" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0151_01BFF637.BCEAC580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0151_01BFF637.BCEAC580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0151_01BFF637.BCEAC580-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 13:06:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PK4At16331 for ipng-dist; Tue, 25 Jul 2000 13:04:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PK3s616324 for ; Tue, 25 Jul 2000 13:03:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA11294 for ; Tue, 25 Jul 2000 13:03:50 -0700 (PDT) Received: from motgate3.mot.com ([144.189.100.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15735 for ; Tue, 25 Jul 2000 14:03:47 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA11268 for ; Tue, 25 Jul 2000 13:02:10 -0700 (MST)] Received: [from ilms03.cig.mot.com (ilms03.cig.mot.com [136.182.15.13]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA16774 for ; Tue, 25 Jul 2000 13:03:32 -0700 (MST)] Received: from em.cig.mot.com ([160.44.128.5]) by ilms03.cig.mot.com (Netscape Messaging Server 3.01) with SMTP id AAA27396; Tue, 25 Jul 2000 15:03:31 -0500 Received: by em.cig.mot.com (SMI-8.6/SMI-SVR4) id PAA10116; Tue, 25 Jul 2000 15:03:31 -0500 Date: Tue, 25 Jul 2000 15:03:31 -0500 Message-Id: <200007252003.PAA10116@em.cig.mot.com> To: bound@ZK3.DEC.COM CC: SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-reply-to: <200007251800.OAA0000722692@anw.zk3.dec.com> (message from Jim Bound on Tue, 25 Jul 2000 14:00:35 -0400) Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: "La Monte Henry Piggy Yarroll" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 25 Jul 2000 14:00:35 -0400 Jim Bound wrote: >Great. See my last mail to Mauro too just sent I go into more detail on >the principle (or is that principal :----)) I didn't see it on either of the lists. I'm still interested in your definitions to see if I understand. >>Is this v4 listener listening on INADDR_ANY and the v6 listener >>listening on in6addr_any for the same port? IMHO this should be >>illegal. The second listener should get an EBUSY when attempting to >>bind. > >I think it should be illegal too. Its like running telnetv4 and >telnetv6 on the same node. Pretty stupid IMO. But if we have a socket >level option to not accept v4mapped for af_inet6 it will let it happen >in theory (not that I believe we should). Forget the socket level option--just adopt the SCTP solution in general. If you are going to allow binding to subsets of addresses you might as well make it completely general. ... >>> There is an issue for the case where an app that is only doing v6 >>> listener for both incoming af_inet and af_inet6, where the app may >>> want to not receive any connections from v4. [...] What we >>> probably want to do is have a setsockopt in rfc2553bis that says >>> DON"T ACCEPT V4MAPPED connections (there are other ways to do this >>> but the socket level option is the cleanest). > >>Blech! In SCTP we need to allow binding on arbitrary subsets of >>addresses. Our solution is to allow multiple calls to bind(). There >>is nothing special about the sets "all IPv4 addresses" and "all IPv6 >>addresses" (well, there shouldn't be...). > >I agree so an sctp app in this case would not set the socket level >option. There need not be anything SCTP-specific about calling bind() multiple times... You do not need the socket option at all. -- Put no trust in extortion, La Monte Henry Piggy Yarroll set no vain hope in plunder; NIC Handle LY if riches increase, do not set your heart upon them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 13:50:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PKmfA16360 for ipng-dist; Tue, 25 Jul 2000 13:48:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PKmW616353 for ; Tue, 25 Jul 2000 13:48:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA00525 for ; Tue, 25 Jul 2000 13:48:31 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01343 for ; Tue, 25 Jul 2000 13:48:31 -0700 (PDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13HBcm-0004ro-00; Tue, 25 Jul 2000 16:48:24 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA01090; Tue, 25 Jul 00 16:45:50 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA28223; Tue, 25 Jul 2000 16:51:35 -0400 Message-Id: <397DFD61.2848CD36@txc.com> Date: Tue, 25 Jul 2000 16:49:37 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Vladislav Yasevich Cc: deering@cisco.com, IPNG Working Group Subject: Re: Tunnel Encapsulation Limit Option in rfc2473 References: <397DDA08.465C8DEB@zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for your note Vlad. The interpretation of the RFC 2473 should be done in the context of RFC 2460. Two pieces of text are perhaps more important than others: RFC 2473 "Tunnel Encapsulation Limit options are of interest only to tunnel entry points. A tunnel entry-point node is required to execute the following procedure for every packet entering a tunnel at that node:..." RFC 2460 " The Unfragmentable Part consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination".... So, in implementing RFC 2473, particularly the "tunnel encapsulation limit", one must take in consideration the fact that: 1.. the "tunnel encapsulation limit" is part of the tunnel headers - this affects the PMTU calculation, and thus fragmentation. 2.. the information carried by the "tunnel encapsulation limit" may be, at an extreme, significant to every node in the tunnel, if every node in the tunnel is a tunnel entry point. Which means that it may be processed at that extreme, like a "hop by hop" header. 3. the "tunnel encapsulation limit" is part of the "control" information carried by the tunnel headers, addressed to the downstream tunnel nodes, therefore it MUST be available to each and every downstream node in the tunnel, at and for the processing of each and every tunnel header and packet generated by the upstream tunnel entry point.. Regards, Alex Vladislav Yasevich wrote: > Hello > > After discussing this with a colleague who is trying to implement this spec > I believe there may be a problem with defining Tunnel Encapsulation Limit Option > as a Destination Option. When the packet is fragmented, the destination option > header can be placed in the fragment if no routing header is present in the > packet. > > Now, if you have nested tunnels, entry point for each tunnel will be doing > fragmentation. So, the first tunnel entry point will encapsulate the original > packet, add the destination option, and then fragment to path MTU, palcing > the destination option in one of the fragments. For the inner tunnel > to correctly process the Tunnel Encapsulation Limit Option, the inner > tunnel entry points will have to reassemble the packet, but there is > no guarantee that it will have all the framents. > > There are 3 solutions to this that I can see. > 1. Each entry point will have to add a routing header. > - this is not very clean. > 2. Use Hop by Hop option. > 3. Invent another tunnel specific extension header that will > be placed in every fragment. > > -vlad > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tel: (603) 884-1079 > Compaq Computer Corp. Fax: (435) 514-6884 > 110 Spit Brook Rd ZK03-3/T07 > Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 14:31:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PLTQV16442 for ipng-dist; Tue, 25 Jul 2000 14:29:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PLTH616435 for ; Tue, 25 Jul 2000 14:29:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA09879 for ; Tue, 25 Jul 2000 14:29:17 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20415 for ; Tue, 25 Jul 2000 15:29:16 -0600 (MDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 7BC687F0; Tue, 25 Jul 2000 17:29:16 -0400 (EDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2ACBD7E0; Tue, 25 Jul 2000 17:29:16 -0400 (EDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id RAA0000007331; Tue, 25 Jul 2000 17:29:15 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA22374; Tue, 25 Jul 2000 17:29:14 -0400 Message-Id: <397E06AA.C793906B@zk3.dec.com> Date: Tue, 25 Jul 2000 17:29:14 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: Alex Conta Cc: deering@cisco.com, IPNG Working Group Subject: Re: Tunnel Encapsulation Limit Option in rfc2473 References: <397DDA08.465C8DEB@zk3.dec.com> <397DFD61.2848CD36@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Alex Conta wrote: > > Thank you for your note Vlad. > > The interpretation of the RFC 2473 should be done in the context of RFC 2460. Two > pieces of text are perhaps more important than others: > > RFC 2473 > "Tunnel Encapsulation Limit options are of interest only to tunnel > entry points. A tunnel entry-point node is required to execute the > following procedure for every packet entering a tunnel at that node:..." > > RFC 2460 > " The Unfragmentable Part consists of the IPv6 header plus any > extension headers that must be processed by nodes en route to the > destination".... to continue the paragraph: "... destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers." Also from RFC 2460: } "4.1 Extension Header Order } } When more than one extension header is used in the same packet, it is } recommended that those headers appear in the following order: } } IPv6 header } Hop-by-Hop Options header } Destination Options header (note 1) } Routing header } Fragment header } Authentication header (note 2) } Encapsulating Security Payload header (note 2) } Destination Options header (note 3) } } note 1: for options to be processed by the first destination } that appears in the IPv6 Destination Address field } plus subsequent destinations listed in the Routing } header. } ... } note 3: for options to be processed only by the final } destination of the packet. } } ... } 4.6 Destination Options Header } } The Destination Options header is used to carry optional information } that need be examined only by a packet's destination node(s)...." Thus, my statement that if you only specify the Destination Option Header (with tunnel encapsulation limit option and any other options), then they will go into the Fragmentable Part on the packet as per 2460. They will only be in the Unfragmentable Part if you specify a Routing Header after the Destination Options. > > So, in implementing RFC 2473, particularly the "tunnel encapsulation limit", one > must take in consideration the fact that: > > 1.. the "tunnel encapsulation limit" is part of the tunnel headers - this affects > the PMTU calculation, and thus fragmentation. > 2.. the information carried by the "tunnel encapsulation limit" may be, at an > extreme, significant to every node in the tunnel, if every node in the tunnel is a > tunnel entry point. Which means that it may be processed at that extreme, like a > "hop by hop" header. > 3. the "tunnel encapsulation limit" is part of the "control" information carried by > the tunnel headers, addressed to > the downstream tunnel nodes, therefore it MUST be available to each and every > downstream node in the tunnel, at and for the processing of each and every tunnel > header and packet generated by the upstream tunnel entry point.. The tunnel encapsulation header in addressed to the tunnel exit point, not the inner tunnels' entry point. Thus, since the inner tunnels' entry point is not the destination, then it will not examine the Destination Option header. Also, since the packet may be fragmented, it will not be able to examine the Destination Option Header as I described above. For each tunnel entry point to examine the Destination Option header, a Routing Header must be specified after the Destination Option Header that would list each tunnel entry point. Otherwise, you create a special rule on how to process the Destination Option Header that conatins "tunnel encapsulation limit" option. > > Regards, > Alex -Vlad > > Vladislav Yasevich wrote: > > > Hello > > > > After discussing this with a colleague who is trying to implement this spec > > I believe there may be a problem with defining Tunnel Encapsulation Limit Option > > as a Destination Option. When the packet is fragmented, the destination option > > header can be placed in the fragment if no routing header is present in the > > packet. > > > > Now, if you have nested tunnels, entry point for each tunnel will be doing > > fragmentation. So, the first tunnel entry point will encapsulate the original > > packet, add the destination option, and then fragment to path MTU, palcing > > the destination option in one of the fragments. For the inner tunnel > > to correctly process the Tunnel Encapsulation Limit Option, the inner > > tunnel entry points will have to reassemble the packet, but there is > > no guarantee that it will have all the framents. > > > > There are 3 solutions to this that I can see. > > 1. Each entry point will have to add a routing header. > > - this is not very clean. > > 2. Use Hop by Hop option. > > 3. Invent another tunnel specific extension header that will > > be placed in every fragment. > > > > -vlad > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Vladislav Yasevich Tel: (603) 884-1079 > > Compaq Computer Corp. Fax: (435) 514-6884 > > 110 Spit Brook Rd ZK03-3/T07 > > Nashua, NH 03062 -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 16:56:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6PNt9g16761 for ipng-dist; Tue, 25 Jul 2000 16:55:09 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6PNsw616754 for ; Tue, 25 Jul 2000 16:54:58 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6PNswI117878; Tue, 25 Jul 2000 16:54:58 -0700 (PDT) Date: Tue, 25 Jul 2000 16:54:49 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: New "IP Version 6 Addressing Architecture" draft To: itojun@iijlab.net Cc: Brian Zill , "'Jim Bound'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <12735.964219981@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - change RFC2553 API to disable RFC2553-inbound > PROS: applications gets simplified very well, AF_INET6 is > always IPv6, AF_INET is always IPv4 (good for security) > PROS: RFC2553-inbound case is gone, application writers do not > need to care about RFC2553-inbound cases > CONS: SIIT itself is okay, but now unnatural This also has the CONS that it makes it harder to port current AF_INET server applications to support both IPv4 and IPv6 - you can no longer have a single in6addr_any AF_INET6 listening/receiving socket. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 25 17:10:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6Q09Ip16791 for ipng-dist; Tue, 25 Jul 2000 17:09:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6Q097616784 for ; Tue, 25 Jul 2000 17:09:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA28487; Tue, 25 Jul 2000 17:09:02 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24768; Tue, 25 Jul 2000 17:09:01 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA05095; Wed, 26 Jul 2000 09:08:58 +0900 (JST) To: Erik Nordmark cc: Brian Zill , "'Jim Bound'" , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Tue, 25 Jul 2000 16:54:49 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: New "IP Version 6 Addressing Architecture" draft From: itojun@iijlab.net Date: Wed, 26 Jul 2000 09:08:58 +0900 Message-ID: <5093.964570138@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> - change RFC2553 API to disable RFC2553-inbound >> PROS: applications gets simplified very well, AF_INET6 is >> always IPv6, AF_INET is always IPv4 (good for security) >> PROS: RFC2553-inbound case is gone, application writers do not >> need to care about RFC2553-inbound cases >> CONS: SIIT itself is okay, but now unnatural >This also has the CONS that it makes it harder to port current AF_INET >server applications to support both IPv4 and IPv6 - you can no longer have >a single in6addr_any AF_INET6 listening/receiving socket. we can make it switchable via setsockopt, if the ported application requires RFC2553-inbound behavior (i think jim mentioned it in past email about netbsd implementation - which is one of the proposals from us). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 25 20:05:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6Q342116927 for ipng-dist; Tue, 25 Jul 2000 20:04:02 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6Q33s616920 for ; Tue, 25 Jul 2000 20:03:54 -0700 (PDT) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6Q33oI139264; Tue, 25 Jul 2000 20:03:51 -0700 (PDT) Date: Tue, 25 Jul 2000 20:03:52 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) To: La Monte Henry Piggy Yarroll Cc: SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200007251638.LAA09292@em.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Blech! In SCTP we need to allow binding on arbitrary subsets of > addresses. Our solution is to allow multiple calls to bind(). There > is nothing special about the sets "all IPv4 addresses" and "all IPv6 > addresses" (well, there shouldn't be...). This is a point which is not clear in the current draft (in fact, there are many things which are not clear as Randy said...). The idea is that a v6 socket bind() to in6addr_any will associate the socket to all interface addresses, regardless of whether they are v4 or v6. A v4 socket bind() to INADDR_ANY is only associated with v4 addresses. There is no equivalent of v6 only bind() in the current draft (v6 socket trying to bind() to v4 INADDR_ANY will fail). Whether we want to have a v6 address only bind() is an issue we need to talk about. There can be apps which support some v6 specific features and do not want to be bothered with "accidental" v4 associations. Instead of aborting those associations when the apps accepts them, it may be better for the OS to reject them right away. K. Poon. kcpoon@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 Jul 25 20:18:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6Q3Gdc16954 for ipng-dist; Tue, 25 Jul 2000 20:16:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6Q3GU616947 for ; Tue, 25 Jul 2000 20:16:31 -0700 (PDT) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6Q3GOI141263; Tue, 25 Jul 2000 20:16:25 -0700 (PDT) Date: Tue, 25 Jul 2000 20:16:26 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) To: La Monte Henry Piggy Yarroll Cc: SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200007252003.PAA10116@em.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Forget the socket level option--just adopt the SCTP solution in > general. If you are going to allow binding to subsets of addresses > you might as well make it completely general. Allowing bind() to subsets of addresses does not necessarily mean that such option is of no use. A SCTP app may not want to find out all v6 addresses in a machine (the way to find out is probably OS dependent) to bind() to. And it just wants to deal with associations using only v6 addresses. In the current SCTP API draft, there is no way to do that. Since we want code to be OS independent, having such an option may not be a bad idea. K. Poon. kcpoon@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 Jul 25 20:33:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6Q3VfR16981 for ipng-dist; Tue, 25 Jul 2000 20:31:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6Q3VW616974 for ; Tue, 25 Jul 2000 20:31:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA13658 for ; Tue, 25 Jul 2000 20:31:30 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA27254 for ; Tue, 25 Jul 2000 21:31:31 -0600 (MDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id BBDA863E; Tue, 25 Jul 2000 22:31:26 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 1A14556F; Tue, 25 Jul 2000 22:31:26 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000564076; Tue, 25 Jul 2000 23:30:52 -0400 (EDT) From: Jim Bound Message-Id: <200007260330.XAA0000564076@anw.zk3.dec.com> To: "La Monte Henry Piggy Yarroll" Cc: bound@zk3.dec.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) In-reply-to: Your message of "Tue, 25 Jul 2000 15:03:31 CDT." <200007252003.PAA10116@em.cig.mot.com> Date: Tue, 25 Jul 2000 23:30:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I think it should be illegal too. Its like running telnetv4 and >>telnetv6 on the same node. Pretty stupid IMO. But if we have a socket >>level option to not accept v4mapped for af_inet6 it will let it happen >>in theory (not that I believe we should). > >>Forget the socket level option--just adopt the SCTP solution in >general. If you are going to allow binding to subsets of addresses >you might as well make it completely general. Well its not that easy. We still do not want af_inet6 listner to get the connections for IPv4 if there is an af_inet listener. That is the only real problem, which the socket level option fixes. Whether we like it or not we will have to deal with stupid permisible behavior like INADDR_ANY binding to port 23 and in6addr_any binding to port 23. It will happen. >There need not be anything SCTP-specific about calling bind() multiple >times... You do not need the socket option at all. Thats not why we need it. I need to still look at your sctp api so I can't comment on that. /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 Jul 26 03:52:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QAosu17754 for ipng-dist; Wed, 26 Jul 2000 03:50:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QAoh617747 for ; Wed, 26 Jul 2000 03:50:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA14718 for ; Wed, 26 Jul 2000 03:50:42 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA02588 for ; Wed, 26 Jul 2000 04:50:41 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03610; Wed, 26 Jul 2000 06:50:39 -0400 (EDT) Message-Id: <200007261050.GAA03610@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-mld-mib-04.txt Date: Wed, 26 Jul 2000 06:50: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 : IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol Author(s) : B. Haberman, R. Worzella Filename : draft-ietf-ipngwg-mld-mib-04.txt Pages : 14 Date : 25-Jul-00 This document defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module which defines managed objects for implementations of the Multicast Listener Discovery Protocol [MLD]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-mld-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-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: <20000725150234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000725150234.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 Jul 26 04:25:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QBNfZ17778 for ipng-dist; Wed, 26 Jul 2000 04:23:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QBNX617771 for ; Wed, 26 Jul 2000 04:23:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA28934 for ; Wed, 26 Jul 2000 04:23:32 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13812 for ; Wed, 26 Jul 2000 05:23:29 -0600 (MDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 26 Jul 2000 17:05:26 +0530 Received: from muralia ([10.0.14.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA15904 for ; Wed, 26 Jul 2000 16:41:50 +0530 Received: by localhost with Microsoft MAPI; Wed, 26 Jul 2000 16:55:05 +0530 Message-Id: <01BFF722.3F374A00.muralia@future.futsoft.com> From: Murali Krishna Ch Reply-To: "muralia@future.futsoft.com" To: "'ipng@sunroof.eng.sun.com'" Subject: Use of same interface id on multiple interfaces (RFC 2373) Date: Wed, 26 Jul 2000 16:55:03 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Can we use the same Interface id for multiple interfaces? If so what are ISSUES, involved in it? For example, if i have one Ethernet interface and 'n' PPP interfaces, is it right to use the same linklocal address constructed from Mac Address for **ALL** the 'n' PPP links? How does it effect the global uniqueness of the address? Thanks & Regards, murali. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 07:03:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QE1H317854 for ipng-dist; Wed, 26 Jul 2000 07:01:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QE16617847 for ; Wed, 26 Jul 2000 07:01:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA10983 for ; Wed, 26 Jul 2000 07:01:06 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04502 for ; Wed, 26 Jul 2000 07:01:05 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA00672; Wed, 26 Jul 2000 09:01:01 -0500 (CDT) Message-Id: <200007261401.JAA00672@gungnir.fnal.gov> To: Jim Bound Cc: "La Monte Henry Piggy Yarroll" , SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) In-reply-to: Your message of Tue, 25 Jul 2000 23:30:51 EDT. <200007260330.XAA0000564076@anw.zk3.dec.com> Date: Wed, 26 Jul 2000 09:01:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well its not that easy. We still do not want af_inet6 listner to get > the connections for IPv4 if there is an af_inet listener. That is the > only real problem, which the socket level option fixes. To give a v4-specific listener priority over a v6 listener is not up to the API but the stack's PCB lookup function, yes? The only reason I can see for a sockopt is to allow overriding this behavior -- but the v6 application could do this more simply by binding to the v4 address (be it wildcard or not) in addition to any others. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 07:56:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QEt0j17979 for ipng-dist; Wed, 26 Jul 2000 07:55:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QEsq617972 for ; Wed, 26 Jul 2000 07:54:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA19919 for ; Wed, 26 Jul 2000 07:54:51 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01571 for ; Wed, 26 Jul 2000 08:54:49 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.20.159.191) by smtp2.libero.it; 26 Jul 2000 16:54:44 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 209674C500; Wed, 26 Jul 2000 16:25:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 1C26D4C4FC; Wed, 26 Jul 2000 16:25:22 +0200 (CEST) Date: Wed, 26 Jul 2000 16:25:22 +0200 (CEST) From: Mauro Tortonesi To: Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: <200007251749.NAA0000717700@anw.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 25 Jul 2000, Jim Bound wrote: > >> An af_inet6 socket should not accept a connection for an af_inet socket. > > > >you are right. they should open another af_inet socket and fall back to > >an ipv4 connection. however, rfc2553 does not even suggest this behaviour. > >quoting from draft-ietf-ipngwg-rfc2553bis-00.txt, section 3.7: > > OK I explained this in mail last night my "for" statement implied to much > for any reader. Assume you have that mail? yes, certainly. > >let me understand, when an af_inet6 socket opens a connection with > >another af_inet6 socket with ipv4-mapped address, the communication > >established is in ipv4, isn't it? so ipv4-mapped addresses are not only > >used for node representation (as they are returned from getaddrinfo and > >getipnodebyname), but also to establish a connection to an ipv4 host. > > This is permissible but not required. The API can ask for just plain > old IPv4 addresses too using af_inet with the API. How thats > implemented in the stack is none of the standards groups business. however, rfc2553 states that an application can use ipv4-mapped addresses to open a TCP connection or send a UDP datagram to an ipv4 node. how can this happen if the connection is not in ipv4? > >so the only protocol that requires ipv4-mapped addresses "on the wire" > >is SIIT. if SIIT is not used, then the kernel can reject all connection > >from outside with an ipv4-mapped address, for security issues - like > >itojun has explained us very well. > > This should be permissable and I think we need to add a socket level > option for af_inet6 that states do not accept v4mapped connections, for > af_inet6 listeners. > > This would be reflected in the next iteration (hopefully last call) > in rfc2553bis. imho such a sockopt is surely a good idea. > >by the way, can you point me to a rfc which explains the difference > >between a hybrid stack and a dual stack? > Hmmm. thank you very much for your answer. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Wed Jul 26 08:13:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QFC5N18025 for ipng-dist; Wed, 26 Jul 2000 08:12:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QFBu618018 for ; Wed, 26 Jul 2000 08:11:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA18749 for ; Wed, 26 Jul 2000 08:11:55 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14285 for ; Wed, 26 Jul 2000 09:11:54 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id AAA22942; Thu, 27 Jul 2000 00:11:21 +0900 To: crawdad@fnal.gov Cc: bound@zk3.dec.com, piggy@em.cig.mot.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <200007261401.JAA00672@gungnir.fnal.gov> References: <200007260330.XAA0000564076@anw.zk3.dec.com> <200007261401.JAA00672@gungnir.fnal.gov> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000727001120S.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Thu, 27 Jul 2000 00:11:20 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 10 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <200007261401.JAA00672@gungnir.fnal.gov> (at Wed, 26 Jul 2000 09:01:01 -0500), "Matt Crawford" says: > the v6 application could do this more simply by binding to the v4 > address (be it wildcard or not) in addition to any others. We cannot do this with Linux. -- Hideaki YOSHIFUJI @ USAGI Project Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 08:42:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QFeVF18233 for ipng-dist; Wed, 26 Jul 2000 08:40:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QFeL618226 for ; Wed, 26 Jul 2000 08:40:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA24641 for ; Wed, 26 Jul 2000 08:40:20 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07759 for ; Wed, 26 Jul 2000 09:40:19 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id AAA15663; Thu, 27 Jul 2000 00:40:15 +0900 (JST) To: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) cc: crawdad@fnal.gov, bound@zk3.dec.com, piggy@em.cig.mot.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-reply-to: yoshfuji's message of Thu, 27 Jul 2000 00:11:20 JST. <20000727001120S.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: itojun@iijlab.net Date: Thu, 27 Jul 2000 00:40:15 +0900 Message-ID: <15661.964626015@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> the v6 application could do this more simply by binding to the v4 >> address (be it wildcard or not) in addition to any others. >We cannot do this with Linux. the whole confusion of AF_INET and AF_INET6 interaction is documented very nicely in BIND9 doc/misc/ipv6. the source of confusion is that we have no specification to look at - RFC2553 should have documented how they should interact. i think i have raised this more than a year ago on ipv6imp mailing list, and the comment was that this is implementation dependent thing. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 26 09:54:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QGr8i18330 for ipng-dist; Wed, 26 Jul 2000 09:53:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QGqx618323 for ; Wed, 26 Jul 2000 09:52:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA16547 for ; Wed, 26 Jul 2000 09:52:58 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07019 for ; Wed, 26 Jul 2000 09:52:56 -0700 (PDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13HUQ9-0002I7-00; Wed, 26 Jul 2000 12:52:37 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA06271; Wed, 26 Jul 00 12:50:06 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA21724; Wed, 26 Jul 2000 12:55:52 -0400 Message-Id: <397F17A0.68C45593@txc.com> Date: Wed, 26 Jul 2000 12:53:52 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Vladislav Yasevich Cc: deering@cisco.com, IPNG Working Group Subject: Re: Tunnel Encapsulation Limit Option in rfc2473 References: <397DDA08.465C8DEB@zk3.dec.com> <397DFD61.2848CD36@txc.com> <397E06AA.C793906B@zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vlad, In RFC 2473, page 14: "Tunnel Encapsulation Limit options are of interest only to tunnel entry points. A tunnel entry-point node is required to execute the following procedure for every packet entering a tunnel at that node:...." ".....(Note that this requirement is an exception to the general IPv6 rule that a Destination Options extension header need only be examined by a packet's destination node. An alternative and "cleaner" approach would have been to use a Hop-by-Hop extension header for this purpose, but that would have imposed an undesirable extra processing burden, and possible consequent extra delay, at every IPv6 node along the path of a tunnel.)" Please note the "exception". Further, or once more: The "tunnel encapsulation limit", along with the forwarding/routing and hop limit information, is part of the "control" information stored by a tunnel entry-point in the tunnel headers. This information is used/processed by the nodes in the tunnel, downstream from the tunnel entry-point, to appropriately forward the tunnel packets towards the tunnel exit point. The forwarding/routing information and hop limit in the IPv6 main header is processed by each and every node. The forwarding/routing information in a routing header is processed by the nodes which are part of the source route. The tunnel encapsulation limit is processed by entry-point nodes in inner nested tunnels, and ignored by other nodes. Ideally, a tunnel entry-point would specify each tunnel entry point in inner nested tunnels in a tunnel routing header. This is however impractical, as a tunnel entry point MAY not know all the downstream entry-points to inner nested tunnels. Nevertheless, all entry-points in inner nested tunnels, which in extremus can be all nodes in a tunnel, MUST have access to the tunnel encapsulation limit, to avoid the effect of infinite encapsulation. The tunnel encapsulation limit carried by the tunnel headers of a packet MUST be put in the tunnel headers of every fragment of that packet, when the packet gets fragmented. To conclude, in the context of RFC2473 explained above, the statement in RFC 2460 " The Unfragmentable Part consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination".... applies fully. Its explanation: "that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers." if it is to be interpreted strictly ad literam, is excepted. Alex Vladislav Yasevich wrote: > > Alex > > Alex Conta wrote: > > > > Thank you for your note Vlad. > > > > The interpretation of the RFC 2473 should be done in the context of RFC 2460. Two > > pieces of text are perhaps more important than others: > > > > RFC 2473 > > "Tunnel Encapsulation Limit options are of interest only to tunnel > > entry points. A tunnel entry-point node is required to execute the > > following procedure for every packet entering a tunnel at that node:..." > > > > RFC 2460 > > " The Unfragmentable Part consists of the IPv6 header plus any > > extension headers that must be processed by nodes en route to the > > destination".... > > to continue the paragraph: > "... destination, that is, all headers up to and including the Routing > header if present, else the Hop-by-Hop Options header if present, > else no extension headers." > > Also from RFC 2460: > } "4.1 Extension Header Order > } > } When more than one extension header is used in the same packet, it is > } recommended that those headers appear in the following order: > } > } IPv6 header > } Hop-by-Hop Options header > } Destination Options header (note 1) > } Routing header > } Fragment header > } Authentication header (note 2) > } Encapsulating Security Payload header (note 2) > } Destination Options header (note 3) > } > } note 1: for options to be processed by the first destination > } that appears in the IPv6 Destination Address field > } plus subsequent destinations listed in the Routing > } header. > } ... > } note 3: for options to be processed only by the final > } destination of the packet. > } > } ... > } 4.6 Destination Options Header > } > } The Destination Options header is used to carry optional information > } that need be examined only by a packet's destination node(s)...." > > Thus, my statement that if you only specify the Destination Option Header (with > tunnel encapsulation limit option and any other options), then they will go into > the Fragmentable Part on the packet as per 2460. They will only be in the > Unfragmentable Part if you specify a Routing Header after the Destination > Options. > > > > > So, in implementing RFC 2473, particularly the "tunnel encapsulation limit", one > > must take in consideration the fact that: > > > > 1.. the "tunnel encapsulation limit" is part of the tunnel headers - this affects > > the PMTU calculation, and thus fragmentation. > > 2.. the information carried by the "tunnel encapsulation limit" may be, at an > > extreme, significant to every node in the tunnel, if every node in the tunnel is a > > tunnel entry point. Which means that it may be processed at that extreme, like a > > "hop by hop" header. > > 3. the "tunnel encapsulation limit" is part of the "control" information carried by > > the tunnel headers, addressed to > > the downstream tunnel nodes, therefore it MUST be available to each and every > > downstream node in the tunnel, at and for the processing of each and every tunnel > > header and packet generated by the upstream tunnel entry point.. > > The tunnel encapsulation header in addressed to the tunnel exit point, not the > inner tunnels' entry point. Thus, since the inner tunnels' entry point is not > the destination, then it will not examine the Destination Option header. Also, > since the packet may be fragmented, it will not be able to examine the > Destination > Option Header as I described above. For each tunnel entry point to examine the > Destination Option header, a Routing Header must be specified after the > Destination Option Header that would list each tunnel entry point. > > Otherwise, you create a special rule on how to process the Destination Option > Header > that conatins "tunnel encapsulation limit" option. > > > > > Regards, > > Alex > > -Vlad > > > > > Vladislav Yasevich wrote: > > > > > Hello > > > > > > After discussing this with a colleague who is trying to implement this spec > > > I believe there may be a problem with defining Tunnel Encapsulation Limit Option > > > as a Destination Option. When the packet is fragmented, the destination option > > > header can be placed in the fragment if no routing header is present in the > > > packet. > > > > > > Now, if you have nested tunnels, entry point for each tunnel will be doing > > > fragmentation. So, the first tunnel entry point will encapsulate the original > > > packet, add the destination option, and then fragment to path MTU, palcing > > > the destination option in one of the fragments. For the inner tunnel > > > to correctly process the Tunnel Encapsulation Limit Option, the inner > > > tunnel entry points will have to reassemble the packet, but there is > > > no guarantee that it will have all the framents. > > > > > > There are 3 solutions to this that I can see. > > > 1. Each entry point will have to add a routing header. > > > - this is not very clean. > > > 2. Use Hop by Hop option. > > > 3. Invent another tunnel specific extension header that will > > > be placed in every fragment. > > > > > > -vlad > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > Vladislav Yasevich Tel: (603) 884-1079 > > > Compaq Computer Corp. Fax: (435) 514-6884 > > > 110 Spit Brook Rd ZK03-3/T07 > > > Nashua, NH 03062 > > -- > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tel: (603) 884-1079 > Compaq Computer Corp. Fax: (435) 514-6884 > 110 Spit Brook Rd ZK03-3/T07 > Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 10:42:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QHeiB18415 for ipng-dist; Wed, 26 Jul 2000 10:40:44 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QHeZ618408 for ; Wed, 26 Jul 2000 10:40:35 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA16463; Wed, 26 Jul 2000 13:40:34 -0400 (EDT) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QHeAS103824; Wed, 26 Jul 2000 13:40:10 -0400 (EDT) Message-Id: <200007261740.e6QHeAS103824@thunk.east.sun.com> From: Bill Sommerfeld To: "Matt Crawford" cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: receiving ipv4 packets through ipv6 sockets.. In-reply-to: Your message of "Wed, 26 Jul 2000 09:01:01 CDT." <200007261401.JAA00672@gungnir.fnal.gov> Reply-to: sommerfeld@east.sun.com Date: Wed, 26 Jul 2000 13:40:10 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looks like other people are running into trouble with the "accept ipv4 traffic through ipv6 sockets" feature: http://www.isc.org/products/BIND/bind9.html, in the bind-9.0.0rc1 release notes: On some systems, IPv6 and IPv4 sockets interact in unexpected ways. For details, see doc/misc/ipv6. To reduce the impact of these problems, the server no longer listens for requests on IPv6 addresses by default. If you need to accept DNS queries over IPv6, you must specify "listen-on-v6 { any; };" in the named.conf options statement. - 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 Wed Jul 26 14:17:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QLGSU18615 for ipng-dist; Wed, 26 Jul 2000 14:16:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QLGJ618608 for ; Wed, 26 Jul 2000 14:16:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA29489; Wed, 26 Jul 2000 14:16:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01654; Wed, 26 Jul 2000 15:16:19 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA12101; Wed, 26 Jul 2000 14:16:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA24076; Wed, 26 Jul 2000 14:16:16 -0700 X-Virus-Scanned: Wed, 26 Jul 2000 14:16:16 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdNBPWTz; Wed, 26 Jul 2000 14:16:14 PDT Message-Id: <4.3.2.7.2.20000726140659.0246b8d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2000 14:13:36 -0700 To: narten@raleigh.ibm.com, Erik.Nordmark@eng.sun.com From: Bob Hinden Subject: Request to Advance "IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol" Cc: scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol Author(s) : B. Haberman, R. Worzella Filename : draft-ietf-ipngwg-mld-mib-04.txt Pages : 14 Date : 25-Jul-00 A working group last call for this document was completed on July 3, 2000. The above draft resolves issues raised during the last call. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 26 14:19:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QLIaq18633 for ipng-dist; Wed, 26 Jul 2000 14:18:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QLIP618626 for ; Wed, 26 Jul 2000 14:18:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA23153 for ; Wed, 26 Jul 2000 14:18:25 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05855 for ; Wed, 26 Jul 2000 14:18:25 -0700 (PDT) Received: from [171.70.84.51] (deering-office-pb.cisco.com [171.70.84.51]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id OAA18901; Wed, 26 Jul 2000 14:17:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <01BFF722.3F374A00.muralia@future.futsoft.com> References: <01BFF722.3F374A00.muralia@future.futsoft.com> Date: Wed, 26 Jul 2000 14:19:50 -0700 To: "muralia@future.futsoft.com" From: Steve Deering Subject: Re: Use of same interface id on multiple interfaces (RFC 2373) Cc: "'ipng@sunroof.eng.sun.com'" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:55 PM +0530 7/26/00, Murali Krishna Ch wrote: >Can we use the same Interface id for multiple interfaces? >If so what are ISSUES, involved in it? >For example, if i have one Ethernet interface and 'n' PPP interfaces, >is it right to use the same linklocal address constructed from Mac Address for **ALL** the 'n' PPP links? >How does it effect the global uniqueness of the address? Murali, Yes, a node may use the same link-local address on more than attached link, and the same site-local address on more than one attached site. Link-local and site-local addresses are required to be unique only within the set of interfaces attached to a given link or site, respectively. The main consequence is that, within a node, any non-global address must be accompanied by a zone identifier (or an indication of "default zone") to identify the link or site to which it pertains. See draft-ipngwg-scoping-arch-01.txt. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 26 14:51:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QLnhR18713 for ipng-dist; Wed, 26 Jul 2000 14:49:43 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QLnY618703 for ; Wed, 26 Jul 2000 14:49:34 -0700 (PDT) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6QLnWI271650; Wed, 26 Jul 2000 14:49:32 -0700 (PDT) Date: Wed, 26 Jul 2000 14:49:35 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) To: Matt Crawford Cc: Jim Bound , La Monte Henry Piggy Yarroll , SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200007261401.JAA00672@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To give a v4-specific listener priority over a v6 listener is not up > to the API but the stack's PCB lookup function, yes? The only reason > I can see for a sockopt is to allow overriding this behavior -- but > the v6 application could do this more simply by binding to the v4 > address (be it wildcard or not) in addition to any others. Another clarfication on the meaning of binding in the SCTP context. The above just talks about finding an endpoint to take an association request. In SCTP an endpoint can have multiple addresses. An SCTP endpoint can use any of those addresses to communicate with a peer endpoint. The binding to in6addr_any means that when setting up an association, the system will associate all its addresses to the endpoint. This means that the peer can use any (there is always a primary) of those addresses to communicate with it. In the current draft, all means both v4 and v6 addresses. This may not be desirable if the app uses some v6 features, e.g. routing header, which are not applicable to v4 addresses. This means that SCTP may not be able to use those v4 addresses associated with the endpoint. If this is the case, why should those v4 addresses be associated with the endpoint in the first place? Note that how the system picks those addresses are still not "clearly" specified. It may not make sense to pick all addresses associated with an interface. The reason for having multiple addresses is that SCTP can failover to another address if the primary fails. But if all the addresses are associated with an interface, failover may not make sense at all. There are still a lot of work to be done in this area in the draft... K. Poon. kcpoon@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 Jul 26 15:16:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QMDwb18806 for ipng-dist; Wed, 26 Jul 2000 15:13:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QMDn618799 for ; Wed, 26 Jul 2000 15:13:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA07150 for ; Wed, 26 Jul 2000 15:13:48 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA12598 for ; Wed, 26 Jul 2000 16:13:47 -0600 (MDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Jul 2000 15:12:14 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Wed, 26 Jul 2000 15:11:57 -0700 Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C31F5@red-msg-24.redmond.corp.microsoft.com> From: Christian Huitema To: "'Kacheong Poon'" , Matt Crawford Cc: Jim Bound , La Monte Henry Piggy Yarroll , SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: RE: SCTP API draft (was Re: New "IP Version 6 Addressing Architec ture" draft) Date: Wed, 26 Jul 2000 15:12:40 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Note that how the system picks those addresses are still not "clearly" > specified. It may not make sense to pick all addresses > associated with an > interface. The reason for having multiple addresses is that > SCTP can failover > to another address if the primary fails. But if all the addresses are > associated with an interface, failover may not make sense at > all. There are > still a lot of work to be done in this area in the draft... If the multiple addresses have different prefixes, then the packets will be routed through different paths. This provides a useful failover situation, from a failing provider to a valid provider, even if the interface is the same. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 15:19:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QMIDw18828 for ipng-dist; Wed, 26 Jul 2000 15:18:13 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QMI3618817 for ; Wed, 26 Jul 2000 15:18:04 -0700 (PDT) Received: from shield (shield.Eng.Sun.COM [129.146.85.114]) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e6QMI2I278489; Wed, 26 Jul 2000 15:18:02 -0700 (PDT) Date: Wed, 26 Jul 2000 15:18:05 -0700 (PDT) From: Kacheong Poon Reply-To: Kacheong Poon Subject: RE: SCTP API draft (was Re: New "IP Version 6 Addressing Architec ture" draft) To: Christian Huitema Cc: "'Kacheong Poon'" , Matt Crawford , Jim Bound , La Monte Henry Piggy Yarroll , SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2E3FA0558747934A8F753CC533A3F6DF043C31F5@red-msg-24.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If the multiple addresses have different prefixes, then the packets will be > routed through different paths. This provides a useful failover situation, > from a failing provider to a valid provider, even if the interface is the > same. This can be one criterion in picking multiple addresses from a single interface. Thanks. K. Poon. kcpoon@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 Jul 26 15:23:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QMMJl18866 for ipng-dist; Wed, 26 Jul 2000 15:22:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QMMA618859 for ; Wed, 26 Jul 2000 15:22:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA14248 for ; Wed, 26 Jul 2000 15:22:11 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA17660 for ; Wed, 26 Jul 2000 16:22:08 -0600 (MDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Jul 2000 15:02:55 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Wed, 26 Jul 2000 15:00:05 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810257E369B@RED-MSG-50> From: Richard Draves To: Steve Deering , muralia@future.futsoft.com Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Use of same interface id on multiple interfaces (RFC 2373) Date: Wed, 26 Jul 2000 14:59:42 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are a couple situations in which you need to take care, when using the same interface identifier for multiple interfaces. First, the interfaces might be attached to the same link and then you'll lose. But at least duplicate address detection will detect the problem. Second, suppose you are operating in an environment where a global prefix is spanning multiple links. Then you might form global addresses that are not unique, and DAD won't detect the problem. (Although an internal check of your data structures would show the same address assigned to multiple interfaces.) Rich > -----Original Message----- > From: Steve Deering [mailto:deering@cisco.com] > Sent: Wednesday, July 26, 2000 2:20 PM > To: muralia@future.futsoft.com > Cc: 'ipng@sunroof.eng.sun.com' > Subject: Re: Use of same interface id on multiple interfaces > (RFC 2373) > > > At 4:55 PM +0530 7/26/00, Murali Krishna Ch wrote: > >Can we use the same Interface id for multiple interfaces? > >If so what are ISSUES, involved in it? > >For example, if i have one Ethernet interface and 'n' PPP > interfaces, > >is it right to use the same linklocal address constructed > from Mac Address for **ALL** the 'n' PPP links? > >How does it effect the global uniqueness of the address? > > Murali, > > Yes, a node may use the same link-local address on more than attached > link, and the same site-local address on more than one attached site. > Link-local and site-local addresses are required to be unique only > within the set of interfaces attached to a given link or > site, respectively. > > The main consequence is that, within a node, any non-global address > must be accompanied by a zone identifier (or an indication of "default > zone") to identify the link or site to which it pertains. > > See draft-ipngwg-scoping-arch-01.txt. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 15:30:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6QMT3W18909 for ipng-dist; Wed, 26 Jul 2000 15:29:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6QMSs618902 for ; Wed, 26 Jul 2000 15:28:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA18304; Wed, 26 Jul 2000 15:28:49 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18498; Wed, 26 Jul 2000 15:28:46 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA19511; Wed, 26 Jul 2000 15:28:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA24367; Wed, 26 Jul 2000 15:28:42 -0700 X-Virus-Scanned: Wed, 26 Jul 2000 15:28:42 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpd8lMnjG; Wed, 26 Jul 2000 15:28:40 PDT Message-Id: <4.3.2.7.2.20000726152023.01a151f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jul 2000 15:25:51 -0700 To: narten@raleigh.ibm.com, Erik.Nordmark@eng.sun.com From: Bob Hinden Subject: Request to Advance "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" Cc: scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Proposed Standard: Title : Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification Author(s) : A. Conta Filename : draft-ietf-ion-ipv6-ind-04.txt Pages : 21 Date : 13-Jul-00 A working group last call for this document was completed on July 6, 2000. The -04 version of the draft resolves issues raised during the last call. This document was originally a ION w.g. document and was transferred to the IPng w.g. when the ION w.g. concluded. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 26 19:48:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6R2lYg19351 for ipng-dist; Wed, 26 Jul 2000 19:47:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6R2lO619344 for ; Wed, 26 Jul 2000 19:47:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA04867 for ; Wed, 26 Jul 2000 19:47:23 -0700 (PDT) Received: from lychee.itojun.org (dhcp109.iijlab.net [202.232.15.109]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA24995 for ; Wed, 26 Jul 2000 20:47:22 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e6R2iip14508 for ; Thu, 27 Jul 2000 11:44:44 +0900 (JST) Message-Id: <200007270244.e6R2iip14508@itojun.org> To: ipng@sunroof.eng.sun.com Subject: IPv6 packets with unspecified source address X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Thu, 27 Jul 2000 11:44:43 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is kind of "host/router requirement" question... IPv6 base specification allows (does not prohibit) use of unspecified IPv6 address in source address. The question we have is, how legitimate it is to use unspecified IPv6 address in source address. The only use we have in our document is: - neighbor solicitation with unspecified IPv6 source, for DAD Please consider the following examples. Are these examples legal? - IPv6 ICMPv6 packet with unspecified source address, which is DAD. (this one should be legal, since it is documented in RFC2462) - IPv6 ICMPv6 packet with unspecified source address, which is NOT DAD. - IPv6 TCP packet with unspecified source address. this form of packet can be used to make a DoS attack. careless implementation may create TCP control block with local address = mine, and foreign address = unspecified, in state SYN_RCVD. this may disable wildcard listening TCP socket from being contacted - IPv6 UDP packet with unspecified source address. - other upper layer protocol with unspecified source address. - mobile-ip6 home address option with unspecified address. - a router which forwards packets with unspecified source address. if we consider that DAD is the only legal use, we should not forward. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 26 20:03:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6R32Aa19388 for ipng-dist; Wed, 26 Jul 2000 20:02:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6R322619381 for ; Wed, 26 Jul 2000 20:02:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA07093 for ; Wed, 26 Jul 2000 20:01:57 -0700 (PDT) Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29590 for ; Wed, 26 Jul 2000 21:01:56 -0600 (MDT) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id MAA13599; Thu, 27 Jul 2000 12:01:55 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.0/8.10.2) id e6R31p401516; Thu, 27 Jul 2000 12:01:51 +0900 (JST) Date: Thu, 27 Jul 2000 12:01:51 +0900 (JST) From: Atsushi Onoe Message-Id: <200007270301.e6R31p401516@duplo.sm.sony.co.jp> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 packets with unspecified source address In-Reply-To: Your message of "Thu, 27 Jul 2000 11:44:43 +0900" <200007270244.e6R2iip14508@itojun.org> References: <200007270244.e6R2iip14508@itojun.org> X-Mailer: Cue version 0.6 (000608-1919/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Please consider the following examples. Are these examples legal? And what do you propose against these examples? The specification should not prohibit anything just because it is not considered useful, IMO. An unspecified source address looks harmless because we don't use it except DAD. In RFC2119, Key words for use in RFCs to Indicate Requirement Levels: | $(Dk(B6. Guidance in the use of these Imperatives | | Imperatives of the type defined in this memo must be used with care | and sparingly. In particular, they MUST only be used where it is | actually required for interoperation or to limit behavior which has | potential for causing harm (e.g., limiting retransmisssions) For | example, they must not be used to try to impose a particular method | on implementors where the method is not required for | interoperability. 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 Wed Jul 26 20:08:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6R37jj19414 for ipng-dist; Wed, 26 Jul 2000 20:07:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6R37Z619407 for ; Wed, 26 Jul 2000 20:07:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA27705 for ; Wed, 26 Jul 2000 20:07:34 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA01919 for ; Wed, 26 Jul 2000 21:07:33 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA23607; Thu, 27 Jul 2000 12:07:30 +0900 (JST) To: Atsushi Onoe cc: ipng@sunroof.eng.sun.com In-reply-to: onoe's message of Thu, 27 Jul 2000 12:01:51 JST. <200007270301.e6R31p401516@duplo.sm.sony.co.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 packets with unspecified source address From: itojun@iijlab.net Date: Thu, 27 Jul 2000 12:07:30 +0900 Message-ID: <23605.964667250@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Please consider the following examples. Are these examples legal? >And what do you propose against these examples? my proposal is like below: - for IPv6 base specification, leave it as is or have more wording about it (like "whether unspecified address is legal or not is defined in the upper layer protocol") - For TCP and UDP, make it illegal. this is to keep practice from IPv4 days and prevent possible implementation mistakes (as we inherited TCP and UDP from IPv4). - for ICMPv6, declare precisely when it is legal and when it is not. For example, "it is allowed only for DAD". - home address option should obey whatever RFC2460 says. - for forwarding case, I'm not sure. what is the scope for ::? if it is linklocal or interface local (node local), maybe "beyond scope" icmp6 error. - for other protocols, up to other protocol specifications. >The specification should not prohibit anything just because it is not >considered useful, IMO. An unspecified source address looks harmless >because we don't use it except DAD. For RFC2460, I agree. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 26 20:18:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6R3HWp19441 for ipng-dist; Wed, 26 Jul 2000 20:17:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6R3HO619434 for ; Wed, 26 Jul 2000 20:17:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA28526 for ; Wed, 26 Jul 2000 20:17:23 -0700 (PDT) Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA05234 for ; Wed, 26 Jul 2000 21:17:21 -0600 (MDT) Received: from duplo.sm.sony.co.jp (onoe@localhost) by onoe2.sm.sony.co.jp (8.9.0/3.7W) with ESMTP id MAA13898; Thu, 27 Jul 2000 12:17:20 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.0/8.10.2) id e6R3HG401680; Thu, 27 Jul 2000 12:17:16 +0900 (JST) Date: Thu, 27 Jul 2000 12:17:16 +0900 (JST) From: Atsushi Onoe Message-Id: <200007270317.e6R3HG401680@duplo.sm.sony.co.jp> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 packets with unspecified source address In-Reply-To: Your message of "Thu, 27 Jul 2000 12:07:30 +0900" <23605.964667250@coconut.itojun.org> References: <23605.964667250@coconut.itojun.org> X-Mailer: Cue version 0.6 (000608-1919/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with you that upper layer should validate the address of the communication end point. > - for forwarding case, I'm not sure. what is the scope for ::? > if it is linklocal or interface local (node local), maybe > "beyond scope" icmp6 error. This is my concern. The unspecified doesn't specify any of the addresses, thus it never belongs any of the scope. If an administrator consider it should be prohibited, use "administratively prohibited" icmp6 error. 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 Wed Jul 26 22:29:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6R5RsZ19512 for ipng-dist; Wed, 26 Jul 2000 22:27:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6R5Rk619505 for ; Wed, 26 Jul 2000 22:27:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA18006 for ; Wed, 26 Jul 2000 22:27:44 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA03208 for ; Wed, 26 Jul 2000 22:27:44 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Jul 2000 22:26:06 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Wed, 26 Jul 2000 22:26:21 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81025A04F92@RED-MSG-50> From: Richard Draves To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 packets with unspecified source address Date: Wed, 26 Jul 2000 22:25:57 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Another place where packets with an unspecified source address are legitimately used is with MLD, when you are sending a Report before your unicast addresses have finished DAD. I think routers should check for the unspecified source address and not forward such packets. The other cases that you outline, I think can probably be left undefined. Rich > -----Original Message----- > From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net] > Sent: Wednesday, July 26, 2000 7:45 PM > To: ipng@sunroof.eng.sun.com > Subject: IPv6 packets with unspecified source address > > > This is kind of "host/router requirement" question... > > IPv6 base specification allows (does not prohibit) use > of unspecified > IPv6 address in source address. The question we have is, how > legitimate it is to use unspecified IPv6 address in > source address. > > The only use we have in our document is: > - neighbor solicitation with unspecified IPv6 source, for DAD > > Please consider the following examples. Are these > examples legal? > - IPv6 ICMPv6 packet with unspecified source address, > which is DAD. > (this one should be legal, since it is documented in RFC2462) > > - IPv6 ICMPv6 packet with unspecified source address, > which is NOT DAD. > > - IPv6 TCP packet with unspecified source address. > this form of packet can be used to make a DoS attack. > careless > implementation may create TCP control block with local > address = mine, and foreign address = unspecified, in > state SYN_RCVD. > this may disable wildcard listening TCP socket from > being contacted > > - IPv6 UDP packet with unspecified source address. > > - other upper layer protocol with unspecified source address. > > - mobile-ip6 home address option with unspecified address. > > - a router which forwards packets with unspecified > source address. > if we consider that DAD is the only legal use, we > should not forward. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 26 22:47:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6R5k2119560 for ipng-dist; Wed, 26 Jul 2000 22:46:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6R5jr619553 for ; Wed, 26 Jul 2000 22:45:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA16988 for ; Wed, 26 Jul 2000 22:45:53 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA19166 for ; Wed, 26 Jul 2000 23:45:51 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id WAA08563; Wed, 26 Jul 2000 22:44:25 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <200007270244.e6R2iip14508@itojun.org> References: <200007270244.e6R2iip14508@itojun.org> Date: Wed, 26 Jul 2000 22:46:39 -0700 To: Jun-ichiro itojun Hagino From: Steve Deering Subject: Re: IPv6 packets with unspecified source address Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, The reason for allowing the unspecified address to be used as a source address is to enable a node to send a packet from an interface before it has an address for that interface. DAD is the one current example where this is necessary; after a node has successfully DADed for a link-local address for an interface, from that point on it can and should use that link-local address (or any additional, successfully acquired address) for any packets sent from that interface. Therefore, the "be conservative in what you send" rule would say that a host SHOULD not send packets with an unspecified source address if it has any other address assigned to the originating interface. (I say SHOULD instead of MUST, because I think it ought to be possible for an upper layer protocol to force the transmission of packet with an unspecified source address at any time, for debugging purposes or other uses we haven't thought of yet). The "be liberal in what you accept" rule would say that a node that receives a packet destined to itself, with an unspecified source address, should always pass it to the appropriate upper-layer protocol (based on Next Header type). If a node receives a packet *not* destined to itself, with an unspecified source address, it should silently drop the packet; this is normal behavior for a host. As for a router, I am surprised and embarrassed to see that the IPv6 Address Architecture spec does not say that packets with unspecified source addresses MUST NOT be forwarded. It ought to say that. (That's another little thing for us to fix, Bob!) On to your specific questions: > Please consider the following examples. Are these examples legal? > - IPv6 ICMPv6 packet with unspecified source address, which is DAD. > (this one should be legal, since it is documented in RFC2462) Yes, that's legal of course. > - IPv6 ICMPv6 packet with unspecified source address, which is NOT DAD. Yes, that's legal. Whether it is acted upon by the ICMP layer in the receiver depends on the nature of the message. Anything that requires a reply (such as an Echo Request) will clearly fail, because it is illegal to use the unspecified address as a destination address, i.e., the destination of the reply. > - IPv6 TCP packet with unspecified source address. > this form of packet can be used to make a DoS attack. careless > implementation may create TCP control block with local > address = mine, and foreign address = unspecified, in state SYN_RCVD. > this may disable wildcard listening TCP socket from being contacted TCP must perform sanity checks on incoming packets, beyond those required by the base IPv6 spec. For example, TCP must discard packets with multicast destination addresses. It should also discard packets with the unspecified source address, because such an address cannot legally be used as the destination address of packets going in the other direction. > - IPv6 UDP packet with unspecified source address. UDP-based applications must perform whatever sanity checks are necessary to satisfy their own semantics. The UDP module itself should not prevent the transmission or reception of packets with the unspecified source address. > - other upper layer protocol with unspecified source address. Same as UDP. > - mobile-ip6 home address option with unspecified address. MUST NOT be sent; MUST be discarded if received. If you don't have a home address, you shouldn't be using mobile IP. If you do have a home address, that's what you should use in the home address option. > - a router which forwards packets with unspecified source address. > if we consider that DAD is the only legal use, we should not forward. There may be legal uses other than DAD but, regardless, I think the Address Architecture spec should say MUST NOT forward packets with unspecified source address. > my proposal is like below: > - for IPv6 base specification, leave it as is or have more > wording about it (like "whether unspecified address is legal or not > is defined in the upper layer protocol") I would be inclined to just add the MUST NOT FORWARD requirement, and not say anything more in the IPv6-layer specs. > - For TCP and UDP, make it illegal. this is to keep practice > from IPv4 days and prevent possible implementation mistakes > (as we inherited TCP and UDP from IPv4). For TCP, yes, it should be illegal (along with other addresses. like multicast destination addresses). > - for ICMPv6, declare precisely when it is legal and when it is not. > For example, "it is allowed only for DAD". I think that's going too far. For those ICMP messages that trigger responses, the response should be stopped by the check for unspecified destination address (i.e., it is not illegal to receive a packet with an unspecified source address, but it is illegal to send a packet with an unspecified destination address). For other ICMP messages, go ahead and try to proces the packet -- either it will have a useful result or it will run into some other prohibition. > - home address option should obey whatever RFC2460 says. RFC-2460 doesn't mention the home address option; that option is defined in the Mobile IPv6 spec. > - for forwarding case, I'm not sure. what is the scope for ::? > if it is linklocal or interface local (node local), maybe > "beyond scope" icmp6 error. As I said, forwarding of packets with unspecified source should be forbidden. Effectively, that makes them link-local addresses (though I think of the unspecified address as "the absence of an address" which therefore has no scope). No ICMP error message can be sent, because there is no (legal) address to send it to. > - for other protocols, up to other protocol specifications. Agreed. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 26 22:50:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6R5niu19582 for ipng-dist; Wed, 26 Jul 2000 22:49:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6R5nZ619575 for ; Wed, 26 Jul 2000 22:49:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA19427 for ; Wed, 26 Jul 2000 22:49:33 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08928 for ; Wed, 26 Jul 2000 22:49:34 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id WAA08657; Wed, 26 Jul 2000 22:48:01 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81025A04F92@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81025A04F92@RED-MSG-50> Date: Wed, 26 Jul 2000 22:50:15 -0700 To: Richard Draves From: Steve Deering Subject: RE: IPv6 packets with unspecified source address Cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:25 PM -0700 7/26/00, Richard Draves wrote: >Another place where packets with an unspecified source address are >legitimately used is with MLD, when you are sending a Report before your >unicast addresses have finished DAD. Ah yes, I forgot about that one. That supports my own suggestions. >I think routers should check for the unspecified source address and not >forward such packets. > >The other cases that you outline, I think can probably be left undefined. Now why couldn't I be that succinct? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 27 02:56:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6R9srY19746 for ipng-dist; Thu, 27 Jul 2000 02:54:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6R9si619739 for ; Thu, 27 Jul 2000 02:54:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA25528 for ; Thu, 27 Jul 2000 02:54:43 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11600 for ; Thu, 27 Jul 2000 03:54:39 -0600 (MDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 27 Jul 2000 15:36:32 +0530 Received: from muralia ([10.0.14.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id PAA05842; Thu, 27 Jul 2000 15:12:54 +0530 Received: by localhost with Microsoft MAPI; Thu, 27 Jul 2000 15:25:49 +0530 Message-Id: <01BFF7DE.F121FC80.muralia@future.futsoft.com> From: Murali Krishna Ch Reply-To: "muralia@future.futsoft.com" To: "'Steve Deering'" , "muralia@future.futsoft.com" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Use of same interface id on multiple interfaces (RFC 2373) Date: Thu, 27 Jul 2000 15:25:47 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Steve, Can you please clarify the meaning of "zone identifier", and am not able to find draft-ipngwg-scoping-arch-01.txt. Can u give exact site. Murali. -----Original Message----- From: Steve Deering [SMTP:deering@cisco.com] Sent: Thursday, July 27, 2000 2:50 AM To: muralia@future.futsoft.com Cc: 'ipng@sunroof.eng.sun.com' Subject: Re: Use of same interface id on multiple interfaces (RFC 2373) At 4:55 PM +0530 7/26/00, Murali Krishna Ch wrote: >Can we use the same Interface id for multiple interfaces? >If so what are ISSUES, involved in it? >For example, if i have one Ethernet interface and 'n' PPP interfaces, >is it right to use the same linklocal address constructed from Mac Address for **ALL** the 'n' PPP links? >How does it effect the global uniqueness of the address? Murali, Yes, a node may use the same link-local address on more than attached link, and the same site-local address on more than one attached site. Link-local and site-local addresses are required to be unique only within the set of interfaces attached to a given link or site, respectively. The main consequence is that, within a node, any non-global address must be accompanied by a zone identifier (or an indication of "default zone") to identify the link or site to which it pertains. See draft-ipngwg-scoping-arch-01.txt. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 27 06:46:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6RDhf119835 for ipng-dist; Thu, 27 Jul 2000 06:43:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6RDhW619828 for ; Thu, 27 Jul 2000 06:43:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA24714 for ; Thu, 27 Jul 2000 06:43:33 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02752 for ; Thu, 27 Jul 2000 06:43:22 -0700 (PDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Thu, 27 Jul 2000 09:40:33 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id P4RRJJK4; Thu, 27 Jul 2000 09:38:40 -0400 Received: from nortelnetworks.com (CLEMSON [132.245.252.81]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id P1S0NW9Q; Thu, 27 Jul 2000 09:38:33 -0400 Message-ID: <39803AEA.E26C862B@nortelnetworks.com> Date: Thu, 27 Jul 2000 09:36:42 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "muralia@future.futsoft.com" CC: IPng Mailing List Subject: Re: Use of same interface id on multiple interfaces (RFC 2373) References: <01BFF7DE.F121FC80.muralia@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Murali, Try http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-01.txt Brian Murali Krishna Ch wrote: > > Dear Steve, > > Can you please clarify the meaning of "zone identifier", > and am not able to find draft-ipngwg-scoping-arch-01.txt. Can u give > exact site. > > Murali. > > -----Original Message----- > From: Steve Deering [SMTP:deering@cisco.com] > Sent: Thursday, July 27, 2000 2:50 AM > To: muralia@future.futsoft.com > Cc: 'ipng@sunroof.eng.sun.com' > Subject: Re: Use of same interface id on multiple interfaces (RFC 2373) > > At 4:55 PM +0530 7/26/00, Murali Krishna Ch wrote: > >Can we use the same Interface id for multiple interfaces? > >If so what are ISSUES, involved in it? > >For example, if i have one Ethernet interface and 'n' PPP interfaces, > >is it right to use the same linklocal address constructed from Mac Address for **ALL** the 'n' PPP links? > >How does it effect the global uniqueness of the address? > > Murali, > > Yes, a node may use the same link-local address on more than attached > link, and the same site-local address on more than one attached site. > Link-local and site-local addresses are required to be unique only > within the set of interfaces attached to a given link or site, respectively. > > The main consequence is that, within a node, any non-global address > must be accompanied by a zone identifier (or an indication of "default > zone") to identify the link or site to which it pertains. > > See draft-ipngwg-scoping-arch-01.txt. > > 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 > -------------------------------------------------------------------- -- Brian Haberman Nortel Networks haberman@nortelnetworks.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 27 10:03:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6RH13Z20023 for ipng-dist; Thu, 27 Jul 2000 10:01:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6RH0q620016 for ; Thu, 27 Jul 2000 10:00:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA29451 for ; Thu, 27 Jul 2000 10:00:51 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07465 for ; Thu, 27 Jul 2000 11:00:41 -0600 (MDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 49842BC1; Thu, 27 Jul 2000 11:59:28 -0500 (CDT) Received: from oflume.zk3.dec.com (yflume.zk3.dec.com [16.140.16.14]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id C6A20825; Thu, 27 Jul 2000 11:59:27 -0500 (CDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id MAA0000006672; Thu, 27 Jul 2000 12:59:27 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA22976; Thu, 27 Jul 2000 12:59:25 -0400 Message-Id: <39806A6A.F1199F96@zk3.dec.com> Date: Thu, 27 Jul 2000 12:59:23 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: Sowmini Varadhan , aconta@txc.com Cc: deering@cisco.com, IPNG Working Group Subject: Re: Tunnel Encapsulation Limit Option in rfc2473 References: <397DDA08.465C8DEB@zk3.dec.com> <397DFD61.2848CD36@txc.com> <397E06AA.C793906B@zk3.dec.com> <397F17A0.68C45593@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex This exception to Destination Option Header processing changes the fragmentation rules and makes Destination Option Header processing inconsistent. 1. Destination Option Header processing inconsistency: - You specify that Destination Option Header with Encapsulation Limit option must be processed by all inner tunnel entry points. However, these entry points are not the destinations specified in the destination field of the Tunnel Encapsulation Header (IPv6 header). Now RFC 2460, section 4 clearly states: "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. ... The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that must be examined and processed by every node along a packet's delivery path, including the source and destination nodes." 2. Change to the fragmentation rule: - You state in the draft that every tunnel entry point must examine and process Tunnel Encapsulation Limit option if one is present. However you never state the amendment to the fragmentation rule, that Destination Option Header carrying the Tunnel Encapsulation Limit option must be placed in every fragment. If this amendment is not required, then there is no way to enforce the requirement the draft places on the tunnel entry points. The reason is, that if fragmentation happens according to rfc 2460, then the Destination Option Header, regardless of the options it carries, will be placed in the fragmentable part and since the inner tunnel entry point is not the destination, there will be no way for it to check the option. With the requirement that your draft places on fragmentation rules, the architecture suddenly needs to concern itself not just with the Extension Headers, but with the options that they carry. -vlad Alex Conta wrote: > > Vlad, > > In RFC 2473, page 14: > > "Tunnel Incapsulation Limit options are of interest only to tunnel > entry points. A tunnel entry-point node is required to execute > the > following procedure for every packet entering a tunnel at that > node:...." > > ".....(Note that this requirement is an > exception to the general IPv6 rule that a Destination > Options extension header need only be examined by a > packet's destination node. An alternative and "cleaner" > approach would have been to use a Hop-by-Hop extension > header for this purpose, but that would have imposed an > undesirable extra processing burden, and possible > consequent extra delay, at every IPv6 node along the path > of a tunnel.)" > > Please note the "exception". > > Further, or once more: > > The "tunnel encapsulation limit", along with the forwarding/routing and > hop limit information, is part of the "control" information stored by a > tunnel entry-point in the tunnel headers. This information > is used/processed by the nodes in the tunnel, downstream from the tunnel > entry-point, to appropriately forward the tunnel packets towards the > tunnel exit point. > > The forwarding/routing information and hop limit in the IPv6 main header > is processed by each and every node. The forwarding/routing information > in a routing header is processed by the nodes which are part of the > source route. The tunnel encapsulation limit is processed by entry-point > nodes in inner nested tunnels, and ignored by other nodes. > > Ideally, a tunnel entry-point would specify each tunnel entry point in > inner nested tunnels in a > tunnel routing header. This is however impractical, as a tunnel entry > point MAY not know all the downstream entry-points to inner nested > tunnels. Nevertheless, all entry-points in inner nested tunnels, which > in extremus can be all nodes in a tunnel, MUST have access to the tunnel > encapsulation limit, to avoid the effect of infinite encapsulation. The > tunnel encapsulation limit carried by the tunnel headers of a packet > MUST be put in the tunnel headers of every fragment of that packet, when > the packet gets fragmented. > > To conclude, in the context of RFC2473 explained above, the statement in > RFC 2460 > > " The Unfragmentable Part consists of the IPv6 header plus any > extension headers that must be processed by nodes en route to > the > destination".... > > applies fully. Its explanation: > > "that is, all headers up to and including the Routing > header if present, else the Hop-by-Hop Options header if > present, > else no extension headers." > > if it is to be interpreted strictly ad literam, is excepted. > > Alex > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 14:30:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6RLT9u20229 for ipng-dist; Thu, 27 Jul 2000 14:29:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6RLT0620222 for ; Thu, 27 Jul 2000 14:29:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA05695 for ; Thu, 27 Jul 2000 14:29:00 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12460 for ; Thu, 27 Jul 2000 14:28:56 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA18570 for ; Thu, 27 Jul 2000 14:28:50 -0700 (MST)] Received: [from ilms03.cig.mot.com (ilms03.cig.mot.com [136.182.15.13]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA23186 for ; Thu, 27 Jul 2000 14:28:49 -0700 (MST)] Received: from em.cig.mot.com ([160.44.128.5]) by ilms03.cig.mot.com (Netscape Messaging Server 3.01) with SMTP id AAA17022; Thu, 27 Jul 2000 16:28:48 -0500 Received: by em.cig.mot.com (SMI-8.6/SMI-SVR4) id QAA16548; Thu, 27 Jul 2000 16:28:48 -0500 Date: Thu, 27 Jul 2000 16:28:48 -0500 Message-Id: <200007272128.QAA16548@em.cig.mot.com> To: yoshfuji@ecei.tohoku.ac.jp CC: crawdad@fnal.gov, bound@zk3.dec.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-reply-to: <20000727001120S.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: "La Monte Henry Piggy Yarroll" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) writes: >In article <200007261401.JAA00672@gungnir.fnal.gov> (at Wed, 26 Jul 2000 09:01:01 -0500), "Matt Crawford" says: > >> the v6 application could do this more simply by binding to the v4 >> address (be it wildcard or not) in addition to any others. > >We cannot do this with Linux. I have not gotten into the v6 portions of the networking code, but what is the constraint? -- Put no trust in extortion, La Monte Henry Piggy Yarroll set no vain hope in plunder; NIC Handle LY if riches increase, do not set your heart upon them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 14:39:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6RLchm20255 for ipng-dist; Thu, 27 Jul 2000 14:38:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6RLcY620248 for ; Thu, 27 Jul 2000 14:38:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA08328 for ; Thu, 27 Jul 2000 14:38:35 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18942 for ; Thu, 27 Jul 2000 14:38:33 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA09075; Thu, 27 Jul 2000 14:38:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA03088; Thu, 27 Jul 2000 14:38:25 -0700 X-Virus-Scanned: Thu, 27 Jul 2000 14:38:25 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdpFLbEW; Thu, 27 Jul 2000 14:38:21 PDT Message-Id: <4.3.2.7.2.20000727143357.025cc5e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2000 14:35:45 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Consensus on "IPv6 Multihoming with Route Aggregation" Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At the September 1999 Tokyo IPng meeting a consensus was developed to move "IPv6 Multihoming with Route Aggregation" forward along with other multihoming approaches (e.g., "IPv6 multihoming support at site exit routers", source and destination address selection, etc.). This was discussed again at the November 1999 Washington, DC IPng meeting. The draft was revised based on comments (including renaming it to it's current title) and a two week working group last call was started on 23 Jun 2000. There was an active discussion on the IPng mailing list. The IPng chairs believe that there is still a consensus to move the document forward to Informational. There were a few active dissenters, but the chairs believe that this draft is a useful part of the IPv6 multihoming framework and that there is still a consensus to request that the IESG published it as an Informational RFC. 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 Thu Jul 27 14:50:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6RLn5b20301 for ipng-dist; Thu, 27 Jul 2000 14:49:05 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6RLmu620294 for ; Thu, 27 Jul 2000 14:48:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA24183; Thu, 27 Jul 2000 14:48:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25808; Thu, 27 Jul 2000 14:48:54 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA10178; Thu, 27 Jul 2000 14:48:50 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA28610; Thu, 27 Jul 2000 14:48:48 -0700 X-Virus-Scanned: Thu, 27 Jul 2000 14:48:48 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdkPO7Cy; Thu, 27 Jul 2000 14:47:44 PDT Message-Id: <4.3.2.7.2.20000727143706.025cbe00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2000 14:45:07 -0700 To: narten@raleigh.ibm.com, Erik.Nordmark@eng.sun.com From: Bob Hinden Subject: Request to Advance "IPv6 Multihoming with Route Aggregation" Cc: scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : IPv6 Multihoming with Route Aggregation Author(s) : J. Yu Filename : draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt Pages : 7 Date : 24-Nov-99 A consensus was developed at the Tokyo (9/1999) and Washington, DC (11/1999) IPng meetings to move this document forward. A working group last call for this document was completed on July 7, 2000. There was an active discussion during the last call. The w.g. chairs conclude from the discussion that there is a consensus in the w.g. to move this document forward as an Informational RFC. This document is part of the IPv6 multihoming framework. The working group will also be advancing other documents dealing with other aspects of IPv6 multihoming. Bob Hinden / Steve Deering IPng Working Group 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 Thu Jul 27 16:57:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6RNuDV20454 for ipng-dist; Thu, 27 Jul 2000 16:56:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6RNu3620447 for ; Thu, 27 Jul 2000 16:56:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA20791 for ; Thu, 27 Jul 2000 16:56:03 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14290 for ; Thu, 27 Jul 2000 16:56:02 -0700 (PDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id IAA01541; Fri, 28 Jul 2000 08:55:52 +0900 To: piggy@em.cig.mot.com Cc: crawdad@fnal.gov, bound@zk3.dec.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <200007272128.QAA16548@em.cig.mot.com> References: <20000727001120S.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200007272128.QAA16548@em.cig.mot.com> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000728085551C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Fri, 28 Jul 2000 08:55:51 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <200007272128.QAA16548@em.cig.mot.com> (at Thu, 27 Jul 2000 16:28:48 -0500), "La Monte Henry Piggy Yarroll" says: > >> the v6 application could do this more simply by binding to the v4 > >> address (be it wildcard or not) in addition to any others. > > > >We cannot do this with Linux. > > I have not gotten into the v6 portions of the networking code, but > what is the constraint? Ipv6 tcp layer and ipv4 tcp layer are shared. You cannot bind a ipv4 socket to a port already bound to ipv6 socket. You cannot bind a ipv6 socket to a port already bound to ipv4 socket. If you want to provide a service to ipv6 and ipv4 client through single local port, you must create an ipv6 scoket and bind to that port; ipv4 clients are serviced by ipv6 scoket through ipv4-mapped addresses. We may be able to provide a new socket option that disables ipv4-mapped feature, but I wonder application might abuse; create ipv6 socket, set that sockopt and create ipv4 socket... then Linux cannot provide a service to ipv4 clinets. please note this... -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 17:34:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6S0X1P20490 for ipng-dist; Thu, 27 Jul 2000 17:33:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6S0Wo620483 for ; Thu, 27 Jul 2000 17:32:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA02192 for ; Thu, 27 Jul 2000 17:32:51 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28051 for ; Thu, 27 Jul 2000 18:32:49 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id JAA08778; Fri, 28 Jul 2000 09:32:47 +0900 (JST) To: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=) cc: piggy@em.cig.mot.com, crawdad@fnal.gov, bound@zk3.dec.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-reply-to: yoshfuji's message of Fri, 28 Jul 2000 08:55:51 JST. <20000728085551C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: itojun@iijlab.net Date: Fri, 28 Jul 2000 09:32:47 +0900 Message-ID: <8776.964744367@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Ipv6 tcp layer and ipv4 tcp layer are shared. >You cannot bind a ipv4 socket to a port already bound to ipv6 socket. >You cannot bind a ipv6 socket to a port already bound to ipv4 socket. > >If you want to provide a service to ipv6 and ipv4 client through single >local port, you must create an ipv6 scoket and bind to that port; >ipv4 clients are serviced by ipv6 scoket through ipv4-mapped addresses. just a comment: the following items are completely separate. you can get any behavior you want, with any code structure. the first 3 line in the above does not match up. - whether tcp layer code is shared between ipv4/v6 or not - whether pcb layer code is shared between AF_INET/INET6 or not - whether you allow bind(2) to the same port, while counterpart is already done that - whether you support RFC2553-inbound or not on AF_INET6 socket - whether you support RFC2553-outbound or not on AF_INET6 socket itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 27 19:39:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6S2bpP20548 for ipng-dist; Thu, 27 Jul 2000 19:37:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6S2bg620541 for ; Thu, 27 Jul 2000 19:37:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA20315 for ; Thu, 27 Jul 2000 19:37:41 -0700 (PDT) Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21055 for ; Thu, 27 Jul 2000 19:37:42 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id UAA10552 for ; Thu, 27 Jul 2000 20:37:41 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200007280237.UAA10552@hunkular.glarp.com> To: ipng@sunroof.eng.sun.com From: huntting@glarp.com Subject: Re: multihome address selection In-Reply-To: Your message of "Thu, 27 Jul 2000 20:35:35 MDT." <200007280235.UAA10462@hunkular.glarp.com> Date: Thu, 27 Jul 2000 20:37:41 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How is a typical v6 TCP client at a multihomed site, with address prefixes from multiple upstream providers, supposed to choose amongst it's local addresses when contacting a remote server? One way might be for each host to keep a full routing table with link-global nexthop addresses. In which case the typical connect() sequence would go something like this: Client app calls connect() on a new socket with local address unspecified. The kernel looks up the remote address in the local forwarding table (aka the routing table) and finds a local interface address. It set's the socket local address accordingly, and begins the 3 way handshake to establish the TCP session. Unfortunately, creating a forwarding table with link-global nexthops is a bit more problematic. It's not practical to run an iBGP session to every host on the network. RIPng uses exclusively link-local nexthops (per RFC2080) which makes it useless for conveying link-global nexthops. I havent investigated using OSPF6 yet. I also have some reservations about "redistributing" BGP routes into an IGP at all. Since many sites already redistribute IGP routes (from ISIS, OSPF, or RIPng) into BGP, can redistributing BGP routes back the other way cause problems? If redistributing routes from BGP into an IGP is an unacceptable risk then perhaps the best way to distribute the full routing table to end systems is to use a RIPng like protocol on a different UDP port and specify that it should use link-global addresses. Would it be better to simply forgo the use of routing protocols and use using Neighbor Discovery to find both the best nexthop and link-global address prefix to use? At least this method doesnt require maintaining a full routing table. brad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 19:48:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6S2lCm20575 for ipng-dist; Thu, 27 Jul 2000 19:47:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6S2l2620568 for ; Thu, 27 Jul 2000 19:47:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA19138 for ; Thu, 27 Jul 2000 19:47:03 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA20727 for ; Thu, 27 Jul 2000 20:47:01 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA10493; Fri, 28 Jul 2000 11:46:55 +0900 (JST) To: huntting@glarp.com cc: ipng@sunroof.eng.sun.com In-reply-to: huntting's message of Thu, 27 Jul 2000 20:37:41 CST. <200007280237.UAA10552@hunkular.glarp.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: multihome address selection From: itojun@iijlab.net Date: Fri, 28 Jul 2000 11:46:55 +0900 Message-ID: <10491.964752415@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >How is a typical v6 TCP client at a multihomed site, with address >prefixes from multiple upstream providers, supposed to choose >amongst it's local addresses when contacting a remote server? regardless from how hard you try to pick the "best" address, that may not be the best one for your peer. i believe draft-ietf-ipngwg-default-addr-select-01.txt covers your goal enough, and does the best we can without having global information (like the whole topology map inbetween). >One way might be for each host to keep a full routing table with >link-global nexthop addresses. In which case the typical connect() >sequence would go something like this: what is "link-global" nexthop here? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 27 23:32:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6S6VES20639 for ipng-dist; Thu, 27 Jul 2000 23:31:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6S6V4620632 for ; Thu, 27 Jul 2000 23:31:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA07091 for ; Thu, 27 Jul 2000 23:31:00 -0700 (PDT) Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA05506 for ; Thu, 27 Jul 2000 23:31:00 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id AAA17745; Fri, 28 Jul 2000 00:30:51 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200007280630.AAA17745@hunkular.glarp.com> To: itojun@iijlab.net cc: huntting@glarp.com, ipng@sunroof.eng.sun.com Subject: Re: multihome address selection In-Reply-To: Your message of "Fri, 28 Jul 2000 11:46:55 +0900." <10491.964752415@coconut.itojun.org> Date: Fri, 28 Jul 2000 00:30:51 -0600 From: Brad Huntting Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>How is a typical v6 TCP client at a multihomed site, with address >>prefixes from multiple upstream providers, supposed to choose >>amongst it's local addresses when contacting a remote server? > regardless from how hard you try to pick the "best" address, that > may not be the best one for your peer. i believe > draft-ietf-ipngwg-default-addr-select-01.txt covers your goal enough, > and does the best we can without having global information (like > the whole topology map inbetween). Well now I feel foolish. Thank you, I should have read that beforehand. >>One way might be for each host to keep a full routing table with >>link-global nexthop addresses. In which case the typical connect() >>sequence would go something like this: > what is "link-global" nexthop here? I'm sorry, I meant "addresses with global scope". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 23:51:46 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6S6oPo20670 for ipng-dist; Thu, 27 Jul 2000 23:50:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6S6oG620663 for ; Thu, 27 Jul 2000 23:50:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA06788 for ; Thu, 27 Jul 2000 23:50:18 -0700 (PDT) Received: from perilla.nov.tahi.org (oxalis.nezu.wide.ad.jp [203.178.142.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA12924 for ; Thu, 27 Jul 2000 23:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by perilla.nov.tahi.org (8.9.3/8.9.3) with ESMTP id PAA15842 for ; Fri, 28 Jul 2000 15:50:15 +0900 (JST) (envelope-from nov@tahi.org) To: ipng@sunroof.eng.sun.com Reply-To: contact@tahi.org Subject: TAHI IPv6 Conformance Test Packages From: OKABE Nobuo X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000728155015Y.nov@tahi.org> Date: Fri, 28 Jul 2000 15:50:15 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, [1] TAHI Project has released the IPv6 Conformance Test Packages at the following web site: http://www.tahi.org/ Changes from the previous release of the IPv6 Conformance Test Packages: The Test Tool (Release-1.1): - ported FreeBSD4.X - Not support FreeBSD2.X - Clarified implementation dependent codes - Got feedback from our 2'nd test event The Test Program (Release-1.1): - IPsec AH and ESP for IPv4 - Got feedback from our 2'nd test event [2] Reports of 2'nd Interoperability Test Event We have also summarized our 2'nd test event. http://www.tahi.org/presentation/2nd-interop/ Here is more detail report about IPsec/IKE interoperability in the test event. http://www.tanu.org/~sakane/doc/public/report-ike-interop0007.html The contents of the reports have been approved by all of participants. [3] Test Report of KAME Stable We are running the test now. We'll show the result by the end of next week. Thanks, --- Nobuo Okabe @ TAHI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 28 02:34:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6S9X3F20792 for ipng-dist; Fri, 28 Jul 2000 02:33:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6S9Ws620785 for ; Fri, 28 Jul 2000 02:32:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA19323 for ; Fri, 28 Jul 2000 02:32:53 -0700 (PDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA12009 for ; Fri, 28 Jul 2000 03:32:53 -0600 (MDT) Received: by alfa.itea.ntnu.no id LAA0000013236; Fri, 28 Jul 2000 11:32:39 +0200 (MET DST) From: Stig Venås Date: Fri, 28 Jul 2000 11:32:39 +0200 To: Hideaki YOSHIFUJI Cc: piggy@em.cig.mot.com, crawdad@fnal.gov, bound@zk3.dec.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) Message-ID: <20000728113238.A19428@itea.ntnu.no> References: <20000727001120S.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200007272128.QAA16548@em.cig.mot.com> <20000728085551C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000728085551C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>; from yoshfuji@ecei.tohoku.ac.jp on Fri, Jul 28, 2000 at 08:55:51AM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Jul 28, 2000 at 08:55:51AM +0900, Hideaki YOSHIFUJI wrote: > In article <200007272128.QAA16548@em.cig.mot.com> (at Thu, 27 Jul 2000 16:28:48 -0500), "La Monte Henry Piggy Yarroll" says: > > > >> the v6 application could do this more simply by binding to the v4 > > >> address (be it wildcard or not) in addition to any others. > > > > > >We cannot do this with Linux. > > > > I have not gotten into the v6 portions of the networking code, but > > what is the constraint? > > Ipv6 tcp layer and ipv4 tcp layer are shared. > You cannot bind a ipv4 socket to a port already bound to ipv6 socket. > You cannot bind a ipv6 socket to a port already bound to ipv4 socket. Unless you bind to specific addresses. I find the Linux behavior pretty logical. Sometimes it gets in the way though. An IPv6 socket option for not accepting IPv4 connections sounds good, then one could bind both IPv4 and IPv6 sockets to the same port without specifying addresses. Stig -- Stig Venaas UNINETT -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 03:56:53 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SAtAD20909 for ipng-dist; Fri, 28 Jul 2000 03:55:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SAt0620902 for ; Fri, 28 Jul 2000 03:55:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA24212 for ; Fri, 28 Jul 2000 03:54:59 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22034 for ; Fri, 28 Jul 2000 03:54:49 -0700 (PDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id SAA07849; Fri, 28 Jul 2000 18:51:43 +0900 To: venaas@alfa.itea.ntnu.no Cc: piggy@em.cig.mot.com, crawdad@fnal.gov, bound@zk3.dec.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <20000728113238.A19428@itea.ntnu.no> References: <200007272128.QAA16548@em.cig.mot.com> <20000728085551C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <20000728113238.A19428@itea.ntnu.no> X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-Id: <20000728185142F.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Fri, 28 Jul 2000 18:51:42 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 22 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e6SAt2620903 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <20000728113238.A19428@itea.ntnu.no> (at Fri, 28 Jul 2000 11:32:39 +0200), Stig Venås says: > > Ipv6 tcp layer and ipv4 tcp layer are shared. > > You cannot bind a ipv4 socket to a port already bound to ipv6 socket. > > You cannot bind a ipv6 socket to a port already bound to ipv4 socket. > > Unless you bind to specific addresses. Even if we bind to in6addr_any / INADDR_ANY. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 08:09:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SF7je21039 for ipng-dist; Fri, 28 Jul 2000 08:07:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SF7a621032 for ; Fri, 28 Jul 2000 08:07:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA09329 for ; Fri, 28 Jul 2000 08:07:36 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19168 for ; Fri, 28 Jul 2000 08:07:36 -0700 (PDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id 8C7781AE0; Fri, 28 Jul 2000 10:07:35 -0500 (CDT) Received: from iota.zk3.dec.com (iota.zk3.dec.com [16.140.32.65]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id A4C4A1B73; Fri, 28 Jul 2000 10:07:34 -0500 (CDT) Received: from localhost by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM) id LAA0000001773; Fri, 28 Jul 2000 11:07:31 -0400 (EDT) From: Jim Bound Message-Id: <200007281507.LAA0000001773@iota.zk3.dec.com> X-Authentication-Warning: iota.zk3.dec.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Matt Crawford" Cc: Jim Bound , "La Monte Henry Piggy Yarroll" , SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) In-reply-to: Your message of "Wed, 26 Jul 2000 09:01:01 CDT." <200007261401.JAA00672@gungnir.fnal.gov> Date: Fri, 28 Jul 2000 11:07:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi Matt, >> Well its not that easy. We still do not want af_inet6 listner to get >> the connections for IPv4 if there is an af_inet listener. That is the >> only real problem, which the socket level option fixes. >To give a v4-specific listener priority over a v6 listener is not up >to the API but the stack's PCB lookup function, yes? The only reason >I can see for a sockopt is to allow overriding this behavior -- but >the v6 application could do this more simply by binding to the v4 >address (be it wildcard or not) in addition to any others. I see your point and agree on the behavior, but I don't want to\ mandate implementation behavior either. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 28 08:25:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SFNxo21084 for ipng-dist; Fri, 28 Jul 2000 08:23:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SFNo621077 for ; Fri, 28 Jul 2000 08:23:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA02756 for ; Fri, 28 Jul 2000 08:23:51 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00068 for ; Fri, 28 Jul 2000 09:23:45 -0600 (MDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13IBz6-000260-00; Fri, 28 Jul 2000 11:23:36 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA21293; Fri, 28 Jul 00 11:21:03 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA21647; Fri, 28 Jul 2000 11:26:52 -0400 Message-Id: <3981A5BA.F7DCB744@txc.com> Date: Fri, 28 Jul 2000 11:24:42 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Vladislav Yasevich Cc: Sowmini Varadhan , deering@cisco.com, IPNG Working Group Subject: Re: Tunnel Encapsulation Limit Option in rfc2473 References: <397DDA08.465C8DEB@zk3.dec.com> <397DFD61.2848CD36@txc.com> <397E06AA.C793906B@zk3.dec.com> <397F17A0.68C45593@txc.com> <39806A6A.F1199F96@zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vlad, 1. There is NO CHANGE to the fragmentation rules stated by RFC 2460. RFC 2473 merely specifies packet size calculations and tunnel headers specifics, which apply to tunnel packets only. These complement/extend the rules of RFC 2460 for tunnel packets. 2. RFC 2473 states the trade off made in using a destination rather than a hop by hop option header to carry the tunnel encapsulation limit. It also explains the reasoning behind the trade off. Practically, inner tunnel entry points are mostly routers in a packet's path. They are infrequent enough to make both the hop by hop processing costs, and a third type of options header in the architecture harder to justify, than an exception in processing destination headers. In making the trade off, the authors, and the WG were in consensus that practical world considerations outweigh abstract perspectives. Note: the third type of options header would be processed only by some nodes in the path, as opposed to hop by hop, and destination. Your comments are a valuable contribution in improving the specifications, which is a permanent goal with documents on standards track is a permanent goal. I noted the request/suggestion for an explicit statement on the placing of a tunnel encapsulation limit at tunnel packet fragmentation. This seems particularly useful for host developers implementing fragmentation. Thanks, Alex Vladislav Yasevich wrote: > > Alex > > This exception to Destination Option Header processing changes the > fragmentation rules and makes Destination Option Header processing > inconsistent. > > 1. Destination Option Header processing inconsistency: > - You specify that Destination Option Header with Encapsulation Limit > option must be processed by all inner tunnel entry points. However, these > entry points are not the destinations specified in the destination field of > the Tunnel Encapsulation Header (IPv6 header). Now RFC 2460, section 4 > clearly states: > > "With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header. > ... > The exception referred to in the preceding paragraph is the Hop-by- > Hop Options header, which carries information that must be examined > and processed by every node along a packet's delivery path, including > the source and destination nodes." > > 2. Change to the fragmentation rule: > - You state in the draft that every tunnel entry point must examine and > process Tunnel Encapsulation Limit option if one is present. However > you never state the amendment to the fragmentation rule, that Destination > Option Header carrying the Tunnel Encapsulation Limit option must be > placed in every fragment. If this amendment is not required, then there > is no way to enforce the requirement the draft places on the tunnel entry > points. The reason is, that if fragmentation happens according to rfc 2460, > then the Destination Option Header, regardless of the options it carries, > will be placed in the fragmentable part and since the inner tunnel entry > point is not the destination, there will be no way for it to check the > option. > > With the requirement that your draft places on fragmentation rules, the > architecture suddenly needs to concern itself not just with the Extension > Headers, but with the options that they carry. > > -vlad > > Alex Conta wrote: > > > > Vlad, > > > > In RFC 2473, page 14: > > > > "Tunnel Incapsulation Limit options are of interest only to tunnel > > entry points. A tunnel entry-point node is required to execute > > the > > following procedure for every packet entering a tunnel at that > > node:...." > > > > ".....(Note that this requirement is an > > exception to the general IPv6 rule that a Destination > > Options extension header need only be examined by a > > packet's destination node. An alternative and "cleaner" > > approach would have been to use a Hop-by-Hop extension > > header for this purpose, but that would have imposed an > > undesirable extra processing burden, and possible > > consequent extra delay, at every IPv6 node along the path > > of a tunnel.)" > > > > Please note the "exception". > > > > Further, or once more: > > > > The "tunnel encapsulation limit", along with the forwarding/routing and > > hop limit information, is part of the "control" information stored by a > > tunnel entry-point in the tunnel headers. This information > > is used/processed by the nodes in the tunnel, downstream from the tunnel > > entry-point, to appropriately forward the tunnel packets towards the > > tunnel exit point. > > > > The forwarding/routing information and hop limit in the IPv6 main header > > is processed by each and every node. The forwarding/routing information > > in a routing header is processed by the nodes which are part of the > > source route. The tunnel encapsulation limit is processed by entry-point > > nodes in inner nested tunnels, and ignored by other nodes. > > > > Ideally, a tunnel entry-point would specify each tunnel entry point in > > inner nested tunnels in a > > tunnel routing header. This is however impractical, as a tunnel entry > > point MAY not know all the downstream entry-points to inner nested > > tunnels. Nevertheless, all entry-points in inner nested tunnels, which > > in extremus can be all nodes in a tunnel, MUST have access to the tunnel > > encapsulation limit, to avoid the effect of infinite encapsulation. The > > tunnel encapsulation limit carried by the tunnel headers of a packet > > MUST be put in the tunnel headers of every fragment of that packet, when > > the packet gets fragmented. > > > > To conclude, in the context of RFC2473 explained above, the statement in > > RFC 2460 > > > > " The Unfragmentable Part consists of the IPv6 header plus any > > extension headers that must be processed by nodes en route to > > the > > destination".... > > > > applies fully. Its explanation: > > > > "that is, all headers up to and including the Routing > > header if present, else the Hop-by-Hop Options header if > > present, > > else no extension headers." > > > > if it is to be interpreted strictly ad literam, is excepted. > > > > Alex > > > > -- > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tel: (603) 884-1079 > Compaq Computer Corp. Fax: (435) 514-6884 > 110 Spit Brook Rd ZK03-3/T07 > Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 09:29:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SGRd521132 for ipng-dist; Fri, 28 Jul 2000 09:27:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SGRT621125 for ; Fri, 28 Jul 2000 09:27:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA16500 for ; Fri, 28 Jul 2000 09:27:29 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17206 for ; Fri, 28 Jul 2000 10:27:28 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA26883 for ; Fri, 28 Jul 2000 09:27:27 -0700 (MST)] Received: [from ilms02.cig.mot.com (ilms02.cig.mot.com [136.182.15.12]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA07101 for ; Fri, 28 Jul 2000 09:27:26 -0700 (MST)] Received: from em.cig.mot.com ([160.44.128.5]) by ilms02.cig.mot.com (Netscape Messaging Server 3.6) with SMTP id AAA5247; Fri, 28 Jul 2000 11:27:25 -0500 Received: by em.cig.mot.com (SMI-8.6/SMI-SVR4) id LAA19012; Fri, 28 Jul 2000 11:27:23 -0500 Date: Fri, 28 Jul 2000 11:27:23 -0500 Message-Id: <200007281627.LAA19012@em.cig.mot.com> To: yoshfuji@ecei.tohoku.ac.jp CC: crawdad@fnal.gov, bound@zk3.dec.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-reply-to: <20000728085551C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Subject: Re: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft) From: "La Monte Henry Piggy Yarroll" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) writes: >In article <200007272128.QAA16548@em.cig.mot.com> (at Thu, 27 Jul 2000 16:28:48 -0500), "La Monte Henry Piggy Yarroll" says: > >> >> the v6 application could do this more simply by binding to the v4 >> >> address (be it wildcard or not) in addition to any others. >> > >> >We cannot do this with Linux. >> >> I have not gotten into the v6 portions of the networking code, but >> what is the constraint? > >Ipv6 tcp layer and ipv4 tcp layer are shared. >You cannot bind a ipv4 socket to a port already bound to ipv6 socket. >You cannot bind a ipv6 socket to a port already bound to ipv4 socket. > >If you want to provide a service to ipv6 and ipv4 client through single >local port, you must create an ipv6 scoket and bind to that port; >ipv4 clients are serviced by ipv6 scoket through ipv4-mapped addresses. > >We may be able to provide a new socket option that disables ipv4-mapped >feature, but I wonder application might abuse; create ipv6 socket, set >that sockopt and create ipv4 socket... then Linux cannot provide a service >to ipv4 clinets. please note this... This is actually the sematics which I advocate. I assume I can still bind separately to single addresses? Our proposal for the SCTP is to allow you to bind to arbitrary subsets of addresses. The semantics of such an operation for SCTP are slightly different for SCTP--each association on the transmission endpoint will use ALL the addresses in the binding. TCP semantics call for connections coming in on ANY of the bound addresses. -- Put no trust in extortion, La Monte Henry Piggy Yarroll set no vain hope in plunder; NIC Handle LY if riches increase, do not set your heart upon them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 10:33:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SHW1i21220 for ipng-dist; Fri, 28 Jul 2000 10:32:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SHVq621213 for ; Fri, 28 Jul 2000 10:31:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA03150 for ; Fri, 28 Jul 2000 10:31:51 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05476 for ; Fri, 28 Jul 2000 11:31:50 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id KAA20731; Fri, 28 Jul 2000 10:30:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <4.3.2.7.2.20000724095640.025dc980@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20000724095640.025dc980@mailhost.iprg.nokia.com> Date: Fri, 28 Jul 2000 10:33:17 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: update on ipngwg meeting times Cc: hinden@iprg.nokia.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The agenda for the Pittsburgh IETF lists three meeting times for the IPng Working Group: Tuesday, 1545-1645 Wednesday, 1300-1500 Thursday, 1300-1500 The first of those three times, i.e., the Tuesday meeting, has now been *cancelled*. (That time was intended to be used for a joint ipngwg- mobileip meeting, but the planning for that did not coalesce.) Therefore, ipngwg will be meeting two times in Pittsburgh, i.e., on Wednesday and Thursday afternoons. The draft agenda for those meeting times was posted here on Monday Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 28 11:07:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SI5iI21288 for ipng-dist; Fri, 28 Jul 2000 11:05:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SI5W621281 for ; Fri, 28 Jul 2000 11:05:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA08727 for ; Fri, 28 Jul 2000 11:05:33 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13377 for ; Fri, 28 Jul 2000 11:05:29 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA21489; Fri, 28 Jul 2000 11:05:47 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA04871; Fri, 28 Jul 2000 11:05:48 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA08011; Fri, 28 Jul 2000 11:09:51 -0700 (PDT) Date: Fri, 28 Jul 2000 11:09:51 -0700 (PDT) From: Tim Hartrick Message-Id: <200007281809.LAA08011@feller.mentat.com> To: vlad@zk3.dec.com, aconta@txc.com Subject: Re: Tunnel Encapsulation Limit Option in rfc2473 Cc: varadhan@zk3.dec.com, deering@cisco.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, > > 1. There is NO CHANGE to the fragmentation rules stated by RFC 2460. > > RFC 2473 merely specifies packet size calculations and tunnel headers > specifics, which apply > to tunnel packets only. These complement/extend the rules of RFC 2460 > for tunnel packets. > Actually, there is a change because if someone has written general code to fragment IPv6 datagrams based on the rules in 2460, that code won't work properly if presented with a datagram of the form. | IPv6 outer header | Dst option header with encap limit | IPv6 inner header | That general code will place the fragment header in front of the destination option header thus creating a datagram that does not have the encap limit option available for the next tunnel ingress point. What Vlad is pointing out is that we now must put code into the general fragmentation path which not only needs to know about existance of dest- ination option headers but needs to know about and search for specific options in the destination options header based on whether the next header value of the last header in the datagram is IPPROTO_IPV6. Either that or we need to have special purpose fragmentation code that only deals with tunnel ingress processing. Both these alternatives are bad in my opinion. The first is a performance hit, the second is code bloat. It is doable but suboptimal. Continuing to insist that you haven't changed the fragmentation rules is not an accurate assessment of the situation once one considers the details of actual implementation. > 2. RFC 2473 states the trade off made in using a destination rather than > a hop by hop > option header to carry the tunnel encapsulation limit. It also explains > the reasoning behind > the trade off. Practically, inner tunnel entry points are mostly routers > in a packet's path. > They are infrequent enough to make both the hop by hop processing costs, > and a third type of > options header in the architecture harder to justify, than an exception > in processing destination > headers. In making the trade off, the authors, and the WG were in > consensus that practical world considerations outweigh abstract > perspectives. > > Note: the third type of options header would be processed only by some > nodes in the path, as opposed to hop by hop, and destination. > Given the limited implementation experience at the time that consensus was reached (read none) I dare say that it might be, and I mean might be not is, time to revisit the consensus. Given that the document is only proposed standard it should be possible to make modifications if necessary. It would be nice to hear from others that are attempting to write code to support this specification. Just one man's opinion. 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 Fri Jul 28 12:36:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SJZBS21368 for ipng-dist; Fri, 28 Jul 2000 12:35:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SJZ2621361 for ; Fri, 28 Jul 2000 12:35:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA07408 for ; Fri, 28 Jul 2000 12:35:02 -0700 (PDT) Received: from smtp1.jaring.my (smtp1.jaring.my [192.228.128.45]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06251 for ; Fri, 28 Jul 2000 13:34:59 -0600 (MDT) Received: from hhorgan (j69.ptl40.jaring.my [161.142.31.83]) by smtp1.jaring.my (8.10.0.Beta6/8.9.3) with SMTP id e6SJYug04537 for ; Sat, 29 Jul 2000 03:34:56 +0800 (MYT) Message-ID: <003201bff8ca$fe655800$531f8ea1@hhorgan> From: "kwtung" To: "IPNG Working Group" Subject: Fw: Help / Advise needed Date: Sat, 29 Jul 2000 03:35:31 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01BFF90E.0BE86060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002F_01BFF90E.0BE86060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi all, sorry for disturb. is anyone there know how to configure kernal forr redhat 6.0 or redhat = 6.1 kernal to support IPV6 ? =20 =20 thanks, best regards, kwtung=20 ------=_NextPart_000_002F_01BFF90E.0BE86060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi all,
 
sorry for disturb.
is anyone there know how to = configure kernal=20 forr redhat 6.0 or redhat 6.1 kernal to
support IPV6 = ?
 
 
thanks,
best regards,
kwtung
------=_NextPart_000_002F_01BFF90E.0BE86060-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 13:54:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SKqFu21863 for ipng-dist; Fri, 28 Jul 2000 13:52:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SKq7621856 for ; Fri, 28 Jul 2000 13:52:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA23739 for ; Fri, 28 Jul 2000 13:52:05 -0700 (PDT) Received: from smtp2.jaring.my (smtp2.jaring.my [192.228.128.47]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23840 for ; Fri, 28 Jul 2000 13:52:03 -0700 (PDT) Received: from hhorgan (j10.ptl40.jaring.my [161.142.31.24]) by smtp2.jaring.my (8.10.0.Beta6/8.9.3) with SMTP id e6SKq1k12152 for ; Sat, 29 Jul 2000 04:52:01 +0800 (MYT) Message-ID: <001001bff8d5$c30265e0$181f8ea1@hhorgan> From: "kwtung" To: "IPNG Working Group" Subject: Advise / Help needed Date: Sat, 29 Jul 2000 04:52:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi all, sorry for disturb. is anyone there know how to configure kernal forr redhat 6.0 or redhat 6.1 kernal to support IPV6 ? thanks, best regards, kwtung -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 14:07:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SL6LO21886 for ipng-dist; Fri, 28 Jul 2000 14:06:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SL6C621879 for ; Fri, 28 Jul 2000 14:06:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA03124 for ; Fri, 28 Jul 2000 14:06:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02293 for ; Fri, 28 Jul 2000 14:06:09 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA28627; Fri, 28 Jul 2000 14:06:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA28902; Fri, 28 Jul 2000 14:06:07 -0700 X-Virus-Scanned: Fri, 28 Jul 2000 14:06:07 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpd7H9ccx; Fri, 28 Jul 2000 14:05:59 PDT Message-Id: <4.3.2.7.2.20000728140213.024a9008@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Jul 2000 14:03:21 -0700 To: Jack McCann From: Bob Hinden Subject: Re: New "IP Version 6 Addressing Architecture" draft Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jack, >During w.g. last call, I suggested a change of wording in the >definition of IPv4-mapped addresses (mail attached below). I >see the suggestion was not incorporated in addr-arch-v3-01. >Let me offer an example of what motivated my suggestion. I did read and consider your suggestion. I should have gotten back in touch. >Suppose we have 2 IPv6/IPv4 nodes: Node A has IPv6 address A::A >and IPv4 address 1.2.3.4. Node B has IPv6 address B::B and IPv4 >address 5.6.7.8. Node A is running a server which is listening >for both IPv4 and IPv6 connections on an AF_INET6 socket. A client >on node B connects to node A's IPv4 address (1.2.3.4), with packets >sourced from B's IPv4 address (5.6.7.8). (Why does the client use >A's IPv4 address? Perhaps it is an AF_INET application that has >not yet been upgraded, or perhaps the user entered 1.2.3.4.) The >server on node A accepts the connection, and because it is using >AF_INET6 sockets, accept() returns B's IPv4 address as ::FFFF:5.6.7.8. >In this example, an IPv4-mapped address (::FFFF:5.6.7.8) is used >to represent the address of an IPv6/IPv4 node (B). > >Is this correct usage of IPv4-mapped addresses? Or is it a violation >of the architecture? It is not the intended use of IPv4-mapped addresses, but I am not sure it is a violation of the architecture either. From an protocol view, I don't think it is possible for a node to tell if it is talking to an IPv4 only node or an IPv4/IPv6 node. They have separate identities. I am not widely enthusiastic about making this change. If folks think it is necessary, I think it would be better to change it to: This address is used to represent the addresses of IPv4 nodes as IPv6 addresses. instead of listing the exceptions one by one. Comments... Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 28 14:17:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6SLG7e21916 for ipng-dist; Fri, 28 Jul 2000 14:16:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SLFv621909 for ; Fri, 28 Jul 2000 14:15:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA05264 for ; Fri, 28 Jul 2000 14:15:58 -0700 (PDT) Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16001 for ; Fri, 28 Jul 2000 15:15:57 -0600 (MDT) Received: from [198.138.94.6] (helo=smtp.txc.com) by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3) id 13IHU0-0002nz-00; Fri, 28 Jul 2000 17:15:52 -0400 Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1) id AA24110; Fri, 28 Jul 00 17:13:19 EDT Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id RAA02870; Fri, 28 Jul 2000 17:19:09 -0400 Message-Id: <3981F84B.1F0D2349@txc.com> Date: Fri, 28 Jul 2000 17:16:59 -0400 From: Alex Conta X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en Mime-Version: 1.0 To: Tim Hartrick Cc: vlad@zk3.dec.com, varadhan@zk3.dec.com, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: Tunnel Encapsulation Limit Option in rfc2473 References: <200007281809.LAA08011@feller.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, 1. There are some implementations that were written tunneling code before the tunneling specs were published as Proposed Standard, and that was independent of the authors, the WG, or the developers. Once RFC 2473 was out, it was supposed to have among others, the role of bringing implementations to a common denominator in regards to tunneling. That put, unfortunately, some additional burden on those developers that had early tunneling implementations, in particular if those implementations were incomplete, or deviated from the RFC 2473. Whether one way of implementing correctly fragmenting tunnel packets carrying the tunnel encapsulation limit is worse or better it is an implementation issue. One can look just for the presence of a destination header with tunnel encapsulation limit, and mark the point past that header as delimiter of the unfragmentable portion of the tunnel packet. The procedure for looking for the tunnel encapsulation limit is to be implemented anyway for the use of the inner tunnel entry-points forwarding engines. An efficient and correct implementation of a fragmentation engine according to RFC 2460, and RFC 2473, is to look for a logical delimiter of the unfragmentable portion rather than use specific next header types as delimiters. Routing, hop by hop, and tunnel header processing engines would set or update such a logical delimiter, past the headers that they generate or process. The delimiter can be a pointer or offset in the IP packet. 2. Please note, that once the specs were published as PS, they reflect a process, which includes a Last Call in the WG and a Last Call in IESG. That qualifies as far as I know as a general consensus. The important point though is that both the specs and implementations can be improved. As part of improving the specs, the authors of RFC 2473 are going to revisit the messages exchanged on this topic. Next week is a very good opportunity and we will take full advantage of it. Meanwhile I subscribe to Tim's call for more opinions on this matter. Thanks, Alex Tim Hartrick wrote: > > Alex, > > > > > 1. There is NO CHANGE to the fragmentation rules stated by RFC 2460. > > > > RFC 2473 merely specifies packet size calculations and tunnel headers > > specifics, which apply > > to tunnel packets only. These complement/extend the rules of RFC 2460 > > for tunnel packets. > > > > Actually, there is a change because if someone has written general > code to fragment IPv6 datagrams based on the rules in 2460, that code > won't work properly if presented with a datagram of the form. > > | IPv6 outer header | Dst option header with encap limit | IPv6 inner header | > > That general code will place the fragment header in front of the > destination option header thus creating a datagram that does not have > the encap limit option available for the next tunnel ingress point. > > What Vlad is pointing out is that we now must put code into the general > fragmentation path which not only needs to know about existance of dest- > ination option headers but needs to know about and search for specific > options in the destination options header based on whether the next header > value of the last header in the datagram is IPPROTO_IPV6. Either that or > we need to have special purpose fragmentation code that only deals with > tunnel ingress processing. > > Both these alternatives are bad in my opinion. The first is a performance > hit, the second is code bloat. It is doable but suboptimal. > > Continuing to insist that you haven't changed the fragmentation rules is > not an accurate assessment of the situation once one considers the details > of actual implementation. > > > 2. RFC 2473 states the trade off made in using a destination rather than > > a hop by hop > > option header to carry the tunnel encapsulation limit. It also explains > > the reasoning behind > > the trade off. Practically, inner tunnel entry points are mostly routers > > in a packet's path. > > They are infrequent enough to make both the hop by hop processing costs, > > and a third type of > > options header in the architecture harder to justify, than an exception > > in processing destination > > headers. In making the trade off, the authors, and the WG were in > > consensus that practical world considerations outweigh abstract > > perspectives. > > > > Note: the third type of options header would be processed only by some > > nodes in the path, as opposed to hop by hop, and destination. > > > > Given the limited implementation experience at the time that consensus was > reached (read none) I dare say that it might be, and I mean might be not is, > time to revisit the consensus. Given that the document is only proposed > standard it should be possible to make modifications if necessary. > > It would be nice to hear from others that are attempting to write code to > support this specification. > > > Just one man's opinion. > > 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 Fri Jul 28 18:11:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6T19vJ22074 for ipng-dist; Fri, 28 Jul 2000 18:09:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6T19m622067 for ; Fri, 28 Jul 2000 18:09:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA06882 for ; Fri, 28 Jul 2000 18:09:48 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11410 for ; Fri, 28 Jul 2000 19:09:46 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id JAA11457 for ; Sat, 29 Jul 2000 09:55:13 +0900 (JST) Date: Sat, 29 Jul 2000 06:32:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: In your message of "Mon, 24 Jul 2000 09:14:17 -0400" <397C4129.A434EDAB@nortelnetworks.com> References: <4.3.2.7.2.20000713142500.0254f0b0@mailhost.iprg.nokia.com> <3978462D.BA263D3E@nortelnetworks.com> <397C4129.A434EDAB@nortelnetworks.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 24 Jul 2000 09:14:17 -0400, >>>>> "Brian Haberman" said: >> According to this description, admin-local is larger than link-local >> and smaller than site-local. Is my understanding correct? And if so, >> is the definition really reasonable? (Although it depends on the >> definition of "site"). > Your understanding is correct (link-local <= scope 3 <= scope 4 <= > site-local). > Is it reasonable? I believe so. Several of us discussed this issue in > relation to RFC 2365 and determined that scope 4 allows for more > flexibility > in the use of admin scoped multicast. I see. I don't necessarily argue that it is unreasonable, but I'm just a bit wandering what if someone wants to specify admin-local scope zone that covers multiple sites...(still, the fact that we don't have a concrete definition of site would be a source of confusion). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 28 19:02:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6T21Jn22100 for ipng-dist; Fri, 28 Jul 2000 19:01:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6T219622093 for ; Fri, 28 Jul 2000 19:01:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA17759 for ; Fri, 28 Jul 2000 19:01:09 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27979 for ; Fri, 28 Jul 2000 20:01:08 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id LAA16106; Sat, 29 Jul 2000 11:00:57 +0900 To: kwtung@pc.jaring.my Cc: ipng@sunroof.eng.sun.com Subject: Re: Advise / Help needed From: Hideaki YOSHIFUJI In-Reply-To: <001001bff8d5$c30265e0$181f8ea1@hhorgan> References: <001001bff8d5$c30265e0$181f8ea1@hhorgan> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000729110057X.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Sat, 29 Jul 2000 11:00:57 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <001001bff8d5$c30265e0$181f8ea1@hhorgan> (at Sat, 29 Jul 2000 04:52:35 +0800), "kwtung" says: > is anyone there know how to configure kernal forr redhat 6.0 or redhat 6.1 > kernal to support IPV6 ? Configure in normal way. Please be sure to use linux-2.2.x or later and to enable "Prompt for development and/or incomplete code/drivers" option or you don't see "The IPv6 Protocol" option etcetra in "Networking options." Good luck! If you have further questions on configuring ipv6 kernel, please mail them to linux-ipv6 or netdev list. -- Hideaki YOSHIFUJI @ USAGI Project Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 28 20:04:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6T32xL22125 for ipng-dist; Fri, 28 Jul 2000 20:02:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6T32o622118 for ; Fri, 28 Jul 2000 20:02:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA29092 for ; Fri, 28 Jul 2000 20:02:50 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06702 for ; Fri, 28 Jul 2000 20:02:28 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA11714 for ; Sat, 29 Jul 2000 11:47:53 +0900 (JST) Date: Sat, 29 Jul 2000 11:52:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: scoped addresses and routing headers(Re: draft-ipngwg-scoping-arch-01.txt) In-Reply-To: In your message of "Thu, 29 Jun 2000 23:01:17 -0700" References: <200006281743.NAA0000583107@anw.zk3.dec.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 90 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 29 Jun 2000 23:01:17 -0700, >>>>> Steve Deering said: >> whether they are crossing boundaries for their scopes. Thus, it is >> possible, though generally inadvisable, to use a Routing Header to >> convey a non-global address across its associated zone boundary. >> >> I believe this is very inadvisable. > Yeah, it's not likely to do anything useful. But I would not want to > impose the cost on implementations of a relatively expensive check (a > scan through all the addresses in a Routing header) for a such an > unlikely event. I agree that we should not introduce expensive checks such as scanning thru the entire routing header. However, the text of the draft about this issue is not very clear for me. The draft says as follows: A node that receives a packet addressed to itself and containing a Routing Header with more than zero Segments Left [RFC 2460, section 4.4] swaps the original destination address with the next address in the Routing Header. Then the above forwarding rules are applied, using the new destination address. Where "the above forwarding rules" are ones based on arrival interfaces, that is, the router determines the appropriate zone for an incoming packet based on the arrival interface, and then forwards the packet to an interface (or interfaces if mulicasted) that belongs to the zone. But the situation is not so trivial (at least for me) with routing headers. Consider the following packet (actually, I raised this six months ago, but I haven't seen any responses to this.) source = some global address (1st hop) destination = a global address "G1" 2nd hop destination (in a routing header) = another global address "G2" 3rd hop destination (in a routing header) = a link-local address "L" Where "global2" belongs to a router "R" that has two interfaces "I1" and "I2". I assume G2 is configured on I1. Also suppose that G1 and G2 are offlink and there are several paths to G2 like the following figure: (node that has G1) ........---+ | / |I1: G2 +-------....(Internet clould) R \ |I2 +......----+ If the router R adopts the weak host(node) model, it will accept packets destined to G2 regardless of the incoming interface (I1 or I2). The incoming interface depends on the routing in the intermediate cloud and can dynamically be changed. Now, consider the situation where the packet with the routing header arrives at I2 (that *doesn't* have G2). When the router R processes the routing header and tries to forward the packet to L, which link (interface) should it send the packet? To the incoming interface (I2), or the interface that has G2 (i.e. I1), or even another interface? It seems to me that the only reasonable approach is to forward the packet to the link to which I1 is attached, because if we forward the packets to the *real* arrival interface (I2), succeeding packets with the same routing header could be forwarded to another interface that should surely be undesirable. I need a clarification on this points before accepting the description. By the way, IMO, I'd rather take a stricter (and even simpler) approach; - the destination addresss field and all addresses in the routing header SHOULD have a same scope. - when a router forwards a packet with a routing header, it should check the "current" destination address in the IPv6 header and the "next" destination address in the routing header. If scopes of the two addresses are different, the router MUST discard the packet (or return an ICMPv6 error). Although the rule is stricter than the current definition in the draft, it's clearer, practical enough, inexpensive for routers, at least for me. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 29 04:58:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6TBuqi22482 for ipng-dist; Sat, 29 Jul 2000 04:56:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6TBuh622475 for ; Sat, 29 Jul 2000 04:56:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA09561 for ; Sat, 29 Jul 2000 04:56:42 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14183 for ; Sat, 29 Jul 2000 04:56:41 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.20.158.210) by smtp1.libero.it; 29 Jul 2000 13:56:39 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id B78CA4C68F; Sat, 29 Jul 2000 12:38:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id B29D24C447; Sat, 29 Jul 2000 12:38:16 +0200 (CEST) Date: Sat, 29 Jul 2000 12:38:16 +0200 (CEST) From: Mauro Tortonesi To: Bob Hinden Cc: Jack McCann , ipng@sunroof.eng.sun.com Subject: Re: New "IP Version 6 Addressing Architecture" draft In-Reply-To: <4.3.2.7.2.20000728140213.024a9008@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 28 Jul 2000, Bob Hinden wrote: > >Is this correct usage of IPv4-mapped addresses? Or is it a violation > >of the architecture? after a careful reading of rfc2553 i guess it is just the correct usage. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Sat Jul 29 19:11:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6U29oj23209 for ipng-dist; Sat, 29 Jul 2000 19:09:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6U29e623202 for ; Sat, 29 Jul 2000 19:09:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA12932 for ; Sat, 29 Jul 2000 19:09:37 -0700 (PDT) Received: from santa.cct.ydc.co.jp (ip173.pittsburgh5.pa.pub-ip.psi.net [38.26.141.173]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA01574 for ; Sat, 29 Jul 2000 19:09:35 -0700 (PDT) Received: from ydc.co.jp (localhost [127.0.0.1]) by santa.cct.ydc.co.jp (8.9.3/8.9.3) with ESMTP id LAA14042 for ; Sun, 30 Jul 2000 11:09:48 +0900 (JST) (envelope-from miyata@ydc.co.jp) Message-ID: <39838E6C.DF27FF93@ydc.co.jp> Date: Sun, 30 Jul 2000 11:09:48 +0900 From: Hiroshi MIYATA X-Mailer: Mozilla 4.7C-ja [ja] (X11; I; FreeBSD 3.5-RELEASE i386) X-Accept-Language: ja MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: TAHI test report was added to IPNG WG agenda Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I'm a member of TAHI Project. I was assigned 5 min for a presentation of TAHI Project test event at the begging of 48th IETF IPNG WG first meeting. So, I introduce it briefly. TAHI Project held IPv6 interoperability test event from 15 to 18 July at YOKOHAMA, JAPAN. You can see the test report summary at following URL. http://www.tahi.org/presentation/2nd-interop/ We have two kind of test. o Interoperability test o Conformance test Interoperability test mainly focuses on Basic function Routing protocol Transition IPsec Conformance test mainly focuses on Basic function IPsec I'll present more details. Sorry for changing of agenda. Regards, -------Hiroshi Miyata @ TAHI Project. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 30 22:27:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6V5QWx23793 for ipng-dist; Sun, 30 Jul 2000 22:26:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V5QO623786 for ; Sun, 30 Jul 2000 22:26:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA25338 for ; Sun, 30 Jul 2000 22:26:23 -0700 (PDT) Received: from southstation.m5p.com (dsl-209-162-215-52.easystreet.com [209.162.215.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA12584 for ; Sun, 30 Jul 2000 23:26:22 -0600 (MDT) Received: (from george@localhost) by southstation.m5p.com (8.11.0.Beta3/8.11.0.Beta3) id e6V5QMF91009; Sun, 30 Jul 2000 22:26:22 -0700 (PDT) Date: Sun, 30 Jul 2000 22:26:22 -0700 (PDT) Message-Id: <200007310526.e6V5QMF91009@southstation.m5p.com> From: george+ipng@m5p.com To: ipng@sunroof.eng.sun.com Subject: Thanks for all the great software! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks to everybody on this list who designed, wrote, and tested IP version 6 software! Now that the 6bone has recovered from its spasm of routing misinformation, I'm pleased to announce that the World Science Fiction Society's web page is now accessible via IPv6 at www6.wsfs.org or www6.worldcon.org. It's my guess that this is one of the first web sites on the 6bone bone which is not concerned in any way with network operations. Perhaps it's the very first, though it would be hard to prove. I'm running FreeBSD-3.4+KAME- stable-March2000, Apache-1.3.12 with KAME patches, sendmail-8.11.0 with IPv6 service, and BIND-9.0.0-rc1 with IPv6 service. My appre- ciation goes out to all the people who made this wonderful software work, and to the people at Verio Northwest who provide my IPv6 tunnel. -- George Mitchell (george+ipv6@m5p.com) (IPv6 mail at george+ipv6@ip6.m5p.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 Jul 30 22:34:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6V5Xow23824 for ipng-dist; Sun, 30 Jul 2000 22:33:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6V5Xg623817 for ; Sun, 30 Jul 2000 22:33:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA12703 for ; Sun, 30 Jul 2000 22:33:40 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA14783 for ; Sun, 30 Jul 2000 23:33:40 -0600 (MDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 30 Jul 2000 22:31:54 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Sun, 30 Jul 2000 22:32:15 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81025A0590C@RED-MSG-50> From: Richard Draves To: JINMEI Tatuya / ???? Cc: ipng@sunroof.eng.sun.com Subject: RE: scoped addresses and routing headers(Re: draft-ipngwg-scoping -arch-01.txt) Date: Sun, 30 Jul 2000 22:32:49 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If the router R adopts the weak host(node) model, it will accept > packets destined to G2 regardless of the incoming interface (I1 or > I2). The incoming interface depends on the routing in the intermediate > cloud and can dynamically be changed. I think the the spec's "receiving interface" should always be the interface to which G2 is assigned, even if this is a weak host model implementation and the packet is actually received on some other interface. I think this interpretation produces the "only reasonable approach" that you describe. > Now, consider the situation where the packet with the routing header > arrives at I2 (that *doesn't* have G2). When the router R processes > the routing header and tries to forward the packet to L, which link > (interface) should it send the packet? To the incoming interface (I2), > or the interface that has G2 (i.e. I1), or even another interface? > > It seems to me that the only reasonable approach is to forward the > packet to the link to which I1 is attached, because if we forward the > packets to the *real* arrival interface (I2), succeeding packets with > the same routing header could be forwarded to another interface that > should surely be undesirable. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 31 09:49:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6VGlRE24212 for ipng-dist; Mon, 31 Jul 2000 09:47:27 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6VGlM624205 for ; Mon, 31 Jul 2000 09:47:22 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA15817 for ipng@sunroof.eng.sun.com; Mon, 31 Jul 2000 09:45:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6SLHi621927 for ; Fri, 28 Jul 2000 14:17:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA22630 for ; Fri, 28 Jul 2000 14:17:46 -0700 (PDT) Received: from aarnima1-pc2.tmt.tele.fi (aarnima1-pc2.tmt.tele.fi [194.252.70.162]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08389 for ; Fri, 28 Jul 2000 14:17:44 -0700 (PDT) Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@aarnima1-pc2.tmt.tele.fi)) by mail.zmailer.org id ; Sat, 29 Jul 2000 00:17:27 +0300 Date: Sat, 29 Jul 2000 00:17:27 +0300 From: Matti Aarnio To: kwtung Cc: IPNG Working Group Subject: Re: Advise / Help needed Message-ID: <20000729001727.D24768@mea-ext.zmailer.org> References: <001001bff8d5$c30265e0$181f8ea1@hhorgan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001001bff8d5$c30265e0$181f8ea1@hhorgan>; from kwtung@pc.jaring.my on Sat, Jul 29, 2000 at 04:52:35AM +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Jul 29, 2000 at 04:52:35AM +0800, kwtung wrote: > hi all, > > sorry for disturb. > is anyone there know how to configure kernal forr redhat 6.0 or redhat 6.1 > kernal to support IPV6 ? Yes. Details offline. However at those two distributions the userspace is *not* entirely IPv6 supporting. (Neither is RedHat 6.2 quite there.) Nevertheless it hasn't prevented me from hacking with IPv6 for past three years. > thanks, > best regards, > kwtung /Matti Aarnio -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 31 12:51:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6VJoEd24403 for ipng-dist; Mon, 31 Jul 2000 12:50:14 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6VJoA624396 for ; Mon, 31 Jul 2000 12:50:10 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id MAA16068 for ipng@sunroof.eng.sun.com; Mon, 31 Jul 2000 12:48:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6VJQQ624378 for ; Mon, 31 Jul 2000 12:26:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA23208 for ; Mon, 31 Jul 2000 12:26:26 -0700 (PDT) Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06762 for ; Mon, 31 Jul 2000 12:26:24 -0700 (PDT) Received: from wired-129-169.ietf.marconi.com ([147.73.129.169]:9220 "HELO kenawang" ident: "IDENT-NOT-QUERIED [port 9220]") by newquern.epilogue.com with SMTP id <639-175>; Mon, 31 Jul 2000 15:26:10 -0400 Message-Id: <4.2.2.20000731122738.01cad0a0@localhost> X-Sender: mrfpop@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 To: IPng Working Group From: Margaret Wasserman Subject: Scoped Addressing Architecture Routing Issue In-Reply-To: References: <01BFF722.3F374A00.muralia@future.futsoft.com> <01BFF722.3F374A00.muralia@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Jul 2000 15:26:10 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe that there is a problem with the forwarding section of the Scoped Addressing Architecture document (section 9). The current draft assumes that a next hop will be selected based only on the destination address of the packet, but I believe that it is necessary to take both the destination and source addresses into account to choose the correct conceptual routing table. Consider the following example: (Cost 1) +--------R1-----------------+ +------------------|-----+ | +------------|------------------+ | SITE A | | | | SITE B | H1 | | Link1________.___|___ | | | Link2______|_______|_ | | | | +---------------+ +--+ | +--------------|---------+ | Link3____|_____________| | | | | //<=== Cost >=2 | | Link4_____.________.___. | | | | | | | | | | | | H2 +--+ | | +-----------|-------------------+ | | +--------------R2--------------+ (Cost 1) There are two sites, SITE A and Site B. SITE A has one link, Link1. SITE B has three links: Link2, Link3 and Link4. H1 is a host on Link2, and H2 is a host on Link4. R1 is a site-boundary router with interfaces on Link1(SITE A), Link2(SITE B) and Link3 (SITE B), and the cost for traversing this router is always 1. R2 is another site-boundary router, connecting Link1(SITE A) and Link4(SITE B), and the cost for traversing R2 is also 1. There is additional routing infrastructure inside SITE B which connects Link3 and Link4 at a cost greater than or equal to 2. H1 sends a packet to H2 with the following addresses: Destination: Global address of H2 Source: Site Local address of H1 Although this packet can (and should) reach its destination, it will not do so using the process described in section 9 of the Scoped Addressing Architecture. o The zone of the destination address is determined by the scope of the address and arrival interface of the packet. The next-hop interface is chosen by looking up the destination address in a (conceptual) routing table specific to that zone. That routing table is restricted to refer only to interfaces belonging to that zone. The zone of the destination address is Global. So, we will look in the global table to determine how to route to H2. The shortest (or cheapest) next-hop will be chosen -- router R2, through SITE A. o After the next-hop interface is chosen, the zone of the source address is considered. As with the destination address, the zone of the source address is determined by the scope of the address and arrival interface of the packet. If transmitting the packet on the chosen next- hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded and an ICMP Destination Unreachable message [RFC 2463] with Code 2 ("beyond scope of source address") is sent to the source of the packet. However, the site local (to SITE B) source address was used, so we will discard the packet before sending it to SITE A. Preferably, we would choose a site-local route to send this packet, even if it might result in a longer (or more expense) routing path. This could be achieved by using the scope of both the destination and source addresses to determine which conceptual routing table to use for packet forwarding. A router should look at both the source and destination addresses and determine which is of the lesser scope. The lesser scope (site-local in my example) will then be used to select the conceptual routing table. In this instance, the global address would be looked up in the site-local routing table, and an appropriate next hop could be chosen (if it exists) to route the packet to the global destination address using a site-local path. Thoughts? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 31 14:44:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e6VLgid24537 for ipng-dist; Mon, 31 Jul 2000 14:42:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e6VLgZ624530 for ; Mon, 31 Jul 2000 14:42:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA00269 for ; Mon, 31 Jul 2000 14:42:36 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA17897 for ; Mon, 31 Jul 2000 15:42:33 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 31 Jul 2000 14:40:24 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Mon, 31 Jul 2000 14:40:42 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA222AC@RED-MSG-50> From: Richard Draves To: "'Margaret Wasserman'" Cc: IPng Working Group Subject: RE: Scoped Addressing Architecture Routing Issue Date: Mon, 31 Jul 2000 14:40:21 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've thought some in the past about your proposal. It would mean, for example, that there would be no Destination Unreachable / Scope Exceeded ICMP error because the routing table lookup would be constrained so as to not exceed the scope of the source address. My conclusion was that in normal configurations, it wouldn't make a difference. But when a network is misconfigured, it would get in the way of debugging the problem because you wouldn't get the ICMP error. Rich > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@epilogue.com] > Sent: Monday, July 31, 2000 12:26 PM > To: IPng Working Group > Subject: Scoped Addressing Architecture Routing Issue > > > > I believe that there is a problem with the forwarding section > of the Scoped Addressing Architecture document (section 9). > > The current draft assumes that a next hop will be selected > based only on the destination address of the packet, but I > believe that it is necessary to take both the destination and > source addresses into account to choose the correct conceptual > routing table. > > Consider the following example: > > (Cost 1) > +--------R1-----------------+ > > +------------------|-----+ | +------------|------------------+ > | SITE A | | | | SITE B | H1 | > | Link1________.___|___ | | | Link2______|_______|_ | > | | | +---------------+ +--+ | > +--------------|---------+ | Link3____|_____________| | | > | | > //<=== Cost >=2 > | | Link4_____.________.___. | | > | | | | | | | > | | | H2 +--+ | > | +-----------|-------------------+ > | | > +--------------R2--------------+ > (Cost 1) > > There are two sites, SITE A and Site B. SITE A has one link, Link1. > SITE B has three links: Link2, Link3 and Link4. H1 is a host on > Link2, and H2 is a host on Link4. R1 is a site-boundary router > with interfaces on Link1(SITE A), Link2(SITE B) and Link3 (SITE B), > and the cost for traversing this router is always 1. R2 is another > site-boundary router, connecting Link1(SITE A) and Link4(SITE B), > and the cost for traversing R2 is also 1. There is additional routing > infrastructure inside SITE B which connects Link3 and Link4 at a > cost greater than or equal to 2. > > H1 sends a packet to H2 with the following addresses: > > Destination: Global address of H2 > Source: Site Local address of H1 > > Although this packet can (and should) reach its destination, it will > not do so using the process described in section 9 of the Scoped > Addressing Architecture. > > > o The zone of the destination address is > determined by the > scope of the address and arrival interface of > the packet. > The next-hop interface is chosen by looking up the > destination address in a (conceptual) routing table > specific to that zone. That routing table is > restricted > to refer only to interfaces belonging to that zone. > > The zone of the destination address is Global. So, we will look in > the global table to determine how to route to H2. The shortest > (or cheapest) next-hop will be chosen -- router R2, through SITE A. > > > o After the next-hop interface is chosen, the zone of the > source address is considered. As with the destination > address, the zone of the source address is > determined by > the scope of the address and arrival interface of the > packet. If transmitting the packet on the chosen next- > hop interface would cause the packet to leave > the zone of > the source address, i.e., cross a zone boundary of the > scope of the source address, then the packet > is discarded > and an ICMP Destination Unreachable message [RFC 2463] > with Code 2 ("beyond scope of source address") > is sent to > the source of the packet. > > However, the site local (to SITE B) source address was used, so we > will discard the packet before sending it to SITE A. > > Preferably, we would choose a site-local route to send this packet, > even if it might result in a longer (or more expense) routing path. > This could be achieved by using the scope of both the destination > and source addresses to determine which conceptual routing table to > use for packet forwarding. > > A router should look at both the source and destination addresses > and determine which is of the lesser scope. The lesser scope > (site-local in my example) will then be used to select the conceptual > routing table. In this instance, the global address would be > looked up in the site-local routing table, and an appropriate next > hop could be chosen (if it exists) to route the packet to the > global destination address using a site-local path. > > Thoughts? > > Margaret > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 31 21:29:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e714Rut24687 for ipng-dist; Mon, 31 Jul 2000 21:27:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e714Rj624680 for ; Mon, 31 Jul 2000 21:27:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA03450 for ; Mon, 31 Jul 2000 21:27:44 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA16133 for ; Mon, 31 Jul 2000 21:27:41 -0700 (PDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id NAA21015; Tue, 1 Aug 2000 13:11:42 +0900 (JST) Date: Tue, 01 Aug 2000 13:21:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: tim@mentat.com Cc: vlad@zk3.dec.com, aconta@txc.com, varadhan@zk3.dec.com, deering@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: Tunnel Encapsulation Limit Option in rfc2473 In-Reply-To: In your message of "Fri, 28 Jul 2000 11:09:51 -0700 (PDT)" <200007281809.LAA08011@feller.mentat.com> References: <200007281809.LAA08011@feller.mentat.com> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 28 Jul 2000 11:09:51 -0700 (PDT), >>>>> Tim Hartrick said: > What Vlad is pointing out is that we now must put code into the general > fragmentation path which not only needs to know about existance of dest- > ination option headers but needs to know about and search for specific > options in the destination options header based on whether the next header > value of the last header in the datagram is IPPROTO_IPV6. Either that or > we need to have special purpose fragmentation code that only deals with > tunnel ingress processing. > Both these alternatives are bad in my opinion. The first is a performance > hit, the second is code bloat. It is doable but suboptimal. > Continuing to insist that you haven't changed the fragmentation rules is > not an accurate assessment of the situation once one considers the details > of actual implementation. (although we've never tried to implement the tunnel encapsulation option in the KAME statck) I completely agree with Tim and Vlad; the proposed rule for the new option contradicts with general rules described in RFC2460, and the advantage of the new rule is not worth modifying existing implementations (IMHO). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 31 21:35:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e714YCn24714 for ipng-dist; Mon, 31 Jul 2000 21:34:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e714Y3624707 for ; Mon, 31 Jul 2000 21:34:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA26018 for ; Mon, 31 Jul 2000 21:34:01 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA18492 for ; Mon, 31 Jul 2000 21:34:00 -0700 (PDT) Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id NAA21049; Tue, 1 Aug 2000 13:19:27 +0900 (JST) Date: Tue, 01 Aug 2000 13:29:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: scoped addresses and routing headers In-Reply-To: In your message of "Sun, 30 Jul 2000 22:32:49 -0700" <4D0A23B3F74DD111ACCD00805F31D81025A0590C@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81025A0590C@RED-MSG-50> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 30 Jul 2000 22:32:49 -0700, >>>>> Richard Draves said: >> If the router R adopts the weak host(node) model, it will accept >> packets destined to G2 regardless of the incoming interface (I1 or >> I2). The incoming interface depends on the routing in the intermediate >> cloud and can dynamically be changed. > I think the the spec's "receiving interface" should always be the interface > to which G2 is assigned, even if this is a weak host model implementation > and the packet is actually received on some other interface. > I think this interpretation produces the "only reasonable approach" that you > describe. Right, there would be no ambiguity with this interpretation. I think the draft should clearly state this. (As I said in the previous mail, I personally prefer a stricter rule, though.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------