From owner-ipng@sunroof.eng.sun.com Wed Mar 1 19:23:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e223LVo27435 for ipng-dist; Wed, 1 Mar 2000 19:21:31 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e223LK927428 for ; Wed, 1 Mar 2000 19:21:20 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with SMTP id e223LJL04214; Wed, 1 Mar 2000 19:21:19 -0800 (PST) Date: Wed, 1 Mar 2000 12:25:25 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Site Identifiers and IPv6 Multisited Applications Nodes To: itojun@iijlab.net Cc: Erik Nordmark , Jim Bound , Robert Elz , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <12636.951883260@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 > (assume this multi-sited server has fec0::1%site0, fec0::1%site1, > and fec0::1%site2) > I thought of binding to more specific address, like: > daemon 1 binds to fec0::1%site0 > daemon 2 binds to fec0::1%site1 > daemon 3 binds to fec0::1%site2 > > Given that the interpretation of sin6_scope_id is determined by > sin6_addr, I think binding to ::%site0 is not a good idea. "::" > does not give context to sin6_scope_id portion... The problem is that e.g. for site1 the server have multiple interfaces with different IIDs i.e. there is more than one site-local address for each site. Thus daemon 2 needs to bind to more than one address fec0::a00:20ff:fe01:4444%site1 fec0::a00:21ff:fe08:5555%site1 fec0::a00:20ff:fe67:3333%site1 fec0::a00:20ff:fe01:2222%site1 (assuming there are 4 interfaces to site1). Doing this would require modifying the application source code. Perhaps those modifications are less than making the application site aware (i.e. carrying around sockaddr_in6 instead of in6_addr internally) - perhaps the modifications are more significant than make it site aware. I suspect the tradeoff is different for different applications. Thus my question was really: Do we need to provide a mechanism for an unmodified application which binds to in6_addr any to limit it so a given site? *If* we do the mechanism might need to be something ugly like an environment variable (e.g. setenv XXX_LIMIT_IPV6_BIND_TO_SITE "site1") that the bind() library/system call interprets. Another possible question is: Do we need a mechanism to make it easier for an application that can be modified to handle the above case with multiple site-local addresses (due to multiple interfaces) per site? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 1 19:38:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e223b8Y27466 for ipng-dist; Wed, 1 Mar 2000 19:37:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e223av927459 for ; Wed, 1 Mar 2000 19:36:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA02538; Wed, 1 Mar 2000 19:36:57 -0800 (PST) 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 UAA20958; Wed, 1 Mar 2000 20:36:55 -0700 (MST) 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 MAA00543; Thu, 2 Mar 2000 12:36:34 +0900 (JST) To: Erik Nordmark cc: Jim Bound , Robert Elz , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 01 Mar 2000 12:25:25 PST. 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: Site Identifiers and IPv6 Multisited Applications Nodes From: itojun@iijlab.net Date: Thu, 02 Mar 2000 12:36:34 +0900 Message-ID: <541.951968194@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe "non site-aware server program on multi-sited node" situation is *extremely* rare. I don't think we need to tweak APIs for this - properly written (*) server program can serve on multi-sited node okay with the existing API. (*) properly written means: - always honor sin6_scope_id came from the kernel - don't try to pack a sockaddr_in6 by itself. this usually result in invalid (or unmatched) sin6_scope_id. - always use getpeername/getsockname to get remote/local address. gethostname -> gethostbyname for getting local address is wrong. - use getaddrinfo and getnameinfo, with jinmei extension format, when you put data into database >The problem is that e.g. for site1 the server have multiple interfaces >with different IIDs i.e. there is more than one site-local address for each >site. Thus daemon 2 needs to bind to more than one address > fec0::a00:20ff:fe01:4444%site1 > fec0::a00:21ff:fe08:5555%site1 > fec0::a00:20ff:fe67:3333%site1 > fec0::a00:20ff:fe01:2222%site1 >(assuming there are 4 interfaces to site1). if this is the case, why not run a daemon on an interface? I agree it is dependent to certain application if we can do it or not. >*If* we do the mechanism might need to be something ugly like an environment >variable (e.g. setenv XXX_LIMIT_IPV6_BIND_TO_SITE "site1") that the >bind() library/system call interprets. >Another possible question is: Do we need a mechanism to make it easier for >an application that can be modified to handle the above case with >multiple site-local addresses (due to multiple interfaces) per site? First of all, I believe multi-sited node is extremely rare. *If we do*, I vote for something similar to setsockopt(IPV6_MULTICAST_IF). 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 Mar 1 21:10:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e2259LE27538 for ipng-dist; Wed, 1 Mar 2000 21:09:21 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e2259C927531 for ; Wed, 1 Mar 2000 21:09:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA04984 for ; Wed, 1 Mar 2000 21:09:11 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA12398 for ; Wed, 1 Mar 2000 21:09:12 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 90EC7297; Thu, 2 Mar 2000 00:09:11 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 676BD33C for ; Thu, 2 Mar 2000 00:09:11 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000012850; Thu, 2 Mar 2000 00:09:11 -0500 (EST) From: Jim Bound Message-Id: <200003020509.AAA0000012850@yquarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: zeroconf comment for IPv6 Date: Thu, 02 Mar 2000 00:09:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk implementors, read the zeroconf draft-ietf-zeroconf-reqts-02.txt. this does not require the use of link-local addresses for IPv6. In fact think about it real hard. Any of us could build a complete zeroconf network with the IPv6 we have running today and ship it to the customer FIS with a menu: Please enter: Do you want to do Stateless Addr Conf or Stateful (well DHCPv6 is close and our next drafts should get implementors moving). Please enter: Global or Site-Local address (this could be preconfigured before shipping but not FIS). But could implement this so users would never see link-local addresses and only "names" that appear before their eyes or they could choose the names. This is the kind of stuff we can make money at, profit, greenbacks, revenue, market share, and all that yummy capitalistic stuff so we can become giant fat cats with IPv6 ......Finally a motivation from "greed" of currency :------). People will pay for this stuff... Hey I am motivated big time now... and zeroconf applies to Wireless and Mobile IPv6 too.... yummmy yummmy I can get some money in my tummy :---) I see no reason to discuss this in the IETF as we should all compete for this business and let the best implementor reap the reward, but I am saying this is prime for IPv6, and implementors should take it very seriously if you build small in home systems for customers..... /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 Mar 1 21:35:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e225Xld27588 for ipng-dist; Wed, 1 Mar 2000 21:33:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e225XN927581 for ; Wed, 1 Mar 2000 21:33:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA14599 for ; Wed, 1 Mar 2000 21:32:43 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA18506 for ; Wed, 1 Mar 2000 21:32:42 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id D16E1786; Thu, 2 Mar 2000 00:32:41 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id B07E941F; Thu, 2 Mar 2000 00:32:41 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000015903; Thu, 2 Mar 2000 00:32:41 -0500 (EST) From: Jim Bound Message-Id: <200003020532.AAA0000015903@yquarry.zk3.dec.com> To: Steve Blake Cc: ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of "Mon, 28 Feb 2000 15:40:51 EST." <200002282040.PAA11235@castillo.torrentnet.com> Date: Thu, 02 Mar 2000 00:32:40 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, OK I am done sitting in my corner :---) >> >If the goal is to add an 8-16 bit site id in the site local prefix between >> >FEC0::/10 and FEC0::/48, then why not make it 24 bits? 32 bits? 38 bits? >> >> Thanks for the input we will recall this mail as we proceed. >If it makes sense to make the site id field larger to avoid collisions at >multi-site nodes (and the consequent renumbering), then why not go all the >way and make site ids globally unique? In other words, assign them via >registries, perhaps leaving a large block free for local assignment, and with >site_id == 0 remaining the zeroconf default. There are 38 bits available so >they should not be scarce (given that SOHO networks have no use for anything >other than the site_id == 0 default), and it is likely that they would be inexpensive to lease. > >Put another way, why not add globally unique, stable, portable (and >non-aggregatable) addresses as a formal part of the IPv6 addressing >architecture? And move the special treatment of site-local addresses out >of the forwarding plane and into the configuration and routing protocol >planes? I have thought about this hard. I think 2^^38 + 16bit subnet ID should be more than capable of doing what you say. But it does not meet the req of IPng that an addressing model should support 1 + E15 networks. So I am not sure we can bite that bullet in the addressing architecture. That being said though I can think of no "reasonable" duplication of site-local addresses with 2^^38 + 16bit subnet ID within an organization where site-local addresses are duplicated. Except in cases of a network merger because of business or merger of orgs reasons. In that case a rule can be specified that the network merging into the larger network should renumber to the site it is entering and I still cannot see breaking the 2^^38 capability. In other words treat site-local as global across sites within an organization. This eliminates the nastiness of site-locals completely. But most of all it eliminates the nastiness of any applications having their software architectural paradigm altered in anyway and neither does it affect the APIs for customers and ISVs moving to IPv6 which is a very big deal to any future user of IPv6 I can think of. And the reason it is good we revisit what we have done here yet again. Of course if we can get around the IPng 1 + E15 networks req for site-locals then we can assign them globally. But I don't think we can right now???? Whats your response to this Steve B.? regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 1 21:56:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e225sTT27621 for ipng-dist; Wed, 1 Mar 2000 21:54:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e225sK927614 for ; Wed, 1 Mar 2000 21:54:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA02227 for ; Wed, 1 Mar 2000 21:54:18 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA23896 for ; Wed, 1 Mar 2000 21:54:19 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id A7CB1A44; Thu, 2 Mar 2000 00:54:18 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 8A77B884; Thu, 2 Mar 2000 00:54:18 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000018161; Thu, 2 Mar 2000 00:54:14 -0500 (EST) From: Jim Bound Message-Id: <200003020554.AAA0000018161@yquarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Tue, 29 Feb 2000 12:42:14 +0900." Date: Thu, 02 Mar 2000 00:54:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI, Thoughts? If a customer does not have to duplicate their site-local addresses in their organization with multiple sites. Then the user does not need to know about the site-identifier scope-id for site-local addresses. This is very possible for MOST cases with 2^^38 bits for differentiating a site-local address. In fact even if the org can do this even putting them in the DNS is not a bad thing either as they won't be duplicated. But even with this the mahinery you have defined is applicable to link-local addresses as link-identifiers. I believe we all "think/believe" link-identifiers are unqiue across a node. But we have not stated that in specs I can find? In your opinion do we need to state somewhere in some spec that link-identifiers MUST be unique across a node whether multisited or not? Also I would add if the scope part of fec0::234%site1 (being "site1") if not specified within our API machinery then we assume it is zero which means take the default as you stated. But does your write up need to apply to both site and link identifiers for clarity when used by our Basic APIs for IPv6? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 1 21:59:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e225wBW27643 for ipng-dist; Wed, 1 Mar 2000 21:58:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e225w3927636 for ; Wed, 1 Mar 2000 21:58:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA11549 for ; Wed, 1 Mar 2000 21:58:02 -0800 (PST) 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 VAA24776 for ; Wed, 1 Mar 2000 21:57:57 -0800 (PST) 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 FA19873; Thu, 2 Mar 2000 16:54:22 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Jim Bound Cc: Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-Reply-To: Your message of "Thu, 02 Mar 2000 00:32:40 CDT." <200003020532.AAA0000015903@yquarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Mar 2000 16:54:20 +1100 Message-Id: <17018.951976460@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 02 Mar 2000 00:32:40 -0500 From: Jim Bound Message-ID: <200003020532.AAA0000015903@yquarry.zk3.dec.com> | I have thought about this hard. I think 2^^38 + 16bit subnet ID should | be more than capable of doing what you say. But it does not meet the | req of IPng that an addressing model should support 1 + E15 networks. So | I am not sure we can bite that bullet in the addressing architecture. Hmm - those numbers seem to keep stretching - originally it was 10^12 nodes (see rfc1550), that was increased to 10^15 nodes sometime during the deliberations. Since then it has been expressed as 10^15 networks, and now it has grown to 10^15 sites? I don't think so - 2^32 sites would be just about enough to be able to handle, 2^35 easily enough, and 2^38 would allow enormous amounts of room. That's 30 or so sites for each human on the planet sometime way out in the future (allowing for population explosion beyond ecological limits probably). There's plenty of space in IPv6 site local addressing to stick a globally unique site number (allocated non hierarchically) if that's what the world decides to do, this is not an issue that we need to concern ourselves with. The more I think of it the more I think this might be a sane solution to several problems. Doing this would (at an adminstrative cost for sure) give sites the reasonably permanent identification that has been lacking since we started on forcing renumbering in IPv4 (and which is continued with IPv6 global addresses - for understandable reasons). The existance of a known identifier that you can keep essentially forever just might be a benefit worth the cost (regardless of it not being useful for global routing). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 1 23:31:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e227TYa27726 for ipng-dist; Wed, 1 Mar 2000 23:29:34 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e227T8927719 for ; Wed, 1 Mar 2000 23:29:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA20927 for ; Wed, 1 Mar 2000 23:28:29 -0800 (PST) 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 AAA21040 for ; Thu, 2 Mar 2000 00:28:26 -0700 (MST) 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 QAA00756; Thu, 2 Mar 2000 16:17:37 +0900 (JST) Date: Thu, 02 Mar 2000 16:29:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Thu, 02 Mar 2000 00:54:14 -0500" <200003020554.AAA0000018161@yquarry.zk3.dec.com> References: <200003020554.AAA0000018161@yquarry.zk3.dec.com> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 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: 65 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 02 Mar 2000 00:54:14 -0500, >>>>> Jim Bound said: > If a customer does not have to duplicate their site-local addresses in > their organization with multiple sites. Then the user does not need to > know about the site-identifier scope-id for site-local addresses. This > is very possible for MOST cases with 2^^38 bits for differentiating a > site-local address. In fact even if the org can do this even putting > them in the DNS is not a bad thing either as they won't be duplicated. Right, since this story basically attempts to introduce (a kind of) global uniquness into site-locals. I know this proposal of yours has recently been discussed in the ipng list, and for now would like to watch the discussion. > But even with this the mahinery you have defined is applicable to > link-local addresses as link-identifiers. Yes, and I believe that expert users (e.g. network administrators) sometimes have to deal with link-local addresses while novice users even should not see link-locals, the fact which will be included in our next draft as a background. So I think the machinery is still vital regardless of how we deal with site-locals. > I believe we all > "think/believe" link-identifiers are unqiue across a node. Definitely yes. > But we have > not stated that in specs I can find? In your opinion do we need to > state somewhere in some spec that link-identifiers MUST be unique across > a node whether multisited or not? Hmm, okay, then I'll clearly state that in our next draft. (BTW, did you actually mean "multilinked" by "multisited" in the last line?) > Also I would add if the scope part of fec0::234%site1 (being "site1") if > not specified within our API machinery then we assume it is zero which > means take the default as you stated. Agreed. That's reasonable and should be clearly stated. > But does your write up need to apply to both site and link identifiers > for clarity when used by our Basic APIs for IPv6? For now I'd like to apply the enhancements to the APIs to both site-locals as well as link-locals because 1. currently there's no guarantee that we can define unique identifiers for sites. 2. the enhancements would be able to coexist with such unique identifiers even if we had one. (Although we'd typically just ommit the scope part, e.g. "site1" in the above example, in this case) Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 07:59:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22Fv4r28443 for ipng-dist; Thu, 2 Mar 2000 07:57:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22Fut928436 for ; Thu, 2 Mar 2000 07:56:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA15588 for ; Thu, 2 Mar 2000 07:56:55 -0800 (PST) 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 HAA26908 for ; Thu, 2 Mar 2000 07:56:54 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Mar 2000 07:54:43 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Thu, 2 Mar 2000 07:54:42 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21CCE@RED-MSG-50> From: Richard Draves To: "'JINMEI Tatuya / ????'" , bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: RE: UPDATE rfc2553bis Update for IPv6 Extended address scope Date: Thu, 2 Mar 2000 07:54:32 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I believe we all > > "think/believe" link-identifiers are unqiue across a node. > > Definitely yes. > > > But we have > > not stated that in specs I can find? In your opinion do we need to > > state somewhere in some spec that link-identifiers MUST be > unique across > > a node whether multisited or not? > > Hmm, okay, then I'll clearly state that in our next draft. > (BTW, did you actually mean "multilinked" by "multisited" in the last > line?) Wait a minute, I don't think we've ever agreed that interface ids are unique across a node. It should be possible to have two interfaces with the same link-local address. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 08:33:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22GW2S28492 for ipng-dist; Thu, 2 Mar 2000 08:32:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22GVp928485 for ; Thu, 2 Mar 2000 08:31:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA21234 for ; Thu, 2 Mar 2000 08:31:51 -0800 (PST) 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 JAA22883 for ; Thu, 2 Mar 2000 09:31:49 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id KAA09960; Thu, 2 Mar 2000 10:24:48 -0600 (CST) Message-Id: <200003021624.KAA09960@gungnir.fnal.gov> To: Jim Bound Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: zeroconf comment for IPv6 In-reply-to: Your message of Thu, 02 Mar 2000 00:09:10 EST. <200003020509.AAA0000012850@yquarry.zk3.dec.com> Date: Thu, 02 Mar 2000 10:24:47 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > read the zeroconf draft-ietf-zeroconf-reqts-02.txt. [...] > Any of us could build a complete zeroconf network with > the IPv6 we have running today and ship it to the customer FIS with a > menu: > > Please enter: Do you want to do Stateless Addr Conf or Stateful (well > DHCPv6 is close and our next drafts should get implementors moving). > > Please enter: Global or Site-Local address (this could be > preconfigured before shipping but not FIS). Pardon my effete ivory-tower never-shipped-a-product background, but where I come from, "zero" is the unique additive identity element. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 2 08:40:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22Gd5428518 for ipng-dist; Thu, 2 Mar 2000 08:39:05 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22Gcu928511 for ; Thu, 2 Mar 2000 08:38:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA25537 for ; Thu, 2 Mar 2000 08:38:57 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19676 for ; Thu, 2 Mar 2000 08:38:56 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 610406AC; Thu, 2 Mar 2000 11:38:55 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 3849B767; Thu, 2 Mar 2000 11:38:55 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000019564; Thu, 2 Mar 2000 11:38:54 -0500 (EST) From: Jim Bound Message-Id: <200003021638.LAA0000019564@yquarry.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: Re: zeroconf comment for IPv6 In-reply-to: Your message of "Thu, 02 Mar 2000 10:24:47 CST." <200003021624.KAA09960@gungnir.fnal.gov> Date: Thu, 02 Mar 2000 11:38:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Pardon my effete ivory-tower never-shipped-a-product background, but >where I come from, "zero" is the unique additive identity element. I agree. But the laws of mathematical properties do not apply to users deploying networks. Products should get as close to this identify as possible. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 09:03:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22H1Bu28591 for ipng-dist; Thu, 2 Mar 2000 09:01:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22H13928584 for ; Thu, 2 Mar 2000 09:01:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA29784 for ; Thu, 2 Mar 2000 09:01:03 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02338 for ; Thu, 2 Mar 2000 09:01:02 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id EAC579AF; Thu, 2 Mar 2000 12:01:01 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id AD8F8B96; Thu, 2 Mar 2000 12:01:01 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000009814; Thu, 2 Mar 2000 12:01:00 -0500 (EST) From: Jim Bound Message-Id: <200003021701.MAA0000009814@yquarry.zk3.dec.com> To: Robert Elz Cc: Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of "Thu, 02 Mar 2000 16:54:20 +1100." <17018.951976460@munnari.OZ.AU> Date: Thu, 02 Mar 2000 12:01:00 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | I have thought about this hard. I think 2^^38 + 16bit subnet ID should | be more than capable of doing what you say. But it does not meet the | req of IPng that an addressing model should support 1 + E15 networks. So | I am not sure we can bite that bullet in the addressing architecture. >Hmm - those numbers seem to keep stretching - originally it was 10^12 >nodes (see rfc1550), that was increased to 10^15 nodes sometime during the >deliberations. Since then it has been expressed as 10^15 networks, >and now it has grown to 10^15 sites? Not defending it but asking. I think it sounds like overkill but can't prove it !!! >I don't think so - 2^32 sites would be just about enough to be able to >handle, 2^35 easily enough, and 2^38 would allow enormous amounts of room. >That's 30 or so sites for each human on the planet sometime way out in >the future (allowing for population explosion beyond ecological limits >probably). Seems right to me too. >There's plenty of space in IPv6 site local addressing to stick a globally >unique site number (allocated non hierarchically) if that's what the world >decides to do, this is not an issue that we need to concern ourselves with. I agree. >The more I think of it the more I think this might be a sane solution to >several problems. Doing this would (at an adminstrative cost for sure) >give sites the reasonably permanent identification that has been lacking since >we started on forcing renumbering in IPv4 (and which is continued with IPv6 >global addresses - for understandable reasons). The existance of a known >identifier that you can keep essentially forever just might be a benefit worth >the cost (regardless of it not being useful for global routing). Good point I think to make this happen documenting benefits like this will go a long way with the working group and those who care too. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 09:07:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22H6oL28648 for ipng-dist; Thu, 2 Mar 2000 09:06:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22H6f928641 for ; Thu, 2 Mar 2000 09:06:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA27411 for ; Thu, 2 Mar 2000 09:06:40 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05631 for ; Thu, 2 Mar 2000 09:06:38 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 0548083C; Thu, 2 Mar 2000 12:06:37 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id C35B4169; Thu, 2 Mar 2000 12:06:37 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000010434; Thu, 2 Mar 2000 12:06:37 -0500 (EST) From: Jim Bound Message-Id: <200003021706.MAA0000010434@yquarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Thu, 02 Mar 2000 16:29:10 +0900." Date: Thu, 02 Mar 2000 12:06:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi JINMEI, >> If a customer does not have to duplicate their site-local addresses in >> their organization with multiple sites. Then the user does not need to >> know about the site-identifier scope-id for site-local addresses. This >> is very possible for MOST cases with 2^^38 bits for differentiating a >> site-local address. In fact even if the org can do this even putting >> them in the DNS is not a bad thing either as they won't be duplicated. > >Right, since this story basically attempts to introduce (a kind of) >global uniquness into site-locals. I know this proposal of yours has >recently been discussed in the ipng list, and for now would like to >watch the discussion. OK its not just my proposal and I have two co-authors now and we are doing requirements definition to write up the draft indirectly now. It will take us to May to get out a draft then the discussion will really start. I won't be at IETF 47 in Australia so look forward to the email discussion. I hope by IETF 48 we can discuss our proposal at Pittsburgh meeting and I think we will be able too. >> But even with this the mahinery you have defined is applicable to >> link-local addresses as link-identifiers. >Yes, and I believe that expert users (e.g. network administrators) >sometimes have to deal with link-local addresses while novice users >even should not see link-locals, the fact which will be included in >our next draft as a background. Good. >So I think the machinery is still vital regardless of how we deal with >site-locals. I agree. >> I believe we all >> "think/believe" link-identifiers are unqiue across a node. > >Definitely yes. I agree. >> But we have >> not stated that in specs I can find? In your opinion do we need to >> state somewhere in some spec that link-identifiers MUST be unique across >> a node whether multisited or not? >Hmm, okay, then I'll clearly state that in our next draft. >(BTW, did you actually mean "multilinked" by "multisited" in the last >line?) I meant both actually. But the bottom line is that link-identifiers should be unique across a node even though link-local addresses may be duplicated. thanks /jim > Also I would add if the scope part of fec0::234%site1 (being "site1") if > not specified within our API machinery then we assume it is zero which > means take the default as you stated. Agreed. That's reasonable and should be clearly stated. > But does your write up need to apply to both site and link identifiers > for clarity when used by our Basic APIs for IPv6? For now I'd like to apply the enhancements to the APIs to both site-locals as well as link-locals because 1. currently there's no guarantee that we can define unique identifiers for sites. 2. the enhancements would be able to coexist with such unique identifiers even if we had one. (Although we'd typically just ommit the scope part, e.g. "site1" in the above example, in this case) Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 09:09:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22H7td28663 for ipng-dist; Thu, 2 Mar 2000 09:07:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22H7g928656 for ; Thu, 2 Mar 2000 09:07:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA28814 for ; Thu, 2 Mar 2000 09:07:42 -0800 (PST) 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 JAA06227 for ; Thu, 2 Mar 2000 09:07:40 -0800 (PST) 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 BAA02943; Fri, 3 Mar 2000 01:58:25 +0900 (JST) Date: Fri, 03 Mar 2000 02:09:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: UPDATE rfc2553bis Update for IPv6 Extended address scope In-Reply-To: In your message of "Thu, 2 Mar 2000 07:54:32 -0800 " <4D0A23B3F74DD111ACCD00805F31D8101CA21CCE@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA21CCE@RED-MSG-50> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.5 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: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 2 Mar 2000 07:54:32 -0800 , >>>>> Richard Draves said: >> > I believe we all >> > "think/believe" link-identifiers are unqiue across a node. >> >> Definitely yes. >> >> > But we have >> > not stated that in specs I can find? In your opinion do we need to >> > state somewhere in some spec that link-identifiers MUST be >> unique across >> > a node whether multisited or not? >> >> Hmm, okay, then I'll clearly state that in our next draft. >> (BTW, did you actually mean "multilinked" by "multisited" in the last >> line?) > Wait a minute, I don't think we've ever agreed that interface ids are unique > across a node. It should be possible to have two interfaces with the same > link-local address. ?? I may have misunderstood the Jim's original mail, but what I meant by "link-identifiers" was (for example) the part of our extended format for a link-local addresses, not the "interface ID (i.e. the lower 64bits)" of the addresses. Yes, this is a kind of tautology, thus I used the word "Definitely". As for the uniqueness of "interface IDs", I completely agree with you (unless the two interfaces belong to a same link), of course. Or...did I miss something important? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 09:15:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22HDJE28704 for ipng-dist; Thu, 2 Mar 2000 09:13:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22HDA928697 for ; Thu, 2 Mar 2000 09:13:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02081 for ; Thu, 2 Mar 2000 09:13:10 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09228 for ; Thu, 2 Mar 2000 09:13:09 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 5CDB760D; Thu, 2 Mar 2000 12:13:09 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 19B12410; Thu, 2 Mar 2000 12:13:09 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000011712; Thu, 2 Mar 2000 12:13:08 -0500 (EST) From: Jim Bound Message-Id: <200003021713.MAA0000011712@yquarry.zk3.dec.com> To: Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Thu, 02 Mar 2000 07:54:32 PST." <4D0A23B3F74DD111ACCD00805F31D8101CA21CCE@RED-MSG-50> Date: Thu, 02 Mar 2000 12:13:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >> > I believe we all >> > "think/believe" link-identifiers are unqiue across a node. >> >> Definitely yes. >> >> > But we have >> > not stated that in specs I can find? In your opinion do we need to >> > state somewhere in some spec that link-identifiers MUST be >> unique across >> > a node whether multisited or not? >> >> Hmm, okay, then I'll clearly state that in our next draft. >> (BTW, did you actually mean "multilinked" by "multisited" in the last >> line?) >Wait a minute, I don't think we've ever agreed that interface ids are unique >across a node. It should be possible to have two interfaces with the same >link-local address. Thats why I brought it up. Yes you can have two intefaces with the same link-local address, but not on the same link. The issue is not the link-local address but the identifer for the interface we have been discussiong le0, le1, tu0, ewa1, etc... /jim Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 10:24:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22IMQX28873 for ipng-dist; Thu, 2 Mar 2000 10:22:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22IMG928861 for ; Thu, 2 Mar 2000 10:22:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA14330 for ; Thu, 2 Mar 2000 10:22:16 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18944 for ; Thu, 2 Mar 2000 10:22:15 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id C2A92CB1; Thu, 2 Mar 2000 13:22:12 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 96FC4316; Thu, 2 Mar 2000 13:22:12 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000027362; Thu, 2 Mar 2000 13:21:58 -0500 (EST) From: Jim Bound Message-Id: <200003021821.NAA0000027362@yquarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: josee_auber@grenoble.hp.com, c.harding@opengroup.org, bound@zk3.dec.com Subject: IEEE/XNS Status for getaddrinfo and rfc2553 Date: Thu, 02 Mar 2000 13:21:58 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I had a con call today with Chris Harding and Andrew Josee from the Open Group Networking Services team. Here is the story. The IEEE P1003 Working Group (aka Austin Group) is the formal dejure ISO body who will put forth the XNS 5.2+ enhancments internationally for the networking set of APIs like they did with other POSIX APIs. In fact the IEEE owns the copyright to getaddrinfo(). The IEEE Austin Group is working with XNS via Andrew over the next 12 months to update the networking set of APIs see: http://www.opengroup.org/austin/ But XNS believes the work on the APIs should be done by the experts working on the APIs, which is on this list. So we can proceed to update rfc2553bis and continue to reference the IEEE for getaddrinfo(), within some limitations (see last paragraph). My hope is we wrap up the API discussion in the next two weeks on this list and we will put out a next draft no later than mid-April. We must stay within the bounds of networking for rfc2553bis and not enter areas such as intra-node communications such as AF_UNIX, or begin to specify the behavior of datatypes to getaddrinfo but treat as much as possible the arguments and datatypes as opaque, where it is not within our domain or list expertise. If you want to work on the UNIX affect and inners of UNIX system space or on the generic space for which ISO will be concerned to ratify an ISO standard ballot then go join IEEE 1003 committee. You must be an IEEE member to vote on this if you don't know when it happens. 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 Thu Mar 2 10:45:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22Ii7g28971 for ipng-dist; Thu, 2 Mar 2000 10:44:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22Ihx928964 for ; Thu, 2 Mar 2000 10:43:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA21336 for ; Thu, 2 Mar 2000 10:43:58 -0800 (PST) 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 KAA01507 for ; Thu, 2 Mar 2000 10:43:56 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Mar 2000 10:41:46 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Thu, 2 Mar 2000 10:41:45 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21CD6@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" , "'JINMEI Tatuya / ????'" Cc: ipng@sunroof.eng.sun.com Subject: RE: UPDATE rfc2553bis Update for IPv6 Extended address scope Date: Thu, 2 Mar 2000 10:41:42 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Thats why I brought it up. Yes you can have two intefaces > with the same > link-local address, but not on the same link. The issue is not the > link-local address but the identifer for the interface we have been > discussiong le0, le1, tu0, ewa1, etc... OK, I was just confused by the term "link-identifier". Btw, when getnameinfo is called with NI_NUMERICHOST, I assume it should return both the address and the scope-id in numeric form? Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 13:11:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22LA2N29630 for ipng-dist; Thu, 2 Mar 2000 13:10:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22L8J929587; Thu, 2 Mar 2000 13:08:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA18174; Thu, 2 Mar 2000 13:08:12 -0800 (PST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02715; Thu, 2 Mar 2000 14:08:12 -0700 (MST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id NAA14664; Thu, 2 Mar 2000 13:06:07 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id NAA28582; Thu, 2 Mar 2000 13:06:07 -0800 (PST) Received: from cyndi (lan-isdn-cmj3.nsd.3com.com [129.213.207.235]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id NAA05540; Thu, 2 Mar 2000 13:04:36 -0800 (PST) Message-Id: <3.0.6.32.20000302131104.008ef6e0@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 02 Mar 2000 13:11:04 -0800 To: 6bone@isi.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, deployment@ipv6.org From: Cyndi Jung Subject: Global IPv6 Summit: Members' code Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e22L8L929588 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is still time to register for this Summit. The code below will give you the early registration rate. Also, the website will give you additional options on lodging - there are still places to stay with reasonable rates. The Telluride Conference Center is not in a hotel - so the entire Town of Telluride (all 10 by 4 blocks) is available for lodging. Thanks, Cyndi >Subject: Global IPv6 Summit: Members' code >Sender: owner-members@ipv6forum.com >X-MIME-Autoconverted: from quoted-printable to 8bit by chicago.nsd.3com.com id QAA02362 > >Hello Folks, > >For those of you planning to attend the Global IPv6 Summit in a few weeks, >here is a registration code "AEKG". Using this code when you register will >give you a price of $695 vs $895. > >Please register soon at: > > >Here is an email that IPv6 Forum Members should feel free to pass around to >company employees, partners and other appropriate persons. > >Thanks, >Marty > > >------------------ >Global IPv6 Summit - >------------------ >When: March 13-16 >Where: Telluride, Colorado USA > >Judy Estrin, Cisco's CTO is the opening keynote for the Global IPv6 Summit. > >The Global IPv6 Summit is the industry's gathering on IPv6 adoption, >innovation and opportunity. The conference, workshops and IPv6 Forum >meetings are March 13-16, 2000 in the beautiful resort town of Telluride, >Colorado USA at the conference center in Mountain Village. > >In this intimate setting (space is limited to 200 people) you will be able >to pose questions and debate with the leaders in this technology. Register >today for only $895 at http://www.stardust.com/ipv6summit/ > >At the summit we will focus on the deployments of IPv6 around the world, >explore why wireless and home networking technology demands IPv6, and >examine how IPv6 is presenting opportunities for application vendors, >service providers, content providers and enterprise network engineers. > >Sessions will focus on >---------------------- >- The Coming Tidal Wave of Applications >- The Industry's Roadmap >- "IPv6-Ready" Platforms and Routers >- IPv6 Around the World >- ISP Commercial Deployment >- IPv6 Customers >- IPv6 Standards >- IPv6 Forum Meetings > >Who should attend? We expect the mix of summit attendees to include CEO's, >CIO's, CTO's, network engineers, architects, developers, scientists, >researchers, network managers and others who are responsible for networks >and network technology. Attendance is limited to 200 people. > >Featured Keynote >---------------- >The New Internet presented by Judy Estrin, CTO of Cisco Systems > >The promise of the New Internet is communications ubiquity; our appliances, >networks, electronic equipment, cars and even clothes will communicate with >us and with each other. But IPv6 is required for us to realize the full >potential of the global network. > >Judy Estrin is Chief Technology Officer and Senior Vice President at Cisco >Systems. She is responsible for strategic technology planning and business >development including investments and acquisitions, consulting engineering >and advanced Internet projects, as well as legal and government affairs. > >Speakers will Represent >----------------------- >@Home, 3Com, Advanced Systems Consulting, Cisco Systems, Compaq, >Ericsson-Telebit, InfiniBand Trade Association, Internet-Standard.com, MCI >WorldCom, Microsoft, NetworkWorld, Nokia, Nortel Networks, NTT, Sun, Telia, >Thomson-CSF, UCAID, UMTS Forum, UNAM, US Navy, and Viagénie. > >Sponsors >-------- >The Global IPv6 Summit is graciously sponsored by 3Com, Cisco, Compaq, >Microsoft, Motorola, Nokia, Nortel Networks, Qwest, Sun Microsystems and >Teleglobe. Viagénie is sponsoring a free IPv6 tutorial on March 13th for >registered summit attendees. > > >Please email Sherryl Alameda or call with any >questions at (408)879-8080. > > > >--- >Marty Bickford - 408.879.8080 (8081-fax) >Stardust.com - http://www.stardust.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 Mar 2 17:43:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e231fSh00539 for ipng-dist; Thu, 2 Mar 2000 17:41:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e231en900532 for ; Thu, 2 Mar 2000 17:40:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA17125 for ; Thu, 2 Mar 2000 17:40:04 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA15281 for ; Thu, 2 Mar 2000 18:40:04 -0700 (MST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 72B87883; Thu, 2 Mar 2000 20:40:03 -0500 (EST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 483D1ABF; Thu, 2 Mar 2000 20:40:03 -0500 (EST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000027627; Thu, 2 Mar 2000 20:40:02 -0500 (EST) From: Jim Bound Message-Id: <200003030140.UAA0000027627@yquarry.zk3.dec.com> To: Richard Draves Cc: "'Jim Bound'" , "'JINMEI Tatuya / ????'" , ipng@sunroof.eng.sun.com Subject: Re: UPDATE rfc2553bis Update for IPv6 Extended address scope In-reply-to: Your message of "Thu, 02 Mar 2000 10:41:42 PST." <4D0A23B3F74DD111ACCD00805F31D8101CA21CD6@RED-MSG-50> Date: Thu, 02 Mar 2000 20:40:02 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Btw, when getnameinfo is called with NI_NUMERICHOST, I assume it should >return both the address and the scope-id in numeric form? I think that is correct but unclear what one will do with it? Could of just called getaddrinfo in the first place? oh well... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 17:51:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e231nmr00568 for ipng-dist; Thu, 2 Mar 2000 17:49:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e231ne900561 for ; Thu, 2 Mar 2000 17:49:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA05622 for ; Thu, 2 Mar 2000 17:49:39 -0800 (PST) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19177 for ; Thu, 2 Mar 2000 18:49:39 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA04237 for <@external-mail-relay.sgi.com:ipng@sunroof.Eng.Sun.COM>; Thu, 2 Mar 2000 17:52:48 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [163.154.34.36]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA53955 for ; Thu, 2 Mar 2000 17:49:37 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (SGI-SGI-8.9.3/8.9.3) id RAA23636 for ipng@sunroof.Eng.Sun.COM; Thu, 2 Mar 2000 17:50:50 -0800 (PST) From: Sam Manthorpe Message-Id: <200003030150.RAA23636@bossette.engr.sgi.com> Subject: foglamps BOF and mailing list (fwd) To: ipng@sunroof.eng.sun.com Date: Thu, 2 Mar 2000 17:50:49 -0800 (PST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For those who aren't on end2end-interest: Forwarded message: > From end2end-interest-owner@isi.edu Thu Mar 2 17:37:52 2000 > From: Melinda.Shore@nokia.com > Message-ID: > To: ietf@ietf.org, end2end-interest@isi.edu, nat@livingston.com > Cc: tiphon@list.etsi.fr > Subject: foglamps BOF and mailing list > Date: Thu, 2 Mar 2000 17:30:51 -0600 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2448.0) > Content-Type: text/plain; > charset="iso-8859-1" > Sender: owner-end2end-interest@isi.edu > Precedence: bulk > > It has been recognized for some time that breaking > the end-to-end model through the introduction of elements > like network address translators causes serious problems > in IP networks, and the IETF has had ongoing discussions > of those problems with an eye towards solving them. What > is probably not fully appreciated, however, is the extent > to which NAT and firewall-related problems are interfering > with the deployment of major applications, such as the > migration from circuit-based to packet-based telecommunications > networks. Some of us are beginning to suspect that it may > be time to bite the bullet and make certain network elements > visible to applications by creating explicit external interfaces. > > To that end, we've requested a BOF session ("foglamps") for > the upcoming meeting in Adelaide, and have created a foglamps > mailing list on egroups.com (sorry). To subscribe, send > email to foglamps-subscribe@egroups.com or use the web-based > interface at http://www.egroups.com. > > Background reading would include: > draft-lear-foglamps-01.txt > draft-shore-h323-firewalls-00.txt > draft-rosenberg-sip-firewalls-00.txt > RFC 2775 > draft-iab-ntwlyrws-over-02.txt > > I'll send along an agenda as soon as it's finalized. > > Melinda > -- > Melinda Shore > Nokia IP Telephony > 127 West State Street "Software longa, > Ithaca, NY 14850 hardware brevis" > +1 607 273 0724 (office) > +1 607 275 3610 (fax) > +1 607 227 4096 (mobile) > melinda.shore@nokia.com > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI, Core Protocols -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 2 18:03:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e2321rC00622 for ipng-dist; Thu, 2 Mar 2000 18:01:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e2321i900615 for ; Thu, 2 Mar 2000 18:01:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA07279 for ; Thu, 2 Mar 2000 18:01:44 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA17678 for ; Thu, 2 Mar 2000 18:01:44 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 3FE73104BFA; Thu, 2 Mar 2000 20:01:44 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 37A41FB101; Thu, 2 Mar 2000 20:01:44 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 03C02BC4CB; Thu, 2 Mar 2000 20:01:27 -0600 (CST) Received: from yquarry.zk3.dec.com (yquarry.zk3.dec.com [16.140.16.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 8FC4DB2A64; Thu, 2 Mar 2000 20:01:27 -0600 (CST) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000030523; Thu, 2 Mar 2000 21:01:33 -0500 (EST) From: Jim Bound Message-Id: <200003030201.VAA0000030523@yquarry.zk3.dec.com> To: Sam Manthorpe Cc: ipng@sunroof.eng.sun.com Subject: Re: foglamps BOF and mailing list (fwd) In-reply-to: Your message of "Thu, 02 Mar 2000 17:50:49 PST." <200003030150.RAA23636@bossette.engr.sgi.com> Date: Thu, 02 Mar 2000 21:01:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk yeah I saw this on the nat list too. guess I have to go read this stuff too. oh well.......... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 2 20:30:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e234T9P00776 for ipng-dist; Thu, 2 Mar 2000 20:29:09 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e234T1900769 for ; Thu, 2 Mar 2000 20:29:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA29809 for ; Thu, 2 Mar 2000 20:28:59 -0800 (PST) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA04949 for ; Thu, 2 Mar 2000 20:28:59 -0800 (PST) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id XAA07987; Thu, 2 Mar 2000 23:27:17 -0500 (EST) Message-Id: <200003030427.XAA07987@castillo.torrentnet.com> To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Another way to support Site-Local Addresses In-reply-to: Your message of "Thu, 02 Mar 2000 00:32:40 EST." <200003020532.AAA0000015903@yquarry.zk3.dec.com> Date: Thu, 02 Mar 2000 23:27:17 -0500 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > I have thought about this hard. I think 2^^38 + 16bit subnet ID should > be more than capable of doing what you say. But it does not meet the > req of IPng that an addressing model should support 1 + E15 networks. So > I am not sure we can bite that bullet in the addressing architecture. > > That being said though I can think of no "reasonable" duplication of > site-local addresses with 2^^38 + 16bit subnet ID within an organization > where site-local addresses are duplicated. Except in cases of a network > merger because of business or merger of orgs reasons. In that case a > rule can be specified that the network merging into the larger network > should renumber to the site it is entering and I still cannot see > breaking the 2^^38 capability. > > In other words treat site-local as global across sites within an > organization. This eliminates the nastiness of site-locals completely. > But most of all it eliminates the nastiness of any applications having > their software architectural paradigm altered in anyway and neither does > it affect the APIs for customers and ISVs moving to IPv6 which is a very > big deal to any future user of IPv6 I can think of. And the reason it > is good we revisit what we have done here yet again. > > Of course if we can get around the IPng 1 + E15 networks req for > site-locals then we can assign them globally. But I don't think we can > right now???? > > Whats your response to this Steve B.? I don't thing all site ids must be globally unique. Allocating locally assigned site ids randomly out of a >= 32 bit range should reduce the probability of collision in the scenario you describe above below what anyone would reasonably care about. I do think there are a couple of scenarios where truly globally unique site ids would be useful. One involves communication among a set of sites (ex/ extranet partners) where stable addresses are desired so that TCP sessions can survive upstream provider renumbering, for instance. The sites could build a topology over a tunnel mesh, and any TCP session would survive provider renumbering as long as new tunnels came up before the sessions timed out. Alternatively, the sites could negotiate for the provider to route the site local prefixes directly. The other scenario is Fortune 500 multihoming. In this case the site local is essentially a portable prefix routed globally. Routing portable addresses doesn't scale so this would be limited to those customers willing to $pay$. If your proposal goes forward, I would suggest that you consider setting aside a large site id block that could be used someday for global assignment. Let the market decide whether these will ever be allocated. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 2 21:19:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e235I6O00905 for ipng-dist; Thu, 2 Mar 2000 21:18:06 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e235I2900898 for ; Thu, 2 Mar 2000 21:18:02 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id VAA14072 for ipng@sunroof.eng.sun.com; Thu, 2 Mar 2000 21:16:17 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e233tM900747 for ; Thu, 2 Mar 2000 19:55:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA19370 for ; Thu, 2 Mar 2000 19:55:21 -0800 (PST) Received: from prserv.net (out5.prserv.net [32.97.166.35]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24350 for ; Thu, 2 Mar 2000 19:55:21 -0800 (PST) Received: from joplin ([129.37.20.140]) by prserv.net (out5) with SMTP id <2000030303551324302jo2k8e>; Fri, 3 Mar 2000 03:55:16 +0000 Message-Id: Message-Id: X-Sender: micke@baskerville.cs.arizona.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 03 Mar 2000 04:48:22 +0100 To: Carl Williams From: Mikael Degermark Subject: Re: IPv6 Wireless and Mobility Roundtable Cc: ipng@sunroof.eng.sun.com, carlw@eng.sun.com, micke@cs.arizona.edu In-Reply-To: <200002290439.UAA04284@audeen.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Carl, As co-chair of the soon-to-be formed ROHC WG (Robust header compression WG) I feel that you should add the following piece of information to the announcement. At 08:39 PM 2/28/00 -0800, Carl Williams wrote: >IPv6 Wireless and Mobility Roundtable >===================================== ... >- The IPv6 header is twice as large as its IPv4 counterpart, > but routers should have a much easier time processing and > forwarding packets. Don't forget that the IPv6 header is simpler to compress. The size of the average compressed IPv6 header will be smaller than the corresponding IPv4 header (although the difference is not large). So the cost of using IPv6 over the air links will be somewhat less than when using IPv4. Cheers, Micke -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 3 02:14:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e23ADGf01501 for ipng-dist; Fri, 3 Mar 2000 02:13:16 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e23AD4901494 for ; Fri, 3 Mar 2000 02:13:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA10147 for ; Fri, 3 Mar 2000 02:13:03 -0800 (PST) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA17793 for ; Fri, 3 Mar 2000 03:13:03 -0700 (MST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AF44@monza.broadswitch.com> From: Thomas Eklund To: "'Sam Manthorpe'" , ipng@sunroof.eng.sun.com Subject: RE: foglamps BOF and mailing list (fwd) Date: Fri, 3 Mar 2000 11:12:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry if I dont understand but isn't end-2-end == IPv6 ?? /Thomas > -----Original Message----- > From: Sam Manthorpe [mailto:sm@bossette.engr.sgi.com] > Sent: Friday, March 03, 2000 2:51 AM > To: ipng@sunroof.eng.sun.com > Subject: foglamps BOF and mailing list (fwd) > > > > For those who aren't on end2end-interest: > > Forwarded message: > > From end2end-interest-owner@isi.edu Thu Mar 2 17:37:52 2000 > > From: Melinda.Shore@nokia.com > > Message-ID: > > To: ietf@ietf.org, end2end-interest@isi.edu, nat@livingston.com > > Cc: tiphon@list.etsi.fr > > Subject: foglamps BOF and mailing list > > Date: Thu, 2 Mar 2000 17:30:51 -0600 > > MIME-Version: 1.0 > > X-Mailer: Internet Mail Service (5.5.2448.0) > > Content-Type: text/plain; > > charset="iso-8859-1" > > Sender: owner-end2end-interest@isi.edu > > Precedence: bulk > > > > It has been recognized for some time that breaking > > the end-to-end model through the introduction of elements > > like network address translators causes serious problems > > in IP networks, and the IETF has had ongoing discussions > > of those problems with an eye towards solving them. What > > is probably not fully appreciated, however, is the extent > > to which NAT and firewall-related problems are interfering > > with the deployment of major applications, such as the > > migration from circuit-based to packet-based telecommunications > > networks. Some of us are beginning to suspect that it may > > be time to bite the bullet and make certain network elements > > visible to applications by creating explicit external interfaces. > > > > To that end, we've requested a BOF session ("foglamps") for > > the upcoming meeting in Adelaide, and have created a foglamps > > mailing list on egroups.com (sorry). To subscribe, send > > email to foglamps-subscribe@egroups.com or use the web-based > > interface at http://www.egroups.com. > > > > Background reading would include: > > draft-lear-foglamps-01.txt > > draft-shore-h323-firewalls-00.txt > > draft-rosenberg-sip-firewalls-00.txt > > RFC 2775 > > draft-iab-ntwlyrws-over-02.txt > > > > I'll send along an agenda as soon as it's finalized. > > > > Melinda > > -- > > Melinda Shore > > Nokia IP Telephony > > 127 West State Street "Software longa, > > Ithaca, NY 14850 hardware brevis" > > +1 607 273 0724 (office) > > +1 607 275 3610 (fax) > > +1 607 227 4096 (mobile) > > melinda.shore@nokia.com > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Sam Manthorpe, SGI, Core Protocols > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 3 02:31:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e23AUDa01520 for ipng-dist; Fri, 3 Mar 2000 02:30:13 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e23ATW901513 for ; Fri, 3 Mar 2000 02:29:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA25755 for ; Fri, 3 Mar 2000 02:28:52 -0800 (PST) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22855 for ; Fri, 3 Mar 2000 03:28:51 -0700 (MST) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD15AF45@monza.broadswitch.com> From: Thomas Eklund To: "'Steve Blake'" , Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: RE: Another way to support Site-Local Addresses Date: Fri, 3 Mar 2000 11:28:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just keep in mind that in the future a cellphone will probably be a mobile IPv6 router with bluetooth link so all the other devices connects via the phone over bluetooth to the Internet and they want an IP address for their interfaces on the bluetooth device like a palm pilot... Because if you have proxy functinality in the phone then it will probably be to big... In other word if the mobile phone/router autoconfigures it neigbouring devices it needs at least 1 bit for the router advertisements... And bluetooth is master/slave based so it fits the ND model very good...:-) Just a reminder if people start assigning site local addresses from the global addrresses /Thomas > -----Original Message----- > From: Steve Blake [mailto:slblake@torrentnet.com] > Sent: Friday, March 03, 2000 5:27 AM > To: Jim Bound > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Another way to support Site-Local Addresses > > > > Jim Bound wrote: > > > I have thought about this hard. I think 2^^38 + 16bit > subnet ID should > > be more than capable of doing what you say. But it does > not meet the > > req of IPng that an addressing model should support 1 + E15 > networks. So > > I am not sure we can bite that bullet in the addressing > architecture. > > > > That being said though I can think of no "reasonable" duplication of > > site-local addresses with 2^^38 + 16bit subnet ID within an > organization > > where site-local addresses are duplicated. Except in cases > of a network > > merger because of business or merger of orgs reasons. In > that case a > > rule can be specified that the network merging into the > larger network > > should renumber to the site it is entering and I still cannot see > > breaking the 2^^38 capability. > > > > In other words treat site-local as global across sites within an > > organization. This eliminates the nastiness of site-locals > completely. > > But most of all it eliminates the nastiness of any > applications having > > their software architectural paradigm altered in anyway and > neither does > > it affect the APIs for customers and ISVs moving to IPv6 > which is a very > > big deal to any future user of IPv6 I can think of. And > the reason it > > is good we revisit what we have done here yet again. > > > > Of course if we can get around the IPng 1 + E15 networks req for > > site-locals then we can assign them globally. But I don't > think we can > > right now???? > > > > Whats your response to this Steve B.? > I don't thing all site ids must be globally unique. > Allocating locally > assigned site ids randomly out of a >= 32 bit range should reduce the > probability of collision in the scenario you describe above below what > anyone would reasonably care about. > > I do think there are a couple of scenarios where truly globally unique > site ids would be useful. One involves communication among a set of > sites (ex/ extranet partners) where stable addresses are desired so > that TCP sessions can survive upstream provider renumbering, > for instance. > The sites could build a topology over a tunnel mesh, and any > TCP session > would survive provider renumbering as long as new tunnels > came up before > the sessions timed out. > negotiate for the > provider to route the site local prefixes directly. > > The other scenario is Fortune 500 multihoming. In this case the site > local is essentially a portable prefix routed globally. > Routing portable > addresses doesn't scale so this would be limited to those > customers willing > to $pay$. > > If your proposal goes forward, I would suggest that you > consider setting > aside a large site id block that could be used someday for global > assignment. Let the market decide whether these will ever be > allocated. > > > Regards, > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven L. Blake > Ericsson IP Infrastructure (919)472-9913 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 3 14:06:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e23M5L901995 for ipng-dist; Fri, 3 Mar 2000 14:05:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e23M5C901988 for ; Fri, 3 Mar 2000 14:05:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA10848 for ; Fri, 3 Mar 2000 14:05:11 -0800 (PST) Received: from mante02.nam.dow.com (mail1.dow.com [216.99.65.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18412 for ; Fri, 3 Mar 2000 14:05:10 -0800 (PST) Received: by mante02.nam.dow.com with Internet Mail Service (5.5.2448.0) id ; Fri, 3 Mar 2000 17:05:09 -0500 Message-ID: From: "Stankevitz, Christian (CT)" To: "'Norihiro Ishikawa'" , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: RE: Is IPv6 died ? Date: Fri, 3 Mar 2000 17:05:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I seem to recall a discussion in the past about IPv6 and the problem of address space. Is IPv6 really just a large scale research project and what is the status of IPv8 from a future implementation point of view to solve the Internet addressing issues? I have included the original IPv8 posting in this message. Christian Stankevitz -----Original Message----- From: Norihiro Ishikawa [mailto:ishikawa@mml.yrp.nttdocomo.co.jp] Sent: Tuesday, February 15, 2000 12:52 AM To: Thomas Narten Cc: Jim Bound; ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? Since I am not involved in any IP work, my position is fairly neutral. But, considering the ongoing discussion, the more realistic approach is to extend IPv4 for fixing "lack of globally unique addresses" problem. Considering the ultimate deployment of IPv4, the solution should be compatible with IPv4 as much as possible. Since I am not an IP expert, I am not sure whether this approach is feasible or not. I understand the technical merit of IPv6. But, to deploy IPv6, the business and operational merit is more important. To discuss this issue, it seems to me that a neutral forum in IETF is needed, with the excellent guidance of IAB. Any comments ? Norihiro Ishikawa At 11:35 AM -0500 00.2.14, Thomas Narten wrote: > Jim, > > Couple of observations. > > The IETF has rough consensus on the selection of IPv6. Rough does not > mean unanimous, nor does it mean that the detractors will necessarily > be silent. We all know that in the end, the market will determine what > happens here. The official IETF stance certainly has some influence > here, but it is limited and by no means definitive. Vendors tend to > act based on business cases. > > Most, if not all of the detractors, seem to have fault with specifics > of IPv6 itself, but that doesn't mean they have an alternative that is > any more widely accepted. > >> Lastly I don't understand why very bright folks who know routing very >> well like Yakov don't put their engineer hats on and help make routing >> work with IPv6. > > Folks that say routing doesn't work with IPv6 are of course being > dishonest. What some folks are saying is that routing in IPv6 (longest > match with provider-based aggregation) is fundamentally the same as in > IPv4/CIDR (and this is correct). Thus, the argument goes, why bother > with IPv6. Of course, that is a strawman argument. We should keep in > mind: > > - IPv6 wasn't designed to "fix the routing problem", despite what many > folks wish. It actually fixes the "lack of globally unique > addresses" problem. Plus, it has other benefits. > > - Although IPv6 may not "fix" the routing problem, there is good > reason to believe it will result in smaller tables than will result > with continued use of IPv4 because of: > - increased ease of end-site renumbering (if more renumbering > takes place, fewer instances of broken aggregation) > - more aggressive aggregation from the start (no legacy assignments > to deal with) > - a multihoming model based on multiple per-host prefixes > (prefixes for multihomed sites are not advertised as exceptions > to achieve multihoming) > > Finally, the IETF is always willing to look at new approaches to > existing problems. Whether a new approach merits serious work in the > IETF depends on the cost/benefit when weighed against the existing > solutions. So certainly, if a credible alternative to IPv6 was brought > up for consideration, the IETF would look at it. We would be foolish > not to. However, this is no different than with any other protocol in > the IETF. > > 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 > -------------------------------------------------------------------- ************************************************************************ -----Original Message----- From: Jeff Williams [mailto:jwkckid1@ix.netcom.com] Sent: Saturday, October 02, 1999 5:18 PM To: Volsinians@aol.com Cc: s_egilstad@hotmail.com; ipng@sunroof.eng.sun.com Subject: Re: IPv6 and business effect Susanne and all, I would tend to agree with this assessment, but I am sure that the IETF and ICANN would not. IPv8 is currently in deployment now, which we feel is a marked improvement over IPv6 in many ways. Susanne, if you would like some additional info here please feel free to contact me offline, or call (See sig file below) Volsinians@aol.com wrote: > In a message dated 10/2/99 11:41:58 PM Eastern Daylight Time, > s_egilstad@hotmail.com writes: > > > can someone please help me with some links or information on what effect > > IPv6 will have on business today. > > > Since IPv6 will probably never be generally deployed, it will > probably have about the same effect on business that MAP > had. > > Joachim Martillo > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 3 14:39:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e23McEf02036 for ipng-dist; Fri, 3 Mar 2000 14:38:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e23Mc5902029 for ; Fri, 3 Mar 2000 14:38:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA09255 for ; Fri, 3 Mar 2000 14:38:05 -0800 (PST) Received: from europe.std.com (europe.std.com [199.172.62.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20077 for ; Fri, 3 Mar 2000 15:38:05 -0700 (MST) Received: from world.std.com (qqi@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id RAA25032; Fri, 3 Mar 2000 17:38:04 -0500 (EST) Received: from localhost (qqi@localhost) by world.std.com (8.9.3/8.9.3) with SMTP id RAA12165; Fri, 3 Mar 2000 17:38:03 -0500 (EST) Date: Fri, 3 Mar 2000 17:38:03 -0500 (EST) From: Quality Quorum To: "Stankevitz, Christian (CT)" cc: "'Norihiro Ishikawa'" , Thomas Narten , ipng@sunroof.eng.sun.com Subject: RE: Is IPv6 died ? 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, 3 Mar 2000, Stankevitz, Christian (CT) wrote: > I seem to recall a discussion in the past about IPv6 and the problem of > address space. Is IPv6 really just a large scale research project and what > is the status of IPv8 from a future implementation point of view to solve > the Internet addressing issues? I have included the original IPv8 posting > in this message. It seems that this topic did not died yet, so I will ask a simple non-technical question which bothers me for a long time. Are all these people plane stupid: 1. Ones who are buying every year a few billion$ worth of network equipment 50% which would never be able to forward IPv6 ? 2. Ones who are paying billion$ to buy manufactures of these boxes ? > Christian Stankevitz Thanks, Aleksey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 11:49:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e24JlVY02457 for ipng-dist; Sat, 4 Mar 2000 11:47:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e24JlL902450 for ; Sat, 4 Mar 2000 11:47:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA05980 for ; Sat, 4 Mar 2000 11:47:20 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24778 for ; Sat, 4 Mar 2000 12:47:20 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id OAA25090; Sat, 4 Mar 2000 14:38:16 -0500 (EST) Date: Sat, 4 Mar 2000 14:38:16 -0500 (EST) From: Scott Bradner Message-Id: <200003041938.OAA25090@newdev.harvard.edu> To: bound@zk3.dec.com, kre@munnari.OZ.AU Subject: Re: Another way to support Site-Local Addresses Cc: ipng@sunroof.eng.sun.com, slblake@torrentnet.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hmm - those numbers seem to keep stretching - originally it was 10^12 >nodes (see rfc1550), that was increased to 10^15 nodes sometime during the >deliberations. Since then it has been expressed as 10^15 networks, >and now it has grown to 10^15 sites? from RFC 1726 5.1 Scale CRITERION The IPng Protocol must scale to allow the identification and addressing of at least 10**12 end systems (and preferably much more). The IPng Protocol, and its associated routing protocols and architecture must allow for at least 10**9 individual networks (and preferably more). The routing schemes must scale at a rate that is less than the square root of the number of constituent networks [10]. . . . We note that one of the white papers solicited for the IPng process [5] indicates that 10**12 end nodes is a reasonable estimate based on the expected number of homes in the world and adding two orders of magnitude for "safety". However, this white paper treats each home in the world as an end-node of a world-wide Internet. We believe that each home in the world will in fact be a network of the world-wide Internet. Therefore, if we take [5]'s derivation of 10**12 as accurate, and change their assumption that a home will be an end-node to a home being a network, we may expect that there will be the need to support at least 10**12 networks, with the possibility of supporting up to 10**15 end- nodes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 13:03:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e25L17203113 for ipng-dist; Sun, 5 Mar 2000 13:01:07 -0800 (PST) Received: from antley.eng.sun.com (antley [129.146.86.225]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e25L0u903105 for ; Sun, 5 Mar 2000 13:00:56 -0800 (PST) Received: from antley (antley [129.146.86.225]) by antley.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA08554; Sun, 5 Mar 2000 13:00:39 -0800 (PST) Message-Id: <200003052100.NAA08554@antley.eng.sun.com> Date: Sun, 5 Mar 2000 13:00:39 -0800 (PST) From: Carl Williams Reply-To: Carl Williams Subject: Reminder: San Jose -- IPv6 Wireless and Mobility Roundtable To: ipng@sunroof.eng.sun.com, tech@ipv6forum.com Cc: carlw@antley.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: a3+taz0cVb2Ak5Qo04Nd5A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reminder: The IPv6 wireless and mobility roundtable is this Monday from 4:00pm-6:00pm at the Crowne Plaza Hotel in downtown San Jose, CA. This event is open to everyone. No need to register. Please drop by to what will be an interesting discussion! See you then... Carl Details below: IPv6 Wireless and Mobility Roundtable ===================================== Connectathon 2000 is presenting a roundtable discussion on IPv6 Wireless and Mobility as part of the interoperability testing event this year. The roundtable is being cosponsored with the IPv6 Forum. The panel will contain key individuals leading the standards, research and/or implementation efforts in IPv6 and Wireless protocols. The discussion is open to anyone. An email invitation is being sent out to the Mobile IP and IPv6 IETF working group members to participate in the audience. Members of the audience will have an opportunity to ask questions to the panel on topics relating to IPv6 and Wireless. Round Table Discussion: IPv6 for Wireless and Mobility The wireless cellular industry, particularly as it prepares to deploy 2.5G and 3G services has been touted as the "killer application" for IPv6. An obvious first consideration to support this notion is the sheer number of devices expected to come on-line via cellular technologies. Predictions range from 600 million to 1 billion at the turn of 4 to 5 years. Managing such a large and sudden influx of devices connected via highly dynamic and unreliable links is a task far more challenging than any the Internet has faced to date. The panel will explore how IPv6 can rise to the challenge, as well as its remaining deficiencies. The following features of IPv6 are some of the topics (but not limited to) that will be discussed at the roundtable: - How can IPv6 streamline the routing infrastructure? IPv6 may have a better chance than IPv4 at route aggregation, because of better initial assignment of address ranges and because of its provisions for renumbering. What remains to be done? - Role of autoconfiguration for mobile networking. Mobile and wireless devices need to bootstrap all configuration information based on a secure token or on a cryptographic identity. The rest should be automatic. This is particularly relevant when considering other wireless technologies like Bluetooth that will need to interact with cellular, and in which the automatic configuration requirements apply to a collection of devices. - How can IPv6 improve the security infrastructure? IPv6 does mandate IPsec, but how practical or deployable is it in a cellular environment? - Can Mobile IP simplify the future Internet? Does IPv6 provide other mechanisms to deal with mobility? Is it better handled at a layer other than layer 3 (as in Mobile IP)? - What is the interaction between IPv6 and cellular telephone standards? There seems to be little more than lip service to IPv6 on the part of next generation cellular consortiums like 3GPP, 3GPP2, and MWIF. Do they have valid concerns? - Issues with supporting 500 Million IP Wireless Devices. What is the right addressing scheme that needs to be used? Are E.164 based addresses more appropriate for cellular than EUI-64 (more common with LAN hardware)? - The IPv6 header is twice as large as its IPv4 counterpart, but routers should have a much easier time processing and forwarding packets. The IPv6 header is simpler to compress. The size of the average compressed IPv6 header will be smaller than the corresponding IPv4 header (although the difference is not large). So the cost of using IPv6 over the air links will be somewhat less than when using IPv4. The above issues apply to both the core network as well as to the wireless devices. Members of the audience can raise any topic regarding IPv6 for Mobility or Wireless at this roundtable. Discussion is not limited to those topics above. Roundtable Panel Charlie Perkins Robert Hinden Nokia Research Laboratories Nokia Steve Deering Martin Korling Cisco Systems Ericsson Research Erik Nordmark Dave Johnson Sun Microsystems Carnegie Mellon University Brian Zill Jun-ichiro Hagino Microsoft Research Internet Initiative Japan Inc. Mihai Mateescu Mobile and Broadband Wireless Communications of GMD Date, Time and Place Monday, March 6, 2000 4:00pm-6:00pm Crowne Plaza Hotel 282 Almaden Blvd San Jose, CA Phone # for Crowne Plaza: (408) 998-0400 The roundtable discussion will take place in the Crowne Plaza Hotel Ballroom. You do *not* need to RSVP to attend the roundtable. Just show up at the Crowne Plaza Hotel Ballroom. There is no registration required for participating. While admission to the IPv6 Wireless and Mobility roundtable is free and open to all, only registered participants of Connectathon will be allowed into the testing halls. Mobile IP Dinner ================ Some members of the panel will be joining Connectathon participants for dinner after the event at a local San Jose restaurant. If you are interested in attending the dinner you *must* RSVP John Hird at jrh@eng.sun.com. You will be responsible for the cost of your dinner. More information about where the dinner will be provided at the roundtable event. There will be limited room so the RSVP will be on a first come basis. Ericsson Presentation ===================== A presentation by Ericsson will be made on their Mobile IPv6 research implementation immediately preceding the roundtable in the same room (Crowne Plaza Hotel Ballroom) from 3:00pm-3:45pm. Conny Larsson of Ericsson Research will be presenting. Again, this is open to anyone. Abstract of talk by Conny Larsson, Ericsson Research: The Ericsson Mobile IPv6 implementation is a free implementation using FreeBSD and the KAME IPv6 implementation. It has been implemented as part of a research project at Ericsson. It consists of three parts; the Correspondent Node, the Home Agent and the Mobile Node. In addition, two applications are offered for configuration and retrieving statistical information. This talk will go over the Ericsson Research Mobile IPv6 implementation. References: www.connectathon.org - for more information on Connectathon 2000. www.ipv6forum.com - for more information on the Worldwide consortium of leading Internet vendors, Research & Education Networks. Connectathon 2000 participants performing interoperability testing for the Mobile IP, IPv6, Mobile IPv6 and/or DIAMETER protocols: Apple Computer, Inc., Cisco Systems, Inc., Carnegie Mellon University, Ericsson Inc., ENST (Ecole National Superieure des Telecommunications) Bretagne, Hewlett-Packard Company, Hitachi, Ltd., IBM Corporation, KAME Project, MCI Worldcom, Microsoft Corporation, NEC Corporation, Nokia Research Center, SCO Ltd., Sun Microsystems, Inc., Silicon Graphics, Inc., TAHI, Toshiba Corporation, University of New Hampshire, Mobile and Broadband Wireless Communications of GMD -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 03:41:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e26BdX103663 for ipng-dist; Mon, 6 Mar 2000 03:39:33 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e26BdO903656 for ; Mon, 6 Mar 2000 03:39:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA10315 for ; Mon, 6 Mar 2000 03:39:22 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA24236 for ; Mon, 6 Mar 2000 03:39:20 -0800 (PST) Received: from localhost (peter-v6@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id WAA27859; Mon, 6 Mar 2000 22:38:41 +1100 (EST) Date: Mon, 6 Mar 2000 22:38:41 +1100 (EST) From: "Peter Tattam (IPv6 Mail)" To: itojun@iijlab.net cc: Jean-Michel COMBES , Jacinto Vieira , ipng@sunroof.eng.sun.com Subject: Re: Ipv6 Internet Browser In-Reply-To: <9956.950709317@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 Also any V4 web browser can access a V6 web site using our bump-in-the-api design of Trumpet Winsock 5.0. Not really the answer you are after, but it is a solution to web browsing in the v6 world. BTW, anyone got a SSL website over v6 that I can test against? I need to see if SSL passes when the virtual circuit is terminated with a V4 connection to a V6 host. Or is SSL immune to this kind of thing. Peter On Wed, 16 Feb 2000 itojun@iijlab.net wrote: > > >here's a list of browsers supporting IPv6 : > > Microsoft Internet Explorer (www.research.microsoft.com/msripv6) > > Mozilla (ftp://ftp.kame.net/pub/kame/misc/) > > Lynx (ftp://ftp.kame.net/pub/kame/misc/) > > w3m (www.freebsd.org) > > It is also very useful to install IPv6/v4 dual stack proxy web server > on your computer. By doing so you can use your favorite (IPv4-only) > web browser to access IPv6 web servers. > > IPv4 client --IPv4--> IPv4/v6 proxy --IPv6--> IPv6 web server > > wwwoffle does it very nicely. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Peter R. Tattam peter-v6@trumpet.com.au Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 6 03:59:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e26Bvsl03701 for ipng-dist; Mon, 6 Mar 2000 03:57:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e26Bvi903694 for ; Mon, 6 Mar 2000 03:57:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA11045 for ; Mon, 6 Mar 2000 03:57:43 -0800 (PST) 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 EAA12925 for ; Mon, 6 Mar 2000 04:57:42 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02508; Mon, 6 Mar 2000 06:57:40 -0500 (EST) Message-Id: <200003061157.GAA02508@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-scoped-routing-03.txt Date: Mon, 06 Mar 2000 06:57:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Author(s) : B. Haberman Filename : draft-ietf-ipngwg-scoped-routing-03.txt Pages : 6 Date : 03-Mar-00 This document outlines a mechanism for generating forwarding tables that include scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward packets addressed to scoped unicast or multicast addresses regardless of the routing protocol. These rules apply to all scoped addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoped-routing-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-scoped-routing-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-scoped-routing-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000303142030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoped-routing-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoped-routing-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000303142030.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 Mar 6 06:44:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e26EdEK03747 for ipng-dist; Mon, 6 Mar 2000 06:39:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e26Ed6903740 for ; Mon, 6 Mar 2000 06:39:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA00763 for ; Mon, 6 Mar 2000 06:39:00 -0800 (PST) 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 GAA24224 for ; Mon, 6 Mar 2000 06:38:59 -0800 (PST) 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 XAA04250; Mon, 6 Mar 2000 23:38:54 +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 XAA03152; Mon, 6 Mar 2000 23:38:54 +0900 (JST) Received: from iijlab.net (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id XAA08585; Mon, 6 Mar 2000 23:38:53 +0900 (JST) Date: Mon, 06 Mar 2000 23:38:40 +0900 (JST) Message-Id: <20000306.233840.104029480.kazu@iijlab.net> To: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU, users@ipv6.org Cc: ip-v6@nic.ad.jp Subject: JPNIC From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b28 on Emacs 20.6 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JPNIC, NIR in Japan, has just started new services for IPv6 from March 1, 2000. - JPNIC now can register AAAA *glue* records for an NS record e.g. for iij.ad.jp's NS record note: transport is now still IPv4 only - Whois DB is now IPv6 contents-ready note: transport is now still IPv4 only The next step is make both services be IPv6 transport-ready. --Kazu with a JPNIC hat -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 10:13:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e28IBxl05838 for ipng-dist; Wed, 8 Mar 2000 10:11:59 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e28IBow05831 for ; Wed, 8 Mar 2000 10:11:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA15681 for ; Wed, 8 Mar 2000 10:11:49 -0800 (PST) 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 LAA10627 for ; Wed, 8 Mar 2000 11:11:48 -0700 (MST) 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 SAA25862; Wed, 8 Mar 2000 18:11:46 GMT 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 SAA31454; Wed, 8 Mar 2000 18:11:43 GMT Message-ID: <38C69689.4DC781C2@hursley.ibm.com> Date: Wed, 08 Mar 2000 12:06:01 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Stankevitz, Christian (CT)" CC: ipng@sunroof.eng.sun.com Subject: Re: Is IPv6 died ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Stankevitz, Christian (CT)" wrote: > > I seem to recall a discussion in the past about IPv6 and the problem of > address space. Is IPv6 really just a large scale research project Hardly, with >30 implementations including some fully supported products. Oh, and it certainly solves the addressing problem for the next 50 years if not for ever. > and what > is the status of IPv8 It has no status in the IETF. Brian Carpenter IAB 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 Wed Mar 8 10:24:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e28IMI705908 for ipng-dist; Wed, 8 Mar 2000 10:22:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e28IMAw05901 for ; Wed, 8 Mar 2000 10:22:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA02158 for ; Wed, 8 Mar 2000 10:22:09 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17209 for ; Wed, 8 Mar 2000 11:22:08 -0700 (MST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 6194E427; Wed, 8 Mar 2000 13:22:08 -0500 (EST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 47542EBD for ; Wed, 8 Mar 2000 13:22:08 -0500 (EST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id NAA0000027823; Wed, 8 Mar 2000 13:22:00 -0500 (EST) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA07781; Wed, 8 Mar 2000 13:22:07 -0500 Message-Id: <38C69A4E.46F18B33@zk3.dec.com> Date: Wed, 08 Mar 2000 13:22:06 -0500 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: IPNG Working Group Subject: 2292bis-01: rcmd_af and rexec_af Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When going throught and implementing these function I discovered that they are not really thread safe. The reason for this is the way we treat the 'ahost' argument. This argument is passed in as 'char **' and the function will change '*ahost' to point to a FQDN for the host [behave the same as rcmd()] obtained through either getipnodebyname() or getaddrinfo(). The FQDN is a dynamically allocated storage that will not persist outside the rcmd_af(). Thus a string copy should be used instead, but we do not know if we have enough room in '*ahost' to contain an FQDN. I propose that we change the rcmd_af and rexec_af to be thread safe. To do that we can change the host argument to be pointer to hostname (char *ahost) and ether specified a lenght argument (size_t hostlen) or we can require that the host buffer be MAXDNAME length. -vlad +++++++++++++++++++++++++++++++ Vladislav Yasevich Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 (603) 884-1079 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 8 15:46:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e28NjDP06194 for ipng-dist; Wed, 8 Mar 2000 15:45:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e28Nj4w06187 for ; Wed, 8 Mar 2000 15:45:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA09044 for ; Wed, 8 Mar 2000 15:45:05 -0800 (PST) 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 PAA28691 for ; Wed, 8 Mar 2000 15:45:03 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA19707; Thu, 9 Mar 2000 00:44:15 +0100 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 AAA24651; Thu, 9 Mar 2000 00:44:14 +0100 (MET) 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 AAA75810; Thu, 9 Mar 2000 00:47:11 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200003082347.AAA75810@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: David Johnson , Charles Perkins Cc: ipng@sunroof.eng.sun.com Subject: two points about draft-ietf-mobileip-ipv6-10.txt Date: Thu, 09 Mar 2000 00:47:11 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The next I-D will show in some cases two destination option headers, one just before AH/SP, one just after but the current base specs (RFC 2460) don't really allow this (ie. this must be accepted but should not be sent). The second point is about sub-option alignment constraints: what error type/code should be used if an alignment constraint is not followed. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 9 03:34:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e29BVUi06477 for ipng-dist; Thu, 9 Mar 2000 03:31:30 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e29BVKw06470 for ; Thu, 9 Mar 2000 03:31:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA12799 for ; Thu, 9 Mar 2000 03:31:20 -0800 (PST) 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 DAA10446 for ; Thu, 9 Mar 2000 03:31:18 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25869; Thu, 9 Mar 2000 06:31:16 -0500 (EST) Message-Id: <200003091131.GAA25869@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-dns-lookups-07.txt Date: Thu, 09 Mar 2000 06:31:15 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : DNS Extensions to Support IPv6 Address Aggregation and Renumbering Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-07.txt Pages : 20 Date : 08-Mar-00 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-07.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-dns-lookups-07.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-dns-lookups-07.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: <20000308171906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-lookups-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308171906.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 9 16:02:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e29NxJS07149 for ipng-dist; Thu, 9 Mar 2000 15:59:19 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e29Nx8w07142 for ; Thu, 9 Mar 2000 15:59:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA08540 for ; Thu, 9 Mar 2000 15:59:04 -0800 (PST) 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 PAA21303 for ; Thu, 9 Mar 2000 15:59:05 -0800 (PST) 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 PAA10904; Thu, 9 Mar 2000 15:59:05 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA04248; Thu, 9 Mar 2000 15:47:53 -0800 X-Virus-Scanned: Thu, 9 Mar 2000 15:47:53 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xmaa03419; Thu, 9 Mar 00 15:47:34 -0800 Message-Id: <4.2.2.20000309155557.00a27900@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 15:56:50 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Request for Agenda Items Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have one (perhaps two slots) scheduled in Adelaide IETF meeting. Please send requests for agenda items to us. Bob Hinden / Steve Deering IPng Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 13 03:18:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2DBHHx09004 for ipng-dist; Mon, 13 Mar 2000 03:17:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2DBH7w08997 for ; Mon, 13 Mar 2000 03:17:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA26739 for ; Mon, 13 Mar 2000 03:17:06 -0800 (PST) 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 DAA05536 for ; Mon, 13 Mar 2000 03:17:05 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14262; Mon, 13 Mar 2000 06:17:02 -0500 (EST) Message-Id: <200003131117.GAA14262@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-scopedaddr-format-01.txt Date: Mon, 13 Mar 2000 06:17:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : An Extension of Format for IPv6 Scoped Addresses Author(s) : T. Jinmei, A. Onoe Filename : draft-ietf-ipngwg-scopedaddr-format-01.txt Pages : 10 Date : 10-Mar-00 This document defines an extension of the format for IPv6 scoped addresses. In the format, a scope identifier is attached to a scoped address in order to supplement the ambiguity of the semantics of the address. Using the format with some library routines will make scope-aware applications simpler. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scopedaddr-format-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-scopedaddr-format-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-scopedaddr-format-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: <20000310134517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scopedaddr-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scopedaddr-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000310134517.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 Mar 15 14:38:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2FMaFp11227 for ipng-dist; Wed, 15 Mar 2000 14:36:15 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2FMa6w11220 for ; Wed, 15 Mar 2000 14:36:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA18673 for ; Wed, 15 Mar 2000 14:36:03 -0800 (PST) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15701 for ; Wed, 15 Mar 2000 15:36:02 -0700 (MST) Received: from localhost (rglr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id RAA15293 for ; Wed, 15 Mar 2000 17:35:58 -0500 (EST) Date: Wed, 15 Mar 2000 17:35:57 -0500 From: Ray LaRocca To: ipng@sunroof.eng.sun.com Subject: RIPng question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We're testing RIPng here at the IPv6 Forum meeting and ran across a question- if anyone can shed some light on this we would appreciate it: In IPv4 it's obviously pointless to claim reachability for a network on the actual network. In IPv6 there may be a case where two routers with interfaces on the same network have different prefixes for that same network. The question is: should a RIPng router advertise its prefix for a network as reachable on that actual network since other routers may or may not know that prefix. -Ray -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 16:35:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2G0XQB11431 for ipng-dist; Wed, 15 Mar 2000 16:33:26 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2G0XLw11424 for ; Wed, 15 Mar 2000 16:33:21 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id QAA01214 for ipng@sunroof.eng.sun.com; Wed, 15 Mar 2000 16:31:26 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2FNDNw11321 for ; Wed, 15 Mar 2000 15:13:23 -0800 (PST) Received: (from samita@localhost) by jurassic.eng.sun.com (8.10.0+Sun/8.10.0) id e2FNDOl416107; Wed, 15 Mar 2000 15:13:24 -0800 (PST) Date: Wed, 15 Mar 2000 15:13:24 -0800 (PST) From: Samita Chakrabarti Message-Id: <200003152313.e2FNDOl416107@jurassic.eng.sun.com> To: rglr@iol.unh.edu Subject: Re: RIPng question Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We're testing RIPng here at the IPv6 Forum meeting and ran across a > question- if anyone can shed some light on this we would appreciate it: > > In IPv4 it's obviously pointless to claim reachability for a network on > the actual network. > > In IPv6 there may be a case where two routers with interfaces on the same > network have different prefixes for that same network. The question > is: should a RIPng router advertise its prefix for a network as reachable > on that actual network since other routers may or may not know that > prefix. > Hi Ray, Good point. We encountered same issue while testing IPv6 in our lab. The problem is that routers advertising different prefixes on the same link do not know about each other's prefix as they don't process the router advertisement sent by other routers. Thus a node cannot reach another node beyond the 2nd router in the journey. I think, RIPng somehow must be smart enough to listen to the routing advertisement and then figure out if advertised prefixes are same as it's own prefix on the same link, if they are not the same, then it can add that route in it's own system. I can see a problem of RIPng advertising it's own prefix as reachable as there may be two routers advertising same prefix on the link and the third one (on same link) advertising a different prefix. Another simple solution is to make routers advertise same prefix on the same link-- that needs some modification in the drafts/rfcs. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 16 06:01:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2GDxRI12331 for ipng-dist; Thu, 16 Mar 2000 05:59:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2GDxJw12324 for ; Thu, 16 Mar 2000 05:59:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA27582 for ; Thu, 16 Mar 2000 05:59:20 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA12671 for ; Thu, 16 Mar 2000 05:59:19 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 08979104D2E; Thu, 16 Mar 2000 07:59:19 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 03486FB101; Thu, 16 Mar 2000 07:59:18 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 4BAE44FB03; Thu, 16 Mar 2000 07:59:12 -0600 (CST) Received: from oflume.zk3.dec.com (oflume.zk3.dec.com [16.140.112.3]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id D6D734C902; Thu, 16 Mar 2000 07:59:11 -0600 (CST) Received: by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id IAA0000010395; Thu, 16 Mar 2000 08:59:17 -0500 (EST) Date: Thu, 16 Mar 2000 08:59:17 -0500 (EST) From: Sowmini Varadhan Message-Id: <200003161359.IAA0000010395@oflume.zk3.dec.com> To: Samita.Chakrabarti@eng.sun.com Subject: Re: RIPng question Cc: ipng@sunroof.eng.sun.com, rglr@iol.unh.edu, varadhan@oflume.zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From owner-ipng@sunroof.eng.sun.com Wed Mar 15 19:36:58 2000 > >> We're testing RIPng here at the IPv6 Forum meeting and ran across a >> question- if anyone can shed some light on this we would appreciate it: >> >> In IPv4 it's obviously pointless to claim reachability for a network on >> the actual network. >> >> In IPv6 there may be a case where two routers with interfaces on the same >> network have different prefixes for that same network. The question >> is: should a RIPng router advertise its prefix for a network as reachable >> on that actual network since other routers may or may not know that >> prefix. > >Hi Ray, >Good point. We encountered same issue while testing IPv6 in our lab. >The problem is that routers advertising different prefixes on the >same link do not know about each other's prefix as they don't >process the router advertisement sent by other routers. This is only a problem in that they are not aware of the prefix as being "on-link". >Thus a node cannot reach another node beyond the 2nd router >in the journey. If there are 2 routers Ra and Rb on a network advertising prefixes Pa and Pb, nodes that are not routers should autoconfigure all of the advertised prefixes, and should have both Ra and Rb on their default router list. I'm not sure I see the problem you are listing above. Could you please illustrate this with an example? A possible kink is that since Ra may possibly not know that Pb is an on-link prefix, but since Rb should be sending out ripng advs on the link saying that Pb with metric 1, Ra should have the routing information to route packets with prefix Pb through Rb. How is reachability affected? >I think, RIPng somehow must be smart enough to listen to the >routing advertisement and then figure out if advertised prefixes are >same as it's own prefix on the same link, if they are not the >same, then it can add that route in it's own system. I can see a problem >of RIPng advertising it's own prefix as reachable as there may be >two routers advertising same prefix on the link and the third one (on same >link) advertising a different prefix. >Another simple solution is to make routers advertise same prefix >on the same link-- that needs some modification in the drafts/rfcs. I don't think this is a good idea- there may be a valid need to autoconfigure more than one prefix on a network, and the above suggestion would preclude that case. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 16 12:54:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2GKnv012740 for ipng-dist; Thu, 16 Mar 2000 12:49:57 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2GKnqw12733 for ; Thu, 16 Mar 2000 12:49:52 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id MAA01608 for ipng@sunroof.eng.sun.com; Thu, 16 Mar 2000 12:47:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2GK5Yw12615; Thu, 16 Mar 2000 12:05:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA13377; Thu, 16 Mar 2000 12:05:29 -0800 (PST) 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 MAA27976; Thu, 16 Mar 2000 12:05:28 -0800 (PST) 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 UAA16893; Thu, 16 Mar 2000 20:05:24 GMT Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id UAA01109; Thu, 16 Mar 2000 20:05:24 GMT Date: Thu, 16 Mar 2000 20:05:24 +0000 (GMT) From: Tim Chown To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: US IPv6 Forum Summit presentations online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The US IPv6 Summit presentations from Telluride are now online at http://www.ipv6forum.com in HTML, Powerpoint and zipped PDF formats. The link is from the top of the front page. Cheers, 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 Thu Mar 16 13:14:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2GLBJ912816 for ipng-dist; Thu, 16 Mar 2000 13:11:19 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2GLB8w12809 for ; Thu, 16 Mar 2000 13:11:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA02182 for ; Thu, 16 Mar 2000 13:11:07 -0800 (PST) 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 OAA21938 for ; Thu, 16 Mar 2000 14:11:05 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19973; Thu, 16 Mar 2000 16:11:02 -0500 (EST) Message-Id: <200003162111.QAA19973@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-00.txt Date: Thu, 16 Mar 2000 16:11:01 -0500 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) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-00.txt Pages : 25 Date : 15-Mar-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-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v3-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000315132232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132232.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 16 13:54:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2GLox812981 for ipng-dist; Thu, 16 Mar 2000 13:50:59 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2GLoow12974 for ; Thu, 16 Mar 2000 13:50:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA03642 for ; Thu, 16 Mar 2000 13:50:50 -0800 (PST) Received: from mail2.packetengines.com (mail2.packetengines.com [208.227.187.173]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA25237 for ; Thu, 16 Mar 2000 14:50:48 -0700 (MST) Received: from steam.corp.packetengines.com by mail2.packetengines.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 16 Mar 2000 21:50:48 UT Received: by STEAM with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 13:47:28 -0800 Message-ID: From: Vivek Venkatraman To: "'ipng@sunroof.eng.sun.com'" Subject: IPsec for IPv6 Date: Thu, 16 Mar 2000 13:47:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Is it mandatory for an IPv6 implementation (especially a router implementation) to support IPsec (as defined in RFC 2401 and companion documents)? If so, are both AH and ESP to be supported and what are the default algorithms -- are they Keyed-MD5 and DES-CBC respectively? Also, will manual key configuration be sufficient or are key management protocols like ISAKMP required? Thanks, Vivek -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 17 05:23:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2HDLVh13428 for ipng-dist; Fri, 17 Mar 2000 05:21:31 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2HDLCw13409 for ; Fri, 17 Mar 2000 05:21:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA18094 for ; Fri, 17 Mar 2000 05:21:10 -0800 (PST) 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 FAA26281 for ; Fri, 17 Mar 2000 05:21:09 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21358; Fri, 17 Mar 2000 08:21:08 -0500 (EST) Message-Id: <200003171321.IAA21358@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-scoping-arch-00.txt Date: Fri, 17 Mar 2000 08:21:07 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Scoped Address Architecture Author(s) : S. Deering, B. Haberman, B. Zill Filename : draft-ietf-ipngwg-scoping-arch-00.txt Pages : 11 Date : 16-Mar-00 This document specifies the architectural characteristics, expected behavior, and usage of IPv6 addresses of different scopes A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-scoping-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-scoping-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000316144212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoping-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoping-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144212.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 Mar 17 05:23:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2HDLYD13429 for ipng-dist; Fri, 17 Mar 2000 05:21:34 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2HDLIw13421 for ; Fri, 17 Mar 2000 05:21:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA23551 for ; Fri, 17 Mar 2000 05:21:16 -0800 (PST) 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 FAA26322 for ; Fri, 17 Mar 2000 05:21:15 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21401; Fri, 17 Mar 2000 08:21:13 -0500 (EST) Message-Id: <200003171321.IAA21401@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-router-renum-10.txt Date: Fri, 17 Mar 2000 08:21:12 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Router Renumbering for IPv6 Author(s) : M. Crawford Filename : draft-ietf-ipngwg-router-renum-10.txt Pages : 31 Date : 16-Mar-00 IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ('RR') which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-10.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-router-renum-10.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-router-renum-10.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: <20000316144225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-renum-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000316144225.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 Mar 17 09:46:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2HHi8n13836 for ipng-dist; Fri, 17 Mar 2000 09:44:08 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2HHi3w13829 for ; Fri, 17 Mar 2000 09:44:03 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA01889 for ipng@sunroof.eng.sun.com; Fri, 17 Mar 2000 09:42:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2HHXWw13783 for ; Fri, 17 Mar 2000 09:33:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA18332 for ; Fri, 17 Mar 2000 09:33:32 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06038 for ; Fri, 17 Mar 2000 09:33:31 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id A4913DA9; Fri, 17 Mar 2000 12:33:30 -0500 (EST) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 8CF084FA for ; Fri, 17 Mar 2000 12:33:30 -0500 (EST) Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Mar 2000 12:33:29 -0500 Message-ID: From: "Powell, Ken" To: ipng@sunroof.eng.sun.com Cc: rglr@iol.unh.edu Subject: RE: RIPng question Date: Fri, 17 Mar 2000 12:33:28 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, A little more background may be needed for this issue. UNH noticed at the Telluride test event that when sending a RIP advertisement on a LAN, different venders handle the LAN's own prefix different ways. The three policies seen were: 1) Do not include the LAN's prefix in the RIP advertisement. 2) Include the LAN's own prefix with a metric of 1. 3) Include the LAN's own prefix with a metric of 16. The spec does not say what to do in this situation and we did not notice any interoperability problems. The configuration Ray described is a case we thought of where it seems the policy implemented by the router vendor could make a difference. Is this something that needs to be specified, or can we live with vendor's choice here? Ken -----Original Message----- From: Sowmini Varadhan [mailto:varadhan@oflume.zk3.dec.com] Sent: Thursday, March 16, 2000 8:59 AM To: Samita.Chakrabarti@eng.sun.com Cc: ipng@sunroof.eng.sun.com; rglr@iol.unh.edu; varadhan@oflume.zk3.dec.com Subject: Re: RIPng question From owner-ipng@sunroof.eng.sun.com Wed Mar 15 19:36:58 2000 > >> We're testing RIPng here at the IPv6 Forum meeting and ran across a >> question- if anyone can shed some light on this we would appreciate it: >> >> In IPv4 it's obviously pointless to claim reachability for a network on >> the actual network. >> >> In IPv6 there may be a case where two routers with interfaces on the same >> network have different prefixes for that same network. The question >> is: should a RIPng router advertise its prefix for a network as reachable >> on that actual network since other routers may or may not know that >> prefix. > >Hi Ray, >Good point. We encountered same issue while testing IPv6 in our lab. >The problem is that routers advertising different prefixes on the >same link do not know about each other's prefix as they don't >process the router advertisement sent by other routers. This is only a problem in that they are not aware of the prefix as being "on-link". >Thus a node cannot reach another node beyond the 2nd router >in the journey. If there are 2 routers Ra and Rb on a network advertising prefixes Pa and Pb, nodes that are not routers should autoconfigure all of the advertised prefixes, and should have both Ra and Rb on their default router list. I'm not sure I see the problem you are listing above. Could you please illustrate this with an example? A possible kink is that since Ra may possibly not know that Pb is an on-link prefix, but since Rb should be sending out ripng advs on the link saying that Pb with metric 1, Ra should have the routing information to route packets with prefix Pb through Rb. How is reachability affected? >I think, RIPng somehow must be smart enough to listen to the >routing advertisement and then figure out if advertised prefixes are >same as it's own prefix on the same link, if they are not the >same, then it can add that route in it's own system. I can see a problem >of RIPng advertising it's own prefix as reachable as there may be >two routers advertising same prefix on the link and the third one (on same >link) advertising a different prefix. >Another simple solution is to make routers advertise same prefix >on the same link-- that needs some modification in the drafts/rfcs. I don't think this is a good idea- there may be a valid need to autoconfigure more than one prefix on a network, and the above suggestion would preclude that case. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 17 10:32:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2HIRlN13913 for ipng-dist; Fri, 17 Mar 2000 10:27:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2HIRbw13902 for ; Fri, 17 Mar 2000 10:27:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA09161 for ; Fri, 17 Mar 2000 10:27:36 -0800 (PST) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05852 for ; Fri, 17 Mar 2000 10:27:35 -0800 (PST) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 0689170E; Fri, 17 Mar 2000 12:27:35 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.im.hou.compaq.com [172.18.229.233]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id EE06E6D0; Fri, 17 Mar 2000 12:27:34 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 8576C4D402; Fri, 17 Mar 2000 12:27:28 -0600 (CST) Received: from oflume.zk3.dec.com (oflume.zk3.dec.com [16.140.112.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 159DE43981; Fri, 17 Mar 2000 12:27:28 -0600 (CST) Received: by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id NAA0000019299; Fri, 17 Mar 2000 13:27:33 -0500 (EST) Date: Fri, 17 Mar 2000 13:27:33 -0500 (EST) From: Sowmini Varadhan Message-Id: <200003171827.NAA0000019299@oflume.zk3.dec.com> To: Ken.Powell@compaq.com, ipng@sunroof.eng.sun.com Subject: RE: RIPng question Cc: rglr@iol.unh.edu, varadhan@oflume.zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >sending a RIP advertisement on a LAN, different >venders handle the LAN's own prefix different ways. >The three policies seen were: > > 1) Do not include the LAN's prefix in the RIP advertisement. > 2) Include the LAN's own prefix with a metric of 1. > 3) Include the LAN's own prefix with a metric of 16. > >The spec does not say what to do in this situation and we >did not notice any interoperability problems. RFC 2080 says: 2.5.2 Generating Response Messages : : To fill in the RTEs, examine each route in the routing table. Routes to link-local addresses must never be included in an RTE. If a triggered update is being generated, only entries whose route change flags are set need be included. If, after Split Horizon processing, the route should not be included, skip it. If the route is to be included, then the destination prefix, prefix length, and metric are put into the RTE. The route tag is filled in as defined in section 2.1. Routes must be included in the datagram even if their metrics are infinite. Note that #2 would comply with Section 2.5.2. It also appears to eliminate policy #1 (the only routes that are to be skipped are link-locals, those eliminated by Split Horizon, and, in the case of triggered updates, those whose route flags have not changed). As for policy #3, RFC2080 says: 2.6 Split Horizon Split Horizon is a algorithm for avoiding problems caused by including routes in updates sent to the gateway from which they were learned. The basic split horizon algorithm omits routes learned from one neighbor in updates sent to that neighbor. In the case of a broadcast network, all routes learned from any neighbor on that network are omitted from updates sent on that network. Split Horizon with Poisoned Reverse (more simply, Poison Reverse) does include such routes in updates, but sets their metrics to infinity. In effect, advertising the fact that there routes are not reachable. This is the preferred method of operation; however, implementations should provide a per-interface control allowing no horizoning, split horizoning, and poisoned reverse to be selected. The onlink prefix is not a route that a router "learned from a gateway", so I don't see how it can justifiably be sent with metric 16. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 17 16:31:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e2I0TsX14268 for ipng-dist; Fri, 17 Mar 2000 16:29:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e2I0Tiw14257 for ; Fri, 17 Mar 2000 16:29:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA29224 for ; Fri, 17 Mar 2000 16:29:44 -0800 (PST) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14981 for ; Fri, 17 Mar 2000 16:29:44 -0800 (PST) Received: from hpncdja.cup.hp.com (hpncdja.cup.hp.com [15.13.106.146]) by atlrel1.hp.com (Postfix) with ESMTP id 92A722E7E for ; Fri, 17 Mar 2000 19:29:43 -0500 (EST) Received: from localhost (dsw@localhost) by hpncdja.cup.hp.com with SMTP (8.8.6 (PHNE_17190)/8.7.3 TIS 5.0.1) id QAA27819 for ; Fri, 17 Mar 2000 16:35:12 -0800 (PST) Date: Fri, 17 Mar 2000 16:35:12 -0800 (PST) From: David Wang To: ipng@sunroof.eng.sun.com Subject: HP-UX IPv6 Developer's Kit version 1.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hewlett-Packard Company announces the release of the HP-UX IPv6 Developer's Kit version 1.1 The HP-UX IPv6 Developer's Kit version 1.1 supports the IETF IPv6 standards that will provide IPv6 functionality on HP-UX 11.00. IPv6 is a new version of the Internet Protocol that provides a larger address space, simple network configuration, and better security. The IPv6 Developer's Kit enables the Internet community to evaluate and experiment with the IPv6 protocol on HP-UX 11.0. More details are available at: http://www.software.hp.com Please search for "IPv6". The HP-UX IPv6 development team -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 11:27:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2KJPm916096 for ipng-dist; Mon, 20 Mar 2000 11:25:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2KJPdN16089 for ; Mon, 20 Mar 2000 11:25:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA02273 for ; Mon, 20 Mar 2000 11:25:38 -0800 (PST) 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 LAA20359 for ; Mon, 20 Mar 2000 11:25:37 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Mar 2000 11:25:38 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Mon, 20 Mar 2000 11:25:37 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21DF4@RED-MSG-50> From: Richard Draves To: "'IPng List'" Cc: "'MSR IPv6 Users'" Subject: Microsoft IPv6 Technology Preview for Windows 2000 Date: Mon, 20 Mar 2000 11:25:31 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You may have seen the recent press release about MS's IPv6 product plans: http://www.microsoft.com/presspass/press/2000/Mar00/IPv6PR.asp The Technology Preview (phase 2 of our product plans) is now available at http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp The Technology Preview is very similar to the MSR IPv6 1.4 release. There are several additional bug fixes. Some noticeable differences are: - The Technology Preview is only for Windows 2000. - It supports draft-ietf-ipngwg-scopedaddr-format-01.txt. - It doesn't include source code. - Improvements to 6to4cfg. There is a new official MS 6to4 relay, 6to4.ipv6.microsoft.com. - ipv6.exe shows "friendly names" (from Connection Manager) for interfaces - We removed support for getipnodebyname, getipnodebyaddr, inet_pton, inet_ntop - use getaddrinfo & getnameinfo. If you wish to install the Technology Preview, you must first uninstall MSR IPv6. If the new address%scopeid syntax is not working properly, try rebooting - there's a bug in the installer where sometimes you need to reboot after installing to update %systemroot%\system32\wship6.dll. At this time, we do anticipate more MSR IPv6 releases (with source code) but not in the near future - our work on Microsoft's IPv6 product takes precedence. 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 Mar 21 04:26:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2LCOo116866 for ipng-dist; Tue, 21 Mar 2000 04:24:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2LCOfN16859 for ; Tue, 21 Mar 2000 04:24:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA26697 for ; Tue, 21 Mar 2000 04:24:40 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA25591 for ; Tue, 21 Mar 2000 05:24:36 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 21 Mar 2000 18:03:32 +0530 Received: from muralia.future.futsoft.com ([10.0.14.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id RAA27909; Tue, 21 Mar 2000 17:41:53 +0530 Received: by localhost with Microsoft MAPI; Tue, 21 Mar 2000 17:53:12 +0530 Message-Id: <01BF935E.539759E0.muralia@future.futsoft.com> From: Murali Krishna Ch Reply-To: "muralia@future.futsoft.com" To: "'Bob.Gilligan@Eng.Sun.COM'" Cc: "'Erik.Nordmar@Eng.Sun.COM'" , "'users@ipv6.org'" , "'ipng@sunroof.eng.sun.com'" Subject: Doubt on Dual IP layer in RFC 1933 Date: Tue, 21 Mar 2000 17:53:11 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are two mechanisms 1) Dual IP layer 2) Tunneling to keep IPv6 hosts/routers compatible with IPv4 hosts/routers. Query 1: If Dual IP layer mechansim is used alone, how does an ipv6 packet from ipv6 host/router will be processed at ipv4-only node? Query 2: Is it necessry to have tunnelling mechanism to be compatible with IPv4? Thanks in advance, 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 Tue Mar 21 07:34:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2LFVfP16926 for ipng-dist; Tue, 21 Mar 2000 07:31:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2LFVWN16919 for ; Tue, 21 Mar 2000 07:31:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA18600; Tue, 21 Mar 2000 07:31:32 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13636; Tue, 21 Mar 2000 08:31:31 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA04302; Tue, 21 Mar 2000 07:31:26 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <01BF935E.539759E0.muralia@future.futsoft.com> References: <01BF935E.539759E0.muralia@future.futsoft.com> Date: Tue, 21 Mar 2000 07:33:58 -0800 To: "muralia@future.futsoft.com" From: Steve Deering Subject: Re: Doubt on Dual IP layer in RFC 1933 Cc: "'Bob.Gilligan@Eng.Sun.COM'" , "'Erik.Nordmar@Eng.Sun.COM'" , "'users@ipv6.org'" , "'ipng@sunroof.eng.sun.com'" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:53 PM +0530 3/21/00, Murali Krishna Ch wrote: >Query 1: If Dual IP layer mechansim is used alone, how does > an ipv6 packet from ipv6 host/router will be processed > at ipv4-only node? If a dual IP-layer mechanism is used *alone*, that means all IPv6-capable nodes are also IPv4-capable. Such a dual IP-layer node sends only IPv4 packets to IPv4-only nodes, so your question is not meaningful. For an IPv6-only (i.e., *not* dual IP-layer) node to send a packet to an IPv4-only node, there must be some sort of translator or gateway in the path, to perform the necessary header conversion. The translator or gateway itself will have dual IP layers. >Query 2: Is it necessry to have tunnelling mechanism to be > compatible with IPv4? No. Tunneling (of IPv6 inside IPv4) is used for IPv6-to-IP6 communication only, when the routers between the source and destination IPv6 nodes do not all support IPv6. 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 Mar 22 11:39:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2MJapq17968 for ipng-dist; Wed, 22 Mar 2000 11:36:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2MJafN17961 for ; Wed, 22 Mar 2000 11:36:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA21746 for ; Wed, 22 Mar 2000 11:36:40 -0800 (PST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01698 for ; Wed, 22 Mar 2000 11:36:39 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Wed, 22 Mar 2000 13:13:57 -0600 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H3L69MR1; Wed, 22 Mar 2000 13:13:01 -0600 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H3MC2B0X; Wed, 22 Mar 2000 14:13:01 -0500 Message-ID: <38D91ACB.87C24EB8@nortelnetworks.com> Date: Wed, 22 Mar 2000 14:11:07 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Updated Scoped Address Architecture doc Content-Type: multipart/mixed; boundary="------------8591A9999C4E2DFE9E892603" X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------8591A9999C4E2DFE9E892603 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Here is an update to the Scoped Address Architecture draft. It will be posted to the I-D editor when the queue is open. Comments to the list or the authors. Brian -- Brian Haberman Nortel Networks haberman@nortelnetworks.com --------------8591A9999C4E2DFE9E892603 Content-Type: text/plain; charset=us-ascii; name="scope-arch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="scope-arch.txt" IPNGWG Working Group S. Deering Internet Draft Cisco Systems draft-ipngwg-scoping-arch-01.txt B. Haberman March 2000 Nortel Networks Expires September 2000 B. Zill Microsoft IP Version 6 Scoped Address Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies the architectural characteristics, expected behavior, and usage of IPv6 addresses of different scopes 1. Introduction The Internet Protocol version 6 (IPv6) introduces the concept of limited scope addresses to the IP lexicon. While operational practice with IPv4 has included the concept of a private address space (net 10, etc.), the design of IPv6 incorporates such addresses into its base architecture. This document defines terms associated with such addresses and describes mechanisms for their behavior. Deering, Haberman, Zill 1 Internet Draft IPv6 Scoped Address Architecture September 2000 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 3. Basic Terminology The terms link, interface, node, host, and router are defined in [RFC 2460]. The definitions of unicast address scopes (link-local, site-local, and global) and multicast address scopes (node-local, link-local, etc.) are contained in [RFC 2373]. 4. Address Scope Every IPv6 address has a specific scope, that is, a topological "distance" within which the address may be used as a unique identifier for an interface. The scope of an address is encoded as part of the address, as specified in [RFC 2373]. For unicast addresses, there are three defined scopes: o Link-local scope, for uniquely identifying interfaces within a single link only. o Site-local scope, for uniquely identifying interfaces within a single site only. A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. A personal residence may be treated as a site (for example, when the residence obtains Internet access via a public Internet service provider), or as a part of a site (for example, when the residence obtains Internet access via an employer's or school's site). o Global scope, for uniquely identifying interfaces anywhere in the Internet. For multicast addresses, there are fourteen possible scopes, ranging from node-local to global (including both link-local and site- local). A node-local multicast address serves as a unique identifier for an interface within a single node only; such an address is used only for "loopback" delivery of multicasts within a single node, for example, as a form of inter-process communication within a computer. Deering, Haberman, Zill 2 Internet Draft IPv6 Scoped Address Architecture September 2000 There is an ordering relationship among scopes: o for unicast scopes, link-local is a smaller scope than site-local, and site-local is a smaller scope than global. o for multicast scopes, scopes with lesser values in the "scop" subfield of the multicast address [RFC 2373, section 2.7] are smaller than scopes with greater values, with node-local being the smallest and global being the largest. However, two scopes of different size may cover the exact same region of topology, for example, a site may consist of a single link, in which both link-local and site-local scope effectively cover the same topological "distance". 5. Scope Zones A scope zone, or a simply a zone, is a connected region of topology of a given scope. For example, the set of links connected by routers within a particular site, and the interfaces attached to those links, comprise a single zone of site-local scope. To understand the distinction between scopes and zones, observe that the topological regions within two different sites are considered to be two DIFFERENT zones, but of the SAME scope. Addresses of a given (non-global) scope may be re-used in different zones of that scope. The zone to which a particular non-global address pertains is not encoded in the address itself, but rather is determined by context, such as the interface from which it is sent or received. Zones of the different scopes are defined as follows: o A node-local zone (for multicast only) consists of a single interface on a node. [Note: node-local scope would have been more accurately named interface-local.] o A link-local zone (for unicast and multicast) consists of a single link and all the interfaces attached to that link. o There is a single zone of global scope (for both unicast and multicast), comprising all the links and interfaces in the Internet. o The boundaries of zones of scope other than node-local, link-local, and global must be defined and configured by network administrators. The only required such Deering, Haberman, Zill 3 Internet Draft IPv6 Scoped Address Architecture September 2000 boundaries are site boundaries. A site boundary serves for both unicast and multicast. Zone boundaries are relatively static features, not changing in response to short-term changes in topology. Thus, the requirement that the topology within a zone be "connected" is intended to include links and interfaces that may be only occasionally connected. For example, a residential node or network that obtains Internet access by dial-up to an employer's site may be treated as part of the employer's site-local zone even when the dial-up link is disconnected. Similarly, a failure of a router, interface, or link that causes a zone to become partitioned does not split that zone into multiple zones; rather, the different partitions are still considered to belong to the same zone. Zones have the following additional properties: o Zone boundaries cut through nodes, not links. (There are two exceptions: the global zone has no boundary, and the boundary of a node-local zone conceptually cuts through an interface between a node and a link.) o Zones of the same scope cannot overlap, i.e., they can have no links or interfaces in common. o A zone of a given scope (less than global) falls completely within zones of larger scope, i.e., a smaller scope zone cannot include more topology than any larger scope zone with which it shares any links or interfaces. Each interface belongs to one node-local zone, one link-local zone, one site-local zone, and the global zone. Each link belongs to one link-local zone, one site-local zone, and the global zone. An interface or link only belongs to additional (i.e., multicast) zones if it falls within the configured boundaries of such additional zones. 6. Zone Indices Because the same address of a given (non-global) scope can be re- used in different zones of that scope, a node must have a means -- other than examining the address itself -- of associating non-global addresses with particular zones when sending, receiving, or forwarding packets containing such addresses. This is accomplished by assigning a local "zone index" to each zone to which a node is attached. Each attached zone of the same scope must be assigned a different index value; attached zones of different scopes can re-use the same index values. Deering, Haberman, Zill 4 Internet Draft IPv6 Scoped Address Architecture September 2000 The assignment of zone indices is illustrated in the example in the figure below: --------------------------------------------------------------- | a node | | | | | | | | | | | | /--site1--\ /--------------site2--------------\ /--site3--\ | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | intf1 intf2 intf3 intf4 intf5 | --------------------------------------------------------------- : | | | | : | | | | : | | | | the ================= a point- a loopback an Ethernet to-point tunnel link link Figure 1 : Zone Indices Example This example node has five interfaces: o A loopback interface, which can be thought of as an interface to a phantom link -- the "loopback link" -- that goes nowhere, o Two interfaces to the same Ethernet, o An interface to a point-to-point link, and o A tunnel interface (e.g., the abstract endpoint of an IPv6-over-IPv6 tunnel [RFC 2473], presumably established over either the Ethernet or the point-to-point link.) It is thus attached to five node-local zones, identified by the interface indices 1 through 5. Because the two Ethernet interfaces are attached to the same link, the node is attached to only four link-local zones, identified by link indices 1 through 4. It is attached to three site-local zones: one imaginary one to which the loopback interface belongs, one to which the Ethernet and the point-to-point link belong, and one to which the tunnel belongs (perhaps because it is a tunnel to another organization). These site-local zones are identified by the site indices 1 through 3. Deering, Haberman, Zill 5 Internet Draft IPv6 Scoped Address Architecture September 2000 The zone indices are strictly local to the node. For example, the node on the other end of the point-to-point link may well be using entirely different interface, link, and site index values for that link. The zone index values are arbitrary. An implementation may use any value it chooses to label a zone as long as it maintains the requirement that the index value of each attached zone of the same scope must be unique within the node. Implementations choosing to follow the recommended basic API [RFC 2553] will also want to restrict their index values to those that can be represented by the sin6_scope_id field of a sockaddr_in6. An implementation may also support the concept of a "default" zone for each scope. It is convenient to reserve the index value zero, at each scope, to mean "use the default zone". This default index can also be used to identify the zone for any scopes for which the node has not assigned any indices, such as the various multicast- only scopes. There is at present no way for a node to automatically determine which of its interfaces belongs to the same zones, e.g., the same link or the same site. In the future, protocols may be developed to determine that information. In the absence of such protocols, an implementation must provide a means for manual assignment and/or reassignment of zone indices. Furthermore, to avoid the need to perform manual configuration in most cases, an implementation should, by default, initially assign zone indices as follows: o A unique interface index for each interface o A unique link index for each interface o A single site index for all interfaces Then, manual configuration would be necessary only for the less common cases of nodes with multiple interfaces to a single link, interfaces to different sites, or interfaces to zones of different (multicast-only) scopes. 7. Sending Packets When an upper-layer protocol sends a packet to a non-global destination address, the node must also identify the intended zone to be used for transmission. Deering, Haberman, Zill 6 Internet Draft IPv6 Scoped Address Architecture September 2000 Note that there is one exception to the above statement: when sending to the IPv6 unicast loopback address, ::1, there is no need to identify the intended zone, even though that address is non-global. Conceptually, the unicast loopback address is a link- local address for a node's loopback interface, and is never assigned to any other interface. Therefore, it unambiguously identifies a single zone of link-scope, that being the phantom loopback link. Although identification of an outgoing interface is sufficient to identify an intended zone (because each interface is attached to no more than one zone of each scope), that is more specific than desired in many cases. For example, when sending to a site-local unicast address, from a node that has more than one interface to the intended site, the upper layer protocol may not care which of those interfaces is used for the transmission, but rather would prefer to leave that choice to the routing function in the IP layer. Thus, the upper-layer requires the ability to specify a zone index, rather than an interface index, when sending to a non-global, non-loopback destination address. There may also be cases where the upper-layer wishes to restrict the choice of outgoing interface to those belonging to a zone of smaller scope than the destination address. For example, when sending to a site-local destination, the upper-layer may wish to specify a specific link on which the packet should be transmitted, but leave the choice of which specific interface to use on that link to the IP layer. 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. Thus, the upper layer requires the ability, when sending a packet, to specify any zone of scope less than or equal to the scope of the destination address, including the case in which the destination address is of global scope. For this reason, an implementation might find it useful to assign a distinct value for each zone index, so that they are unique across all zones, regardless of scope. (Authors' note to selves: Think about distinct values for default at each scope level.) 8. Receiving Packets When an upper-layer protocol receives a packet containing a non- global source or destination address, the zone to which that address pertains can be determined from the arrival interface, because the arrival interface can attached to only one zone of the same scope as the address under consideration. Deering, Haberman, Zill 7 Internet Draft IPv6 Scoped Address Architecture September 2000 9. Forwarding When a router receives a packet addressed to a node other than itself, it must take the zone of the destination and source addresses into account as follows: 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. 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. Note that the above procedure applies for addresses of all scopes, including link-local. Thus, if a router receives a packet with a link-local destination address that is not one of the router's own link-local addresses on the arrival link, the router is expected to try to forward the packet to the destination on that link (subject to successful determination of the destination's link-layer address via the Neighbor Discovery protocol [RFC 2461]). The forwarded packet may be transmitted back out the arrival interface, or out any other interface attached to the same link. 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. An implementation MUST NOT examine additional addresses in the Routing header to determine whether they are crossing boundaries for their scopes. Thus, it is possible, though generally inadvisable, to use a Routing Header to convey a non-global address across its associated zone boundary. 10. Routing When a routing protocol determines that it is operating on a zone boundary, it MUST protect inter-zone integrity and maintain intra- zone connectivity. Deering, Haberman, Zill 8 Internet Draft IPv6 Scoped Address Architecture September 2000 In order to maintain connectivity, the routing protocol must be able to create forwarding information for the global prefixes as well as for all of the zone prefixes for each of its attached zones. The most straightforward way of doing this is to create (conceptual) forwarding tables for each specific zone. To protect inter-zone integrity routers must be selective in the prefix information that is shared with neighboring routers. Routers routinely exchange routing information with neighboring routers. When a router is transmitting this routing information, it must not include any information about zones other than the zones assigned to the interface used to transmit the information. * * * * * ----------- Site ID = X * * | | * +-*---|-------|-----+ * | * i/f 1 i/f 2 | * | * | * | * i/f 5 - * | ******************************* | | | Router | ******************* ******************* | * * | Site ID = Y - i/f 3 * * i/f 4 - Site ID = Z | * * | ******************* ******************* +-------------------+ Figure 2: Multi-Sited Router As an example, the router in Figure 2 must exchange routing information on five interfaces. The information exchanged is as follows: o Interface 1 o All global prefixes o All site prefixes learned from Interfaces 1, 2, and 5 o Interface 2 o All global prefixes o All site prefixes learned from Interfaces 1, 2, and 5 Deering, Haberman, Zill 9 Internet Draft IPv6 Scoped Address Architecture September 2000 o Interface 3 o All global prefixes o All site prefixes learned from Interface 3 o Interface 4 o All global prefixes o All site prefixes learned from Interface 4 o Interface 5 o All global prefixes o All site prefixes learned from Interfaces 1, 2, and 5 By imposing route exchange rules, zone integrity is maintained by keeping all zone-specific routing information contained within the zone. 11. Related Documents The following list is a set of documents that are related to IPv6 address scope: o Site Prefixes in Neighbor Discovery, draft-ietf-ipngwg- site-prefixes-03.txt o An Extension of Format for IPv6 Scoped Addresses, draft- ietf-ipngwg-scopedaddr-format-00.txt o Default Address Selection for IPv6, draft-ietf-ipngwg- default-addr-select-00.txt o Basic Socket Interface Extensions for IPv6, RFC 2553 o Advanced Sockets API for IPv6, draft-ietf-ipngwg- rfc2292bis-01.txt 12. Mobility TBD 13. Textual Representation TBD Deering, Haberman, Zill 10 Internet Draft IPv6 Scoped Address Architecture September 2000 14. Security Considerations The routing section of this document specifies a set of guidelines that allow routers to prevent zone-specific information from leaking out of each site. If site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromise 15. References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1999. [RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC 2473] Conta, A., and Deering, S., "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC 2463] Conta, A., and Deering, S., "Internet Control Message Protocol (RFC 2463) for Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998. [RFC 2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC 2553] Gilligan, R., Thomson, S., Bound, J., and Stevens, W., "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. Acknowledgements Authors' Addresses Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1-408-527-8213 Fax: +1-408-527-8213 Deering, Haberman, Zill 11 Internet Draft IPv6 Scoped Address Architecture September 2000 Email: deering@cisco.com Brian Haberman Nortel Networks 4309 Emperor Blvd. Suite 200 Durham, NC 27703 USA Phone: +1-919-992-4439 Email: haberman@nortelnetworks.com Brian D. Zill Microsoft Research One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1-425-703-3568 Fax: +1-425-936-7329 Email: bzill@microsoft.com Deering, Haberman, Zill 12 --------------8591A9999C4E2DFE9E892603-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 03:14:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2NBCYC18584 for ipng-dist; Thu, 23 Mar 2000 03:12:34 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2NBCPN18577 for ; Thu, 23 Mar 2000 03:12:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA12436 for ; Thu, 23 Mar 2000 03:12:21 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15475 for ; Thu, 23 Mar 2000 04:12:13 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 23 Mar 2000 16:51:04 +0530 Received: from muralia.future.futsoft.com ([10.0.14.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id QAA08831; Thu, 23 Mar 2000 16:32:22 +0530 Received: by localhost with Microsoft MAPI; Thu, 23 Mar 2000 16:41:22 +0530 Message-Id: <01BF94E6.9EFF8CC0.muralia@future.futsoft.com> From: Murali Krishna Ch Reply-To: "muralia@future.futsoft.com" To: "'users@ipv6.org'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: Clarifications in RFC 2460 Date: Thu, 23 Mar 2000 16:41:20 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1) In Page 7 of RFC 2460 its written like this - " Multi- octet fields within each extension header are aligned on their natural boundaries, i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8." Can you please explain this more clearly (if time permits, with examples)? 2) Alignment requirement "xn+y" in Options Section (Sec 4.2) with two examples are not still clear. Can you please explain this furthur? Thank you for your co-operation, 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 Thu Mar 23 11:32:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2NJTIY18943 for ipng-dist; Thu, 23 Mar 2000 11:29:18 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2NJStN18936 for ; Thu, 23 Mar 2000 11:28:56 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA05280 for ipng@sunroof.eng.sun.com; Thu, 23 Mar 2000 11:26:53 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2NDx5N18650 for ; Thu, 23 Mar 2000 05:59:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA20301; Thu, 23 Mar 2000 05:59:06 -0800 (PST) Received: from ns.cstnet-hf.net.cn ([202.102.223.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18739; Thu, 23 Mar 2000 05:58:59 -0800 (PST) Received: from ustc.edu.cn (hpe25.nic.ustc.edu.cn [202.38.64.1]) by ns.cstnet-hf.net.cn (8.8.7/8.8.6) with SMTP id UAA09689; Thu, 23 Mar 2000 20:41:33 -0800 Received: from tarn.isdn.ustc.edu.cn by ustc.edu.cn with ESMTP (8.6.10/16.2) id UAA03941; Thu, 23 Mar 2000 20:24:47 +0800 Date: Thu, 23 Mar 2000 20:36:57 +0800 (CST) From: Wang Hui X-Sender: hwang@tarn.isdn.ustc.edu.cn To: Murali Krishna Ch cc: "'Bob.Gilligan@Eng.Sun.COM'" , "'Erik.Nordmar@Eng.Sun.COM'" , "'users@ipv6.org'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: Doubt on Dual IP layer in RFC 1933 In-Reply-To: <01BF935E.539759E0.muralia@future.futsoft.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, 21 Mar 2000, Murali Krishna Ch wrote: > > > There are two mechanisms > > 1) Dual IP layer > 2) Tunneling > > to keep IPv6 hosts/routers compatible with > IPv4 hosts/routers. > > Query 1: If Dual IP layer mechansim is used alone, how does > an ipv6 packet from ipv6 host/router will be processed > at ipv4-only node? Should there be a v6-to-v4 translator? And should we standize a translating rules? I think we need both of them. > Query 2: Is it necessry to have tunnelling mechanism to be > compatible with IPv4? > > Thanks in advance, > murali. > > > --------------------------------------------------------------------- > The IPv6 Users Mailing List > Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.org > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 23 14:21:11 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2NMJGT19061 for ipng-dist; Thu, 23 Mar 2000 14:19:16 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2NMJ5N19054 for ; Thu, 23 Mar 2000 14:19:05 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with SMTP id e2NMJ5b382064; Thu, 23 Mar 2000 14:19:06 -0800 (PST) Date: Thu, 23 Mar 2000 14:18:25 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Doubt on Dual IP layer in RFC 1933 To: Wang Hui Cc: Murali Krishna Ch , "'users@ipv6.org'" , "'ipng@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Should there be a v6-to-v4 translator? It might be useful in certain transition scenarios. But in other scenarios socks (draft-ietf-ngtrans-socks-gateway-03.txt) or application layer gateways (web proxies, mail relays) on a dual-stack machine will suffice. > And should we standize a translating rules? > I think we need both of them. See RFC 2765 (SIIT) and 2766 (NAT-PT). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 23 14:45:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2NMhVS19110 for ipng-dist; Thu, 23 Mar 2000 14:43:31 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2NMhMN19103 for ; Thu, 23 Mar 2000 14:43:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA04979 for ; Thu, 23 Mar 2000 14:43:23 -0800 (PST) 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 OAA20358 for ; Thu, 23 Mar 2000 14:43:23 -0800 (PST) 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 OAA23259; Thu, 23 Mar 2000 14:43:06 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA22484; Thu, 23 Mar 2000 14:29:20 -0800 X-Virus-Scanned: Thu, 23 Mar 2000 14:29:20 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma022339; Thu, 23 Mar 00 14:29:16 -0800 Message-Id: <4.3.1.2.20000323142940.0192a158@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 23 Mar 2000 14:42:15 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Agenda for Adelaide IETF 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 IPng w.g. sessions at the Adelaide IETF. The chairs will be keeping track of the time allotted for each talk and will take appropriate measure if the speaker runs over. Please send us changes, additions, and corrections. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------- WEDNESDAY, March 29, 2000 0900-1130 (Hall E) Introduction / S. Deering (5 min) Review Agenda / S. Deering (10 min) Document Status / R. Hinden (10 min) Link-shared secrets for ND / D. McDonald (20 min) IPv6 Multicast Address Structure / B. Haberman (15 min) MLD MIB / B. Haberman (5 min) Local Scope IPv6 Networking / R. Hinden (20 min) Scoped Address Architecture draft / S. Deering (5 min) Scoped Address Format / J. Tatyua (15 min) Default Address Selection / R. Draves (20 min) THURSDAY, March 30, 2000 1300-1500 Possible abuse of IPv6 transition technologies / J. I. Hagino (20 min) IPv6 Literal addresses in HTTP1.1 / A. Durand (10 min) IPv6 hooks for AAA registration and "host routing" / E. Nordmark (20 min) AAAv6 / C. Perkins (20 min) Connectathon 2000 & IPv6 Forum interoperability testing (20 min) - Overview of Connectathon testing / C. Williams - NFS/RPC over IPv6 testing - Mobile IPv6 testing / D. Johnson - UNH Conformance: Cthon & Telluride / R. Larocca - IPsec Over IPv6 conformance testing / H. Hoshino ------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 21:27:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2R5Pu420336 for ipng-dist; Sun, 26 Mar 2000 21:25:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2R5PlN20329 for ; Sun, 26 Mar 2000 21:25:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA19191 for ; Sun, 26 Mar 2000 21:25:48 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA19197 for ; Sun, 26 Mar 2000 22:25:46 -0700 (MST) Received: from [169.208.240.15] (ssh.cisco.com [171.69.10.34]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA22767 for ; Sun, 26 Mar 2000 21:25:42 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: Date: Sun, 26 Mar 2000 21:25:34 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: ipngwg meeting slots in Adelaide Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Though the printed agenda only lists one, there will in fact be two meeting slots for the IPng Working Group in Adelaide: Wed 09:00-11:30 Hall E Thu 13:00-15:00 (location to be posted on board in reg. area) 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 Mar 27 17:10:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2S18S220861 for ipng-dist; Mon, 27 Mar 2000 17:08:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2S18KN20854 for ; Mon, 27 Mar 2000 17:08:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA09988 for ; Mon, 27 Mar 2000 17:08:19 -0800 (PST) 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 SAA15497 for ; Mon, 27 Mar 2000 18:08:17 -0700 (MST) 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 RAA26454; Mon, 27 Mar 2000 17:08:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA03038; Mon, 27 Mar 2000 16:52:30 -0800 X-Virus-Scanned: Mon, 27 Mar 2000 16:52:30 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from (dhcp-192-30.ietf.connect.com.au [169.208.192.30]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma002892; Mon, 27 Mar 00 16:52:25 -0800 Message-Id: <4.3.1.2.20000327170008.01857438@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 27 Mar 2000 17:04:37 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "IP Version 6 Addressing Architecture" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Draft Standard: Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-00.txt Pages : 25 Date : 15-Mar-00 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two week from today on April 10, 2000. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 27 17:14:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2S1Cer20880 for ipng-dist; Mon, 27 Mar 2000 17:12:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2S1CVN20873 for ; Mon, 27 Mar 2000 17:12:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA16492 for ; Mon, 27 Mar 2000 17:12:30 -0800 (PST) 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 SAA17954 for ; Mon, 27 Mar 2000 18:12:30 -0700 (MST) 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 RAA27056; Mon, 27 Mar 2000 17:11:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA07528; Mon, 27 Mar 2000 16:55:40 -0800 X-Virus-Scanned: Mon, 27 Mar 2000 16:55:40 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from (dhcp-192-30.ietf.connect.com.au [169.208.192.30]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma007203; Mon, 27 Mar 00 16:55:34 -0800 Message-Id: <4.3.1.2.20000327170826.0189ee90@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 27 Mar 2000 17:10:22 -0800 To: narten@raleigh.ibm.com, Jeffrey Burgan From: Bob Hinden Subject: Request to Advance "Initial IPv6 Sub-TLA ID Assignments" 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 Jeff, 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 Informational RFC: Title : Initial IPv6 Sub-TLA ID Assignments Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain Filename : draft-ietf-ipngwg-iana-tla-03.txt Pages : 5 Date : 14-Jan-00 This document was discussed at the Washington, DC IETF meeting and is being submitted to document the initial IPv6 Sub-TLA ID assignments. 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 Mon Mar 27 17:27:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2S1Ptb20963 for ipng-dist; Mon, 27 Mar 2000 17:25:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2S1PiN20956 for ; Mon, 27 Mar 2000 17:25:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA24697 for ; Mon, 27 Mar 2000 17:25:44 -0800 (PST) Received: from lychee.itojun.org (dhcp-192-9.ietf.connect.com.au [169.208.192.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25659 for ; Mon, 27 Mar 2000 18:25:41 -0700 (MST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e2S1PH110130; Tue, 28 Mar 2000 10:25:17 +0900 (JST) To: Bob Hinden cc: ipng@sunroof.eng.sun.com In-reply-to: hinden's message of Mon, 27 Mar 2000 17:04:37 PST. <4.3.1.2.20000327170008.01857438@mailhost.iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" From: Jun-ichiro itojun Hagino Date: Tue, 28 Mar 2000 10:25:17 +0900 Message-ID: <10128.954206717@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is a IPng working group last call for comments on advancing the >following document as a Draft Standard: > Title : IP Version 6 Addressing Architecture > Author(s) : R. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-00.txt > Pages : 25 > Date : 15-Mar-00 >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the authors. This last call period will end two >week from today on April 10, 2000. Based on analysis outlined in the following URL, I would suggest adding the following into the document. http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-00a.txt I'm tempted to add more lines like "SHOULD drop invalid packets", however, the document may not be the best place to discuss node behavior... itojun --- *** draft-ietf-ipngwg-addr-arch-v3-00.txt- Tue Mar 28 10:14:35 2000 --- draft-ietf-ipngwg-addr-arch-v3-00.txt Tue Mar 28 10:23:05 2000 *************** *** 573,578 **** --- 573,586 ---- |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ + The IPv4 address embedded into an IPv4-compatible IPv6 address MUST be + an IPv4 unicast address. For example, the following lists some of + non-conforming IPv4 address prefixes [IANA]: + - IANA reserved, usually used for unspecified address (0.0.0.0/8) + - IANA reserved, usually used for loopbacks (127.0.0.0/8) + - IPv4 multicast (224.0.0.0/4) + - IANA reserved, usually used for subnet broadcast (255.0.0.0/8) + - subnet broadcast addresses A second type of IPv6 address which holds an embedded IPv4 address is also defined. This address is used to represent the addresses of *************** *** 586,591 **** --- 594,600 ---- |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ + The form of address does not usually appear on the wire. [RFC2553] 2.5.5 NSAP Addresses *************** *** 1315,1320 **** --- 1324,1332 ---- [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC2467, December 1998. + [IANA] "Internet protocol address space", + http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space + [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. *************** *** 1329,1334 **** --- 1341,1349 ---- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, BCP14, March 1997. + + [RFC2553] R. Gilligan, S. Thomson, J. Bound, W. Stevens, + "Basic Socket Interface Extensions for IPv6", RFC2553, March 1999. [TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC2470, December 1998. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 21:20:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2S5J1o21105 for ipng-dist; Mon, 27 Mar 2000 21:19:01 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2S5IqN21098 for ; Mon, 27 Mar 2000 21:18:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA17645 for ; Mon, 27 Mar 2000 21:18:51 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA12967 for ; Mon, 27 Mar 2000 22:18:43 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 28 Mar 2000 10:57:15 +0530 Received: from muralia ([10.0.14.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA01655; Tue, 28 Mar 2000 10:37:34 +0530 Received: by localhost with Microsoft MAPI; Tue, 28 Mar 2000 10:46:37 +0530 Message-Id: <01BF98A2.E4C4F460.muralia@future.futsoft.com> From: Murali Krishna Ch Reply-To: "muralia@future.futsoft.com" To: "users@ipv6.org" , "'itojun@iijlab.net'" , "6bone@isi.edu" <6bone@isi.edu>, "'ipng@sunroof.eng.sun.com'" Subject: Path MTU in IPv6 Date: Tue, 28 Mar 2000 10:46:36 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How does transport layers are innformed about ICMP "packet too big message" ? and what is the best way? thanks in advance, 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 Mon Mar 27 22:25:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2S6Nrl21257 for ipng-dist; Mon, 27 Mar 2000 22:23:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2S6NiN21250 for ; Mon, 27 Mar 2000 22:23:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA21064 for ; Mon, 27 Mar 2000 22:23:43 -0800 (PST) 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 XAA09973 for ; Mon, 27 Mar 2000 23:23:42 -0700 (MST) 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 WAA16163; Mon, 27 Mar 2000 22:23:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id WAA27507; Mon, 27 Mar 2000 22:06:55 -0800 X-Virus-Scanned: Mon, 27 Mar 2000 22:06:55 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from (dhcp-33-137.ietf.connect.com.au [169.208.33.137]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma027361; Mon, 27 Mar 00 22:06:49 -0800 Message-Id: <4.3.1.2.20000327222053.0186cac0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 27 Mar 2000 22:22:31 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: ipngwg meeting slots in Adelaide In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The second meeting location is now posted. It will be in Hall E. Bob At 09:25 PM 3/26/2000 -0800, Steve Deering wrote: >Though the printed agenda only lists one, there will in fact be two >meeting slots for the IPng Working Group in Adelaide: > > Wed 09:00-11:30 Hall E > Thu 13:00-15:00 (location to be posted on board in reg. area) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 04:19:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2SCHJk21427 for ipng-dist; Tue, 28 Mar 2000 04:17:19 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2SCH8N21420 for ; Tue, 28 Mar 2000 04:17:08 -0800 (PST) Received: from lillen ([192.9.10.203]) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with SMTP id e2SCH5G874755; Tue, 28 Mar 2000 04:17:06 -0800 (PST) Date: Mon, 27 Mar 2000 22:47:47 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" To: Jun-ichiro itojun Hagino Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <10128.954206717@lychee.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Re: IPv4-mapped address. > + The form of address does not usually appear on the wire. [RFC2553] RFC 2765 (SIIT) does state that these addresses may appear on the wire. Thus I don't see how adding the above sentence brings more clarity to the specification. In addition, it would make sense to specify the IPv4-translatable addresses (in SIIT) in the addressing architecture in section 2.5.4 (those addresses are ::ffff:0:a.b.c.d where a.b.c.d is an IPv4 address. Note 16 bits of zero between ffff and the IPv4 address) 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 Mar 28 07:22:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2SFKIu21534 for ipng-dist; Tue, 28 Mar 2000 07:20:18 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2SFK8N21527 for ; Tue, 28 Mar 2000 07:20:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA01681 for ; Tue, 28 Mar 2000 07:20:08 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02934 for ; Tue, 28 Mar 2000 08:20:07 -0700 (MST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 2C6C5151FDE; Tue, 28 Mar 2000 09:20:03 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 204BB148506; Tue, 28 Mar 2000 09:20:03 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id ACF794D404; Tue, 28 Mar 2000 09:19:56 -0600 (CST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 252BD43982; Tue, 28 Mar 2000 09:19:56 -0600 (CST) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id KAA0000653750; Tue, 28 Mar 2000 10:20:01 -0500 (EST) From: Jim Bound Message-Id: <200003281520.KAA0000653750@anw.zk3.dec.com> To: Erik Nordmark Cc: Jun-ichiro itojun Hagino , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" In-reply-to: Your message of "Mon, 27 Mar 2000 22:47:47 PST." Date: Tue, 28 Mar 2000 10:20:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, I agree with you on mapped addresses. But last I checked 2373 says they can't be on the wire? But I will recheck. /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 Mar 28 07:33:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2SFVDJ21641 for ipng-dist; Tue, 28 Mar 2000 07:31:13 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2SFV1N21632 for ; Tue, 28 Mar 2000 07:31:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA02853; Tue, 28 Mar 2000 07:30:52 -0800 (PST) Received: from lychee.itojun.org (dhcp-192-9.ietf.connect.com.au [169.208.192.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23139; Tue, 28 Mar 2000 07:30:49 -0800 (PST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e2SFU3704573; Wed, 29 Mar 2000 00:30:03 +0900 (JST) To: Erik Nordmark cc: Bob Hinden , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Mon, 27 Mar 2000 22:47:47 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" From: Jun-ichiro itojun Hagino Date: Wed, 29 Mar 2000 00:30:03 +0900 Message-ID: <4571.954257403@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Re: IPv4-mapped address. >> + The form of address does not usually appear on the wire. [RFC2553] >RFC 2765 (SIIT) does state that these addresses may appear on the wire. >Thus I don't see how adding the above sentence brings more clarity to >the specification. (after talking with eric) I see, I drop the suggestion to add notice about IPv4 mapped address in addr-arch-v3-00. Though separate topic but worth mentioning: SIIT requires IPv6 routers to forward IPv6 native packets with IPv4 mapped address as is. Therefore, I will need to rephrase abuse draft to something like: "Check IPv6 packets in following occasions, and drop the packet if you see IPv4 mapped address on the packet: - last stage of IPv6 input logic, when IPv6 packet is accepted by the node itself (after forwarding decision) Note: for SIIT to work, IPv6 routers needs to forwards packets with IPv4 mapped source/destination - transport layer input, like TCP/UDP." 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 Mar 28 16:48:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2T0kXt22018 for ipng-dist; Tue, 28 Mar 2000 16:46:33 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2T0kMN22011 for ; Tue, 28 Mar 2000 16:46:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA14296 for ; Tue, 28 Mar 2000 16:46:22 -0800 (PST) Received: from lychee.itojun.org (dhcp-192-9.ietf.connect.com.au [169.208.192.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06036 for ; Tue, 28 Mar 2000 16:46:17 -0800 (PST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e2T0j6p01005; Wed, 29 Mar 2000 09:45:06 +0900 (JST) To: richdr@microsoft.com cc: ipng@sunroof.eng.sun.com Subject: comments to src/dst selection X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Wed, 29 Mar 2000 09:45:05 +0900 Message-ID: <1003.954290705@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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. like: ::1/128 50 1 1 fe80::%loopback/10 40 2 2 fe80::%ether0/10 40 3 3 fec0::%kame/10 30 4 4 fec0::%wide/10 30 5 5 ::/0 20 6 6 2002::/16 10 7 7 ::/96 0 8 8 Looking up policy table for fec0::1%kame would pick 4th item on the table. I should also note that there are ethernet cards with universal/local bit set to local. I think we can't use u/l bit to determine anonymous address (for privacy). I vote for deprecating non-anonymous addersses. 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 Mar 28 19:06:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2T33pY22160 for ipng-dist; Tue, 28 Mar 2000 19:03:51 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2T33fN22153 for ; Tue, 28 Mar 2000 19:03:41 -0800 (PST) Received: (from samita@localhost) by jurassic.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2T33g6999228; Tue, 28 Mar 2000 19:03:42 -0800 (PST) Date: Tue, 28 Mar 2000 19:03:42 -0800 (PST) Message-Id: <200003290303.e2T33g6999228@jurassic.eng.sun.com> From: Samita.Chakrabarti@eng.sun.com To: vardhan@oflume.zk3.dec.com Cc: ipng@sunroof.eng.sun.com, samita@jurassic.eng.sun.com Subject: Re: RIPNG question Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If there are 2 routers Ra and Rb on a network advertising prefixes > Pa and Pb, nodes that are not routers should autoconfigure all of the > advertised prefixes, and should have both Ra and Rb on their > default router list. I'm not sure I see the problem you are listing > above. Could you please illustrate this with an example? > > --Sowmini > The example in my mind is : Pa---> <----Pb Pn---> -------- ------ | |------------------------------| |---------------- | Ra | | | Rb | | |------- -------- ------- ----- | Node1 | | | | | | node2| -------- -------- Pa:X Pb:X Pn:Y Now if node2 wants to do "ping Node1" with address Pa:X, then Pa:X will be unreachable from node2. Because Rb does not autoconfigure with other router's advertisements and RIPNG of Ra advertises Pa with metric 16 on the link, so Rb will not be able to resolve the route for 'Pa:X'. However, node2 will not have have any problem reaching Node1 using address Pb:X. So it depends what address of Node1 is returned by the name server of node2. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 19:24:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2T3Ldx22195 for ipng-dist; Tue, 28 Mar 2000 19:21:39 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2T3LUN22188 for ; Tue, 28 Mar 2000 19:21:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA21070 for ; Tue, 28 Mar 2000 19:21:16 -0800 (PST) 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 UAA26808 for ; Tue, 28 Mar 2000 20:21:14 -0700 (MST) 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 EAA95608; Wed, 29 Mar 2000 04:21:12 +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 EAA24944; Wed, 29 Mar 2000 04:21:02 +0100 (BST) Message-ID: <38E17650.C8677DE8@hursley.ibm.com> Date: Tue, 28 Mar 2000 21:19:44 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: comments to src/dst selection References: <1003.954290705@lychee.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > I vote for deprecating non-anonymous addersses I'm definitely and strongly against this. I am totally happy for everyone to know my IEEE address, in fact I had it in my .sig file for a while. >From the point of view of a corporate network manager who needs to track assets as they move around the corporation, anonymous addresses would be a disaster. We have to offer an anonymous alternative for those who want this degree of privacy, but it should be simply an alternative to the normal type of address. And I think it should be a config option whether anonymous addresses get priority. 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 Mar 28 19:43:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2T3g3H22240 for ipng-dist; Tue, 28 Mar 2000 19:42:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2T3fqN22233 for ; Tue, 28 Mar 2000 19:41:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA22925 for ; Tue, 28 Mar 2000 19:41:51 -0800 (PST) Received: from lychee.itojun.org (dhcp-192-9.ietf.connect.com.au [169.208.192.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA23193 for ; Tue, 28 Mar 2000 19:41:45 -0800 (PST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e2T3eVv00822; Wed, 29 Mar 2000 12:40:31 +0900 (JST) To: Brian E Carpenter cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com In-reply-to: brian's message of Tue, 28 Mar 2000 21:19:44 CST. <38E17650.C8677DE8@hursley.ibm.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments to src/dst selection From: Jun-ichiro itojun Hagino Date: Wed, 29 Mar 2000 12:40:31 +0900 Message-ID: <820.954301231@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I vote for deprecating non-anonymous addersses >I'm definitely and strongly against this. I am totally happy for everyone >to know my IEEE address, in fact I had it in my .sig file for a while. >From the point of view of a corporate network manager who needs to track >assets as they move around the corporation, anonymous addresses would be >a disaster. Sorry I was unclear. I should have written like this: for doing anonymous address, I would vote for a configuration where we mark non-anonymous addresses as "deprecate" IPv6 address. There were 3 plans for supporting privacy thing from rich's slides, they are: - mark non-anonymous address as "deprecate" address so that we don't use it as source - use u/l bit - implementation remembers which address was configured for privacy thing I voted for the first one. Again, sorry for confusion. 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 Mar 29 06:22:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2TEL7k22529 for ipng-dist; Wed, 29 Mar 2000 06:21:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2TEKxN22522 for ; Wed, 29 Mar 2000 06:20:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA04912 for ; Wed, 29 Mar 2000 06:20:58 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14878 for ; Wed, 29 Mar 2000 07:20:58 -0700 (MST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id E54CD60F; Wed, 29 Mar 2000 09:20:57 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 673A4573; Wed, 29 Mar 2000 09:20:57 -0500 (EST) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000728045; Wed, 29 Mar 2000 09:20:57 -0500 (EST) Date: Wed, 29 Mar 2000 09:20:57 -0500 (EST) From: Sowmini Varadhan Message-Id: <200003291420.JAA0000728045@anw.zk3.dec.com> To: Samita.Chakrabarti@eng.sun.com, vardhan@oflume.zk3.dec.com Subject: Re: RIPNG question Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From owner-ipng@sunroof.eng.sun.com Tue Mar 28 22:09:04 2000 > >> If there are 2 routers Ra and Rb on a network advertising prefixes >> Pa and Pb, nodes that are not routers should autoconfigure all of the >> advertised prefixes, and should have both Ra and Rb on their >> default router list. I'm not sure I see the problem you are listing >> above. Could you please illustrate this with an example? >> >> --Sowmini >> > > >The example in my mind is : > > Pa---> <----Pb Pn---> >-------- ------ >| |------------------------------| |---------------- >| Ra | | | Rb | | >|------- -------- ------- ----- > | Node1 | | | > | | | node2| > -------- -------- > Pa:X > Pb:X Pn:Y > > > >Now if node2 wants to do "ping Node1" with address Pa:X, then Pa:X will Only if Ra was not advertising Pa with metric 1 on the link between Ra and Rb. If Ra was advertising Pa with metric 1 (as I believe it should, according to RFC 2080, Section 2.5.2) then Rb would forward packets with {src Pn:Y, dst: Pa:X} to Ra, and then Ra would forward the packet to Node 1. Ra may send a redirect to Rb while forwarding the packet to Node 1, and Rb would ignore the redirect (as it should), but there's no unreachability problem between Pn:Y and Pa:X here. >other router's advertisements and RIPNG of Ra advertises Pa with >metric 16 on the link, so Rb will not be able to resolve the route ^^^^^^^^^^^^^^^^^^^^^ Where does the RFC 2080 require or specify this? Please see Section 2.6 in RFC 2080, which I have quoted in my previous message dated Fri, 17 Mar 2000 13:27:33 -0500 (EST)) on this thread. --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 30 10:19:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2UIGaq23441 for ipng-dist; Thu, 30 Mar 2000 10:16:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2UIGON23434 for ; Thu, 30 Mar 2000 10:16:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA25611 for ; Thu, 30 Mar 2000 10:16:24 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06813 for ; Thu, 30 Mar 2000 10:16:23 -0800 (PST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id C258AE0D; Thu, 30 Mar 2000 13:16:21 -0500 (EST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id A8CF3DC8 for ; Thu, 30 Mar 2000 13:16:21 -0500 (EST) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0001010022; Thu, 30 Mar 2000 13:16:21 -0500 (EST) Date: Thu, 30 Mar 2000 13:16:21 -0500 (EST) From: Jack McCann Message-Id: <200003301816.NAA0001010022@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 30 18:02:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2V21Ej23911 for ipng-dist; Thu, 30 Mar 2000 18:01:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2V215N23904 for ; Thu, 30 Mar 2000 18:01:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA16486 for ; Thu, 30 Mar 2000 18:01:06 -0800 (PST) Received: from dthaler.microsoft.com ([131.107.152.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA06435 for ; Thu, 30 Mar 2000 19:01:05 -0700 (MST) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id TAA11155; Thu, 30 Mar 2000 19:34:48 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <200003310334.TAA11155@dthaler.microsoft.com> Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" In-Reply-To: <4.3.1.2.20000327170008.01857438@mailhost.iprg.nokia.com> from Bob Hinden at "Mar 27, 2000 5: 4:37 pm" To: hinden@iprg.nokia.com (Bob Hinden) Date: Thu, 30 Mar 2000 19:34:44 -0800 (PST) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's my review of the multicast section of the draft. (My proposed fixes are in draft-haberman-ipngwg-mcast-arch-01.txt, but I will try to repeat everything relevant here.) Section 2.7: The list of multicast scopes is arguably out of date... RFC 2365 defines the "Local Scope" as (to paraphrase) the smallest enclosing scope larger than link-local, and therefore associates it with scop 3. This scope is used by MZAP, and is also a requirement by the zeroconf wg, etc. Also, draft-ietf-malloc-arch-04.txt (The Internet Multicast Address Allocation Architecture) has already been submitted to the IESG for consideration as Informational. It proposes an "Allocation Scope" (which could conceivably apply to other purposes as well, but couldn't think of any more general name) which would be scop 6. (The argument being that most of the time it's identical to site, but could need to be larger in some scenarios.) Section 2.7.1: Regarding FF0x::0 table... is a table really necessary here? It makes you want to look more closely just to see if all 16 are there. Proposed text: > The following well-known multicast addresses are pre-defined: > > Reserved Multicast Addresses: FF0x:0:0:0:0:0:0:0 and possibly adding something like: > where "x" indicates all scop values. Section 2.7 states: > The "meaning" of a permanently assigned multicast address is > independent of the scope value. Section 2.7.1's definitions of All-nodes, All-Routers, and Solicited-node addresses appear to contradict the above statement because they specifically _don't_ seem to apply to all scopes. Some language to clarify this seems warranted. Proposed text (and perhaps SHOULD NOT should be MUST NOT below?) > All Nodes Addresses: FF0x:0:0:0:0:0:0:1 > > The above multicast addresses identify the group of all IPv6 nodes > within a given scope. The All-Nodes-Address for scopes larger than > scope 2 (link-local) SHOULD NOT be used or joined by nodes. > > All Routers Addresses: FF0x:0:0:0:0:0:0:2 > > The above multicast addresses identify the group of all IPv6 routers > within a given scope. The All-Routers-Address for scopes other than > scope 1 (node-local), 2 (link-local), and 5 (site-local) SHOULD NOT be > used or joined by routers. > > Solicited-Node Address: FF0x:0:0:0:0:1:FFXX:XXXX > > The above multicast address is computed as a function of a node's > unicast and anycast addresses, and SHOULD NOT be used or joined for any > scope value other than scope 2 (link-local). [...rest of current text...] -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------