From masaki@merit.edu Thu Aug 1 00:28:57 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Wed, 31 Jul 1996 19:28:57 -0400 Subject: RIPng In-Reply-To: Your message of "Wed, 31 Jul 1996 18:07:02 EDT." <9607312207.AA23783@fwasted.zk3.dec.com> Message-ID: <199607312329.TAA11809@home.merit.edu> Allison writes, >> Yes. Craig Labovitz (MERIT) has developed a RIPv2 for IPv6, >> which some sites on this list have been testing. Craig and I are working on. It works on INRIA freebsd. It need some modification to make it work on a tunnel, but soon. Jim writes, > We have the following implementations running RIPng to start using > routing: > > 1. Telebit Router > 2. Digital Router > 3. Bay Networks Router > 4. Sun Host > 5. Digital Host (Static Routes now) > > So lets use them. UNH will have both Digital and Bay Routers. There > will also be a Digital IPv6 router at G6 soon. Telebit is already doing > this I think. > > So lets just do it and quit talking about it the code does exist. > > /jim I want to know how they implement ripng on a tunnel. I think that the ripng draft doesn't clearly say in case of tunneling. There is no link-local address and maybe no multicasting depending on its sit implementation. I'm afraid that we need interoperablity check on ripng as well. (Have it done at UNH? I'm sorry I'm a newcomer) If some of 6bone sites can run ripng, I'd like to make a temporal tunnel to it in order to check interoperablity with our implementation. Masaki From bound@zk3.dec.com Thu Aug 1 00:18:16 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 31 Jul 96 19:18:16 -0400 Subject: RIPng In-Reply-To: Your message of "Wed, 31 Jul 96 18:07:02 EDT." <9607312207.AA23783@fwasted.zk3.dec.com> Message-ID: <9607312318.AA28132@fwasted.zk3.dec.com> If we are not going to do RIPng in 1 month then lets use Alain's scheme for now at least for the star topology. And I am listening more to people who are sending packets on the network and doing this real time than the theories to get this up and running. ESPECIALLY IF THEY TELL SOMEONE WORKING THEIR BUTT OFF THAT THEIR IDEA IS TERRIBLE (they almost got a real flameagram from me on that one). And I have respect for those who were at the bake-off and ran real code under test with other implementations than those who did not. Nov 96 will be the next bake off hope we have more implementations. This is the 6bone list not the IETF list and different rules. We need to see what happens via deployment of IPv6 thats the purpose of this work not to appease any interests other than that. Right now we are 60 days ahead of where I thought we would be I think this thing is going to explode and lots of users will be coming on quick. Based on my intelligence in the market. Even if we do get RIPng working that does not fix the administrative problems of configured tunnels. I still think it needs to be automated simply because its part of transition to IPv6. We should be thinking about that and if we come up with an idea do it. Changing RFC 1897 might cause more pain than its worth, but I don't think we should rule it out just yet. /jim From deering@parc.xerox.com Thu Aug 1 02:05:06 1996 From: deering@parc.xerox.com (Steve Deering) Date: Wed, 31 Jul 1996 18:05:06 PDT Subject: RIPng In-Reply-To: bound's message of Wed, 31 Jul 96 16:18:16 -0800. <9607312318.AA28132@fwasted.zk3.dec.com> Message-ID: <96Jul31.180507pdt."75270"@digit.parc.xerox.com> > If we are not going to do RIPng in 1 month then lets use Alain's scheme for > now at least for the star topology. Note that I was agreeing with Alain regarding the basic topology of this stage of the 6bone, that is, a mesh of "backbone" or "core" routers, with individual sites or sub-communities hung off that. Any problem with insufficient aggregation should only be in the backbone routers, since the leaf sites or communities can just use default for all off-site or out-of- community destinations. There seems to be some disagreement on the severity of the backbone problem, but if the folks managing those routers find it too much of a burden, and can't solve it soon enough by getting RIPng running, by all means let's aggregate routes as Alain suggested. Though, as Pedro pointed out, we don't need to change the addressing format for that. To aggregate all the European sites, for example, just pick one of the European AS numbers currently being used in the 6bone and get all European sites to renumber their nodes under that one AS number -- they'll still have the IPv4 prefix in there to ensure uniqueness. > And I am listening more to people who are sending packets on the network > and doing this real time than the theories to get this up and running. Are you suggesting that I should shut up? > And I have respect for those who were at the bake-off and ran real code > under test with other implementations than those who did not. Let's all try to maintain respect for each other, OK? This whole enterprise is fragile enough as it is without the stress of squabbling among ourselves. Steve From bound@zk3.dec.com Thu Aug 1 04:20:08 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Wed, 31 Jul 96 23:20:08 -0400 Subject: RIPng In-Reply-To: Your message of "Wed, 31 Jul 96 18:05:06 PDT." <96Jul31.180507pdt."75270"@digit.parc.xerox.com> Message-ID: <9608010320.AA04534@fwasted.zk3.dec.com> >> If we are not going to do RIPng in 1 month then lets use Alain's scheme for >> now at least for the star topology. >Note that I was agreeing with Alain regarding the basic topology of this >stage of the 6bone, that is, a mesh of "backbone" or "core" routers, with >individual sites or sub-communities hung off that. Any problem with >insufficient aggregation should only be in the backbone routers, since the >leaf sites or communities can just use default for all off-site or out-of- >community destinations. There seems to be some disagreement on the severity >of the backbone problem, but if the folks managing those routers find it >too much of a burden, and can't solve it soon enough by getting RIPng >running, by all means let's aggregate routes as Alain suggested. Though, >as Pedro pointed out, we don't need to change the addressing format for that. >To aggregate all the European sites, for example, just pick one of the >European AS numbers currently being used in the 6bone and get all European >sites to renumber their nodes under that one AS number -- they'll still >have the IPv4 prefix in there to ensure uniqueness. I think we are in violent agreement. What I think would be good is to not force anyone to use a "path" UNH-NRL-WIDE if they can go to MIT-UNIVARIZONA-WIDE. It should be open to what path is available like on the Internet today based on some metric of choice. I also think this gives us a better system test scenario and hopefully with ripng. I think it should be loose, complex, and break so we understand where it breaks. Too much order in the beginning will cause us to get secure in a bogus way. >> And I am listening more to people who are sending packets on the network >> and doing this real time than the theories to get this up and running. >Are you suggesting that I should shut up? No. I am running your architecture why would I want that. No one knows it better than you. I am just saying that the discussion of how maybe to automate the tunnels should be OK. The reason I brought it up is cause I saw the problem if I had to do this for 1000 nodes. In addition it affects the transition. When you speak as above its clear, precise, and 99% right. But thats not what I heard in all the mail. I heard people who are not Steve Deering, or Brian Carpenter, or Christian Huitema, et al. (who I consider people I automatically listen too) tell a person doing this work and who themselves I don't think are even putting packets on the wire that, the other person does not have a clue. Anyone in that category should not shut up but I am not going to listen to them. OK. I can see how you got what you did out of what I said and I am sorry about that but that was not my intention. >> And I have respect for those who were at the bake-off and ran real code >> under test with other implementations than those who did not. >Let's all try to maintain respect for each other, OK? This whole enterprise >is fragile enough as it is without the stress of squabbling among ourselves. I agree. But I am not going to just sit here and watch abuse either, and you know I can't do that even if I wanted to. /jim From kazu@is.aist-nara.ac.jp Thu Aug 1 05:10:22 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Thu, 01 Aug 1996 13:10:22 +0900 Subject: Things to do Message-ID: <14007.838872622@mine.aist-nara.ac.jp> Now I feel much better than yesterday since many people started talking about dynamic routing. It would be appreciated if we have the following rough consensus: (1) At present we tolerate a pain from static routing and manage routing information somehow. (2) The next routing protocol is RIPng. We will test interoperability for RIPng at the next IOL and then move to RIPng after that if available. (3) Before 6bone become so large that RIPng is not enough, we will move to hierarchical routing. But now is not the time to do so. (4) Now we should discuss the following issues: (a) automating tunnels as Jim said (b) clarifying the RIPng spec especially on tunnels as Masaki said --Kazu From bound@zk3.dec.com Thu Aug 1 05:05:56 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Thu, 01 Aug 96 00:05:56 -0400 Subject: more tunnels and what to do next (fwd) In-Reply-To: Your message of "Wed, 31 Jul 96 23:01:27." <199608010301.XAA25567@agate.cs.unh.edu> Message-ID: <9608010405.AA05968@fwasted.zk3.dec.com> Steve, >By the way I thought the large addresses were created for heirachial routing >and 6bone was something experimental where we can try this out. This is what is bugging me. We have to be able to play and experiment now as I think IPv6 will be deployed in the market 1 year from now and on the Internet and on Intranets. I hope the big ISPs join in but if they don't lots of small ones will and I think the mgmt consulting firms too who will be ISPs for Intranets that are fortune 100 companies. We will have no time like the present to play like this again (unless we keep an IPv6 research Internet up which is a really good thing to do IMHO) and I think that is what I and others are wanting to do. Not cast anything in concrete or even build or change an existing IPv6 draft. I am totally convinced IPv6 must be deployed and real products can be built to gain revenune, market share, and $$$$ for anyone wishing to move users to IPv6. So we have about 1 year to get this right on the 6bone. I realize we don't want to waste our time either. We have gotten a lot of good ideas for IPv6 from the implementor meetings and implementations in general. I think the 6bone can do that for us too especially around transition. /jim From deering@parc.xerox.com Thu Aug 1 06:55:22 1996 From: deering@parc.xerox.com (Steve Deering) Date: Wed, 31 Jul 1996 22:55:22 PDT Subject: more tunnels and what to do next (fwd) In-Reply-To: qv's message of Tue, 30 Jul 96 19:54:07 -0800. <199608010254.WAA25537@agate.cs.unh.edu> Message-ID: <96Jul31.225522pdt."75270"@digit.parc.xerox.com> Quaizar, > I actually meant almost the same, though stupid enough not to be able to > express it well in my mails. No, it's mostly my fault for spouting off without carefully reading the mail I'm responding to. Anyway, I glad to see we are all in approximate agreement, even if the consensus is a bit rough. > Hence we have a few core routers each routing for a big cloud and the cloud > should have one common prefix (desirable) or a few, not a lots, i.e. > one for each subnet. You should at least be aggregating multiple subnets from a single site already. Is each individual subnet showing up in all the default-free routers?? > By the way I thought the large addresses were created for heirachial routing > and 6bone was something experimental where we can try this out. Absolutely. I didn't mean to discourage experiments in hierarchical routing. However, simply aggregating a handful of static routes into a single static route isn't going to teach us anything new about hierarchical routing, and it sounded like the main motivation for the proposed aggregation was not to demonstrate or experiment with hierarchical routing, but simply to reduce a configuration burden that some other folks think isn't such a big deal at the moment. Certainly, as soon as people have implementations of actual v6 routing protocols that they wish to try out in a hierarchical fashion on the 6bone, they should be encouraged and helped to do so. I like Kazu's description of the set of steps to be taken to get to that stage. Steve From brian@dxcoms.cern.ch Thu Aug 1 09:12:42 1996 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Thu, 1 Aug 1996 10:12:42 +0200 (MET DST) Subject: more tunnels and what to do next (fwd) In-Reply-To: <199607312209.AA26407@metro.isi.edu> from "Allison Mankin" at Jul 31, 96 06:12:50 pm Message-ID: <9608010812.AA09191@dxcoms.cern.ch> Allison, > > > Flat routing with RIPng should suffice for hundreds of routes; beyond that, > > we clearly need hierarchical routing, but that should probably also > > coincide with moving to "real" addresses, rather than the test addresses. > > > > > Those quotes around real are very poignant. > Can we later this year have an interim draft > for aggregatable addresses? Huh? draft-ietf-ipngwg-unicast-addr-fmt-04.txt > I would like to see it be > geographic addressing without all the details resolved: If you have a solution for geographic addressing that works, unlike all previous attempts, pls write it up. Brian From shand@shand.reo.dec.com Thu Aug 1 10:53:47 1996 From: shand@shand.reo.dec.com ( (Mike Shand REO2 G/C2 DTN:830-4424)) Date: Thu, 01 Aug 96 10:53:47 +0100 Subject: RIPng In-Reply-To: Your message of "Wed, 31 Jul 96 19:28:57 EDT." <199607312329.TAA11809@home.merit.edu> Message-ID: <9608010953.AA12503@shand.reo.dec.com> > I want to know how they implement ripng on a tunnel. I think that > the ripng draft doesn't clearly say in case of tunneling. There > is no link-local address and maybe no multicasting depending on > its sit implementation. I'm afraid that we need interoperablity > check on ripng as well. (Have it done at UNH? I'm sorry I'm a > newcomer) If some of 6bone sites can run ripng, I'd like to make > a temporal tunnel to it in order to check interoperablity with > our implementation. Well, we don't at the moment. At first sight it seems pretty trivial. You just define a pseudo pt-pt interface for the tunnel and run RIPng (or whatever other routing protocol you fancy) over that interface. Presumably you assign a link local address by whatever means you would normally use for a pt-pt (e.g. PPP) link. The MTU would have to be set to take account of the additional IPv4 header. There would be no broadcast/multicasting. However, thinking about it some more, it starts to get interesting. Suppose the IPv4 tunnel becomes unidirectional, either because it was wrongly configured, or because the underlying IPv4 routing becomes unidirectional. Do we need any special mehanisms to dectect such misconfiguiration? What other gotchas might be lurking? Do we need to send router advertisements over such a link which should only have another router at the other end? Presumably so, since it could in theory be a host running RIP in listen mode (say). etc. etc. I think we can make it work, but it looks like we need either some mods to RIPng or a separate draft to specify exectly how it is supposed to be done. Has anyone else actually got this working? Mike From roque@di.fc.ul.pt Thu Aug 1 11:59:01 1996 From: roque@di.fc.ul.pt (Pedro Roque Marques) Date: Thu, 1 Aug 1996 11:59:01 +0100 Subject: RIPng In-Reply-To: <9607312318.AA28132@fwasted.zk3.dec.com> References: <9607312207.AA23783@fwasted.zk3.dec.com> <9607312318.AA28132@fwasted.zk3.dec.com> Message-ID: <199608011059.LAA11527@oberon.di.fc.ul.pt> >>>>> "Jim" == bound writes: Jim> And I am listening more to people who are sending packets on Jim> the network and doing this real time than the theories to get Jim> this up and running. ESPECIALLY IF THEY TELL SOMEONE WORKING Jim> THEIR BUTT OFF THAT THEIR IDEA IS TERRIBLE (they almost got a Jim> real flameagram from me on that one). You have every right to flame, Jim. Although i didn't ment the interpretation that the phrase got i recognise that was a very bad choice of words and i would like give you my public apologies for that. I ask you to consider that for a non native english speaker it is sometimes hard to know the intensity of an expression. I still think that it is not the way to go. Please disregard the first sentence in that mail and consider the rest of it. Jim> And I have respect for those who were at the bake-off and ran Jim> real code under test with other implementations than those Jim> who did not. My stuff is working, although i constantly find new problems with it every day. As we have no money to participate in the IOL consortium the only testing we can do is via the 6bone. Everybody has been very cooperative there and we're making good progress. Basically i think people are discussing problems that there is no need to solve now. I believe we should concentrate on getting the basic working and then build the rest of the building. I only have one implementation other than my own here, so i cannot comment from first hand knowledge, but the comments i hear is that most implementations are still on very raw state. To give you the example i know off, it is not very interesstening to have a machine capable of RIPng but not capable of configured tunneling, that can't delete routes, has random source address selection and so on. I'm not complaining, they do a better job than i do in some aspects ... regards, Pedro. From Alain.Durand@imag.fr Thu Aug 1 00:08:57 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Thu, 1 Aug 1996 01:08:57 +0200 Subject: RIPng & what to do next. In-Reply-To: Pedro Roque Marques "Re: RIPng" (Aug 1, 11:59am) References: <9607312207.AA23783@fwasted.zk3.dec.com> <9607312318.AA28132@fwasted.zk3.dec.com> <199608011059.LAA11527@oberon.di.fc.ul.pt> Message-ID: <960801010857.ZM11096@rama.imag.fr> On Aug 1, 11:59am, Pedro Roque Marques wrote: > Subject: Re: RIPng > Basically i think people are discussing problems that there is no need > to solve now. I believe we should concentrate on getting the basic > working and then build the rest of the building. I only have one > implementation other than my own here, so i cannot comment from first > hand knowledge, but the comments i hear is that most implementations > are still on very raw state. > > To give you the example i know off, it is not very interesstening to > have a machine capable of RIPng but not capable of configured > tunneling, that can't delete routes, has random source address > selection and so on. I'm not complaining, they do a better job than i Let me say I disagree on this particular point. The IPv6 network I run at IMAG already has two separates networks and will grow up to 5 or 6 by the end of August with different routers. In those nets, I use native IPv6 other ethernet. I need RIPng code now. And to connect this to the G6-bone or the 6-bone, I only need one tunneling machine that I already have. - Alain. From Alain.Durand@imag.fr Thu Aug 1 00:15:28 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Thu, 1 Aug 1996 01:15:28 +0200 Subject: No subject Message-ID: <960801011529.ZM11106@rama.imag.fr> I have the feeling that we reach a rough consensus on the 6-bone topology, i.e. some core/backbone nodes and some clouds connected to them. In the next diagram : - a net is native IPv6 link - an island is a collection of ipv6 nets - a Core is core/backbone ipv6 node. - v6 means native IPv6 - v4 means IPv6 encapsulated in IPv4 v6 v6 v4 net132----island13----Core1----Core2 | \ / | | \/ | v6 | /\ | ___ net475 | / \ | v6 | Core3----Core4----island47---| | |___ net473 | v4| v6 |__island48_____net484 Core4 is very close to the current situation of the G6-bone and I believe to the other nodes of the 6-bone. The question now is how to route packets from net475 to net132 and from net473 to net484 In my opinion, those are two different problems. It's really interior routing versus exterior routing. In the G6 bone, we plan to use RIPng inside islands. Maybe with some manual configuration, we can extend it to route among our islands. I have the feeling that doing RIPng to announce every single route other the global 6-bone will simply not work. We need to agregate. Doing dynamic external routing seems to me a bit premature. We can still do a good job wit static routes if we take some precautions. If there could be one common prefix to everything behind Core X, then this will be very easy to do staticaly, and things could grow. If they are many prefixes, it's going to be more difficult. What I'd like to have on Core routers will be a simple external routing tables like: 5f-prefix1::/prefixlen1 -> Core1 5f-prefix2::/prefixlen2 -> Core2 5f-prefix3::/prefixlen1 -> Core3 5f-prefix4::/prefixlen2 -> Core4 ... To maintain those routing tables, a simple registry will be enough. I see a little problem with RFC1897 address format, mainly because not all islands behind Core X will have the same ISP, thus not the same prefix. If we want to stay close to RFC1897, I see 3 solutions: a) use a special AS number for all Core X different from the ISP ones b) use the AS number of Core X ISP for all nets behind Core X c) have a Core node per AS number participating to the 6-bone. If we agree an a scheme like this one, things could grow smoothly & quickly. We could test both dynamic routing & hierarchical routing. - Alain. From roque@di.fc.ul.pt Thu Aug 1 15:01:01 1996 From: roque@di.fc.ul.pt (Pedro Roque Marques) Date: Thu, 1 Aug 1996 15:01:01 +0100 Subject: RIPng & what to do next. In-Reply-To: <960801010857.ZM11096@rama.imag.fr> References: <9607312207.AA23783@fwasted.zk3.dec.com> <9607312318.AA28132@fwasted.zk3.dec.com> <199608011059.LAA11527@oberon.di.fc.ul.pt> <960801010857.ZM11096@rama.imag.fr> Message-ID: <199608011401.PAA11715@oberon.di.fc.ul.pt> >>>>> "Alain" == Alain Durand writes: >> >> To give you the example i know off, it is not very >> interesstening to have a machine capable of RIPng but not >> capable of configured tunneling, that can't delete routes, has >> random source address selection and so on. I'm not complaining, >> they do a better job than i Alain> Let me say I disagree on this particular point. The IPv6 Alain> network I run at IMAG already has two separates networks Alain> and will grow up to 5 or 6 by the end of August with Alain> different routers. In those nets, I use native IPv6 other Alain> ethernet. I need RIPng code now. And to connect this to Alain> the G6-bone or the 6-bone, I only need one tunneling Alain> machine that I already have. I think i'm not making myself very clear. On the particular example i was giving the machine picks, 50% of the times, a link local source address when talking to a host on another ethernet via a router. Even if you have the best routing solution in the world that machine is not going to be able to communicate much. This is just one particular example. I don't disagree when you say we need routing protocols. I disagree when people suggest that we should stop the show until we get routing protocols because, with the current state of the art, machines crash all over when you try something less common. Do we agree on this ? I would think so. If people want to start coding routing deamons i'll try to do anything i can do to help. This includes coding routing sockets which is something i still don't have. regards, Pedro. From dino@cisco.com Thu Aug 1 16:51:24 1996 From: dino@cisco.com (Dino Farinacci) Date: Thu, 1 Aug 1996 08:51:24 -0700 Subject: more tunnels and what to do next (fwd) In-Reply-To: <9607312203.AA23604@fwasted.zk3.dec.com> (bound@zk3.dec.com) Message-ID: <199608011551.IAA22239@stilton.cisco.com> >> I use this to get to UNH as I direct all traffic through to UNH as >> 5f00/8. But I don't want Quaizar doing this for the east coast. I want >> him to have a route to you, one to WIDE, one to Europe, one to NRL, et >> al. We should not have to go through you to get to WIDE that is not a >> good enough test. Or likewise I don't think you should have to go >> through us to get to G6 in Europe via UNH. I disagree. This is how the MBONE got messed up. Dino From deering@parc.xerox.com Thu Aug 1 16:34:14 1996 From: deering@parc.xerox.com (Steve Deering) Date: Thu, 1 Aug 1996 08:34:14 PDT Subject: more tunnels and what to do next (fwd) In-Reply-To: brian's message of Thu, 01 Aug 96 01:12:42 -0800. <9608010812.AA09191@dxcoms.cern.ch> Message-ID: <96Aug1.083415pdt."75270"@digit.parc.xerox.com> Brian, > If you have a solution for geographic addressing that works, > unlike all previous attempts, pls write it up. ftp://parcftp.xerox.com/pub/net-research/metro-addr-slides-jul95.ps OK, so that's not the kind of write-up you were asking for. (Allison was also saying "pls write it up".) But I was unaware of any proof that it doesn't work. Exactly which failed "attempts" at geographic addressing are you referring to? (Note: there are [at least] two distinct classes of "geographic" addressing that have been proposed: (1) addressing by latitude and longitude, e.g., the recent GPS addressing draft, and (2) "exchange-based" addressing using regional provider interconnects, of which metro-based addressing is one specific example. They have significantly different properties, so we need to be careful to disambiguate which we are talking about. For example, lat/long addressing would certainly exacerbate, rather than relieve, the routing scaling problem; the same is not true of exchange-based addressing.) Steve From brian@dxcoms.cern.ch Thu Aug 1 17:01:47 1996 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Thu, 1 Aug 1996 18:01:47 +0200 (MET DST) Subject: more tunnels and what to do next (fwd) In-Reply-To: <96Aug1.083415pdt."75270"@digit.parc.xerox.com> from "Steve Deering" at Aug 1, 96 08:34:14 am Message-ID: <9608011601.AA14678@dxcoms.cern.ch> Steve, We should take this over to some other list, although I'm not sure which one. IPng? I'm certainly not talking about GPS, but about your Jul 95 presentation or the old Simpson draft on MIXen. But let's not waste 6bone airtime on it. Brian >--------- Text sent by Steve Deering follows: > > Brian, > > > If you have a solution for geographic addressing that works, > > unlike all previous attempts, pls write it up. > > ftp://parcftp.xerox.com/pub/net-research/metro-addr-slides-jul95.ps > > OK, so that's not the kind of write-up you were asking for. (Allison > was also saying "pls write it up".) But I was unaware of any proof that > it doesn't work. > > Exactly which failed "attempts" at geographic addressing are you referring > to? > > (Note: there are [at least] two distinct classes of "geographic" addressing > that have been proposed: (1) addressing by latitude and longitude, e.g., > the recent GPS addressing draft, and (2) "exchange-based" addressing using > regional provider interconnects, of which metro-based addressing is one > specific example. They have significantly different properties, so we > need to be careful to disambiguate which we are talking about. For example, > lat/long addressing would certainly exacerbate, rather than relieve, the > routing scaling problem; the same is not true of exchange-based addressing.) > > Steve > From bound@zk3.dec.com Thu Aug 1 15:54:07 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Thu, 01 Aug 96 10:54:07 -0400 Subject: RIPng In-Reply-To: Your message of "Thu, 01 Aug 96 11:59:01 BST." <199608011059.LAA11527@oberon.di.fc.ul.pt> Message-ID: <9608011454.AA17354@fwasted.zk3.dec.com> Cool. Good point about the language thats my error and I apologize for that. >Basically i think people are discussing problems that there is no need >to solve now. I believe we should concentrate on getting the basic >working and then build the rest of the building. I only have one >implementation other than my own here, so i cannot comment from first >hand knowledge, but the comments i hear is that most implementations >are still on very raw state. Lets be careful on the 6bone. "raw state" to get on the 6bone and do Internet. Several of the implementations are very mature using IPv6 and all the specs associated with this new protocol. I know we have over 40 users banging on our implementation now. Yes its raw for the 6bone work but not raw. Don't forget some of us have stacks that have been maturing for 3 years since sip 8byte proposal and have learned a lot of engineering knowledge for the kernel, transition, and the application interface. But the 6bone is raw but I think we can evolve quickly and make it medium (as opposed to well done). As far as you not getting to the bake-offs. UNH does have a policy if you are a pure academic environment they can arrange for you to participate without joining the consortia. The other good news I have for you is I talked to our Director of Alpha Linux at Digital and he is going to help me get you an Alpha in Lisbon if you want it? Also I am willing to put your machine up and test it for you at the next bake-off to as I think Linux is real important to IPv6 with the user base I see evolving. As I know travel for some is also too expensive. >To give you the example i know off, it is not very interesstening to >have a machine capable of RIPng but not capable of configured >tunneling, that can't delete routes, has random source address >selection and so on. I'm not complaining, they do a better job than i >do in some aspects ... Again please be careful with the words interesting. If we have routers that can run pure IPv6 and need to get tunneling working I still think its interesting that engineers built IPv6 on routers already. I agree they need to now do tunnels rip-to-rip a.s.a.p. but they are still interesting. For example I want to build a pure IPv6 subnet behind our Internet tunnel and on our host take IPv6 packets and inject them onto an IPv6 link via an IPv6 router where the nodes on that link only speak IPv6 (IPv4 is there but for testing just use IPv6). That to me is interesting. I also hope (big hope) to test our anycast spec on this subnet to as the in_pcb changes I checked out are minimal and the transport ones too at least for prototyping anyway. /jim From bound@zk3.dec.com Thu Aug 1 17:28:38 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Thu, 01 Aug 96 12:28:38 -0400 Subject: 6bone DNS Servers Message-ID: <9608011628.AA29421@fwasted.zk3.dec.com> Hi, I will be setting up our DNS Server for our AAAA records tomorrow for our node(s). Who can I feed our DNS records for the 6bone? Geert? Bill Manning? thanks /jim From GeertJan.deGroot@ripe.net Thu Aug 1 21:48:52 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Thu, 01 Aug 1996 22:48:52 +0200 Subject: 6bone registry Message-ID: <199608012048.UAA05490@kantoor.ripe.net> I'm sorry to disrupt the current discussion on the 6bone list, but I have been trying to send this to the list several times. It looks like majordomo doesn't like the email-from-mailinglist setup I'm using, and I hope it works now. Geert Jan --- Hi, Sorry for this much belated message. I have been extremely busy with a number of other things, and small problems like a summer cold and equipment problems (I learned more about incompatibility with PC keyboard controllers than I ever wanted to know while setting up an IPv6 testbox for the NCC..) Moreover, as we're in the process of replacing our computing equipment, I wanted to migrate some NCC services to new machines before adding things like the ip6rr to it. As far as our FTP server, that's completed now; I needed that machine (see below) In the mean time, several people have posted their setup on the 6bone mailing list. This was very useful to me because it allowed me to look at requirements people have. The 6bone, certainly in its current state, is quite a bit different from the regular IP4 network we all know. To rephrase, the 6bone in its current state, is - - A virtual network - - Exists of a dozen islands or so - - Multiple prefixes on an island are possible - - (for now), routes between islands are configured statically. - - DNS IP6 is till in the startup phase and I think it's unwise to depend on it now. While the IPv4 RR uses IP addresses as its main search key, that is probably not very useful for the 6bone. Instead, I think that it is more important to find out about other islands on 6bone and how to get there. IPv6 index capabilities have been added in the RIPE database software last week. However, at this stage the database is not as useful as I want it to be because it is prefix-based too, and it it not possible to ask 'give me all the islands' currently. Also, I expect that the 6bone requirements are going to change fairly soon as the thing evolves. For this reason, I propose to use a public FTP server as drop-point at this time, but at the same time keep the data in the 'database' machine-readable as much as possible to allow for easy migration to the database as soon as there is a need for it. Using the FTP server now gives a little extra flexability which is probably useful at this stage. For instance, 'mget *' gets you a complete overview of the 6bone. To access the FTP 'database', use the following url: ftp://ftp.ripe.net/ipv6/ip6rr/ While I would like to have a public writable FTP directory, I'm concerned about people deleting files, adding 'makemoneyfast.txt' files, etc. For this reason, I added a group password; it is OK to publish the password on the 6bone list but it should probably be a shared secret among list members To get write-access, use: site group ip6rr site gpass 6bone For those who have never used the RIPE-database before, I think that a short introduction is helpful (while we don't use the database, we'll use the database format). The attributes for objects in the database have the following format: attribute1: value attribute2: value This helps to make the data machine-readable. Attributes can be mandatory or optional. Likewise, some attributes may only be allowed in single instances, while other attributes can have multiple instances. To introduce the proposed format, I'd like to show how our entry might look like: site: RIPE NCC location: Amsterdam, The Netherlands loc-string: 33 40 10n 117 49 20w 10m prefix: 5f0d:0500:c100:0000/64 ping: 5f0d:0500:c100:0000::234 tunnel: 193.0.0.234 10.10.10.10 other-site contact: IP6 operations status: example remark: this is only an example! changed: GeertJan.deGroot@ripe.net 960725 source: RIPE Attiribute-definition: site: [single, mandatory] This is the name of the 'island' in freetext format. Obvious examples are 'NRL', 'Digital', 'INRIA', ... location: [multiple, optional] This explains where the site is located. loc-string: [single, optional?] This is the location in lat/longitude format. There is a proposal in draft-ietf-rps-location-00.txt which I'm copying as I have not thought about this myself yet. prefix: / [multiple, mandatory] This documents which prefixes are used within the island. I hope this will be sufficient for 'route add' statements and the like. They should be RFC1897 addresses at this time. XXX ip6 compatible addresses? ping: [multiple, optional] Address of a host that is likely to be available to ping. tunnel: [multiple, mandatory] This documents how a tunnel is built. I'm not really confident if this is sufficient in all cases (automatic tunneling? single hosts? 'native' IPv6 lines?). other-site should be the name of another site: object. contact: [multiple, mandatory] The contact address for this island, for setup of new tunnels and all that. It has been suggested to me that NIC-handles (or RIPE-handles) should also be accepted here; is this acceptable to the group? status: [single, mandatory] The operational status of the island. remark: [multiple, optional] Other useful comments you may have changed: [multiple, mandatory] When the object was last changed, and by whom. While people are primary responsible for their objects themselves, experience has shown that in some cases others might want to make a change too. If you're changing your own object, replace the changed: line; if you're changing someone else's, append a new line and leave the old one intact. source: [single, mandatory] This is used for for exchange of data with other databases. It is currently a fixed value, 'RIPE'. Open issues: 1. I'm not confident about the tunnel syntax. I'd like to make it complete enough so that one stands a fighting chance setting up the local end of a tunnel correctly (so that one only has to send 'this is my end; I assume that's your end, can we tunnel') but I don't know if all cases can be described accurately. (single hosts with automatic tunneling?) 2. Do you think that the latitude/longitude thing is sufficient? I wouldn't know how to get to this information easily (the data in the example is from the draft and thus somewhere in California..) 3. In the 'regular' database, contact persons are split up in administrative and technical contacts, and the contact names point recursively to 'person objects'. (for those who never have seen this, telnet to whois.ripe.net and play around if you want). I don't think that that approach is appropiate at this time; we can always migrate to it once we're using the database. 4. Work on the database version is in progress, thanks to work by its current maintainer, David Kessens. This is an example of what is possible now: $ whois -h whois.ripe.net 5f0d:0500:c100:0000::/64 inet6num: 5F0D:500:C100::0/64 netname: RIPE-NCC-RFC1897 descr: IPv6 RFC 1897 test allocation for RIPE NCC country: NL admin-c: GJD8 tech-c: GJD8 remarks: Experimental on 6bone! notify: GeertJan.deGroot@ripe.net changed: geertJan.deGroot@ripe.net 960801 source: RIPE person: Geert Jan de Groot address: RIPE Network Coordination Centre (NCC) address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5090 e-mail: GeertJan.deGroot@ripe.net nic-hdl: GJD8 remarks: Pager (emergencies only) +31 6 59957375 changed: GeertJan.deGroot@ripe.net 950706 source: RIPE You'll notice that this is not a registered route but a prefix, but the object definition can be changed as desired. (oh, and David just informed me that he's working on the whois server, so it may not work if you'd try now; hopefully in a day or so) That's as far as I got. Please advise if you think this is useful, or if I'm way off. Geert Jan (with credit to David for some last-minute hacks..) ------- End of Forwarded Message From GeertJan.deGroot@ripe.net Thu Aug 1 23:15:23 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Fri, 02 Aug 1996 00:15:23 +0200 Subject: 6bone DNS Servers In-Reply-To: Your message of "Thu, 01 Aug 1996 12:28:38 EDT." <9608011628.AA29421@fwasted.zk3.dec.com> Message-ID: <199608012215.AAA00425@berklix.ripe.net> (I hope this message gets reflected by the list; I'm still having problems. Can people please ack?) On Thu, 01 Aug 96 12:28:38 -0400 bound@zk3.dec.com wrote: > I will be setting up our DNS Server for our AAAA records tomorrow for > our node(s). Who can I feed our DNS records for the 6bone? > > Geert? Bill Manning? Great! The ip6.int records are handled by Bill. I guess that the forward zone is something.dec.com so that can be arranged in-house by DEC? Am I missing something? Geert Jan From hinden@ipsilon.com Mon Aug 5 07:38:28 1996 From: hinden@ipsilon.com (Bob Hinden) Date: Sun, 4 Aug 1996 23:38:28 -0700 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: <960801011529.ZM11106@rama.imag.fr> Message-ID: Folks, The address allocation scheme defined in RFC1897 uses the autonomous system as the top level of the address. The intent behind this (besides making address allocation easy) was that there would be one route per organization having a set of IPv6 nodes. All of the routes in one organization (identified by the AS number) should aggregate into one route. Seems to me that until we get many thousands of organizations on the 6bone, this is not too many routes. I even think that it would be good to get some early experience with large IPv6 routing tables. When the 6bone grows out of this AS style of routing, we can start renumbering the organizations to either aggregatable AS numbers or (probably better) real IPv6 addresses as specified in the unicast address allocation document. I think it will be a very good thing if we get some early experience runumbering IPv6 nodes. We should not try very hard to avoid this. From this I would see the following steps: Status: RO 1) Start with static routes (what we are doing today) 2) Install RIPng on 6bone routers create a reasonable routing topology (some alternative paths, try to avoid multiple ocean hops) 3) At some point (when routing tables get too big or routing traffic exceeds some limit) renumber the IPv6 nodes reduce the number of routes (greater aggregation). Comments? Bob From crawdad@fnal.gov Mon Aug 5 15:58:46 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Mon, 05 Aug 1996 09:58:46 -0500 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: "04 Aug 1996 23:38:28 PDT." <"v03007802ae2b41013000"@[205.226.7.88]> Message-ID: <199608051458.JAA20346@munin.fnal.gov> > The address allocation scheme defined in RFC1897 uses the autonomous system > as the top level of the address. The intent behind this (besides making > address allocation easy) was that there would be one route per organization > having a set of IPv6 nodes. Actually, it says to use the AS of your provider. Thus, even though FNAL has an AS, I'm using an AS of ESNET's in my IPv6 prefix. > I think it will be a very good thing if we get some early experience > runumbering IPv6 nodes. We should not try very hard to avoid this. Absolutely. If renumbering is proven to be "easy" (in some reasonable metric), many objections vaporize. Matt From bound@zk3.dec.com Mon Aug 5 15:45:54 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 05 Aug 96 10:45:54 -0400 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: Your message of "Sun, 04 Aug 96 23:38:28 PDT." Message-ID: <9608051445.AA08737@fwasted.zk3.dec.com> Bob , This sounds good to me. One issue I just found though which is logistical is that I know of two customers that will ask very soon for REAL IPv6 addresses and begin to deploy them. They will join the 6bone and use 1897 but clearly this will be a pain and they don't want to have to IPv6 address AS's. Comments? /jim From hinden@ipsilon.com Mon Aug 5 16:47:13 1996 From: hinden@ipsilon.com (Bob Hinden) Date: Mon, 5 Aug 1996 08:47:13 -0700 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: <9608051445.AA08737@fwasted.zk3.dec.com> References: Your message of "Sun, 04 Aug 96 23:38:28 PDT." Message-ID: Jim, >This sounds good to me. One issue I just found though which is logistical >is that I know of two customers that will ask very soon for REAL IPv6 >addresses and begin to deploy them. They will join the 6bone and use 1897 >but clearly this will be a pain and they don't want to have to IPv6 >address AS's. Yes, this would be good. I think we need to get all of the registries involved. The work Geert Jan is doing at RIPE is a great first step. Bob From GeertJan.deGroot@ripe.net Mon Aug 5 17:10:32 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Mon, 05 Aug 1996 18:10:32 +0200 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: Your message of "Mon, 05 Aug 1996 10:45:54 EDT." <9608051445.AA08737@fwasted.zk3.dec.com> Message-ID: <199608051610.QAA09477@kantoor.ripe.net> On Mon, 05 Aug 96 10:45:54 -0400 bound@zk3.dec.com wrote: > This sounds good to me. One issue I just found though which is logistical > is that I know of two customers that will ask very soon for REAL IPv6 > addresses and begin to deploy them. They will join the 6bone and use 1897 > but clearly this will be a pain and they don't want to have to IPv6 > address AS's. There is no such thing as real IPv6 addresses. It shouldn't be needed either; if people can't renumber at the flick of a switch, then I don't think we have met all the requirements for IPv6. I have suggested it before, but I think it's worth repeating: when developments gets a little further, then I think it makes sense to make some kind of 'master-router-announcer' that would 'announce' the prefix of 6bone. This prefix would change frequently (I'm thinking about 15 minutes, but one day is acceptable), and the whole cloud would automatically renumber and phase out the old prefix. This would just be an experiment but it would make clear we're serious about easy renumbering; also, it would make sure that renumbering actually is simple. Said otherwise: I don't see that using 1897 addresses would be a pain. geert jan From dhaskin@baynetworks.com Mon Aug 5 18:48:59 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Mon, 5 Aug 96 13:48:59 EDT Subject: 6bone Routing [was RIPng & tunnels] Message-ID: <9608051748.AA14529@pobox.BayNetworks.com> Jan, > > There is no such thing as real IPv6 addresses. It shouldn't be needed > either; if people can't renumber at the flick of a switch, then I don't > think we have met all the requirements for IPv6. > > I have suggested it before, but I think it's worth repeating: > when developments gets a little further, then I think it makes > sense to make some kind of 'master-router-announcer' that would > 'announce' the prefix of 6bone. This prefix would change frequently > (I'm thinking about 15 minutes, but one day is acceptable), > and the whole cloud would automatically renumber and phase out the > old prefix. > Given that routers don't act on Router Advertisements from other routers I have a hard time to see how the 'master-router-announcer' can make the whole IPv6 cloud to renumber. As it stands now, it would require flicks of many switches (as many as there are routers) to renumber the entire cloud. It might be possible (albeit hard) to renumber by commands from a maser network management station provided we had a set of standard configuration tools implemented by every router vendor. But this is not here as yet. Any news from the IPv6 MIB WG, BTW? Dimitry From GeertJan.deGroot@ripe.net Mon Aug 5 20:51:45 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Mon, 05 Aug 1996 21:51:45 +0200 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: Your message of "Mon, 05 Aug 1996 08:47:13 PDT." Message-ID: <199608051951.TAA10040@kantoor.ripe.net> On Mon, 5 Aug 1996 08:47:13 -0700 Bob Hinden wrote: > >This sounds good to me. One issue I just found though which is logistical > >is that I know of two customers that will ask very soon for REAL IPv6 > >addresses and begin to deploy them. They will join the 6bone and use 1897 > >but clearly this will be a pain and they don't want to have to IPv6 > >address AS's. > > Yes, this would be good. I think we need to get all of the registries > involved. The work Geert Jan is doing at RIPE is a great first step. Maybe I should elaborate on my previous message. I apologise that it's a little bit offtopic for the 6bone list, but since the topic was brought up here, I hope this is useful. It seems we're having different ideas on the usability of RFC1897 addresses and the need to renumber. As far as the registry work is concerned, we're getting close to be able to assign address space. Software to register IPv6 address space is currently experimental but initial tests work. This software is used by the RIPE NCC, and similar code is used by APNIC; the Internic uses a totally different package. A few things are missing. One is assignment guidelines; should we always assign /64 prefiexes, and to whom? Should each department of a company obtain its own prefix, or should they work this out internally. Keep in mind that IMHO the IPv4 'scarcity' isn't caused by amount of machines, but assignment efficiency; the whole Internet still fits in less than one A. Another thing, and I'm really speaking outside my own department here, is the way address space is assigned. For IPv4, the RIPE NCC only accepts requests from contributing registries (we don't get NSF funding). How this applies to IPv6 space, I don't know; if you want me to bring this up internally, tell me privately. Personally I expected the issue of non-1897 IPv6 addresses to be one year away at this time. But what I'm really concerned with is the push Jim showed to get 'real' addresses, I assume because he didn't want his customers to renumber. That really scares me. One of the big plusses for IPv6 is that renumbering is supposed to be easy. Aren't we sending out the wrong message if for initial deployment, we publically push for 'final' IPv6 assignments? Don't get me wrong: I think that having first customers using this 'for real' is quite a result, but I'm concerned about the precedent it sets and the message it sends out. That's why I'm not very enthousiastic about non-1897 addresses. If I'm dead wrong, enlighten me. Geert Jan From bound@zk3.dec.com Tue Aug 6 03:28:11 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 05 Aug 96 22:28:11 -0400 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: Your message of "Mon, 05 Aug 96 18:10:32 +0200." <199608051610.QAA09477@kantoor.ripe.net> Message-ID: <9608060228.AA17088@fwasted.zk3.dec.com> Geert, >> This sounds good to me. One issue I just found though which is logistical >> is that I know of two customers that will ask very soon for REAL IPv6 >> addresses and begin to deploy them. They will join the 6bone and use 1897 >> but clearly this will be a pain and they don't want to have to IPv6 >> address AS's. > >There is no such thing as real IPv6 addresses. It shouldn't be needed >either; if people can't renumber at the flick of a switch, then I don't >think we have met all the requirements for IPv6. Even with IPv6 its still going to be painful. If customers are going to move to IPv6 they will want to avoid instantaneous renumbering. We need to be realistic here. I have an idea. Stay tuned. So your not going to set up the registries as Bob pointed out? /jim From bound@zk3.dec.com Tue Aug 6 03:55:28 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 05 Aug 96 22:55:28 -0400 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: Your message of "Mon, 05 Aug 96 21:51:45 +0200." <199608051951.TAA10040@kantoor.ripe.net> Message-ID: <9608060255.AA16798@fwasted.zk3.dec.com> Geert, I can renuber any link with stateless or DHCPv6 pretty easy. I think with OSPFv6 I can probably do it quite well with the LSPs using link-local addresses instead of global addresses. So for sure the infrastructure of IPv6 will work well. But that does not account for many other things. 1. I still don't have away to propogate my prefix from the ISP to my backbone. 2. If you read the PIER reqs its dependent on hosts changing lots of stuff and routers to make renumbering pleasant. I think it will take at least 2 years for vendors to get smart and wake up to those changes and get them in "real" products. 3. I think customers want IPv6 RIGHT NOW and as far as they are concerned the Internet has already melted down. They are going to build their Intranets with IPv6 if they can. They would like to understand how they will get the prefixes in their routers (for stateless) and servers (for DHCPv6). They don't want to depend on 1897 to build a real IPv6 back-bone network. I think a year is reasonable as it will take them that long to get up to speed. I will also tell you that there is a bunch of unhappy users out there who have been given a load of garbage about IPv6 from someone. I have just connected with 3 large fortune 100 and International accounts as they wanted to talk to the engineer and me directly. They want IPv6 and they want it right now. If they have to they will replace existing equipment from people who don't support it. This is what I predicted would happen and force the market 3 years ago. I think its going to happen very quickly. This is why we cannot treat the 6bone as the Mbone. The Mbone is very useful but I don't have customers asking me to put it into the very heart of their network backbones. For IPv6 I do. Note Dynamic DNS Updates is another one RIGHT NOW. To make matters better. I am going to take the time to train at least 15 Tech Support folks who will each train 15 more and 15 more etc. In addition in the U.S. from Sept - Dec 1996 there will be an intensive IPv6 set of Seminars across the U.S. in most major cities. So by Jan 97 I think we will have a greater req for IPv6 in the market. This way I can stay home and do what I like which is engineering. 4. The last thing is the idea of renumbering. Its a lot of up front work for the customer. Its like trying to get user requirements out of them for an application. They want to spend as little time with that as possible. Even with IPv6 it just is not as easy as our mail makes it sound here or on PIER. With IPv4 I have been told they will not even bother and just move to IPv6. /jim From GeertJan.deGroot@ripe.net Tue Aug 6 18:29:33 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Tue, 06 Aug 1996 19:29:33 +0200 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: Your message of "Mon, 05 Aug 1996 22:28:11 EDT." <9608060228.AA17088@fwasted.zk3.dec.com> Message-ID: <199608061729.RAA01549@kantoor.ripe.net> On Mon, 05 Aug 96 22:28:11 -0400 bound@zk3.dec.com wrote: > >There is no such thing as real IPv6 addresses. It shouldn't be needed > >either; if people can't renumber at the flick of a switch, then I don't > >think we have met all the requirements for IPv6. > > Even with IPv6 its still going to be painful. If customers are going to > move to IPv6 they will want to avoid instantaneous renumbering. We need > to be realistic here. > > So your not going to set up the registries as Bob pointed out? If you need non-RFC1897 IPv6 addresses, I think you should talk to IANA as IANA has not mandated the registries to do that yet. As I explained, some things are simply not set up for it yet, and the best way to make this going is to talk to Jon. On the other hand, I don't see much advantage to using different addresses. 1897 addresses are globally unique, don't have a fixed lifetime (they will disappear someday, but not in the forseeable future - they aren't net39 addresses with a fixed 'no good after' date). What _is_ lacking is aggregation possibilities. However, should 'real' address space be assigned at this time, then these addresses would not be aggregatable either, so unfortunately it looks like your customers will need to renumber anyway. Can you provide technical motivation why renumbering from 'real' addresses would be better than renumbering from 1897 addresses? Again, please talk to Jon about your needs. It hasn't been discussed much between IANA and the regional registries yet, so if you want to start it, go ahead. Please understand that I don't want to hamper you but I'm just asking the same questions Jon would probably do. geert jan (I'd like to take this offline, is that OK?) From hinden@ipsilon.com Tue Aug 6 20:01:23 1996 From: hinden@ipsilon.com (Bob Hinden) Date: Tue, 6 Aug 1996 12:01:23 -0700 Subject: 6bone Routing [was RIPng & tunnels] In-Reply-To: <199608061729.RAA01549@kantoor.ripe.net> References: Your message of "Mon, 05 Aug 1996 22:28:11 EDT." <9608060228.AA17088@fwasted.zk3.dec.com> Message-ID: Geert Jan, Jim, >Again, please talk to Jon about your needs. It hasn't been discussed much >between IANA and the regional registries yet, so if you want to >start it, go ahead. Please understand that I don't want to hamper you >but I'm just asking the same questions Jon would probably do. I will start a converstion with Jon. I think it is time we get this started. In the mean time, we should all continue using the RFC1897 style addresses. We should not slow the 6bone effor down waiting for registry assigned addresses to appear. Bob From masaki@merit.edu Wed Aug 7 01:08:29 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Tue, 06 Aug 1996 20:08:29 -0400 Subject: How to configure a tunnel In-Reply-To: Your message of "Thu, 25 Jul 1996 19:14:17 EDT." <199607252314.TAA22654@home.merit.edu> Message-ID: <199608070008.UAA25901@merit.edu> 6bone folks, I previously reported how to make a configured tunnel on inria ipv6 freebsd version, but I found another better way. If you use a configuration similar to that I posted before, you will see that all outgoing packets generated on that machine for the configured tunnel have a compatible address as its source, which means that returning packets will be through automatic tunneling. I learned how the inria ipv6 implemented configured tunneling, and found the following way. ifconfig sit0 inet6 fe80::c0:f000:e59a route -n add -inet6 -net fe80::c051:6042/128 ::192.168.10.103 ifconfig sit0 inet6 5f00:ed00:c66c:3c00::153 route -n add -inet6 -net 5f00:ed00:c0a8:0a00::/80 ::192.168.10.103 In this case, the destination has a link-local address as well as a global one. When sending a packet destined to one of them, its source address will be corresponding one. I believe this doesn't affect automatic tunneling. Masaki From masaki@merit.edu Wed Aug 7 01:17:10 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Tue, 06 Aug 1996 20:17:10 -0400 Subject: How to configure a tunnel In-Reply-To: Your message of "Tue, 30 Jul 1996 19:06:09 +0900." <12133.838721169@mine.aist-nara.ac.jp> Message-ID: <199608070017.UAA26022@merit.edu> Kazu, I wrote this a couple of days ago, but it seems I've forgot to send. > Gee. Why don't you, a member of WIDE project, use one of WIDE > implementations? Actually Nara implementation provides a good > and I personally tried. You may remember I asked you. Our main purpose is to implement ipv6 routing protocols, currently working on ripng, so we'll use an ipv6 kernel which provides functions we need. INRIA version is almost enough. I tried Solaris one, but I need to wait its next release due to luck of setsockopt extension for ipv6 multicasting, although their ripng is working on solaris. To implement ripng, we need, o Basic Socket Interface Extensions for IPv6 defined in the draft, o ipv6 extension to socket ioctl's to obtain interface info, o ipv6 extension to access method to kernel resident routing table, o ipv6 link-local multicasting and related setsockopt functions, and o handling link-local addresses properly with Neighbor Discovery even in case of multiple ethernet interfaces. Ripng on solaris sends an update packet with a global ipv6 address as its source, and our current implementation does so. Ripng ID says that a link-local address must be used. So, capability to bind a socket with a link-local address will be needed. And also, the routing daemon wants to identify the incoming interface even for packets with a link-local source address. Neighbor Discovery may be able to ask all the interfaces where that link-local address is on (although the cache may answer). I know INRIA version does well in part. When these become available on your implementation, I'd like to try it. Thanks. Masaki From masaki@merit.edu Wed Aug 7 01:27:04 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Tue, 06 Aug 1996 20:27:04 -0400 Subject: RIPng In-Reply-To: Your message of "Thu, 01 Aug 1996 10:53:47 BST." <9608010953.AA12503@shand.reo.dec.com> Message-ID: <199608070027.UAA26124@merit.edu> 6bone folks, We made ripng in MRT able to work even on configured tunneling. As I reported just before, we can use both link-local and global addresses on a configured tunnel of inria ipv6. We currently use the same link-local address with one of ethernet interfaces attached. I think it's OK because the destination address should be used to identify interfaces in case of point-to-point. It seems that the draft "Identifying IPv6 Interfaces in Link-Local Addresses" doesn't say about poin-to-point network like the ripng draft doesn't. I hope inria ipv6 provides pseudo interfaces which correspond each configured tunnels respectively so that a routing daemon can easily know its configuration and status. And, I also hope the kernel automatically (or provides a way to) switch a source address of outgoing packets to a link-local address even in case of the packet destined to a link-local multicasting address. I haven't made our code to use multicasting on a configured tunnel because I understood it doesn't matter for now. However, I believe the kernel should support multicasting even on a configured tunnel because it will help introducing global multicasting over the 6bone. I think we will not build 6Mbone over 6bone. Masaki From GeertJan.deGroot@ripe.net Wed Aug 7 09:19:50 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Wed, 07 Aug 1996 10:19:50 +0200 Subject: RIPng In-Reply-To: Your message of "Tue, 06 Aug 1996 20:27:04 EDT." <199608070027.UAA26124@merit.edu> Message-ID: <199608070819.KAA00204@berklix.ripe.net> On Tue, 06 Aug 1996 20:27:04 -0400 Masaki Hirabaru wrote: > We made ripng in MRT able to work even on configured > tunneling. As I reported just before, we can use both link-local > and global addresses on a configured tunnel of inria ipv6. Can you make this code available somewhere? Geert Jan From deering@parc.xerox.com Thu Aug 8 23:04:26 1996 From: deering@parc.xerox.com (Steve Deering) Date: Thu, 8 Aug 1996 15:04:26 PDT Subject: RIPng In-Reply-To: shand's message of Thu, 01 Aug 96 02:53:47 -0800. <9608010953.AA12503@shand.reo.dec.com> Message-ID: <96Aug8.150426pdt."75270"@digit.parc.xerox.com> Mike, > > I want to know how they implement ripng on a tunnel. ... > > Well, we don't at the moment. At first sight it seems pretty trivial. > You just define a pseudo pt-pt interface for the tunnel and run > RIPng (or whatever other routing protocol you fancy) over that > interface. Presumably you assign a link local address by whatever > means you would normally use for a pt-pt (e.g. PPP) link. Whether or not the endpoints of a tunnel need their own link-local addresses is an open issue. I don't think RIPng should require that, since RIP classically has operated fine over unnumbered p-to-p links. > There would be no broadcast/multicasting. Well, there's no broadcasting since IPv6 does not have broadcast addresses. But RIPng might as well use its assigned IPv6 link-scope multicast address for messages sent to neighbors across across p-to-p links, including tunnels, just like on multi-access links. The implementation of multicast on a p-to-p link is a trivial and degenerate -- just send the packet to the other end of the link. > Suppose the IPv4 tunnel becomes unidirectional, either because it was > wrongly configured, or because the underlying IPv4 routing becomes > unidirectional. Do we need any special mehanisms to dectect such > misconfiguiration? Yes, I think it's important to be able to detect one-way link or interface failures, regardless of link type. A few of us here at PARC are currently implementing an experimental "RIPng++" which has support for that, plus several other extensions. We plan to test it out on DARTnet before deciding which specific extensions to suggest for RIPng itself. > Do we need to send router advertisements over such a link which should > only have another router at the other end? Presumably so, since it could > in theory be a host running RIP in listen mode (say). etc. etc. I hope we can get away from the use of routing-protocol-snooping by hosts. Steve From masaki@merit.edu Fri Aug 9 00:32:00 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Thu, 08 Aug 1996 19:32:00 -0400 Subject: Mrt's ripng code updated (Re: RIPng ) In-Reply-To: Your message of "Wed, 07 Aug 1996 10:19:50 +0200." <199608070819.KAA00204@berklix.ripe.net> Message-ID: <199608082332.TAA28851@merit.edu> Geert Jan and 6bone folks, I placed the latest mrt code on: ftp://ftp.merit.edu/net-research/mrt/mrt-1.2A.freebsd.tar.gz Mrt's home page is http://compute.merit.edu/mrt/, but this release is not linked from the page. This page has general information about mrt, but I haven't updated any document related to this ripng code. Ripng is one of protocols mrt supports. This release has binaries compiled which run on inria ipv6 freebsd boxes. 1) change your directory to src/programs/mrt, 2) check its default config named "config", whose syntax is like cisco's, and 3) run mrt. You can check mrt's routing table by doing "telnet localhost 5674", then typing "show ripng route" like cisco. Be careful, no security for now. For test, -v (verbose) and -n (not install routes into kernel) options are available when invoking mrt. Our code currently depends on inria's implementation of configured tunnel. When mrt receives a route via a tunnel, mrt has to swap its actual nexthop with nexthop's compatible address because a configured tunnel by inria is not a interface, but just a route. Of course, before running mrt, you should change your configured tunnel to use a global ipv6 address as I posted before. Mrt doesn't obtain routing information from the kernel when starting. This is under development, so don't expect much functions, please. Enjoy. Masaki From dhaskin@baynetworks.com Fri Aug 9 00:17:38 1996 From: dhaskin@baynetworks.com (dhaskin@baynetworks.com) Date: Thu, 8 Aug 1996 23:17:38 +0000 Subject: RIPng Message-ID: <9608090318.AA25242@pobox.BayNetworks.com> > From: Steve Deering > > Whether or not the endpoints of a tunnel need their own link-local addresses > is an open issue. I don't think RIPng should require that, since RIP > classically has operated fine over unnumbered p-to-p links. > I believe it would be much cleaner to require all interfaces including tunnels to have link-local addresses. This way no special considerations have to be applied to p-to-p links. Address tokens can be trivially generated for tunnel interfaces (e.g. use a local IPv4 address for an IPv6-in-IPv4 tunnel or the token of the encapsulating interface for a IPV6-in-IPv6 tunnel). What are benefits of the totally unnumbered IPv6 interfaces? I guess link-local address space conservation is not one of them :) > .. > Yes, I think it's important to be able to detect one-way link or interface > failures, regardless of link type. A few of us here at PARC are currently > implementing an experimental "RIPng++" which has support for that, plus > several other extensions. We plan to test it out on DARTnet before deciding > which specific extensions to suggest for RIPng itself. > I thought NUD as specified in the ND spec could be quite sufficiently used on all types of links to verify two-way reachability. Am I missing something? > Steve > Dimitry From deering@parc.xerox.com Fri Aug 9 05:41:31 1996 From: deering@parc.xerox.com (Steve Deering) Date: Thu, 8 Aug 1996 21:41:31 PDT Subject: RIPng In-Reply-To: dhaskin's message of Thu, 08 Aug 96 16:17:38 -0800. <9608090318.AA25242@pobox.BayNetworks.com> Message-ID: <96Aug8.214131pdt."75270"@digit.parc.xerox.com> Dimitry, > I believe it would be much cleaner to require all interfaces > including tunnels to have link-local addresses. This way no special > considerations have to be applied to p-to-p links. Address tokens can > be trivially generated for tunnel interfaces (e.g. use a local IPv4 > address for an IPv6-in-IPv4 tunnel or the token of the encapsulating > interface for a IPV6-in-IPv6 tunnel). What are benefits of the totally > unnumbered IPv6 interfaces? I guess link-local address space > conservation is not one of them :) Sounds reasonable to me. I suppose we should move this discussion to the main IPng list, to see if anyone has any killer counter-arguments. > > Yes, I think it's important to be able to detect one-way link or interface > > failures, regardless of link type. A few of us here at PARC are currently > > implementing an experimental "RIPng++" which has support for that, plus > > several other extensions. We plan to test it out on DARTnet before > > deciding which specific extensions to suggest for RIPng itself. > > I thought NUD as specified in the ND spec could be quite sufficiently > used on all types of links to verify two-way reachability. Am I missing > something? I don't think NUD is sufficient on multi-access links to verify that multicast routing updates are reaching all neighboring routers. NUD serves to detect the unreachability only of those destinations or next- hop routers to which one is sending unicast packets. So yes, we could depend on NUD on p-to-p links and tunnels, if we specified that RIPng must use unicast destination addresses over those types of links; however, we'd still have to employ a different strategy on multi-access links, and presumably that same strategy would also work in the degenerate case of a p-to-p link without requiring it to be treated as a special case. Steve From onoe@sm.sony.co.jp Fri Aug 9 05:48:55 1996 From: onoe@sm.sony.co.jp (Atsushi Onoe) Date: Fri, 09 Aug 96 13:48:55 +0900 Subject: RIPng In-Reply-To: Your message of "Thu, 8 Aug 1996 15:04:26 PDT" References: <96Aug8.150426pdt."75270"@digit.parc.xerox.com> Message-ID: <199608090448.NAA21646@onoe2.sm.sony.co.jp> > Whether or not the endpoints of a tunnel need their own link-local addresses > is an open issue. I don't think RIPng should require that, since RIP > classically has operated fine over unnumbered p-to-p links. In addition, I don't think RIPng should require link-local addresses even over multicast network. If RIPng doesn't use link-local addresses as the source address, routed can determine the interface where RIPng comes by checking its source address with address of interface. Currently, routed require special interface to determine the interface (ask ND, or extented recvfrom()). Atsushi Onoe, WIDE Project From unigrd@unidhp1.uni-c.dk Fri Aug 9 13:17:12 1996 From: unigrd@unidhp1.uni-c.dk (Gudrun R. Dalgeir) Date: Fri, 9 Aug 1996 14:17:12 +0200 (METDST) Subject: UNI-C ipv6 web server Message-ID: Hello, I've set up an ipv6 web server giving status of the IPv6 activities at UNI-C. Please try it, http://www6.ipv6.uni-c.dk/ ipv6 http://www.ipv6.uni-c.dk/ ipv4 regards, ---------------- oo000oo ---------------------------------- Gudrun Dalgeir phone : (+) 45 35878532 UNI-C fax : (+) 45 35878890 Vermundsgade 5 e-mail : Gudrun.Dalgeir@uni-c.dk DK-2100 Kbh. O ----------------------------------------------------------- From dhaskin@baynetworks.com Fri Aug 9 15:19:30 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Fri, 9 Aug 96 10:19:30 EDT Subject: RIPng Message-ID: <9608091419.AA12922@pobox.BayNetworks.com> Steve, > > > > I thought NUD as specified in the ND spec could be quite sufficiently > > used on all types of links to verify two-way reachability. Am I missing > > something? > > I don't think NUD is sufficient on multi-access links to verify that > multicast routing updates are reaching all neighboring routers. NUD > serves to detect the unreachability only of those destinations or next- > hop routers to which one is sending unicast packets. So yes, we could > depend on NUD on p-to-p links and tunnels, if we specified that RIPng > must use unicast destination addresses over those types of links; however, > we'd still have to employ a different strategy on multi-access links, and > presumably that same strategy would also work in the degenerate case > of a p-to-p link without requiring it to be treated as a special case. I'm not sure that a router sending multicast routing updates should ever care if his updates are reaching all neighboring routers (and if he learned that they don't, what he is going to do about that?). But receivers of routing updates should be able to verify that they can reach the advertising router if they chose to send traffic through it. NUD is quite sufficient for that. And, if a router relying on the reception of routing updates does not get them or can't use them for lack of reachability to the advertiser, someone will scream rather sooner than later. > Steve > Dimitry From dhaskin@baynetworks.com Fri Aug 9 15:32:47 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Fri, 9 Aug 96 10:32:47 EDT Subject: RIPng Message-ID: <9608091432.AA13906@pobox.BayNetworks.com> > > Whether or not the endpoints of a tunnel need their own link-local addresses > > is an open issue. I don't think RIPng should require that, since RIP > > classically has operated fine over unnumbered p-to-p links. > > In addition, I don't think RIPng should require link-local addresses > even over multicast network. > Well.. this would be fundamental deviation from the ND requirements. > If RIPng doesn't use link-local addresses as the source address, > routed can determine the interface where RIPng comes by checking its > source address with address of interface. > The source address IS the address of the interface where RIPng comes from. > Currently, routed require special interface to determine the > interface (ask ND, or extented recvfrom()). > It sounds that routed is fundamentally broken. > Atsushi Onoe, WIDE Project > Dimitry From hinden@ipsilon.com Fri Aug 9 16:20:41 1996 From: hinden@ipsilon.com (Bob Hinden) Date: Fri, 9 Aug 1996 08:20:41 -0700 Subject: RIPng In-Reply-To: <199608090448.NAA21646@onoe2.sm.sony.co.jp> References: Your message of "Thu, 8 Aug 1996 15:04:26 PDT" <96Aug8.150426pdt."75270"@digit.parc.xerox.com> Message-ID: Atsushi, >In addition, I don't think RIPng should require link-local addresses >even over multicast network. One of the motivations for RIPng (and other routing protocols) using link-local addresses for exchanging routing information between nodes running RIPng is to make it possible to renumber with out breaking the routing adjacencies. This is, at least to me, an important capability. Bob From masaki@merit.edu Fri Aug 9 17:22:53 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Fri, 09 Aug 1996 12:22:53 -0400 Subject: RIPng In-Reply-To: Your message of "Fri, 09 Aug 1996 10:32:47 EDT." <9608091432.AA13906@pobox.BayNetworks.com> Message-ID: <199608091622.MAA09422@merit.edu> > > If RIPng doesn't use link-local addresses as the source address, > > routed can determine the interface where RIPng comes by checking its > > source address with address of interface. > > > The source address IS the address of the interface where RIPng comes from. Current my solution is to let the ripng daemon know the (link-local) address of the other end in configuration. When receiving a ripng packet, the ripng daemon checks if its source address is the destination address of one of tunnels, if fails then asks ND. I'm not sure that letting the daemon know a remote link-local address is good thing or not, but there is no ND available on a tunnel. > > Currently, routed require special interface to determine the > > interface (ask ND, or extented recvfrom()). > > > It sounds that routed is fundamentally broken. > > > Atsushi Onoe, WIDE Project > > > Dimitry On inria ipv6, they intend to use ND. Its method I saw in its ping6 code is to try connect() and then getsockname() in order to know the local interface where the sender host is on. Masaki From deering@parc.xerox.com Fri Aug 9 17:28:58 1996 From: deering@parc.xerox.com (Steve Deering) Date: Fri, 9 Aug 1996 09:28:58 PDT Subject: RIPng In-Reply-To: onoe's message of Fri, 09 Aug 96 09:19:22 -0800. <199608091619.BAA26015@onoe2.sm.sony.co.jp> Message-ID: <96Aug9.092858pdt."75270"@digit.parc.xerox.com> > We perhaps needs some extensions to bsd-api spec to determine interface > where datagram comes in. Exactly! Steve From onoe@sm.sony.co.jp Fri Aug 9 17:19:22 1996 From: onoe@sm.sony.co.jp (Atsushi Onoe) Date: Sat, 10 Aug 96 01:19:22 +0900 Subject: RIPng In-Reply-To: Your message of "Fri, 9 Aug 1996 08:20:41 -0700" References: Message-ID: <199608091619.BAA26015@onoe2.sm.sony.co.jp> Bob, > One of the motivations for RIPng (and other routing protocols) using > link-local addresses for exchanging routing information between nodes > running RIPng is to make it possible to renumber with out breaking the > routing adjacencies. This is, at least to me, an important capability. Well... it sounds reasonable. We perhaps needs some extensions to bsd-api spec to determine interface where datagram comes in. Anyway, we are now implementing RIPng based on current RIPng draft, and it will be available soon. Atsushi From deering@parc.xerox.com Fri Aug 9 22:06:10 1996 From: deering@parc.xerox.com (Steve Deering) Date: Fri, 9 Aug 1996 14:06:10 PDT Subject: RIPng In-Reply-To: dhaskin's message of Fri, 09 Aug 96 07:19:30 -0800. <9608091419.AA12922@pobox.BayNetworks.com> Message-ID: <96Aug9.140611pdt."75270"@digit.parc.xerox.com> Dimitry, > I'm not sure that a router sending multicast routing updates should ever care > if his updates are reaching all neighboring routers (and if he learned that > they don't, what he is going to do about that?). Well, there are examples in multicast routing (e.g., broadcast-and-prune style algorithms like DVMRP or PIM-DM), where I might end up waiting for a prune from a neighbor that I can hear, but who can't hear me and will therefore never send a prune. If I don't happen to also have any unicast traffic to send via that router, then NUD won't help me detect the failure. But for the case of unicast routing (like RIPng), I think you're right -- doing NUD on the forwarded traffic would suffice. In which case, it becomes a question of whether or not it still might be better to use some other approach -- I have always thought that routing protocols either do or ought to do their own neighbor reachability verification, and that the need for NUD in IPv6 was to handle the case where one or both of the neighbors is a host. I should probably flush that particular mindset. But first, let me explain what I had in mind, and let me know what you think. What we are were planning on doing as part of our RIPng++ experiment was to add periodic RIP Hello messages, which would carry a list of all routers on that link from whom the sending router had heard a Hello within the last n seconds (n = some small multiple of the Hello interval); if Router A fails to see its own address in the Hellos from Router B, that indicates that B cannot hear A and, therefore, A should ignore B's routing advertisements. Relative to using NUD, this scheme would appear to have the following advantages: - fewer packets than NUD on a busy link: N Hellos per interval, instead of up to 2N(N-1) ND packets per interval; note that, as in the router->host case, router->router NUD cannot take advantage of upper-layer info to suppress the NUD pings. - can detect failure of a neighbor *before* sending any packets to it, and therefore need not drop or delay any data packets while waiting for NUD to time out. The latter point seems important for RIP -- I can know not to update my routing table with info from a deaf neighbor who offers the shortest path to a given destination, rather than doing the table update and then later learning that the neighbor is deaf when I send data packets into that black hole (and then I have to remember not to believe subsequewnt routing messages from that deaf neighbor, at least not for a while [in case it recovers its hearing], ...). The disadvantage of my proposal is that it is an additional mechanism that is not strictly necessary. > And, if a router relying on the reception of routing updates does > not get them or can't use them for lack of reachability to the advertiser, > someone will scream rather sooner than later. I'd like to do better than waiting for someone to scream. We had an incident here where an Ethernet board went dead in one direction in a machine running mrouted, which caused a multicast packet loop that was very nasty and very hard to diagnose. I would have been much happier having my router scream at me (via its logging mechanism) and eliminate the loop, than having the users screaming at me. Steve From bound@zk3.dec.com Fri Aug 9 22:08:04 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Fri, 09 Aug 96 17:08:04 -0400 Subject: RIPng In-Reply-To: Your message of "Sat, 10 Aug 96 01:19:22 +0900." <199608091619.BAA26015@onoe2.sm.sony.co.jp> Message-ID: <9608092108.AA11827@fwasted.zk3.dec.com> You will see an extended API spec that supports interfaces by Mid September and hopefully earlier. And other parts too. /jim From kazu@is.aist-nara.ac.jp Sat Aug 10 07:23:39 1996 From: kazu@is.aist-nara.ac.jp (Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) Date: Sat, 10 Aug 1996 15:23:39 +0900 Subject: RIPng In-Reply-To: Your message of "Fri, 9 Aug 96 10:32:47 EDT" References: <9608091432.AA13906@pobox.BayNetworks.com> Message-ID: <20782.839658219@mine.aist-nara.ac.jp> From: dhaskin@baynetworks.com (Dimitry Haskin) Subject: Re: RIPng Date: Fri, 9 Aug 96 10:32:47 EDT > > If RIPng doesn't use link-local addresses as the source address, > > routed can determine the interface where RIPng comes by checking its > > source address with address of interface. > > > The source address IS the address of the interface where RIPng comes from. I don't understand this. If a source address is link-local, the address isn't unique over multiple links. So, we can't figure out the interface where the packet comes from by checking only the source address. If routed opens one socket per one neighbor, we can figure out an input interface: (1) BSD implementation saves a pointer to the input interface in mbuf(i.e. the received packet). (2) Find a PCB where not only group addresses match but also a pointer in PCB and the pointer in the packet match. (Of course, we need to modify the PCB data structure.) (3) Pass the packet to routed via the PCB. The socket tells routed the neighbor which sent the packet. Unfortunately, some routing daemon don't take this way. That is, just open one unbinded-and-unconnected socket for all neighbors then use sendto() function. So, Atushi said that we need a new API. This problem can be generalized to "an address scope problem" which the Internet has not experienced. We WIDE project had two meetings to discuss this problem but we have not achieved even rough consensus yet. It is felt that there are many models for address scope and each has both advantages and disadvantages. I'm now hesitating to submit an ID about this problem which I wrote weeks ago. WIDE project is planning to have one more meeting on this problem around 8/23. --Kazu From dhaskin@baynetworks.com Sun Aug 11 13:44:49 1996 From: dhaskin@baynetworks.com (dhaskin@baynetworks.com) Date: Sun, 11 Aug 1996 12:44:49 +0000 Subject: RIPng Message-ID: <9608111645.AA19278@pobox.BayNetworks.com> Steve, > Dimitry, > > > I'm not sure that a router sending multicast routing updates should ever care > > if his updates are reaching all neighbouring routers (and if he learned that > > they don't, what he is going to do about that?). > > Well, there are examples in multicast routing (e.g., broadcast-and-prune > style algorithms like DVMRP or PIM-DM), where I might end up waiting for > a prune from a neighbor that I can hear, but who can't hear me and will > therefore never send a prune. If I don't happen to also have any unicast > traffic to send via that router, then NUD won't help me detect the failure. > I was talking about RIPng. I agree if a routing protocol (unicast or multicast) relies on two-way communications for its integrity it should be able to detect failures in such communications. > But for the case of unicast routing (like RIPng), I think you're right -- > doing NUD on the forwarded traffic would suffice. In which case, it becomes > a question of whether or not it still might be better to use some other > approach -- I have always thought that routing protocols either do or ought > to do their own neighbor reachability verification, and that the need for > NUD in IPv6 was to handle the case where one or both of the neighbors is > a host. I should probably flush that particular mindset. But first, let > me explain what I had in mind, and let me know what you think. > > What we are were planning on doing as part of our RIPng++ experiment was > to add periodic RIP Hello messages, which would carry a list of all routers > on that link from whom the sending router had heard a Hello within the last > n seconds (n = some small multiple of the Hello interval); if Router A fails > to see its own address in the Hellos from Router B, that indicates that > B cannot hear A and, therefore, A should ignore B's routing advertisements. > Relative to using NUD, this scheme would appear to have the following > advantages: > > - fewer packets than NUD on a busy link: N Hellos per interval, > instead of up to 2N(N-1) ND packets per interval; note that, > as in the router->host case, router->router NUD cannot take > advantage of upper-layer info to suppress the NUD pings. > > - can detect failure of a neighbor *before* sending any packets > to it, and therefore need not drop or delay any data packets > while waiting for NUD to time out. > > The latter point seems important for RIP -- I can know not to update my > routing table with info from a deaf neighbor who offers the shortest path > to a given destination, rather than doing the table update and then later > learning that the neighbor is deaf when I send data packets into that black > hole (and then I have to remember not to believe subsequewnt routing messages > from that deaf neighbor, at least not for a while [in case it recovers its > hearing], ...). > > The disadvantage of my proposal is that it is an additional mechanism that > is not strictly necessary. > It seems as a nice simple mechanism. As far as RIPng is concerned, I have the following reservations: - in places where RIP is still used between routers most of the routers (typically in stubs domains) don't generate routing advertisements themselves but only listen to RIP advertisements from one or two routers in a transit domain. In such typical setups the proposed mechanism would not work unless you also require for RIP updates to be always sent even if only empty one. - I view RIPv6 as a temporary solution for routing exchange between routers -- only to buy time until OSPFv6 and IDRP are developed. If you agree with this premiss, it would be difficult to justify an additional effort beyond research purposes to improve RIPv6 in its operation between routers. As far as RIP snooping by hosts, it is quite common today and I believe, good or bad, it, the most probably, will continue to be used in IPv6 by multihomed hosts. Your proposal would not not help here either. > > And, if a router relying on the reception of routing updates does > > not get them or can't use them for lack of reachability to the advertiser, > > someone will scream rather sooner than later. > > I'd like to do better than waiting for someone to scream. We had an incident > here where an Ethernet board went dead in one direction in a machine > running mrouted, which caused a multicast packet loop that was very nasty > and very hard to diagnose. I would have been much happier having my > router scream at me (via its logging mechanism) and eliminate the loop, > than having the users screaming at me. > Sounds reasonable. > Steve > Dimitry From dhaskin@baynetworks.com Sun Aug 11 13:56:54 1996 From: dhaskin@baynetworks.com (dhaskin@baynetworks.com) Date: Sun, 11 Aug 1996 12:56:54 +0000 Subject: RIPng Message-ID: <9608111657.AA19462@pobox.BayNetworks.com> Kazu, Please ignore my reply to Atsushi mail. I just misunderstood the problem of the BSD API. Thanks for detail explanation. Dimitry > > > > If RIPng doesn't use link-local addresses as the source address, > > > routed can determine the interface where RIPng comes by checking its > > > source address with address of interface. > > > > > The source address IS the address of the interface where RIPng comes from. > > I don't understand this. If a source address is link-local, the > address isn't unique over multiple links. So, we can't figure out the > interface where the packet comes from by checking only the source > address. > If routed opens one socket per one neighbor, we can figure out an > input interface: > > (1) BSD implementation saves a pointer to the input interface > in mbuf(i.e. the received packet). > (2) Find a PCB where not only group addresses match but also > a pointer in PCB and the pointer in the packet match. > (Of course, we need to modify the PCB data structure.) > (3) Pass the packet to routed via the PCB. The socket tells > routed the neighbor which sent the packet. > > Unfortunately, some routing daemon don't take this way. That is, just > open one unbinded-and-unconnected socket for all neighbors then use > sendto() function. So, Atushi said that we need a new API. > > This problem can be generalized to "an address scope problem" which > the Internet has not experienced. We WIDE project had two meetings to > discuss this problem but we have not achieved even rough consensus > yet. > > It is felt that there are many models for address scope and each has > both advantages and disadvantages. I'm now hesitating to submit an ID > about this problem which I wrote weeks ago. WIDE project is planning > to have one more meeting on this problem around 8/23. > > --Kazu > > From Francis.Dupont@inria.fr Sun Aug 11 20:37:54 1996 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Sun, 11 Aug 1996 21:37:54 +0200 Subject: RIPng In-Reply-To: Your message of Fri, 09 Aug 1996 12:22:53 EDT. <199608091622.MAA09422@merit.edu> Message-ID: <199608111937.VAA04475@givry.inria.fr> In your previous mail you wrote: On inria ipv6, they intend to use ND. Its method I saw in its ping6 code is to try connect() and then getsockname() in order to know the local interface where the sender host is on. => it is not exactly the idea. The ICMPv6 user interface doesn't compute the checksum for you then you need to know the source address. You can provide one or simulate the source address selection, ie do a connect() then a getsockname() (of course the source address is printed out ASAP for obvious routing debug purposes :-). The source address selection is a real issue, BSD OSs give a good control over it but it is very easy to get a bad address (link-local address for a foreign destination for instance :-). Regards Francis.Dupont@inria.fr PS: Alain Durand has tried some ways to put a RFC1897 address on a (configured) tunnel, there will be a note about this in the next release (in some weeks). From shand@shand.reo.dec.com Mon Aug 12 09:23:24 1996 From: shand@shand.reo.dec.com ( (Mike Shand REO2 G/C2 DTN:830-4424)) Date: Mon, 12 Aug 96 09:23:24 +0100 Subject: RIPng In-Reply-To: Your message of "Fri, 09 Aug 96 14:06:10 PDT." <96Aug9.140611pdt."75270"@digit.parc.xerox.com> Message-ID: <9608120823.AA12045@shand.reo.dec.com> Steve, > But for the case of unicast routing (like RIPng), I think you're right -- > doing NUD on the forwarded traffic would suffice. In which case, it becomes > a question of whether or not it still might be better to use some other > approach -- I have always thought that routing protocols either do or ought > to do their own neighbor reachability verification, and that the need for > NUD in IPv6 was to handle the case where one or both of the neighbors is > a host. I should probably flush that particular mindset. I must confess that I too have that mindset. > - fewer packets than NUD on a busy link: N Hellos per interval, > instead of up to 2N(N-1) ND packets per interval; note that, > as in the router->host case, router->router NUD cannot take > advantage of upper-layer info to suppress the NUD pings. > This seems like a big win to me. Maybe not for RIP which traditionally is slow to reconfigure, but certainly for OSPF and (dare I say it) integrated IS-IS which tend to be used in situations where very rapid response to router failure is required. If the interval is of the order of a second the extra load from the full mesh conectivity checks becomes significant. However, even for RIP is seems to me that the efficency gain is worthwhile. Of course this is not particularly relevant to the tunnel case which first prompted this discussion. > - can detect failure of a neighbor *before* sending any packets > to it, and therefore need not drop or delay any data packets > while waiting for NUD to time out. Presumably since the RIP packets are multicast you don't trigger NUD on the sending of the RIP packets themselves rather than the data. Would that also be true over a pt-pt link (e.g. tunnel)? > The disadvantage of my proposal is that it is an additional mechanism that > is not strictly necessary. Yes, but it doesn't rely on a somewhat tenuous connection between the operation of the routing protocol and the forwarding process. On the other hand you could argue that such a connection is exactly what you do want. Examples abound of problems arising where the connectivity indicated by the routing protocol neighbor detection is different from that actually existing for the data itself. This is presumably one reason for the (to my mind) somewhat incestuous relationship of IP routing protocols running over IP. Of course that doesn't completely remove the problem, but it goes some way to reduce its likelyhood. On balance I would feel more comfortable with an explicit mechanism along the lines of Steve's proposal. OSPF or course already has such a mechanism. Mike From RLFink@lbl.gov Wed Aug 14 15:59:02 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 14 Aug 1996 07:59:02 -0700 Subject: 6bone logical drawing Message-ID: 6bone Folk, I've drawn a simple overview of the 6bone, derived from the info on the WIDE 6bone drawing (thanks to Munechika Sumikawa and Kazu Yamamoto), but hiding the WIDE inner detail. Please let me know of errors and/or suggested format changes...and especially incorrect network interconnect details. Also I'll need to know when new stuff is added in (Geert Jan or ...??) Clearly this picture form will rapidly become outdated, but I'll try to adapt it as the 6bone grows. It seems important (to me anyway) to be able to be able to pictorially describe the 6bone to the curious. So...hopefully this is useful...but let me know if it isn't. It is pointed to on the 6bone home page: http://www-6bone.lbl.gov/6bone/6bone-drawing.GIF Also, I've finally put the Montreal 6bone bof minutes on the 6bone pages as well. Sorry it's taken so long, but for US Govt. funded folk, summers ain't fun with budgets and personnel issues :-( . Thanks, Bob From RLFink@lbl.gov Wed Aug 14 17:23:19 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 14 Aug 1996 09:23:19 -0700 Subject: first mods to 6bone diagram Message-ID: Courtesy of some updates from Alain, a new 6bone picture is now installed to show JOIN/DE and G6/FR connectivity. As before, corrections/updates appreciated! Thanks, Bob --------- =46rom: "Alain Durand" Date: Wed, 14 Aug 1996 17:54:26 +0200 To: Bob Fink LBNL Subject: Re: 6bone logical drawing It is really nice to have this map! here a first update for the G6: I have now tunnels to: - UNI-C (dk) 5f07:2b00:82e1:e700::/64 - WIDE (jp) 5f09:c400::/32 - ULISPON (pt) 5f0c:b300:c043:4c00::/64 - JOIN (de) 5f04:fb00::/32 - UNH-BAY-DEC (us) 5f02:3000::/32 && 5f0d:e900:ce98:a300::/64 I will shortly add a tunnel to RIPE and maybe some others to the US Yours, - Alain. From rja@cisco.com Wed Aug 14 18:13:07 1996 From: rja@cisco.com (Ran Atkinson) Date: Wed, 14 Aug 1996 10:13:07 PDT Subject: 6bone map Message-ID: <199608141713.KAA20419@puli.cisco.com> As I've already noted to Bob Fink, the tunnels between cisco/Sun and cisco/MERIT aren't noted on his current drawing. Those have been up and running for a while now. -- From RLFink@lbl.gov Wed Aug 14 21:46:49 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 14 Aug 1996 13:46:49 -0700 Subject: 6bone map In-Reply-To: <199608141713.KAA20419@puli.cisco.com> Message-ID: At 10:13 AM -0700 8/14/96, Ran Atkinson wrote: >As I've already noted to Bob Fink, the tunnels between cisco/Sun and >cisco/MERIT aren't noted on his current drawing. Those have been up >and running for a while now. I've added Sun and MERIT, but need the ASN nos. they are using. Bob From RLFink@lbl.gov Thu Aug 15 00:26:22 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 14 Aug 1996 16:26:22 -0700 Subject: Yet Anoter Picture (YAP) ...and a few comments Message-ID: 6bone Folk, I have added and corrected from various data and a newer diagram is on the web. I've decided to number them in the title block, this one being version 5. I realize that several of the tunnels may not be up yet, but decided to err on the side of too much info rather too little :-) A few comments come to mind from various things mentioned to me during this process: 1. many seem to like having this diagram, but a valid point has been made that the prefix numbers may be less than useful. You really need more than that from some registry anyhow (the point of the next comment). I propose dropping the prefix numbers. 2. given the difficulty in culling this info accurately, I would propose that in the future I add only tunnels that have been registered with the 6bone registry run by RIPE-NCC/Geert Jan. 3. given the current randomness of tunnels, we may find RIPng beginning to have difficulty converging - maybe not yet, but keep up this pace of everyone randomly connecting and we probably will have problems. I propose we have a bit of dicussion about at least controlling the topology of the nets/tunnels that we RIP over. This area is not my specialty to say the least, but it does look like a problem ahead of us to me. Please send comments on all this to the list. Note my goal here is to make 6bone deployment work the best way...if you want to change something, please comment on it...others have. Thanks, Bob From RLFink@lbl.gov Fri Aug 16 16:22:52 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 16 Aug 1996 08:22:52 -0700 Subject: email archive pointer added to 6bone web pages Message-ID: I've added a pointer to the 6bone email archive on the 6bone mail list web page (courtesy of Mike Carlton at ISI). Bob From bound@zk3.dec.com Mon Aug 19 20:23:23 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 19 Aug 96 15:23:23 -0400 Subject: 6bone logical drawing In-Reply-To: Your message of "Wed, 14 Aug 96 07:59:02 PDT." Message-ID: <9608191923.AA08938@fwasted.zk3.dec.com> Bob, Thanks for doing this its very helpful. /jim From RLFink@lbl.gov Fri Aug 23 14:57:43 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 23 Aug 1996 06:57:43 -0700 Subject: new 6bone diagram (version 7) Message-ID: I've put up version 7 (Aug 23) of the 6bone diagram. Shows new link from: Cisco/US to NETLAG/US Also have corrected Craig Metz' site name to Inner as I had put it on the map incorrectly before (sorry Craig). Have removed prefixes as almost no comments were received about my removing them, and I'm getting tighter on space. I think Craig Metz is correct when he says this picture should be for link/site overview viewing and not for data that's best kept elsewhere. Am only showing sites that I've been told are really up. Sites/links that may be up, but I've not been told are: HP/US to Cisco/US ISI-W/US to Cisco/US INRIA/FR to G6/FR ULisboa/PT to RIPE/NL As I've said before, showing all sites connected to the 6bone may be best for now, as we are just getting this going, but eventually the routing backbone may be all that should be (can be) shown. As always, comments to me or the list! Thanks, Bob From bound@zk3.dec.com Fri Aug 23 17:17:56 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Fri, 23 Aug 96 12:17:56 -0400 Subject: new 6bone diagram (version 7) In-Reply-To: Your message of "Fri, 23 Aug 96 06:57:43 PDT." Message-ID: <9608231617.AA02453@fwasted.zk3.dec.com> Bob, Be good to get a list of what routers (hardware numbers etc.) are running on the 6bone too. In a FAQ sheet not necessarilty on the drawing. thanks /jim From RLFink@lbl.gov Tue Aug 27 00:58:58 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 26 Aug 1996 16:58:58 -0700 Subject: request for a 6bone feed In-Reply-To: <199608262039.NAA03970@galaxy.nas.nasa.gov> Message-ID: Kevin, At 1:39 PM -0700 8/26/96, Kevin M. Lahey wrote: >Thanks for all of your hard work on the 6bone diagram -- it certainly >is helpful to see how things are proceeding! I've noticed that >quite alot of sites seem to be appearing without any requests >showing up on the 6bone list -- I presume that there is some out of >band signalling going on, and I'd like to be a part of it. :-) >I apologize for bothering you with this, but I presumed that >if you were documenting this growth, you must have some idea >of how it is proceeding... Yes, there does seem to be some out of band signalling going on...but I'm not involved in it either. So far I've just been told after something is hooked up, and I add it to the diagram. My hope is that we can come up with a process that is more reasonable for planning new connections, especially in the backbone/core of the 6bone. Right now I think we are in learning mode and will evolve to a process that works in the most practical way. >I presume that I just need to request a connection from the >closest site, which looks to be Cisco at about 10 hops and 15ms. >Could you give me the name of the contact at Cisco (or a contact >at some other likely site)? Talk to Ran Atkinson at cisco (rja@cisco.com). >Once we get a connection, we are certainly willing to provide >further connections to others, if our upstream site doesn't mind. >The NAS is maybe four FDDI hops from FIX-West, so it would seem that >we have reasonable connectivity. Makes sense. Again we do need some process for discussing these things. =46or now this list will have to do. Thanks for bringing this up. Bob From RLFink@lbl.gov Wed Aug 28 15:08:32 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 28 Aug 1996 07:08:32 -0700 Subject: NASA-Ames now added to 6bone Message-ID: 6bone drawing version 8 (28 Aug 96) adds NASA-Ames (the NAS facility) to the 6bone stubbed from Cisco. Bob http://www-6bone.lbl.gov/6bone/ From RLFink@lbl.gov Wed Aug 28 16:57:09 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Wed, 28 Aug 1996 08:57:09 -0700 Subject: Gutenberg Univ. now added to 6bone Message-ID: 6bone drawing version 9 (28 Aug 96) adds Gutenberg Univ. (in Mainz, Germany) to the 6bone stubbed from G6/FR. Bob http://www-6bone.lbl.gov/6bone/ =3D=3D=3D=3D=3D=3D =46rom: "Alain Durand" Date: Wed, 28 Aug 1996 16:48:29 +0200 To: Bob Fink LBNL Subject: new tunnel Hi bob. I have a new tunnel between G6 and Johannes Gutenberg Universitaet, Mainz, Germany. (5f0b:2900::/32 ipv4: 134.93.8.107) Yours, - Alain. From RLFink@lbl.gov Thu Aug 29 17:50:31 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 29 Aug 1996 09:50:31 -0700 Subject: SICS/SE now added to 6bone Message-ID: 6bone drawing version 10 (29 Aug 96) adds the Swedish Institute of Computer Science (SICS) (in Kista, Sweden) to the 6bone stubbed from UNI-C/DK. Bob http://www-6bone.lbl.gov/6bone/ =3D=3D=3D=3D=3D=3D To: Bob Fink LBNL Cc: "Gudrun R. Dalgeir" , peter@sics.se Subject: SICS on the 6bone Date: Thu, 29 Aug 1996 18:06:10 +0200 =46rom: Peter Sjodin Hi Bob, SICS is now connected to the 6bone via a tunnel to UNI-C: prefix: 5f0b:1700::/32 tunnel: 193.10.66.50 (HP 725) ping: sauce.ipv6.sics.se (5f0b:1700:c10a:4200:0:800:978:196d) tott.ipv6.sics.se (5f0b:1700:c10a:4200:0:800:94e:984b) Peter -- Peter Sj=F6din Swedish Institute of Computer Science, PO Box 1263, S-164 28 KISTA, SWEDEN Mail: peter@sics.se Tel: +46 8 752 15 50 Fax: +46 8 751 72 30 - From strauss@ibr.cs.tu-bs.de Thu Aug 29 19:50:19 1996 From: strauss@ibr.cs.tu-bs.de (Frank Strauss) Date: Thu, 29 Aug 1996 20:50:19 +0200 Subject: 6bone maps Message-ID: <199608291850.UAA15530@sol.ibr.cs.tu-bs.de> Hi! What do you think about using a more sophisticated tool for drawing these 6bone maps. One tool I think of (why ever ;-) is tkined (http://www.cs.tu-bs.de/ibr/projects/nm/tkined/welcome.html). It may be used to draw maps with some more information than just the interconnection of IPv6 islands, e.g. those islands may get expanded, to get more information on their internal structures and addresses. Of course, simple postscript maps may be extracted. One major problem would be, to keep the information up to date. ;-/ To get an impression (not more), you might take a look at a few links at the bottom of http://www.cs.tu-bs.de/~strauss/ipng/. Frank From Alain.Durand@imag.fr Thu Aug 29 21:21:21 1996 From: Alain.Durand@imag.fr (Alain Durand) Date: Thu, 29 Aug 1996 22:21:21 +0200 Subject: G6/IMAG web server Message-ID: <960829222122.ZM4485@rama.imag.fr> Hi all, I'm pleased to announce our web server http://www.ipv6.imag.fr It can be reach with regular IPv4 or IPv6 for folks on the 6-bone with a tunnel to G6. Let me know if you have any problem to read those pages. - Alain. From bound@zk3.dec.com Thu Aug 29 23:52:49 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Thu, 29 Aug 96 18:52:49 -0400 Subject: Atlanta Networld/Interop and IPv6 Connectivity Message-ID: <9608292252.AA03900@fwasted.zk3.dec.com> Anyone going to show IPv6 at Interop in Atlanta Sept 18-20. If so let me know we can coordinate some interop tests if you like. Also we should try to show access to the 6bone from the show floor too. /jim From RLFink@lbl.gov Fri Aug 30 01:29:42 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 29 Aug 1996 17:29:42 -0700 Subject: 6bone maps In-Reply-To: <199608291850.UAA15530@sol.ibr.cs.tu-bs.de> Message-ID: =46rank, >What do you think about using a more sophisticated tool for drawing >these 6bone maps. One tool I think of (why ever ;-) is tkined >(http://www.cs.tu-bs.de/ibr/projects/nm/tkined/welcome.html). It may >be used to draw maps with some more information than just the >interconnection of IPv6 islands, e.g. those islands may get expanded, >to get more information on their internal structures and addresses. >Of course, simple postscript maps may be extracted. > >One major problem would be, to keep the information up to date. ;-/ > >To get an impression (not more), you might take a look at a few >links at the bottom of http://www.cs.tu-bs.de/~strauss/ipng/. Thanks for bringing this up. I really believe that, in the long run, it would be best to auto generate the maps. As you point out, we would need to have an up to date registry, which hopefully is what Geert Jan's efforts are all about. =46or me, unfortunately, this form of drawing is not directly viewable on my Mac as I could not find a tkined viewer. Also, I still must print .ps files to look at them. Unix users may not have these problems of course. Can it be taught to generate .gif files? I'm pretty clueless about tkined :-( I say we do both manual and auto maps for awhile, till it is clear that the registry gives sufficient data for the map to be up-to-date, and that we like the auto gen'd result. Would you be willing to set up a process (code!) to generate a map from Geert Jan's registry? It would probably have the effect of forcing people to register :-) Thanks again, Bob From strauss@ibr.cs.tu-bs.de Fri Aug 30 12:09:00 1996 From: strauss@ibr.cs.tu-bs.de (Frank Strauss) Date: Fri, 30 Aug 1996 13:09:00 +0200 Subject: 6bone maps In-Reply-To: (message from Bob Fink LBNL on Thu, 29 Aug 1996 17:29:42 -0700) Message-ID: <199608301109.NAA22424@sol.ibr.cs.tu-bs.de> Hi! >> What do you think about using a more sophisticated tool for drawing >> these 6bone maps. One tool I think of (why ever ;-) is tkined >> (http://www.cs.tu-bs.de/ibr/projects/nm/tkined/welcome.html). It may >> be used to draw maps with some more information than just the >> interconnection of IPv6 islands, e.g. those islands may get expanded, >> to get more information on their internal structures and addresses. >> Of course, simple postscript maps may be extracted. >> >> One major problem would be, to keep the information up to date. ;-/ >> >> To get an impression (not more), you might take a look at a few >> links at the bottom of http://www.cs.tu-bs.de/~strauss/ipng/. Bob> Thanks for bringing this up. I really believe that, in the long Bob> run, it would be best to auto generate the maps. As you point Bob> out, we would need to have an up to date registry, which Bob> hopefully is what Geert Jan's efforts are all about. Hm. I think this is worth a separate thesis. ;-) (extraction of locations from DNS, managing databases of addresses, arranging `good looking' graphs, ...) Bob> =46or me, unfortunately, this form of drawing is not directly Bob> viewable on my Mac as I could not find a tkined viewer. Also, I Bob> still must print .ps files to look at them. Unix users may not Bob> have these problems of course. Can it be taught to generate .gif Bob> files? I'm pretty clueless about tkined :-( I converted those two maps to gif and put links on my page. BTW, probably, tkined may compile cleanly on your Mac. Juergen? ;-) Bob> I say we do both manual and auto maps for awhile, till it is Bob> clear that the registry gives sufficient data for the map to be Bob> up-to-date, and that we like the auto gen'd result. Real automated map generation is quite difficult, I think. It would take much time to define all needed attributes and write some code. Once, reaching the point of acceptable operation, the 6bone might be that large, that it doesn't fit on one page. ;-) Bob> Would you be willing to set up a process (code!) to generate a Bob> map from Geert Jan's registry? It would probably have the effect Bob> of forcing people to register :-) Nice aspect. ;-) But I don't want to put much work on arranging those maps. For me, using tkined is just a very nice way to combine the creation of map overviews and some kind of network management. Probably we could put another field into the registry records, that contains a tkined map URL. Such a map may contain pointers to neighboring tkined maps. This would be a good way to decentralize the map management, although it doesn't give an overview at once. Frank From RLFink@lbl.gov Fri Aug 30 14:51:13 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 30 Aug 1996 06:51:13 -0700 Subject: new tunnel In-Reply-To: <960830111741.ZM5154@rama.imag.fr> References: Bob Fink LBNL "Re: 6bone maps" (Aug 29, 5:29pm) Message-ID: 6bone drawing version 11 (30 Aug 96) adds tunnel from SICS/SE to G6/FR. Bob http://www-6bone.lbl.gov/6bone/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D At 2:17 AM -0700 8/30/96, Alain Durand wrote: >Hi bob, > >There is a new tunnel to connect SICS and G6. > > - Alain. From RLFink@lbl.gov Fri Aug 30 18:57:43 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 30 Aug 1996 10:57:43 -0700 Subject: 6bone maps In-Reply-To: <199608301109.NAA22424@sol.ibr.cs.tu-bs.de> References: (message from Bob Fink LBNL on Thu, 29 Aug 1996 17:29:42 -0700) Message-ID: =46rank, >Real automated map generation is quite difficult, I think. It would >take much time to define all needed attributes and write some code. >Once, reaching the point of acceptable operation, the 6bone might be >that large, that it doesn't fit on one page. ;-) Thanks for your response, though I don't understand how much your approach does to shorten the time involved drawing maps as almost any manual time spent per new link is no faster than what I do now. At least for the simple hi-level stick map I do at present. >Probably we could put another field into the registry records, that >contains a tkined map URL. Such a map may contain pointers to >neighboring tkined maps. This would be a good way to decentralize the >map management, although it doesn't give an overview at once. Sure, this might be a good way to do things. Geert Jan? Did someone solve this proble for the mbone? I think I will keep generating a manual map for a while longer. Thanks, Bob