From jeffb@hsnp.com Sun Dec 1 05:13:56 1996 From: jeffb@hsnp.com (Jeff Barrow) Date: Sat, 30 Nov 1996 23:13:56 -0600 (CST) Subject: RIPE registry Message-ID: I'm interested in adding an entry to the RIPE registry. I don't have the group password, however. Here's the entry I'd like added (NETC): site: Internet Connections, Inc. location: Hot Springs, AR, USA prefix: 5f0f:4a00:c7be:6e00::/64 ping: 5f00:4a00:c7be:6e00:0:a0:24ec:f97a v6.netc.com tunnel: 199.190.110.15 204.123.2.236 DIGITAL-CA operational contact: Jeff Barrow status: operational remark: Linux 2.1/ipv6 changed: jeffb@netc.com 961129 source: RIPE Thanks, Jeff Barrow From bound@zk3.dec.com Mon Dec 2 13:05:30 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Mon, 02 Dec 96 08:05:30 -0500 Subject: evolution of the 6-bone In-Reply-To: Your message of "Sat, 30 Nov 96 19:31:43 GMT." Message-ID: <9612021305.AA00370@wasted.zk3.dec.com> how about a core node forwards packets? /jim From ronlee@CS.NRL.NAVY.MIL Mon Dec 2 17:44:27 1996 From: ronlee@CS.NRL.NAVY.MIL (Ronald Lee) Date: Mon, 2 Dec 1996 12:44:27 -0500 (EST) Subject: New VRML Map & snapshots In-Reply-To: <9611300554.AA25080@nsl-too.pa.dec.com> from "Stephen Stuart" at Nov 29, 96 09:54:33 pm Message-ID: <9612021244.aa16396@CS.NRL.NAVY.MIL> > NIST and NRL requested tunnels a while back but never followed up when > I added them; I've taken them off our list. My apologies Stephen. My email must have gotten lost, because I was waiting for a reply from you and then I got caught up in some projects. If you're still interested, we can still set up tunnel. Take care! Ron From kazu@is.aist-nara.ac.jp Mon Dec 2 10:49:20 1996 From: kazu@is.aist-nara.ac.jp (at the University of New Hampshire) Date: Mon, 02 Dec 1996 19:49:20 +0900 Subject: link-local addresses are traversing Message-ID: <4429.849523760@hikari.aist-nara.ac.jp> Hi, The following is the result of "traceroute6" from the University of New Hampshire to WIDE project. lobster# traceroute6 bravo.v6.wide.ad.jp traceroute to bravo.v6.wide.ad.jp (5f09:c400:a3dd:ca00::f801:5df5), 30 hops max, 60 byte packets 1 5f02:3000:84b1:7e80:: (5f02:3000:84b1:7e80::) 1.908 ms 1.824 ms 1.772 ms 2 fe80::cc7b:2ec (fe80::cc7b:2ec) 103.54 ms 99.682 ms 120.378 ms 3 6bone-router.cisco.inner.net (5f00:6d00:c01f:700:1:60:3e11:6770) 347.197 ms * 274.7 ms 4 esnet-v6r1.es.net (::198.128.2.27) 281.609 ms 251.368 ms 253.379 ms 5 6bone-router.cisco.inner.net (5f00:6d00:c01f:700:1:60:3e11:6770) 248.65 ms First, I would like to ask each maintainer to make your router not to select a link-local source address for a global destination. According to the 6bone map, fe80::cc7b:2ec is NRL/US(one between UNH/US and IBM/US). Second, routing loop occurs. Please check out your routing tables. Thanks. --Kazu From jeffb@hsnp.com Tue Dec 3 07:56:40 1996 From: jeffb@hsnp.com (Jeff Barrow) Date: Tue, 3 Dec 1996 01:56:40 -0600 Subject: link-local addresses are traversing Message-ID: <199612030517.XAA13954@netc.netc.com> ---------- >From: at the University of New Hampshire >To: 6bone@ISI.EDU >Subject: link-local addresses are traversing >Date: Monday, December 02, 1996 4:49 AM [...] > 1 5f02:3000:84b1:7e80:: (5f02:3000:84b1:7e80::) 1.908 ms 1.824 ms 1.772 ms > 2 fe80::cc7b:2ec (fe80::cc7b:2ec) 103.54 ms 99.682 ms 120.378 ms > 3 6bone-router.cisco.inner.net (5f00:6d00:c01f:700:1:60:3e11:6770) 347.197 ms * 274.7 ms > 4 esnet-v6r1.es.net (::198.128.2.27) 281.609 ms 251.368 ms 253.379 ms > 5 6bone-router.cisco.inner.net (5f00:6d00:c01f:700:1:60:3e11:6770) 248.65 ms > >First, I would like to ask each maintainer to make your router not to >select a link-local source address for a global destination. According >to the 6bone map, fe80::cc7b:2ec is NRL/US(one between UNH/US and >IBM/US). Are you sure? I have a tunnel from v6.netc.com (NETC) to DIGITAL-CA as my ONLY tunnel, and it's traceroute comes up with that same link-local address as the first destination node of any traceroute that works... (I think that address may be DIGITAL-CA's, but I can't be too sure) --Jeff Barrow From stuart@pa.dec.com Tue Dec 3 08:50:58 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Tue, 03 Dec 96 00:50:58 -0800 Subject: link-local addresses are traversing In-Reply-To: Your message of Tue, 03 Dec 96 01:56:40 -0600. <199612030517.XAA13954@netc.netc.com> Message-ID: <9612030850.AA21130@nsl-too.pa.dec.com> > Are you sure? I have a tunnel from v6.netc.com (NETC) to DIGITAL-CA as my > ONLY tunnel, and it's traceroute comes up with that same link-local address > as the first destination node of any traceroute that works... (I think that > address may be DIGITAL-CA's, but I can't be too sure) The router at DIGITAL-CA has a link-local address of fe80::f842:142c, not fe80::cc7b:02ec. A traceroute from one of my IPV6 hosts (host.ipv6.pa-x.dec.com) to v6.netc.com shows that gw.ipv6.pa-x.dec.com is reporting its address correctly. I'll check with the engineers to see if there are conditions under which it would behave differently, though. % traceroute6 v6.netc.com traceroute to v6.netc.com (5F0F:4A00:C7BE:6E00::A0:24EC:F97A), 30 hops max, 24 byte packets 1 gw.ipv6.pa-x.dec.com (5F00:2100:CC7B::12:0:F842:142C) 1.952 ms 1.952 ms 1.952 ms 2 5F0F:4A00:C7BE:6E00::A0:24EC:F97A (5F0F:4A00:C7BE:6E00::A0:24EC:F97A) 123.952 ms 97.542 ms 132.694 ms Stephen From leewb@dcn.soongsil.ac.kr Wed Dec 4 04:52:10 1996 From: leewb@dcn.soongsil.ac.kr (Lee Wangbong) Date: Tue, 03 Dec 1996 20:52:10 -0800 Subject: request Message-ID: <32A5037A.6420@dcn.soongsil.ac.kr> This is Soongsil Univ in Seoul, Korea. I'm Wangbong Lee , working at DCN lab in Soongsil Univ. We are implementing IPv6 host based on FreeBSDv2.0 O.S. Then we now implemented basic function of IPv6 host. We want join 6-bone. I have some questions for choosing an ipv6 address. That is ANS field of address format. How can I choose ANS ? And I thought that RES field filled by zeros. Is it correct? I wonder about that. Pleade HELP me.. and Our implemented host address is 203.253.3.205(IPv6/IPv4 host). Waiting for your respond. Thanks for reading. Good Luck. From phan@badfan.nrl.navy.mil Tue Dec 3 14:57:39 1996 From: phan@badfan.nrl.navy.mil (Bao Phan) Date: Tue, 3 Dec 1996 09:57:39 -0500 (EST) Subject: link-local addresses are traversing Message-ID: <199612031457.AA24404@venera.isi.edu> > The following is the result of "traceroute6" from the University of > New Hampshire to WIDE project. > > lobster# traceroute6 bravo.v6.wide.ad.jp > traceroute to bravo.v6.wide.ad.jp (5f09:c400:a3dd:ca00::f801:5df5), 30 hops ma x, 60 byte packets > 1 5f02:3000:84b1:7e80:: (5f02:3000:84b1:7e80::) 1.908 ms 1.824 ms 1.772 m s > 2 fe80::cc7b:2ec (fe80::cc7b:2ec) 103.54 ms 99.682 ms 120.378 ms > 3 6bone-router.cisco.inner.net (5f00:6d00:c01f:700:1:60:3e11:6770) 347.197 ms * 274.7 ms > 4 esnet-v6r1.es.net (::198.128.2.27) 281.609 ms 251.368 ms 253.379 ms > 5 6bone-router.cisco.inner.net (5f00:6d00:c01f:700:1:60:3e11:6770) 248.65 m s > > First, I would like to ask each maintainer to make your router not to > select a link-local source address for a global destination. According > to the 6bone map, fe80::cc7b:2ec is NRL/US(one between UNH/US and > IBM/US). fe80::cc7b:2ec does not belong to NRL/US. This link-local address appears to be from DIGITAL-CA/US (pax-6bone.pa-x.dec.com/204.123.2.236). A traceroute to the host yields: # ./traceroute ::204.123.2.236 traceroute to ::204.123.2.236 (::204.123.2.236), 30 hops max, 16 byte packets 1 fe80::cc7b:2ec (fe80::cc7b:2ec) 222.196 ms 78.362 ms 84.14 ms I have seen packets with link-local source address forwarded on the 6bone on a number of occasions. Do most implementations forward such packets despite what the specs say? From bound@zk3.dec.com Wed Dec 4 02:59:26 1996 From: bound@zk3.dec.com (bound@zk3.dec.com) Date: Tue, 03 Dec 96 21:59:26 -0500 Subject: BOF topic - address allocation In-Reply-To: Your message of "Fri, 29 Nov 96 00:28:33 GMT." <199611290028.AAA28569@oberon.di.fc.ul.pt> Message-ID: <9612040259.AA27771@wasted.zk3.dec.com> Pedro, I am concerned about propogating IPv4 any further than we have. I am hoping we some consensus with Mike O'dell's 8+8 proposal at San Jose and then I think you might want to consider its use is my input to you. I am not saying I disagree with you. I just think we need to get even more real if possible. /jim From dichro@tartarus.uwa.edu.au Wed Dec 4 15:08:01 1996 From: dichro@tartarus.uwa.edu.au (Mikolaj J. Habryn) Date: Wed, 4 Dec 1996 23:08:01 +0800 Subject: UWA looking for tunnel Message-ID: <199612041508.XAA03200@s185.dialup.uwa.edu.au> Hi - we're looking for a tunnel into the 6bone. We being a part of the University of Western Australia, in Perth, WA. Tunnel endpoint is ::130.95.101.10, and our net is 5f04:c500:825f:6500::/64. Thanks. m. From Ivano.Guardini@cselt.stet.it Wed Dec 4 17:24:17 1996 From: Ivano.Guardini@cselt.stet.it (Guardini Ivano) Date: Wed, 04 Dec 1996 18:24:17 +0100 Subject: New site CSELT-IT Message-ID: Hy, we connected our IPv6 test-site to the 6bone. One tunnel is operational to CEFRIEL-IT. Following information has been stored on the RIPE server: site: CSELT (Centro Studi E Laboratori Telecomunicazioni) location: Torino, ITALY loc-string: 45 03 52.2n 07 39 43.2e 250m prefix: 5f16:4d00::/32 ping: 5f16:4d00:a3a2:1100:11:800:2071:d812 tunnel: 163.162.252.4 131.175.5.37 CEFRIEL contact: Ivano Guardini status: operational since December 4, 1996 remark: Sun SPARC STATION 20, IPv6 for Solaris 2.5 changed: ivano.guardini@cselt.stet.it 19961204 source: RIPE Ivano --------------------------------------------------- Ivano Guardini CSELT SpA via G. Reiss Romoli 274 Torino (Italy) Tel. +39 11 228 5424 Fax. +39 11 228 5069 --------------------------------------------------- From RLFink@lbl.gov Thu Dec 5 15:20:35 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 5 Dec 1996 07:20:35 -0800 Subject: 6bone BOF reminder Message-ID: Just a reminder that the 6bone BOF will be on Tuesday (Dec 10) from 3:30 to 5:30. The agenda is still as originally advertized: 1. Discussion of usefulness and goals of a 6bone deployment working group 2. Ongoing 6bone business For ongoing business I will start with Alain Durand's list (with Pedro Roque's submission added) and we can modify it at the start of the meeting: - RIPE registry * database clean up * new syntax & new entries (some important infos are missing) - experimental tunnels - IPv6 endpoints - speed/reliability of tunnels - sub-tunnels (tunnels to a subset of a site) - existence of a routing protocol - site carrying full routing table * database sanity check - 6-bone topology * comments on the current topology * how to add new tunnels ? * should we go to a full mesh of core routers? - map of the 6-bone * usefullness of various maps * full maps, sub-maps... - dynamic routing * is it needed at the scale of the 6-bone? * is RIPng suitable? * experiences with other routing protocols? - Addresses * limitations of RFC1897 * Pedro Roque's proposal for a change to RFC 1897 * could we try something else? * what about "real" IPv6 addresses ? Thanks, Bob From RLFink@lbl.gov Thu Dec 5 16:04:21 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 5 Dec 1996 08:04:21 -0800 Subject: 6bone map changes Message-ID: 6bone diagram 42: new site DFN/DE tunnelled to JOIN/DE new site SWITCH/CH tunnelled to SICS/SE new site ETHZ/CH tunnelled to SWITCH/CH new site CSELT/IT tunnelled to CEFRIEL/IT Welcome to new sites DFN, SWITCH, ETHZ and CEFRIEL. ALso welcome to CH for the first time (so the Tshirt is now telling no lie!). Thanks, Bob From crawdad@fnal.gov Thu Dec 5 16:45:28 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Thu, 05 Dec 1996 10:45:28 -0600 Subject: 6bone BOF reminder In-Reply-To: "05 Dec 1996 07:20:35 PST." <"v03007805aecc966437b4"@[128.3.9.22]> Message-ID: <199612051645.KAA00990@gungnir.fnal.gov> How about a trial deplyment of 8+8? I realize that this requires changes from host implementations (not least because of the change to the pseudo-header checksum) and the router vendors (to insert the RG), but a statement "from the 6bone" might be useful encouragement. Anyway, I request that this go on the agenda. Matt From RLFink@lbl.gov Thu Dec 5 17:06:49 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Thu, 5 Dec 1996 09:06:49 -0800 Subject: 6bone BOF reminder In-Reply-To: <199612051645.KAA00990@gungnir.fnal.gov> References: "05 Dec 1996 07:20:35 PST." <"v03007805aecc966437b4"@[128.3.9.22]> Message-ID: At 8:45 AM -0800 12/5/96, Matt Crawford wrote: >How about a trial deplyment of 8+8? I realize that this requires >changes from host implementations (not least because of the change to >the pseudo-header checksum) and the router vendors (to insert the >RG), but a statement "from the 6bone" might be useful encouragement. > >Anyway, I request that this go on the agenda. Sure! Thanks, Bob From junkins@nwnet.net Fri Dec 6 00:07:38 1996 From: junkins@nwnet.net (Doug Junkins) Date: Thu, 5 Dec 1996 16:07:38 -0800 (PST) Subject: 6bone tunnel request Message-ID: I'm interested in getting a 6bone tunnel. We are a regional ISP for the Pacific Northwest with DS-3 connectivity to both Sprint and MCI in Seattle so a tunnel source with good connectivity to one of those providers will make good topological sense. I've got a Sun workstation with version 5.0 of Sun's IPv6 code installed. The RFC-1897 prefix is 5f02:ad00:c050:0d00/64. Once we have a tunnel provider, I will submit our entry to the RIPE-NCC 6bone Registry. I am interested in participating in the 6bone to get some experience with IPv6 -- especially dynamic routing implementations and troubleshooting. - Doug / Douglas A. Junkins | Network Engineering \ / Network Engineer | NorthWestNet \ \ junkins@nwnet.net | Bellevue, Washington, USA / \ (206)649-7419 | / P.S. See you in San Jose... From stuart@pa.dec.com Fri Dec 6 01:45:11 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Thu, 05 Dec 96 17:45:11 -0800 Subject: 6bone tunnel request In-Reply-To: Your message of Thu, 05 Dec 96 16:07:38 -0800. Message-ID: <9612060145.AA01047@nsl-too.pa.dec.com> > I've got a Sun workstation with version 5.0 of Sun's IPv6 code installed. > The RFC-1897 prefix is 5f02:ad00:c050:0d00/64. Once we have a tunnel > provider, I will submit our entry to the RIPE-NCC 6bone Registry. Tell me your IPV4 address, and I'll set up a tunnel from DIGITAL-CA. > I am interested in participating in the 6bone to get some experience with > IPv6 -- especially dynamic routing implementations and troubleshooting. Does that mean you'd like RIPv6 turned on? Stephen - ----- Stephen Stuart stuart@pa.dec.com Network Systems Laboratory Digital Equipment Corporation From meyer@network-services.uoregon.edu Fri Dec 6 11:12:08 1996 From: meyer@network-services.uoregon.edu (David M. Meyer) Date: Fri, 6 Dec 1996 03:12:08 -0800 (PST) Subject: 6bone tunnel request In-Reply-To: from "Doug Junkins" at Dec 5, 96 04:07:38 pm Message-ID: <199612061112.DAA22969@network-services.uoregon.edu> Doug, I'll provide it to you., Dave According to Doug Junkins: > > > I'm interested in getting a 6bone tunnel. We are a regional ISP for the > Pacific Northwest with DS-3 connectivity to both Sprint and MCI in Seattle > so a tunnel source with good connectivity to one of those providers will > make good topological sense. > > I've got a Sun workstation with version 5.0 of Sun's IPv6 code installed. > The RFC-1897 prefix is 5f02:ad00:c050:0d00/64. Once we have a tunnel > provider, I will submit our entry to the RIPE-NCC 6bone Registry. > > I am interested in participating in the 6bone to get some experience with > IPv6 -- especially dynamic routing implementations and troubleshooting. > > - Doug > > / Douglas A. Junkins | Network Engineering \ > / Network Engineer | NorthWestNet \ > \ junkins@nwnet.net | Bellevue, Washington, USA / > \ (206)649-7419 | / > > P.S. See you in San Jose... > > From RLFink@lbl.gov Fri Dec 6 15:17:22 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Fri, 6 Dec 1996 07:17:22 -0800 Subject: Tshirt info Message-ID: I'm still not sure about when I can distribute the 6bone Tshirts, but will let people know at the IPng sessions on Monday afternoon. Maybe will start doing it after that session during the break. Almost certainly I will be doing it before and after the 6bone BOF session Tuesday 3:30-5:00, but may do other times as well. I WON'T be there on Sunday night so don't even wonder. I'm still not yet asking people to send money and won't till I have the real Tshirts in my hands (supposed to receive them today!). As an aside for non-US'rs that have asked how to send funds by check to me: My bank will only take a foreign funds check if I manually process each and every one personally at the bank. Hence, I don't want foreign funds, only US. i.e., I'm asking you to do the manual work to get your local currency into US$. PLEASE don't send any money yet. I will let you know when I want money mailed to me for the non-direct pickup orders. However, those intending on picking their Tshirts up at the IETF should be prepared to give me cash or a US$ check at that time. Thanks, Bob From malara@crs4.it Fri Dec 6 16:50:43 1996 From: malara@crs4.it (Paolo Malara) Date: Fri, 06 Dec 96 17:50:43 +0100 Subject: New site: CRS4 Message-ID: <199612061650.AA69090@bruckner.crs4.it> Hi all, another ipv6 island on the 6bone: CRS4 (ftp://ftp.ripe.net/ipv6/ip6rr/CRS4) Regards Paolo Malara -- * * * * *Centro di Ricerca, Sviluppo e Studi Superiori in Sardegna * * * * * * * * * * Paolo Malara * Phone: (+39) 70 2796 260 * * * * * CRS4 * Fax: (+39) 70 2796 245 * * via Nazario Sauro, 10 * * * 09123 Cagliari, Italy * E-mail: malara@crs4.it * * * * * * * Centre for Advanced Studies, Research, and Development in Sardinia * * * From Doug Junkins Fri Dec 6 19:17:51 1996 From: Doug Junkins (Doug Junkins) Date: Fri, 6 Dec 1996 11:17:51 -0800 (PST) Subject: RIPE-NCC routing registry Message-ID: NorthWestNet now has a 6Bone tunnel thanks to Stephen Stuart at DEC. I'd like to add our entry to the RIPE-NCC 6bone Registry but I need the group and gpass strings for the FTP server. For those interested, here's our entry: site: NorthWestNet location: Bellevue, Washington, USA loc-string: 47 35 2n 122 8 2w 5m prefix: 5F02:AD00:C050:0D00/64 ping: 5F02:AD00:C050:0D00:0001:0800:207F:049D tunnel: 192.80.13.59 204.123.2.236 Digital-CA contact: Doug Junkins status: operational remarks: Sun Ultra1 running IPv6 for Solaris Release 5.0 changed: junkins@nwnet.net 961206 source: RIPE - Doug / Douglas A. Junkins | Network Engineering \ / Network Engineer | NorthWestNet \ \ junkins@nwnet.net | Bellevue, Washington, USA / \ (206)649-7419 | / From Doug Junkins Fri Dec 6 21:04:05 1996 From: Doug Junkins (Doug Junkins) Date: Fri, 6 Dec 1996 13:04:05 -0800 (PST) Subject: New 6Bone site: NWNET Message-ID: Thanks to all those that helped with the process of getting on the 6Bone. NorthWestNet is now up are operational with a tunnel from Digital-CA. Our IPv6 routing registry information can be found at: ftp://ftp.ripe.net/ipv6/ip6rr/NWNET. - Doug / Douglas A. Junkins | Network Engineering \ / Network Engineer | NorthWestNet \ \ junkins@nwnet.net | Bellevue, Washington, USA / \ (206)649-7419 | / From RLFink@lbl.gov Sat Dec 7 16:51:22 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sat, 7 Dec 1996 08:51:22 -0800 Subject: new 6bone map - last 6bone map change?! Message-ID: 6bone drawing 43: new site NWNET/US with tunnel to DIGITAL-CA/US new site CRS4/IT with tunnel to POLITO/IT Welcome to new sites NWNET and CRS4! Some comments: NWNET/US is a regional ISP and is possibly our first commercial ISP to hook to the 6bone (please correct me if I'm wrong). Second, I think these last two entries represent the limits of the current style of drawing to document what we are doing on the 6bone. One of our agenda items for the 6bone BOF is to discuss this. So...I will not be adding more to this drawing, at least in its current style. If we can reach consensus in San Jose on what is the best approach I will happily take up a drawing tool yet again. Note that this drawing has served us well during startup of the 6bone, but has survived precisely one IETF meeting cycle! Sign of the times! See you in San Jose! Bob From RLFink@lbl.gov Sat Dec 7 17:19:21 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Sat, 7 Dec 1996 09:19:21 -0800 Subject: Tshirts arrive! Message-ID: Well, I finally got them. What a lot of Tshirts! They look neat! Given the weight and volume, I have decided to distribute them only from my hotel sleeping room at the Fairmont. My room number you will have to learn at the Monday 1 pm IPng session as I don't know it yet. On Monday from 3:15 pm till 7:15 pm (just before the evening IPng session). On Tuesday from 11:45 am till 3:00 pm (just before the 6bone BOF session). On Wednesday from 9:00 till 3:00 pm. Those picking up Tshirts in my hotel room should pay me in cash or check (made out to Robert L. Fink) at time of pickup. Anyone that misses those times will have to reach me thru email and arrange something. Failing that, the us mail will still get the Tshirts to you, i.e., anyone missing me WILL get their Tshirts mailed to them after the IETF. At this point anyone who is having their Tshirts mailed can send me checks by the mail (please no cash) for the Tshirts you have ordered. Remember they must be in US $ currency, $10 per Tshirt. Only pay for what you have ordered on the official list (below). Make all checks payable to Robert L. Fink and send them to: Robert L. Fink 3085 Buena Vista Way Berkeley, CA 94708 USA If I haven't received a check from you by the time I mail the Tshirts, no matter...I trust all of you. Just please get me the checks somehow, someday :-) Thanks, Bob =================================================== Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL ietf Atkinson, Ran 2 L, 1 XL ietf Belding, Peter 1 XL mail Bassham, Larry 1 L ietf Bhogavilli, Suresh 1 L ietf Blundell, Phil 2 L mail Boroumand, Jarad 2 XL ietf Bound, Jim 3 L ietf Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L mail Cianci, Frank 1 XL ietf Clauberg, Axel 3 XL ietf Clay, Mike 1 L, 1 XL mail Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Curran, Peter 2 L mail (need postal address) Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL ietf DeCasper, Dan 10 XL mail Deering, Steve 1 XL ietf Degermark, Mikael 2 XL ? (not confirmed) de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf Durand, Alain 2L, 8 XL ietf Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf Fang, Hsin 1 XL ietf Fernstedt, Anders 25 L, 25 XL ietf Field, Brian 1 XL mail Fink, Bob 1 L, 25 XL ietf Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Hamilton, Martin 2 XL ietf Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Honerkamp, Robbie 1 XL mail Jaeger, Kurt 5 XL, 1 XXL mail Jinmei, Tatuya 5 L ietf Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf Kato, Akira 2 L ietf King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Lee, Ron 1 L, 5 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf McCann, Jack 2 XL ? (not confirmed) Meier, Erich 2 XL mail Metz, Craig 2 XL, 1 L mail (not confirmed) Meyer, David 2 M, 3 XXL ietf Michlmayr, Mike 4 XXL, 2 XL mail Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Onoe, Atsushi 1 L mail Ouin, Edouard 3 XL ietf Page, John 2 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shabou, malek 1 XL mail (need postal address) Shand, Mike 1 XL ietf Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL ietf (pickup by Steve Pink) Solensky, Frank 1 L ietf Souissi, Mohsen 1 L ietf (Dupont pickup) Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Turner, Rob 1 XXL ietf or mail (need postal address) Vohra, Quaizar 3 XL, 1 L, 1 M ietf Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Winchcombe, Charlie 5 XXL mail Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf Zhang, Lixia 1 M ietf -end From dan@tik.ee.ethz.ch Mon Dec 9 11:58:36 1996 From: dan@tik.ee.ethz.ch (Dan S. Decasper) Date: Mon, 09 Dec 1996 10:58:36 -0100 Subject: Tshirts arrive! Message-ID: <3.0.32.19961209105835.0190e808@tik1.ethz.ch> Bob, [...] > >At this point anyone who is having their Tshirts mailed can send me checks >by the mail (please no cash) for the Tshirts you have ordered. Remember >they must be in US $ currency, $10 per Tshirt. Only pay for what you have >ordered on the official list (below). > >Make all checks payable to Robert L. Fink and send them to: > > Robert L. Fink > 3085 Buena Vista Way > Berkeley, CA 94708 > USA > > >If I haven't received a check from you by the time I mail the Tshirts, no >matter...I trust all of you. Just please get me the checks somehow, >someday :-) > Could you give me some bank account information so I could ask my bank to do a transfer? Thanks a lot, -Dan From pcurran@ticl.co.uk Tue Dec 10 22:29:41 1996 From: pcurran@ticl.co.uk (Peter Curran) Date: Tue, 10 Dec 1996 22:29:41 -0000 Subject: Tunnel request Message-ID: <199612102222.WAA04895@gate.ticl.co.uk> Dear All We are looking for a tunnel please. We are located in the UK, 'bout 2 hops from LINX and 3 from MAE East. IPv4 address is 193.32.1.66 our IPv6 prefix is 5f15:200:c120:100/64. At the same time, could somebody tell me the name/pass for the RIPE database site so I can craft an entry. We are a Consultancy Company, based in the UK (but we work in US also). We provide tech support for ISPs, develop training courses and do a lot of work on security. We want to move some of our security tools and products to IPv6 to try and get some experience of the new environment before we gaet asked any questions about it :-). We also want to play with the PPP stuff, and probably develop a training course on migration issues. Look forward to joining you all. Cheers Peter Curran The Internet Connection Ltd UK ------ From meyer@network-services.uoregon.edu Wed Dec 11 01:22:09 1996 From: meyer@network-services.uoregon.edu (David M. Meyer) Date: Tue, 10 Dec 1996 17:22:09 -0800 (PST) Subject: RPSL extensions for tunnels Message-ID: <199612110122.RAA06320@network-services.uoregon.edu> Folks, I didn't get a chance to present this in the BOF, so here's the draft. Any comments appreciated. Dave ----------- INTERNET-DRAFT David Meyer draft-ietf-rps-tunnels-01.txt University of Oregon Category: Standards Track November 1996 Representing Tunnels in RPSL Status of this Memo This document provides extensions to the Routing Policy Specification Language [RPSL] to provide support for tunnels of various types. Internet Drafts This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document specifies the language and set of semantics describing tunnels in the Routing Policy Specification Language (RPSL). It defines a new tunnel class, inet-tunnel, and a set of extensions to the inet-rtr class. An instance of the inet-tunnel class specifies endpoints for tunnels of various encapsulation types, including DVMRP [DVMRP], GRE [GRE], and IPv6 [IPV6]. This memo is a product of the Routing Policy System Working Group (RPS) in the Operational Requirements area of the Internet Engineer- ing Task Force. Submit comments to or the author. Introduction Tunneling is a fundamental networking technology that is used in a variety circumstances. A common use of tunneling is to incrementally deploy a new network layer protocol. The approach is to encapsulate ("tunnel") the new protocol through the existing network layer proto- col, usually IP. Examples of this approach include include the multi- cast backbone [MBONE], where multicast packets are encapsulated in IP packets using protocol 4 (IP in IP), and IPv6 backbone [6BONE], where IPv6 packets are encapsulated in IP packets using IP protocol 41 [V6TRNS]. Another use of tunneling is to force congruence between the existing (IP unicast) topology and some new topology. Due the special require- ments of IP multicast routing, the MBONE is also an example of this use of tunneling. This document describes extensions to RPSL to support general tunnel- ing mechanisms. The extensions support point to point and point to multipoint tunnels of encapsulation types, including DVMRP, GRE, and IPv6. In addition to the encapsulation, a protocol to run inside the tunnel can also be specified. Extensions to the inet-rtr class The inet-rtr class' peer attribute is extended to describe tunnels by assigning a new peer type (tunnel). The tunnel peer attribute has the following fields: inet-rtr: ... peer: tunnel source= encap= name= ... peer: tunnel source= encap= name= The type clause of then tunnel peer attribute describes the encapsu- lation on the tunnel. The defined encapsulation types are DVMRP [DVMRP], GRE [GRE], or IPv6 [IPV6]. The name clause refers to a tun- nel object (see below). If there are multiple tunnel peer attributes with the same name attribute, then the tunnel is a point to mul- tipoint tunnel. Note that a router can be the source of multiple tun- nels. Each inet-rtr tunnel peer instance has a mandatory name, source, and destination attributes. The tunnel source attribute must correspond to an ifaddr attribute for the inet-rtr instance. The inet-rtr instance below describes a DVMRP tunnel with source 204.70.32.6 and destination 204.70.158.61. The tag MBONE-TUNNEL-EUG refers to a tunnel instance (see below). The same router has a GRE tunnel. inet-rtr: eugene-isp.nero.net loacalas: AS4600 ifaddr: 204.70.32.6 masklen 30 ... peer: tunnel encap=DVMRP name=MBONE-TUNNEL-EUG 204.70.158.61 204.70.32.6 peer: tunnel encap=GRE name=GRE-TUNNEL-EUG 206.42.19.240 204.70.32.6 ... The inet-tunnel Class A tunnel is specified by an instance of the inet-tunnel class. The attributes of the inet-tunnel class are described below. inet-tunnel: tunnel-source: tunnel-sink: ... tunnel-sink: tunnel-protocol: tunnel-in: from accept tunnel-in: from accept ... tunnel-in: from accept tunnel-out: to [action [scope=;] [boundary=;] [dvmrp-metric=;]] announce tunnel-out: to [action [scope=;] [boundary=;] [dvmrp-metric=;]] announce ... tunnel-out: to [action [scope=;] [boundary=;] [dvmrp-metric=;]] announce inet-tunnel Class Attributes inet-tunnel: mandatory, single valued tunnel-source: mandatory, single valued, class key tunnel-sink: mandatory, single valued, class key tunnel-protocol: mandatory, single valued tunnel-in: mandatory, multi-valued tunnel-out: mandatory, multi-valued An instance of the inet-tunnel class describes a single tunnel (although the tunnel-source may be the source of multiple tunnels). The name attribute is a key that is used in an inet-rtr object to reference the tunnel object. The tunnel may be point to point or point to multipoint. A multipoint tunnel will have more than one tunnel-sink value. Each tunnel-sink must have corresponding tunnel-in and tunnel-out attributes. The tunnel-protocol is the protocol to run "inside" the tunnel. The values for tunnel-protocol include BGP, RIPv6, DVMRP, PIM-DM, and PIM-SM. See [SSMMC] for an application that uses BGP tunneled in GRE. The inet-tunnel class's tunnel-out attribute includes an action clause for which the currently defined actions include: (i). The minimum IP time-to-live required for a packet to be forwarded to the specified endpoint (in the case of multipoint tunnels, there may be per endpoint scopes), (ii). A boundary attribute describes a class of packets that will not be forwarded through the tunnel, and (iii). A DVMRP metric. These attributes are particularly relevant to multicast routing. The inet-tunnel class also has routing filter specifications which describe filters that are appropriate for the tunnel's routing proto- col. In the case of DVMRP, the filter specification can be the list of network prefixes accepted or advertised. Finally, an instance of the inet-tunnel class also has all of the administrative fields present in an aut-num class, including guar- dian, admin-c, tech-c, notify, mnt-by, changed, and source. Example In this example, the inet-rtr eugene-isp.nero.net has a DVMRP tunnel with the sink on the inet-rtr dec3800-2-fddi-0.SanFrancisco.mci.net. The tunnel object is called MBONE-TUNNEL-EUG. eugene-isp.nero.net will accept any routes. eugene-isp.nero.net will forward packets to the DVMRP tunnel if the packet's time-to-live is greater than or equal to 64. In addition, eugene-isp.nero.net will not pass any pack- ets that match the administrative scope boundary filter (in this case, 239.254.0.0/16). In addition, the inet-rtr eugene-isp.nero.net has a GRE tunnel represented by GRE-TUNNEL-EUG. inet-tunnel: MBONE-TUNNEL-EUG tunnel-source: 204.70.158.61 tunnel-sink: 204.70.32.6 tunnel-protocol: DVMRP tunnel-in: from 204.70.158.61 accept ANY tunnel-out: to 204.70.158.61 action scope=64; boundary={239.254.0.0/16}; dvmrp-metric=1; announce AS-NERO-TRANSIT guardian: meyer@ns.uoregon.edu admin-c: DMM65 tech-c: DMM65 notify: nethelp@ns.uoregon.edu mnt-by: MAINT-AS3582 changed: meyer@ns.uoregon.edu 961122 source: RADB inet-tunnel: GRE-TUNNEL-EUG tunnel-source: 204.70.158.61 tunnel-sink: 206.42.19.240 tunnel-protocol: PIM-DM tunnel-in: from 206.42.19.240 accept ANY tunnel-out: to 206.42.19.240 action scope=64; announce ANY guardian: meyer@ns.uoregon.edu admin-c: DMM65 tech-c: DMM65 notify: nethelp@ns.uoregon.edu mnt-by: MAINT-AS3582 changed: meyer@ns.uoregon.edu 961122 source: RADB Security Considerations Security considerations are not discussed in this memo. References [6BONE] See http://www-6bone.lbl.gov/6bone/ [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-03, September, 1996. [GRE] S. Hanks, T. Li, D. Farinacci, and P. Traina, "Generic Routing Encapsulation (GRE)", RFC1701, October, 1994. [IPV6] A. Conta and S. Deering, "Generic Packet Tunneling in IPv6", draft-ietf-ipngwg-ipv6-tunnel-04.txt, October, 1996 [MBONE] See http://www.best.com/~prince/techinfo/misc.html [RPSL] C. Alaettinoglu, et. al., "Routing Policy Specification Language (RPSL)", draft-ietf-rps-rpsl-00.txt, October, 1996. [SSMMC] Y. Rekhter, "Auto route injection with tunnelling", NANOG, October, 1996. For additional information, see http://www.academ.com/nanog/oct1996/multihome.html [V6TRNS] R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. Author's Address David Meyer University of Oregon 1225 Kincaid St. Eugene, OR 97403 phone: +1 541.346.1747 email: meyer@ns.uoregon.edu From pcurran@ticl.co.uk Wed Dec 11 14:01:56 1996 From: pcurran@ticl.co.uk (Peter Curran) Date: Wed, 11 Dec 1996 14:01:56 -0000 Subject: New 6bone site Message-ID: <199612111354.NAA07642@gate.ticl.co.uk> Thanks for the help so far, the site TICL is connected via IFB initially. The RIPE entry looks like this: site: TICL location: Dorking, UK loc-string: 51 13 30n 000 21 40w 115m prefix: 5f15:200:c120:100/64 ping: 5f15:200:c120:100:1::c120:142 tunnel: 193.32.1.66 194.105.166.254 IFB contact: Peter Curran status: Operational remark: More tunnels sought! changed pcurran@ticl.co.uk 961211 source: RIPE Hope to have a proper nameservice operational today, followed by a web server. Cheers Peter Curran TICL ------- From rchiang@coocoo.tnjc.edu.tw Thu Dec 12 09:24:56 1996 From: rchiang@coocoo.tnjc.edu.tw (Rick Chiang) Date: Thu, 12 Dec 1996 17:24:56 +0800 Subject: *** tunnel request *** Message-ID: <32AFCF68.73F65478@coocoo.tnjc.edu.tw> Dear 6bone folks: This is TNJC (Tung Nan Junior College of Technology) from Taiwan. We are seeking ipv6 tunnel link, please e-mail me if you have add our site to your ipv6 hosts. We shall update our tunnel file. Our current configuration are as follows: site: TNJC-TW IPv6 project location: Shen-Kan, Taipei, Taiwan, Republic of China prefix: 5f06:7b00::/64 ping: 5f06:7b00:8c81:8e00:0000:0800:207a:2cae ipv6.tnjc.edu.tw tunnel: 140.129.142.99 132.250.90.5 NRL tunnel: 140.129.142.99 131.175.5.37 CEFRIEL (Milano,Italy) tunnel: 140.129.142.99 192.32.29.62 Bay Networks (USA) tunnel: 140.129.142.99 129.99.237.71 NASA-NAS tunnel: 140.129.142.99 192.31.7.104 CISCO tunnel: 140.129.142.99 193.32.1.66 TICL contact: rchiang@coocoo.tnjc.edu.tw status: Operational Since 12/12/1996 remark: Using Solaris 2.5 for IPv6 changed: rchiang@coocoo.tnjc.edu.tw 961212 source: RIPE or, you may connect to ftp://info.ripe.net/ripe/ipv6/ip6rr/TNJC-TW for our latest update. Thanks for all your support. Sincerely Yours, Rick Chiang Chief of Computer Center Tung Nan Junior College of Technology From brandner@kar.dec.com Fri Dec 13 10:15:28 1996 From: brandner@kar.dec.com (Rudolf Brandner CEC Karlsruhe (+49-721-690231)) Date: Fri, 13 Dec 96 11:15:28 +0100 Subject: New 6bone site DIGITAL-EARC/DE Message-ID: <9612131015.AA11936@kaputt.kar.dec.com> Hi, I've just downloaded our RIPE entry, which looks like this: site: Digital Equipment Corporation location: Karlsruhe, Germany loc-string: 49 00 54n 8 24 18e 150m prefix: 5F04:FB00:810D:A900::/80 ping: earc-rtr.ipv6.kar-x.dec.com (5F04:FB00:810D:A900::F84A:A7B0) ping: earc.ipv6.kar-x.dec.com (5F04:FB00:810D:A900::800:2B3C:1FAD) tunnel: 129.13.169.3 204.123.2.236 DIGITAL-CA/US (RIP) tunnel-v4: earc-rtr.kar-x.dec.com (129.13.169.3) contact: @pa.dec.com status: operational since 12-DEC-1996 remark: RouteAbout Access EI/IPv6, Digital UNIX IPv6 remark: New tunnels added, RIP or static; send mail to contact changed: brandner@kar.dec.com 19961213 source: RIPE IPv4 nameserver is operational; IPv6 entries will be added soon. Tunnels and IPv6 connections are soon to be added, too. Regards, Rudolf Brandner CEC Karlsruhe, European Applied Research Center Digital Equipment Corporation email: brandner@kar.dec.com From dhaskin@baynetworks.com Tue Dec 17 20:56:14 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Tue, 17 Dec 1996 15:56:14 -0500 Subject: routin loop Message-ID: <199612172056.PAA11778@pobox.BayNetworks.com> traceroute -ip6 5f03:1200:9e7d:6000::1c10:30d1 1 [FE80::CC7B:02EC], time = 167 ms. 2 [5F00:6D00:C01F:0700:0001:0060:3E11:6770], time = 164 ms. 3 [FE80::CC7B:02EC], time = 140 ms. 4 [5F00:6D00:C01F:0700:0001:0060:3E11:6770], time = 171 ms. traceroute -ip6 5f01:2500:83e1:0:1:40:b40:728b 1 * 2 [FE80::CC7B:02EC], time = 249 ms. 3 [5F02:3000:C020:AE00:201D::0007], time = 207 ms. 4 [FE80::84B1:7E9D], time = 367 ms. 5 [FE80::CC7B:02EC], time = 503 ms. 6: * 7 [FE80::84B1:7E9D], time = 597 ms. 8 [FE80::CC7B:02EC], time = 574 ms. It seems that we have plenty of these nowadays ;( Dimitry From RLFink@lbl.gov Wed Dec 18 00:56:28 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 17 Dec 1996 16:56:28 -0800 Subject: 6bone Tshirt first order followup Message-ID: 6bone Tshirt folk: I have enclosed three lists below: Tshirts to be mailed real soon as I do have your address Tshirts I can't mail as I don't have your address Tshirts picked up and paid for at the IETF in San Jose Those on the third list, read no further, and thanks for your support! Those on the second list, please send your mail address so I can send out your Tshirts. Those on the first list, your Tshirts will be sent out either this week, or the first week in January. (The Lab here closes for most of the two weeks from 21 Dec to 5 Jan - I love it :-) All Tshirts mailed will be sent airmail, will have an enclosed piece of LBNL literature telling you what great R&D we do, and will have a declared value of $0! There will be no bills mailed. This email constitutes your bill. Please send me your payment of $10 per Tshirt as soon as possible, but no later that when you actually receive your Tshirt. If you need a receipt, please email me and I'll email a receipt back to you. If you want more Tshirts at this stage, please wait for the call for the 2nd Tshirt order. Thanks, Bob ======================================== To be mailed, i.e., I have your address: ---------------------------------------- Belding, Peter 1 XL mail PAID Blundell, Phil 2 L mail Bryant, Geoff 1 L mail Choi, Woohyong 6 XL, 4 L mail Clay, Mike 1 L, 1 XL mail Curran, Peter 2 L mail Dalgeir, Gudrun 1 XXL, 1 S, 5 XL mail Davis, Eric 2 XXL mail Day, Jonathan 3 XL mail Ganis, Matt 3 XL, 5 L Mail Glenn, Robert 2 XL mail Goode, Rob 1 M mail Haskin, Dimitry 4 XL, 2 M, 9 L mail Hazeltine, Andy 2 M, 1 L, 1 XL mail Hjalmtysson, Gisli 10 XL mail Honerkamp, Robbie 1 XL mail Jaeger, Kurt 5 XL, 1 XXL mail Kessler, Gary 1 XL mail King, Ray 4 L mail Kirkpatrick, Ben 1 XL mail Konczal, Joe 1 XL mail Kules, Bill 1 XL, 1 L mail Laird, Scott 7 L, 7 XL mail Latzko, Alex 9 XL, 1 L mail Malek, Shabou 1 XL mail Meier, Erich 2 XL mail Michlmayr, Mike 4 XXL, 2 XL mail Onoe, Atsushi 1 L mail Page, John 2 L mail Peachey, Alex 2 XXL mail Peck, Martin 8 L, 4 XL mail Sharfmesser, Igor 3 XL mail Sjodin, Peter 4 XL mail Spindler, Tom 2 XXL mail Stevens, Richard 1 XL mail StPierre, Brad 1 L mail Turner, Rob 1 XXL mail PAID -end ====================================== To be mailed, but I need your address: -------------------------------------- Bassham, Larry 1 L ietf Boroumand, Jarad 2 XL ietf DeCasper, Dan 10 XL mail Degermark, Mikael 2 XL ? (not confirmed) Field, Brian 1 XL mail Hamilton, Martin 2 XL ietf Macker. Joe 1 XL ietf Martin, Jim 1 XL ietf (not confirmed) Metz, Craig 2 XL, 1 L mail (not confirmed) Winchcombe, Charlie 5 XXL mail -end ======================= Picked up and paid for: ----------------------- Acheson, Steve 1 XL mail Asayesh, Hamid 35 L, 10 XL ietf Atkinson, Ran 2 L, 1 XL ietf Bhogavilli, Suresh 1 L ietf Bound, Jim 3 L ietf Cianci, Frank 1 XL ietf Clauberg, Axel 3 XL ietf Collins, Mike 1 XL, 1 XXXL ietf Crawford, Matt 4 XL ietf Deering, Steve 1 XL ietf de Groot, Geert Jan 1 XL ietf Dupont, Francis 1 XXL ietf Durand, Alain 2L, 8 XL ietf Edmondson, Dave 9 XL ietf (pickup by Andrew Malcolm) Eklund, Thomas 10 XL ietf Fang, Hsin 1 XL ietf Fernstedt, Anders 25 L, 25 XL ietf Hinden, Bob 2 XL ietf Hirabaru, Masaki 2 XL ietf Hoag, Andrew 2 XL ietf Jinmei, Tatuya 5 L ietf Jork, Markus 2 L, 3 XL ietf Juliano, Bryan 1 XL ietf Kann, Jong 4 L ietf Kato, Akira 2 L ietf Labovitz, Craig 1 XL ietf Lahey, Kevin 2 L ietf Lee, Ron 1 L, 5 XL ietf McCann, Jack 2 XL ? (not confirmed) Meyer, David 2 M, 3 XXL ietf Montgomery, Doug 2 XL, 2 L ietf Moore, Mike 2 XL ietf Narten, Tom 1 XL ietf (not confirmed) Nerenberg, Lyndon 6 XL ietf Nitzan, Becca 1 M ietf Ouin, Edouard 3 XL ietf Sakurai, Akihiro 1 M, 1 L, 1 XL mail Schoenwaelder, Juergen 10 XL, 1 L ietf Shand, Mike 1 XL ietf Solensky, Frank 1 L ietf (not confirmed) Souissi, Mohsen 1 L ietf (Dupont pickup) Stuart, Stephen 3 XL ietf Sumikawa, Munechika 2 L ietf Templin, Fred 1 XL, 2 XXL ietf Vohra, Quaizar 3 XL, 1 L, 1 M ietf Weise, Bernd 5 XL, 5 XXL ietf Wessendorf, Guido 2 XL, 1 L ietf Yamamoto, Kazuhiko 1 L ietf Yoshida, Shin 1 L ietf Zhang, Lixia 1 M ietf -end From RLFink@lbl.gov Wed Dec 18 02:56:00 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Tue, 17 Dec 1996 18:56:00 -0800 Subject: 6bone and the IETF Message-ID: The IETF San Jose meetings went quite well, in spite of early concerns about overcrowding. The really important v6 highlights for me were: 1. Dimitry Haskin (Bay) and Dave Katz (Cisco) agreeing to work together to make a BGP4+ that supports both v4 and v6. I think this will turn out to be a watershed item for ISP willingness to support v6. 2. Sincere interest in Mike O'Dell's 8+8 v6 addressing proposal. There are many unanswered questions, but almost everyone feels that understanding if 8+8 can be made to work is a very high priority. As for the 6bone BOF, things went well. There were ~115 folk attending and strong consensus to start up a 6bone working group. I have agreed to chair the working group. More on this new working group formation below. We also discussed topology, addressing, and routing for a 6bone better suited for continuing IPv6 testbed activities. Also discussed was a new format for the RIPE registry based on RPSL work and what to do with the 6bone map. On these discussion items there were no decisions attempted, just agreement to carry on more discussions on the mailer. More on this in other email(s). As for Working Group formation, I have included a first draft 6bone charter below as I presented to the BOF. I would like some discussion and hopefully consensus on this, and on a set of goals/milestones for the first year under this charter. I have proposed some for discussion below. You will note that I have caste the 6bone BOF discussions on topology, addressing and routing in the context of creating a new 6bone testbed infrastructure better suited to learning about IPv6 implementations and IPv6 transition. Though not explicitly stated this way in the large, I believe this to be the general intent of the discussions, and at this point in the life of the 6bone, an important next step. Comments to the mailer please! Thanks, Bob ===================== Goals and Milestones: Jan 97 Establish and submit initial charter, goals, and first year group agenda. Jan/Feb 97 Interact with RPS WG on extensions for "Representing Tunnels in RPSL" based on David Meyer's Internet-Draft. Jan 97 Continue discussion on topology, addressing and routing (from the BOF) for a new 6bone infrastructure better suited to IPv6 testbed goals. Continue discussion on the future of the RIPE-NCC 6bone routing registry and how it relates to the RPSL work. Feb 97 Begin to restructure the 6bone testbed based on discussions. Mar 97 Begin work on an Internet-Draft outlining requirements for the new 6bone infrastructure. Apr 97 Decide what direction to take with the RIPE-NCC 6bone routing registry. Apr 97 Continuing interaction with, and feedback to, the IPng working groups at the IETF. Aug 97 Finish work on Internet-Draft outlining requirements for the new 6bone infrastructure. Aug 97 Continuing interaction with, and feedback to, the IPng working groups at the IETF. Sep 97 Interact with MBONED on their work for co-existence strategies for IPv4 multicast and IPv6 multicast. (This based on the MBONED milestones.) Dec 97 Begin work on a document describing operational practices and experiences for the 6bone. Dec 97 Continuing interaction with, and feedback to, the IPng working groups at the IETF. =============================================================================== Draft 6bone Charter as presented at the BOF The 6bone Working Group is a forum for information concerning the deployment, engineering, and operation of ipv6 protocols and procedures in the global Internet. This activity will include, but not be limited to: - Deployment of ipv6 transport and routing in the global Internet via a "6bone" testbed to assist in the following. - Creation of "practice and experience" informational RFC documents that capture the experiences of those who have deployed, and are deploying, various ipv6 technologies. - Feedback to various IETF ipv6-related activities, based on testbed experience, where appropriate. - Development of mechanisms and procedures to aid in the transition to native ipv6, where appropriate. - Development of mechanisms and procedures for sharing operational information to aid in operation of global ipv6 routing. - end From stuart@pa.dec.com Wed Dec 18 05:47:21 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Tue, 17 Dec 96 21:47:21 -0800 Subject: routin loop In-Reply-To: Your message of Tue, 17 Dec 96 15:56:14 -0500. <199612172056.PAA11778@pobox.BayNetworks.com> Message-ID: <9612180547.AA14015@nsl-too.pa.dec.com> > > traceroute -ip6 5f03:1200:9e7d:6000::1c10:30d1 > 1 [FE80::CC7B:02EC], time = 167 ms. > 2 [5F00:6D00:C01F:0700:0001:0060:3E11:6770], time = 164 ms. > 3 [FE80::CC7B:02EC], time = 140 ms. > 4 [5F00:6D00:C01F:0700:0001:0060:3E11:6770], time = 171 ms. I'm hops 1 and 3, and I think I fixed this by directing traffic to LUT and IFB through NRL instead of CISCO, but my traceroute now dies at IFB: % traceroute6 5f03:1200:9e7d:6000::1c10:30d1 traceroute to 5f03:1200:9e7d:6000::1c10:30d1 (5F03:1200:9E7D:6000::1C10:30D1), 30 hops max, 24 byte packets 1 gw.ipv6.pa-x.dec.com (5F00:2100:CC7B::12:0:F842:142C) 2.928 ms 1.952 ms 0.976 ms 2 buzzcut.ipv6.nrl.navy.mil (5F00:3000:84FA:5A00::5) 89.744 ms 88.416 ms 87.84 ms 3 ::194.105.166.254 (::194.105.166.254) 1403.25 ms 408.544 ms * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * > traceroute -ip6 5f01:2500:83e1:0:1:40:b40:728b > 1 * > 2 [FE80::CC7B:02EC], time = 249 ms. > 3 [5F02:3000:C020:AE00:201D::0007], time = 207 ms. > 4 [FE80::84B1:7E9D], time = 367 ms. > 5 [FE80::CC7B:02EC], time = 503 ms. > 6: * > 7 [FE80::84B1:7E9D], time = 597 ms. > 8 [FE80::CC7B:02EC], time = 574 ms. > > It seems that we have plenty of these nowadays ;( Hops 2, 5, and 8 were me, and I was sending the traffic back to you (BAY). Looking at the registry entry for ESNET, it appeared that the right thing to do was for me to direct the traffic toward CISCO; I did, and: % traceroute6 5f01:2500:c680:200:0:800:2bbc:f1ec traceroute to 5f01:2500:c680:200:0:800:2bbc:f1ec (5F01:2500:C680:200::800:2BBC:F1EC), 30 hops max, 24 byte packets 1 gw.ipv6.pa-x.dec.com (5F00:2100:CC7B::12:0:F842:142C) 1.952 ms 0.976 ms 0.976 ms 2 6bone-router.cisco.inner.net (5F00:6D00:C01F:700:1:60:3E11:6770) 4.88 ms * 5.856 ms 3 esnet-v6r1.es.net (5F01:2500:C680:200::800:2BBC:F1EC) 16.592 ms 27.328 ms 15.616 ms Can you check to see if you still see a loop? Stephen From dhaskin@baynetworks.com Wed Dec 18 15:18:37 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Wed, 18 Dec 1996 10:18:37 -0500 Subject: routin loop Message-ID: <199612181518.KAA13205@pobox.BayNetworks.com> Stephen, Those two loops that I originally posted are fixed. But there is another one: traceroute -ip6 5f00:3100:8106:3300:0:c0:3302:5a 1 (If 1): [FE80::84B1:7E9D], time = 105 ms. 2 (If 7): [FE80::CC7B:02EC], time = 148 ms. 3 (If 0): [5F02:3000:C020:AE00:201D::0007], time = 132 ms. 4 (If 1): [FE80::84B1:7E9D], time = 253 ms. 5 (If 7): [FE80::CC7B:02EC], time = 308 ms. 6 (If 0): [5F02:3000:C020:AE00:201D::0007], time = 304 ms. 7 (If 1): [FE80::84B1:7E9D], time = 457 ms. 8 (If 7): [FE80::CC7B:02EC], time = 531 ms. Looking at NIST's stats on the 6bone home page it seems that very few 6bone nodes are reachable from NIST. I beleive that the problem stems from the fact that we now have a combination of rip and static routing on 6bone. This is a sure recipe for loops. A correct model would be to form a backbone of routers that use only rip to pass reachability information among themselves and use static routes only to point to their leaf clients. Dimitry > From stuart@pa.dec.com Wed Dec 18 00:50 EST 1996 > Posted-Date: Tue, 17 Dec 1996 21:50:50 -0800 (PST) > To: dhaskin@BayNetworks.com (Dimitry Haskin) > Cc: 6bone@isi.edu > Subject: Re: routin loop > Date: Tue, 17 Dec 96 21:47:21 -0800 > From: Stephen Stuart > X-Mts: smtp > Content-Type> : > text> > Content-Length: 1910 > > > > > traceroute -ip6 5f03:1200:9e7d:6000::1c10:30d1 > > 1 [FE80::CC7B:02EC], time = 167 ms. > > 2 [5F00:6D00:C01F:0700:0001:0060:3E11:6770], time = 164 ms. > > 3 [FE80::CC7B:02EC], time = 140 ms. > > 4 [5F00:6D00:C01F:0700:0001:0060:3E11:6770], time = 171 ms. > > I'm hops 1 and 3, and I think I fixed this by directing traffic to LUT > and IFB through NRL instead of CISCO, but my traceroute now dies at > IFB: > > % traceroute6 5f03:1200:9e7d:6000::1c10:30d1 > traceroute to 5f03:1200:9e7d:6000::1c10:30d1 (5F03:1200:9E7D:6000::1C10:30D1), 30 hops max, 24 byte packets > 1 gw.ipv6.pa-x.dec.com (5F00:2100:CC7B::12:0:F842:142C) 2.928 ms 1.952 ms 0.976 ms > 2 buzzcut.ipv6.nrl.navy.mil (5F00:3000:84FA:5A00::5) 89.744 ms 88.416 ms 87.84 ms > 3 ::194.105.166.254 (::194.105.166.254) 1403.25 ms 408.544 ms * > 4 * * * > 5 * * * > 6 * * * > 7 * * * > 8 * * * > > > > traceroute -ip6 5f01:2500:83e1:0:1:40:b40:728b > > 1 * > > 2 [FE80::CC7B:02EC], time = 249 ms. > > 3 [5F02:3000:C020:AE00:201D::0007], time = 207 ms. > > 4 [FE80::84B1:7E9D], time = 367 ms. > > 5 [FE80::CC7B:02EC], time = 503 ms. > > 6: * > > 7 [FE80::84B1:7E9D], time = 597 ms. > > 8 [FE80::CC7B:02EC], time = 574 ms. > > > > It seems that we have plenty of these nowadays ;( > > Hops 2, 5, and 8 were me, and I was sending the traffic back to you > (BAY). Looking at the registry entry for ESNET, it appeared that the > right thing to do was for me to direct the traffic toward CISCO; I did, > and: > > % traceroute6 5f01:2500:c680:200:0:800:2bbc:f1ec > traceroute to 5f01:2500:c680:200:0:800:2bbc:f1ec (5F01:2500:C680:200::800:2BBC:F1EC), 30 hops max, 24 byte packets > 1 gw.ipv6.pa-x.dec.com (5F00:2100:CC7B::12:0:F842:142C) 1.952 ms 0.976 ms 0.976 ms > 2 6bone-router.cisco.inner.net (5F00:6D00:C01F:700:1:60:3E11:6770) 4.88 ms * 5.856 ms > 3 esnet-v6r1.es.net (5F01:2500:C680:200::800:2BBC:F1EC) 16.592 ms 27.328 ms 15.616 ms > > Can you check to see if you still see a loop? > > Stephen From nitzan@es.net Wed Dec 18 16:57:17 1996 From: nitzan@es.net (Rebecca L. Nitzan) Date: Wed, 18 Dec 96 08:57:17 -0800 Subject: routin loop In-Reply-To: Your message of "Tue, 17 Dec 96 21:47:21 PST." <9612180547.AA14015@nsl-too.pa.dec.com> Message-ID: <199612181657.IAA02000@hershey.es.net> >(BAY). Looking at the registry entry for ESNET, it appeared that the >right thing to do was for me to direct the traffic toward CISCO; I did, >and: > >% traceroute6 5f01:2500:c680:200:0:800:2bbc:f1ec >traceroute to 5f01:2500:c680:200:0:800:2bbc:f1ec (5F01:2500:C680:200::800:2BBC > :F1EC), 30 hops max, 24 byte packets > 1 gw.ipv6.pa-x.dec.com (5F00:2100:CC7B::12:0:F842:142C) 1.952 ms 0.976 ms > 0.976 ms > 2 6bone-router.cisco.inner.net (5F00:6D00:C01F:700:1:60:3E11:6770) 4.88 ms * > 5.856 ms > 3 esnet-v6r1.es.net (5F01:2500:C680:200::800:2BBC:F1EC) 16.592 ms 27.328 m > s 15.616 ms > >Can you check to see if you still see a loop? > Stephen: You are correctly pointing the prefix to Cisco, who in turn has a static route to ESnet for 5f01:2500:83e1::/48. From ESnet it looks like I can't reach any of the FNAL hosts either, Status: RO I tried all 4 of them that I know of. We'll follow up w/FNAL. root@esnet-v6r1 795 : traceroute6 5f01:2500:83e1:0:1:40:b40:728b traceroute to 5f01:2500:83e1:0:1:40:b40:728b (5F01:2500:83E1::1:40:B40:728B), 30 hops max, 24 byte packets 1 * * * 2 * * * ... Thanks for letting us know. -- Becca ----------------------------------------------------------------------- Rebecca L. Nitzan Lawrence Berkeley National Lab Network Engineering Services Group 1 Cyclotron Rd, MS 50A-3111 ESnet - Energy Sciences Network Berkeley, CA. 94720 phone: 510-486-6468 fax: 510-486-6712 nitzan@es.net ----------------------------------------------------------------------- From stuart@pa.dec.com Wed Dec 18 16:14:26 1996 From: stuart@pa.dec.com (Stephen Stuart) Date: Wed, 18 Dec 96 08:14:26 -0800 Subject: routin loop In-Reply-To: Your message of Wed, 18 Dec 96 10:18:37 -0500. <199612181518.KAA13205@pobox.BayNetworks.com> Message-ID: <9612181614.AA23607@nsl-too.pa.dec.com> > Stephen, > > Those two loops that I originally posted are fixed. But there is > another one: > > traceroute -ip6 5f00:3100:8106:3300:0:c0:3302:5a > [...] > > Looking at NIST's stats on the 6bone home page it seems that > very few 6bone nodes are reachable from NIST. I pointed my NIST route at NRL, and got there in 3: % traceroute6 5f00:3100:8106:3300:0:c0:3302:5a traceroute to 5f00:3100:8106:3300:0:c0:3302:5a (5F00:3100:8106:3300::C0:3302:5A), 30 hops max, 24 byte packets 1 gw.ipv6.pa-x.dec.com (5F00:2100:CC7B::12:0:F842:142C) 3.908 ms 1.954 ms 1.954 ms 2 buzzcut.ipv6.nrl.navy.mil (5F00:3000:84FA:5A00::5) 113.251 ms 108.336 ms 109.312 ms 3 ipng9.ipng.nist.gov (5F00:3100:8106:3300::C0:3302:5A) 125.904 ms * 126.88 ms > I beleive that the problem stems from the fact that we now > have a combination of rip and static routing on 6bone. This > is a sure recipe for loops. A correct model would be to > form a backbone of routers that use only rip to pass reachability > information among themselves and use static routes only to > point to their leaf clients. Something like that, to be sure; much of IETF week is a blur to me, but I have a vague recollection that the opposite was proposed? A static routed core, with RIP to leaf nodes? Stephen From martin@mrrl.lut.ac.uk Wed Dec 18 18:48:49 1996 From: martin@mrrl.lut.ac.uk (Martin Hamilton) Date: Wed, 18 Dec 1996 18:48:49 +0000 Subject: routin loop In-Reply-To: Your message of "Tue, 17 Dec 1996 21:47:21 PST." <9612180547.AA14015@nsl-too.pa.dec.com> Message-ID: <199612181848.SAA21223@gizmo.lut.ac.uk> --==_Exmh_853725952P Content-Type: text/plain; charset=us-ascii Stephen Stuart writes: | % traceroute6 5f03:1200:9e7d:6000::1c10:30d1 | traceroute to 5f03:1200:9e7d:6000::1c10:30d1 (5F03:1200:9E7D:6000::1C10:30D1) | , 30 hops max, 24 byte packets | 1 gw.ipv6.pa-x.dec.com (5F00:2100:CC7B::12:0:F842:142C) 2.928 ms 1.952 ms | 0.976 ms | 2 buzzcut.ipv6.nrl.navy.mil (5F00:3000:84FA:5A00::5) 89.744 ms 88.416 ms | 87.84 ms | 3 ::194.105.166.254 (::194.105.166.254) 1403.25 ms 408.544 ms * | 4 * * * We'd slipped off the 6bone! Having said that, this machine is highly experimental in any case, so don't be surprised if you can't contact it. I've added a note to this effect to our RIPE entry. You should be able to ping us now, and I'll try not to break anything for a few days... :-) Cheerio, Martin --==_Exmh_853725952P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3i iQCVAwUBMrg8jdZdpXZXTSjhAQFHBQQAmGzGSqEQZeC6i18Q3h2CzLXLffzd18ec mP5C/8b9+VDU3NAuKDZ6ibgbx5APF3fl6Fk4it3L3VKWBEt9CuS5Uma0hiaqdGND sABh1PH13+Jx6h8izea3Zl4aConB5tZc+Lk/2lIFAlWS4il0xNIzuFJW/2yqTtzg 0GtAGUdiCdY= =11rt -----END PGP MESSAGE----- --==_Exmh_853725952P-- From Ivano.Guardini@cselt.stet.it Wed Dec 18 10:45:11 1996 From: Ivano.Guardini@cselt.stet.it (Guardini Ivano) Date: Wed, 18 Dec 1996 11:45:11 +0100 Subject: New tunnel from CSELT Message-ID: Hi, there is one new tunnel between CSELT and G6. G6 <-----> CSELT I have updated CSELT RIPE database entry: site: CSELT (Centro Studi E Laboratori Telecomunicazioni) location: Torino, ITALY loc-string: 45 03 52.2n 07 39 43.2e 250m prefix: 5f16:4d00::/32 ping: 5f16:4d00:a3a2:1100:11:800:2071:d812 tunnel: 163.162.17.77 129.88.26.1 G6 tunnel: 163.162.252.4 131.175.5.37 CEFRIEL contact: Ivano Guardini status: operational since December 4, 1996 remark: Sun SPARC STATION 20, IPv6 for Solaris 2.5 changed: ivano.guardini@cselt.stet.it 19961218 source: RIPE Here is ping from CSELT to G6: root@carmen:/#>ping6 -s 6bone-gw.ipv6.imag.fr PING 6bone-gw.ipv6.imag.fr: 56 data bytes 104 bytes from 5f06:b500:8158:1a00:1:0:8158:1a01: icmp_seq=0. time=274 ms 104 bytes from 5f06:b500:8158:1a00:1:0:8158:1a01: icmp_seq=1. time=335 ms 104 bytes from 5f06:b500:8158:1a00:1:0:8158:1a01: icmp_seq=2. time=240 ms 104 bytes from 5f06:b500:8158:1a00:1:0:8158:1a01: icmp_seq=4. time=373 ms 104 bytes from 5f06:b500:8158:1a00:1:0:8158:1a01: icmp_seq=5. time=245 ms 104 bytes from 5f06:b500:8158:1a00:1:0:8158:1a01: icmp_seq=6. time=161 ms Bye Ivano --------------------------------------------------- Ivano Guardini CSELT SpA via G. Reiss Romoli 274 Torino (Italy) Tel. +39 11 228 5424 Fax. +39 11 228 5069 --------------------------------------------------- From jstewart@metro.isi.edu Wed Dec 18 22:21:15 1996 From: jstewart@metro.isi.edu (John W. Stewart III) Date: Wed, 18 Dec 1996 17:21:15 EST Subject: BGP-4+ In-Reply-To: Your message of "Wed, 18 Dec 1996 12:11:14 PST." <199612182011.MAA23562@puli.cisco.com> Message-ID: <199612182221.AA20250@metro.isi.edu> yakov, under what circumstances does a router send SNPAs? and what does a router do on receipt of SNPAs? also, from reading the draft, i'm assuming that you plan to support only ASs and not RDs? did you consider typing routing domains in addition to network addresses? thanks, /jws > Sue, > > > > > Hi all: > > > > > > FYI - Neither Dimitry or Dave Katz have forwarded a specification > > for the BGP-4+. Please encourage them to forward > > a description of the protocol to the idr working group. > > An open discussion of changes to bgp-4 is always welcome. > > Yakov and I both expressed interest in getting a specification > > before the working group. We did not discuss it at the > > December meeting because there was not a specification. > > > > [This ends my speaking as the co-chair of IDR working group.] > > Attached is the proposal from Tony Bates, Ravi Chandra, Dave Katz > and myself for backward compatible multiprotocol extensions to > BGP-4. > > Yakov. > > P.S. I added bgp@ans.net to the cc: list. > -------------------------------------------------------------------- > > > > > > Network Working Group Tony Bates > Internet Draft Cisco Systems > Expiration Date: June 1997 Ravi Chandra > Cisco Systems > Dave Katz > Cisco Systems > Yakov Rekhter > Cisco Systems > > > Multiprotocol Extensions for BGP-4 > > draft-bates-bgp4-multiprotocol-00.txt > > > 1. Status of this Memo > > This document is an Internet-Draft. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its areas, > and its working groups. Note that other groups may also distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as ``work in progress.'' > > To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow > Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), > munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or > ftp.isi.edu (US West Coast). > > > 2. Abstract > > Currently BGP-4 [BGP-4] is capable of carrying routing information > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > enable it to carry routing information for multiple Network Layer > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > compatible - a router that supports the extensions can interoperate > with a router that doesn't support the extensions. > > > > > > > > > > Bates, Chandra, Katz, Rekhter [Page 1] > > > > > > Internet Draft draft-bates-bgp4-multiprotocol-00.txt December 1996 > > > 3. Overview > > The only three pieces of information carried by BGP-4 that are IPv4 > specific are (a) the NEXT_HOP attribute (expressed as an IPv4 > address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI > (expressed as IPv4 address prefixes). This document assumes that any > BGP speaker (including the one that supports multiprotocol > capabilities defined in this document) will have to support IPv4 and > have an IPv4 address. Therefore, to enable BGP-4 to support routing > for multiple Network Layer protocols the only two things that have to > be added to BGP-4 are (a) the ability to associate a particular > Network Layer protocol with the next hop information, and (b) the > ability to associated a particular Network Layer protocol with NLRI. > To identify individual Network Layer protocols this document uses > Address Family, as defined in [RFC1700]. > > One could further observe that the next hop information (the > information provided by the NEXT_HOP attribute) is meaningful (and > necessary) only in conjunction with the advertisements of reachable > destinations - in conjunction with the advertisements of unreachable > destinations (withdrawing routes from service) the next hop > information is meaningless. This suggests that the advertisement of > reachable destinations should be grouped with the advertisement of > the next hop to be used for these destinations, and that the > advertisement of reachable destinations should be segregated from the > advertisement of unreachable destinations. > > To provide backward compatibility, as well as to simplify > introduction of the multiprotocol capabilities into BGP-4 this > document uses two new attributes, Multiprotocol Reachable NLRI > (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI > (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the > set of reachable destinations together with the next hop information > to be used for forwarding to these destinations. The second one > (MP_UNREACH_NLRI) is used to carry the set of unreachable > destinations. Both of these attributes are optional and non- > transitive. This way a BGP speaker that doesn't support the > multiprotocol capabilities would just ignore the information carried > in these attributes, and wouldn't pass it to other BGP speakers. > > > > > > > > > > > > > Bates, Chandra, Katz, Rekhter [Page 2] > > > > > > Internet Draft draft-bates-bgp4-multiprotocol-00.txt December 1996 > > > 4. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14): > > This is an optional non-transitive attribute that can be used for the > following purposes: > > (a) to advertise a feasible route to a peer > > (b) to permit a router to advertise the Network Layer address of > the router that should be used as the next hop to the destinations > listed in the Network Layer Reachability Information field of the > MP_NLRI attribute. > > (c) to allow a given router to report some or all of the > Subnetwork Points of Attachment (SNPAs) that exist within the > local system > > > The attribute consists of two components, the next hop information > and the list of reachable destinations. > > The attribute is encoded as shown below: > > > +---------------------------------------------------+ > | Address Family (2 octets) | > +---------------------------------------------------+ > | Length of Network Address (1 octet) | > +---------------------------------------------------+ > | Network Address of Next Hop (variable) | > +---------------------------------------------------+ > | Number of SNPAs (1 octet) | > +---------------------------------------------------+ > | Length of first SNPA(1 octet) | > +---------------------------------------------------+ > | First SNPA (variable) | > +---------------------------------------------------+ > | Length of second SNPA (1 octet) | > +---------------------------------------------------+ > | Second SNPA (variable) | > +---------------------------------------------------+ > | ... | > +---------------------------------------------------+ > | Length of Last SNPA (1 octet) | > +---------------------------------------------------+ > | Last SNPA (variable) | > +---------------------------------------------------+ > | Network Layer Reachability Information (variable) | > +---------------------------------------------------+ > > > > Bates, Chandra, Katz, Rekhter [Page 3] > > > > > > Internet Draft draft-bates-bgp4-multiprotocol-00.txt December 1996 > > > The use and meaning of these fields are as follows: > > Address Family > > This field carries the identity of the Network Layer protocol > associated with the Network Address that follows. Presently > defined values for this field are specified in RFC1700. > > Length of Network Address: > > A 1 octet field whose value expresses the length of the > "Network Address of Next Hop" field as measured in octets > > Network Address of Next Hop: > > A variable length field that contains the Network Address of > the next router on the path to the destination system > > Number of SNPAs: > > A 1 octet field which contains the number of distinct SNPAs to > be listed in the following fields. The value 0 may be used to > indicate that no SNPAs are listed in this attribute. > > Length of Nth SNPA: > > A 1 octet field whose value expresses the length of the "Nth > SNPA of Next Hop" field as measured in semi-octets > > Nth SNPA of Next Hop: > > A variable length field that contains an SNPA of the router > whose Network Address is contained in the "Network Address of > Next Hop" field. The field length is an integral number of > octets in length, namely the rounded-up integer value of one > half the SNPA length expressed in semi-octets; if the SNPA > contains an odd number of semi-octets, a value in this field > will be padded with a trailing all-zero semi-octet. > > Network Layer Reachability Information: > > A variable length field that lists the destinations for the > feasible routes that are being advertised in this attribute. > Each NLRI is encoded as specified in the "NLRI encoding" > section of this document. > > The next hop information carried in the MP_REACH_NLRI path attribute > defines the Network Layer address of the border router that should be > > > > Bates, Chandra, Katz, Rekhter [Page 4] > > > > > > Internet Draft draft-bates-bgp4-multiprotocol-00.txt December 1996 > > > used as the next hop to the destinations listed in the MP_NLRI > attribute in the UPDATE message. When advertising a MP_REACH_NLRI > attribute to an external peer, a router may use one of its own > interface addresses in the next hop component of the attribute, > provided the external peer to which the route is being advertised > shares a common subnet with the next hop address. This is known as a > "first party" next hop. A BGP speaker can advertise to an external > peer an interface of any internal peer router in the next hop > component, provided the external peer to which the route is being > advertised shares a common subnet with the next hop address. This is > known as a "third party" next hop information. A BGP speaker can > advertise any external peer router in the next hop component, > provided that the Network Layer address of this border router was > learned from an external peer, and the external peer to which the > route is being advertised shares a common subnet with the next hop > address. This is a second form of "third party" next hop > information. > > Normally the next hop information is chosen such that the shortest > available path will be taken. A BGP speaker must be able to support > disabling advertisement of third party next hop information to handle > imperfectly bridged media. > > A BGP speaker must never advertise an address of a peer to that peer > as a next hop, for a route that the speaker is originating. A BGP > speaker must never install a route with itself as the next hop. > > When a BGP speaker advertises the route to an internal peer, the > advertising speaker should not modify the next hop information > associated with the route. When a BGP speaker receives the route via > an internal link, it may forward packets to the next hop address if > the address contained in the attribute is on a common subnet with the > local and remote BGP speakers. > > > 5. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15): > > This is an optional non-transitive attribute that can be used for the > purpose of withdrawing multiple unfeasible routes from service. > > The attribute is encoded as shown below: > > +-----------------------------+ > | Address Family (2 octets) | > +-----------------------------+ > | Withdrawn Routes (variable) | > +-----------------------------+ > > > > > Bates, Chandra, Katz, Rekhter [Page 5] > > > > > > Internet Draft draft-bates-bgp4-multiprotocol-00.txt December 1996 > > > The use and the meaning of these fields are as follows: > > Address Family > > This field carries the identity of the Network Layer protocol > associated with the NLRI that follows. Presently defined values > for this field are specified in RFC1700. > > Withdrawn Routes: > > This is a variable length field that contains a list of NLRIs > for the routes that are being withdrawn from service. Each NLRI > is encoded as specified in the "NLRI encoding" section of this > document. > > > > 6. NLRI encoding > > The Network Layer Reachability information is encoded as one or more > 2-tuples of the form , whose fields are described > below: > > > +---------------------------+ > | Length (1 octet) | > +---------------------------+ > | Prefix (variable) | > +---------------------------+ > > > > The use and the meaning of these fields are as follows: > > a) Length: > > The Length field indicates the length in bits of the address > prefix. A length of zero indicates a prefix that matches all > (as specified by the address family) addresses (with prefix, > itself, of zero octets). > > b) Prefix: > > The Prefix field contains address prefixes followed by enough > trailing bits to make the end of the field fall on an octet > boundary. Note that the value of trailing bits is irrelevant. > > > > > > Bates, Chandra, Katz, Rekhter [Page 6] > > > > > > Internet Draft draft-bates-bgp4-multiprotocol-00.txt December 1996 > > > 7. Security Considerations > > Security issues are not discussed in this document. > > > 8. Acknowledgements > > To be supplied. > > > 9. References > > > [BGP-4] > > [IPv4] > > [IPv6] > > [RFC1700] > > > 10. Author Information > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bates, Chandra, Katz, Rekhter [Page 7] > > > > > > Internet Draft draft-bates-bgp4-multiprotocol-00.txt December 1996 > > > > Tony Bates > Cisco Systems, Inc. > 170 West Tasman Drive > San Jose, CA 95134 > email: tbates@cisco.com > > Ravi Chandra > Cisco Systems, Inc. > 170 West Tasman Drive > San Jose, CA 95134 > email: rchandra@cisco.com > > Dave Katz > Cisco Systems, Inc. > 170 West Tasman Drive > San Jose, CA 95134 > email: dkatz@cisco.com > > Yakov Rekhter > Cisco Systems, Inc. > 170 West Tasman Drive > San Jose, CA 95134 > email: yakov@cisco.com > > Internet Draft draft-bates-bgp4-multiprotocol-00.txt December 1996 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bates, Chandra, Katz, Rekhter [Page 8] > > From jstewart@metro.isi.edu Wed Dec 18 22:37:52 1996 From: jstewart@metro.isi.edu (John W. Stewart III) Date: Wed, 18 Dec 1996 17:37:52 EST Subject: BGP-4+ In-Reply-To: Your message of "Wed, 18 Dec 1996 14:27:54 PST." <199612182227.OAA19295@puli.cisco.com> Message-ID: <199612182237.AA20555@metro.isi.edu> > > also, from reading the draft, i'm assuming that you plan > > to support only ASs and not RDs? did you consider typing > > routing domains in addition to network addresses? > > I am a bit confused - in my mind "RD" and "AS" describe > pretty much similar thing. AS is two bytes, while RD is variable. right? or is it me that's confused? /jws From Thomas.Eklund@era-t.ericsson.se Thu Dec 19 09:16:39 1996 From: Thomas.Eklund@era-t.ericsson.se (Thomas Eklund T/N) Date: Thu, 19 Dec 1996 10:16:39 +0100 Subject: RIPng Message-ID: <199612190916.KAA24913@mackabee> Hi, I'm wondering where I can get a RIPng implementation. It was mentioned in the 6bone BOF but I didn't get the address where to download it from. Could someone please help me out here. Thomas Eklund From dhaskin@baynetworks.com Thu Dec 19 15:25:11 1996 From: dhaskin@baynetworks.com (Dimitry Haskin) Date: Thu, 19 Dec 1996 10:25:11 -0500 Subject: BGP-4+ Message-ID: <199612191525.KAA07565@pobox.BayNetworks.com> > > The expansion of the AS/RD space is an orthogonal issue, and one that is > far more difficult to achieve in a backward compatible fashion. I would > argue that this is beyond the scope of the hack on the table... > 1) Is the backward compatibility with BGP4 is really necessary or even useful for v6? 2) What are actual benefits and applicability of the proposed multiprotocol capabilities of BGP4+? Can we require that all v6 RD boundaries stay the same as the v4 AS boundaries for the proposed scheme to work? 3) Depending on the answer on 1) and 2), it may be that BGPng don't have to be more a hack that BGP4 is, and to this end provide a longer term solution that "the hack on the table". 4) Not that I necessary disagree that 2-byte AS space is large enough for the time being, but, if there is any discomfort with that, it is a perfect opportunity to use expanded space for v6 (to avoid pain later). Dimitry From jstewart@metro.isi.edu Thu Dec 19 15:46:12 1996 From: jstewart@metro.isi.edu (John W. Stewart III) Date: Thu, 19 Dec 1996 10:46:12 EST Subject: BGP-4+ In-Reply-To: Your message of "Wed, 18 Dec 1996 16:42:32 PST." <199612190042.QAA25743@puli.cisco.com> Message-ID: <199612191546.AA00456@metro.isi.edu> > The expansion of the AS/RD space is an orthogonal issue, and one that is > far more difficult to achieve in a backward compatible fashion. I would > argue that this is beyond the scope of the hack on the table... i understand what you're saying but it makes me wonder what the goal is of these bgp4 extensions. i had thought that it was mainly to make it easier for providers to start routing ipv6: by allowing bgp4 to do it, then we get to use a protocol we already know very well. by allowing bgp4 to route ipv6 (as well as any other protocol with an Address Family identifier) then couldn't bgp4 become even more entreanched than it already is? in other words, if bgp4 becomes multiprotocol, then why would i *ever* care to switch to idrp? and if the result of this is an increased lifetime for bgp4, then shouldn't the future of the AS space be addressed now? if the authors of the draft had envisioned a different future, then perhaps it would be useful for that to be spelled out /jws > > X-Auth: NOLNET SENDMAIL AUTH > Date: Wed, 18 Dec 1996 17:31:25 -0600 (CST) > From: Brandon Black > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-idr@merit.edu > Precedence: bulk > > On Wed, 18 Dec 1996, Yakov Rekhter wrote: > > > John, > > > > > > > also, from reading the draft, i'm assuming that you plan > > > > > to support only ASs and not RDs? did you consider typing > > > > > routing domains in addition to network addresses? > > > > > > > > I am a bit confused - in my mind "RD" and "AS" describe > > > > pretty much similar thing. > > > > > > AS is two bytes, while RD is variable. right? or is > > > it me that's confused? > > > > Ok, I got it (I was confused). > > > > To answer your question, it doesn't look like we'll have shortage of > > ASs any time soon. So, it is not clear if there is a need for variable > > length RDs. > > > > Yakov. > > > > Famous last words :) > > Bill Gates I think once said something along the lines of "nobody will > _ever_ need more than 640 kilobytes of main memory" > > And somebody (some whole group of bodies) once thought that a 32-bit IP > address would hold off for along time.... > > Just food for thought... > > ................................. .............. > : Brandon Lee Black : [Office] :.............: [Personal] :.... > :....................: brandon.black@wcom.com : photon@nol.net :....... > : "Sanity is the : +1.281.362.6466 .......: photon@gnu.ai.mit.edu : > : trademark of a :.................:..../\: vis_blb@unx1.shsu.edu : > : weak mind. . ." : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......: > :....................:.....................:..:.................: > > From brandner@kar.dec.com Fri Dec 20 13:34:31 1996 From: brandner@kar.dec.com (Rudolf Brandner CEC Karlsruhe (+49-721-690231)) Date: Fri, 20 Dec 96 14:34:31 +0100 Subject: RIPE database update Message-ID: <9612201334.AA03019@kaputt.kar.dec.com> Hi all, following is an RIPE database update. I've added a new RIPnG tunnel and corrected my mail address. site: Digital Equipment Corporation location: Karlsruhe, Germany loc-string: 49 00 54n 8 24 18e 150m prefix: 5F04:FB00:810D:A900::/80 ping: earc-rtr.ipv6.kar-x.dec.com (5F04:FB00:810D:A900::F84A:A7B0) ping: earc.ipv6.kar-x.dec.com (5F04:FB00:810D:A900::800:2B3C:1FAD) tunnel: 129.13.169.3 204.123.2.236 DIGITAL-CA/US (RIPnG) tunnel: 129.13.169.3 141.39.66.6 DETEBERKOM/DE (RIPnG) tunnel-v4: earc-rtr.kar-x.dec.com (129.13.169.3) contact: @kar.dec.com status: operational since 12-DEC-1996 remark: RouteAbout Access EI/IPv6, Digital UNIX IPv6 remark: New tunnels added, RIP or static; send mail to contact changed: brandner@kar.dec.com 19961220 source: RIPE Regards, Rudolf Brandner CEC Karlsruhe, European Applied Research Center Digital Equipment Corporation email: brandner@kar.dec.com From crawdad@fnal.gov Fri Dec 20 19:44:47 1996 From: crawdad@fnal.gov (Matt Crawford) Date: Fri, 20 Dec 1996 13:44:47 -0600 Subject: routin loop In-Reply-To: "18 Dec 1996 08:57:17 PST." <"199612181657.IAA02000"@hershey.es.net> Message-ID: <199612201944.NAA22921@gungnir.fnal.gov> > From ESnet it looks like I can't reach any of the FNAL hosts either, > I tried all 4 of them that I know of. We'll follow up w/FNAL. Yeah, well ... our entry point is/was a Sun, and there turned out to be a gaping wide security hole in Solaris 2.X such that anyone on the internet could become root. Fixing that bug conflicted with IPv6, so we're off until the v6 guys roll the bugfix into their release. Bummer. From lpz@nautique.epm.ornl.gov Fri Dec 20 21:08:00 1996 From: lpz@nautique.epm.ornl.gov (Lawrence MacIntyre) Date: Fri, 20 Dec 1996 16:08:00 -0500 Subject: 6bone routing loops persist Message-ID: <32BB0030.237C@nautique.epm.ornl.gov> # traceroute6 !$ traceroute6 5f35:6100:ce60:d900:1:0:c082:7710 traceroute to 5f35:6100:ce60:d900:1:0:c082:7710 (5F35:6100:CE60:D900:1::C082:7710), 30 hops max, 24 byte packets 1 ::198.128.2.27 (::198.128.2.27) 71.248 ms 70.272 ms 72.224 ms 2 6bone-router.cisco.com (5F00:6D00:C01F:700:1:60:3E11:6770) 106.384 ms * 103.456 ms 3 * * * 4 6bone-router.cisco.com (5F00:6D00:C01F:700:1:60:3E11:6770) 106.384 ms * * 5 * * * 6 6bone-router.cisco.com (5F00:6D00:C01F:700:1:60:3E11:6770) 113.216 ms * 111.264 ms -- Lawrence ~ ------------------------------------------------------------------------ Lawrence MacIntyre Oak Ridge National Laboratory 423.574.8696 lpz@ornl.gov http://www.epm.ornl.gov/~lpz lpz@nautique.epm.ornl.gov From watson@ulysse.enet.dec.com Fri Dec 20 22:14:32 1996 From: watson@ulysse.enet.dec.com (Robert Watson (Bob)) Date: Fri, 20 Dec 96 22:14:32 MET Subject: New Site DIGITAL-ETC Message-ID: <199612202108.WAA27850@vbormc.vbo.dec.com> Hi, We have a new site now operational, from the Digital European Technical Centre, Sophia Antipolis, France. There is no nameserver just yet, just an IPv6 Router. The Nameserver will come on-line in a week or so (christmas permitting). The RIPE record is below. It will be in the database shortly. Regards Bob Watson, Digital site: Digital Equipment Corporation location: Centre Technique Europe, Sophia Antipolis, France prefix: 5F06:B500:C138:0F00::/64 ping: 5F06:B500:C138:0F00::F8A4:8428 vboipv6rtr.ipv6.europe.digital.com tunnel: 193.56.15.54 204.123.2.236 DIGITAL-CA tunnel: 193.56.15.54 129.13.169.3 DIGITAL-EARC contact: robert.watson@vbo.mts.dec.com status: operational since 20-Dec-1996 remark: Digital RouteAbout Access EI-ISDN /IPv6 remark: New tunnels added, RIP or static; send mail to contact changed: rwatson@sutra.enet.dec.com 961220 source: RIPE From jstewart@metro.isi.edu Sun Dec 22 23:15:16 1996 From: jstewart@metro.isi.edu (John W. Stewart III) Date: Sun, 22 Dec 1996 18:15:16 EST Subject: BGP-4+ In-Reply-To: Your message of "Sun, 22 Dec 1996 06:29:18 PST." <199612221429.GAA03193@puli.cisco.com> Message-ID: <199612222315.AA12463@metro.isi.edu> i have a follow-up question to one of the things dennis asked, but i have a general question as well the UPDATE message looks like: +-----------------------------------------------------+ | Unfeasible Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ let's say that i'm an implementation with these extensions and i want to advertise an IPv6 route over an ebgp session with just the mandatory well-known attributes ORIGIN="IGP", AS-PATH="3561" and NEXT-HOP="10.1.1.1". what do i put in the "NLRI" field of the UPDATE message (not the NLRI component of the attribute)? as i read it, the proposed extension doesn't include the ability to specify attributes within the MP_REACH_NLRI attribute, so the "Total Path Attribute Length" and "Path Attributes" fields of the UPDATE message need to be used. the spec says: >> >> Total Path Attribute Length: >> >> [...] >> >> A value of 0 indicates that no Network Layer Reachability >> Information field is present in this UPDATE message. >> so conversely a non-zero value in "Total Path Attribute Length" means that NLRI *is* present. since i need to associate attributes with the IPv6 route, "Total Path Attribute Length" needs to be non-zero, so what goes in NLRI if i don't have any IP4-related thing to do in this message? > > (2) It seems to me advantageous that IPv4 and IPv6 routes with the same pa th > > attributes are able to be advertised in the same update message, rathe r > > than replicating the same set of attributes in two messages. The curr ent > > proposal does indeed allow this to happen. Given that this may have e ven > > been designed in rather than happy circumstance, however, I find the > > It was intentional - not just "happy circumstance". > > > `Address Family' field a bit annoying. There seem to be only two > > possibilities for its use: > > > > (i) BGP-4 never carries routes from an address family other than IPv4 > > and IPv6. In this case the address family field is a constant in > > attributes with type codes 0x14 and 0x15, and might just as well > > have not been present since 0x14 and 0x15 always imply IPv6. > > > > (ii) BGP-4 is used to carry routes from address families in addition > > to IPv4 and IPv6. In this case the address family field is a > > variable, but the constraint on a path attribute type appearing > > twice in one message now prevents you from listing all routes with > > the same attributes in the same message, independent of family. > > That is, you get to advertise IPv4 and something in the same message, > > but only one something. > > Yes, this is an undesirable restriction. > > > Given that the total number of protocol families there are to carry in > > BGP-4 is relatively small anyway, that type codes are not in short > > supply and that the `Address Family' seems more a constraint than a > > generalization, might it not be better to do away with the address > > family identifier and just use different attribute type codes to > > identify the x_REACH_NRLI's and x_UNREACH_NLRI's for different > > protocols? > > This is certainly one possibility. Another possibility is to allow > MP_REACH_NLRI and MP_UNREACH_NLRI to carry NLRI for multiple address > families (this would require minor changes to the proposed encoding). given that the attributes of an advertised route will always include AS-PATH, ORIGIN and NEXT-HOP (and LOCAL-PREF for IBGP), and given that in practice there is a high degree of variability of these fields (the variability of each individually is high and in combination the variability is even higher), is it necessary to complicate the protocol with an optimization which would require an implementation to be very ineffecient to take advantage of? /jws From ben@ibs-us.net Sun Dec 22 23:20:29 1996 From: ben@ibs-us.net (Ben Kirkpatrick) Date: Sun, 22 Dec 1996 15:20:29 -0800 (PST) Subject: INRIA code 961129 on FreeBSD2.1.6 Message-ID: Could someone please point me towards the proper list for discussing the Inria IPv6 code or IPv6 under any BSD. Thanks, Sideways to the Sun, www.ibs-us.net/~ben 45.5183754N/-122.6750031W --Ben Kirkpatrick IBS 503.227.7010 fax 503.227.5778 page 503.229.3199 From ben@ibs-us.net Mon Dec 23 00:00:52 1996 From: ben@ibs-us.net (Ben Kirkpatrick) Date: Sun, 22 Dec 1996 16:00:52 -0800 (PST) Subject: Form to generate RFC1897 format addresses... Message-ID: I setup a form to compute IPv6 addresses. It's not foolproof, but might be useful. So give it a whirl and throw me some feedback. http://www.ibs-us.net/ipv6 --Ben Kirkpatrick IBS 503.227.7010 fax 503.227.5778 From pcurran@ticl.co.uk Mon Dec 23 10:25:59 1996 From: pcurran@ticl.co.uk (Peter Curran) Date: Mon, 23 Dec 1996 10:25:59 -0000 Subject: INRIA code 961129 on FreeBSD2.1.6 Message-ID: <199612231018.KAA01989@gate.ticl.co.uk> If this gem could be shared with the list, then that would be helpful to many. I guess the FreeBSD question probably comes under the FreeBSD list - not sure the name, but check out http://www.freebsd.org. Peter TICL ---------- > From: Ben Kirkpatrick > To: 6bone@ISI.EDU > Subject: INRIA code 961129 on FreeBSD2.1.6 > Date: 22 December 1996 23:20 > > Could someone please point me towards the proper list for > discussing the Inria IPv6 code or IPv6 under any BSD. > Thanks, > > Sideways to the Sun, www.ibs-us.net/~ben 45.5183754N/-122.6750031W > --Ben Kirkpatrick IBS 503.227.7010 fax 503.227.5778 page 503.229.3199 > From GeertJan.deGroot@ripe.net Mon Dec 23 11:50:50 1996 From: GeertJan.deGroot@ripe.net (Geert Jan de Groot) Date: Mon, 23 Dec 1996 12:50:50 +0100 Subject: Message for Roger Buttiens Message-ID: <199612231150.MAA02803@x0.ripe.net> [Sorry to shout, but I can't reach him otherwise] Would Roger Buttiens please contact me and send an alternative email address? The current one is bouncing. Thanks, Geert Jan From jpickering@phase2net.com Mon Dec 23 16:02:38 1996 From: jpickering@phase2net.com (Jeff Pickering) Date: Mon, 23 Dec 1996 08:02:38 -0800 Subject: new tunnel Message-ID: <32BEAD1E.3158@phase2net.com> This is a multi-part message in MIME format. --------------1F9574BD7896 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We have added a new tunnel to NRL. Do appropriate routing entries get added automatically via the RIPE database, or do I need to specifically request that an entry be added? Jeff --------------1F9574BD7896 Content-Type: text/plain; charset=us-ascii; name="RIPEREG.DOC" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RIPEREG.DOC" site: phase2 Networks location: Durham, North Carolina, USA prefix: 5f35:6100:ce60:d900/64 ping: 5f35:6100:ce60:d900:1:0:c082:7710 tunnel: 206.96.217.178 132.250.90.5 NRL, USA Static Routing contact: jeff pickering status: operational since December 1996, dial out only remark: changed: jpickering@phase2net.com 961209 source: RIPE --------------1F9574BD7896-- From jstewart@metro.isi.edu Mon Dec 23 15:10:04 1996 From: jstewart@metro.isi.edu (John W. Stewart III) Date: Mon, 23 Dec 1996 10:10:04 EST Subject: BGP-4+ In-Reply-To: Your message of "Mon, 23 Dec 1996 05:43:06 PST." <199612231343.FAA05649@puli.cisco.com> Message-ID: <199612231510.AA13702@metro.isi.edu> i guess i don't understand the spec completely, then. how do you specify no NLRI, then? a prefix-length of 0 doesn't do it because that means 0.0.0.0/0, right? /jws > John, > > > i have a follow-up question to one of the things dennis asked, > > but i have a general question as well > > > > the UPDATE message looks like: > > > > +-----------------------------------------------------+ > > | Unfeasible Routes Length (2 octets) | > > +-----------------------------------------------------+ > > | Withdrawn Routes (variable) | > > +-----------------------------------------------------+ > > | Total Path Attribute Length (2 octets) | > > +-----------------------------------------------------+ > > | Path Attributes (variable) | > > +-----------------------------------------------------+ > > | Network Layer Reachability Information (variable) | > > +-----------------------------------------------------+ > > > > let's say that i'm an implementation with these extensions and > > i want to advertise an IPv6 route over an ebgp session with > > just the mandatory well-known attributes ORIGIN="IGP", > > AS-PATH="3561" and NEXT-HOP="10.1.1.1". what do i put in the > > "NLRI" field of the UPDATE message (not the NLRI component of > > the attribute)? as i read it, the proposed extension doesn't > > include the ability to specify attributes within the > > MP_REACH_NLRI attribute, so the "Total Path Attribute Length" > > and "Path Attributes" fields of the UPDATE message need to be > > used. the spec says: > > > > >> > > >> Total Path Attribute Length: > > >> > > >> [...] > > >> > > >> A value of 0 indicates that no Network Layer Reachability > > >> Information field is present in this UPDATE message. > > >> > > > > so conversely a non-zero value in "Total Path Attribute Length" > > means that NLRI *is* present. since i need to associate > > attributes with the IPv6 route, "Total Path Attribute Length" > > needs to be non-zero, so what goes in NLRI if i don't have any > > IP4-related thing to do in this message? > > The converse is not true (and perhaps this should be clarified in the > BGP-4 spec). That is, "Total Path Attribute Length" may be non-zero *and* > no NLRI may be present. This way one could have NLRI carried only in the > MP_REACH_NLRI and have all the other necessary attributes as well. > > Yakov. From lpz@nautique.epm.ornl.gov Mon Dec 23 18:22:09 1996 From: lpz@nautique.epm.ornl.gov (Lawrence MacIntyre) Date: Mon, 23 Dec 1996 13:22:09 -0500 Subject: new tunnel References: <32BEAD1E.3158@phase2net.com> Message-ID: <32BECDD1.167E@nautique.epm.ornl.gov> Jeff Pickering wrote: > > We have added a new tunnel to NRL. Do appropriate routing entries > get added automatically via the RIPE database, or do I need to > specifically request that an entry be added? > > Jeff > > --------------------------------------------------------------- > > site: phase2 Networks > location: Durham, North Carolina, USA > prefix: 5f35:6100:ce60:d900/64 > ping: 5f35:6100:ce60:d900:1:0:c082:7710 > tunnel: 206.96.217.178 132.250.90.5 NRL, USA Static Routing > contact: jeff pickering > status: operational since December 1996, dial out only > remark: > changed: jpickering@phase2net.com 961209 > source: RIPE I still can't get there from here. I reported this last week as well... scorpion.epm.ornl.gov> traceroute6 5f35:6100:ce60:d900:1:0:c082:7710 traceroute to 5f35:6100:ce60:d900:1:0:c082:7710 (5F35:6100:CE60:D900:1::C082:771 0), 30 hops max, 24 byte packets 1 ::198.128.2.27 (::198.128.2.27) 71.248 ms 71.248 ms 71.248 ms 2 6bone-router.cisco.com (5F00:6D00:C01F:700:1:60:3E11:6770) 102.08 ms * 98. 576 ms 3 * * * 4 6bone-router.cisco.com (5F00:6D00:C01F:700:1:60:3E11:6770) 105.408 ms * 99 .552 ms 5 * * * 6 6bone-router.cisco.com (5F00:6D00:C01F:700:1:60:3E11:6770) 145.424 ms * 15 2.256 ms -- Lawrence ~ ------------------------------------------------------------------------ Lawrence MacIntyre Oak Ridge National Laboratory 423.574.8696 lpz@ornl.gov http://www.epm.ornl.gov/~lpz lpz@nautique.epm.ornl.gov From masaki@merit.edu Mon Dec 23 20:45:38 1996 From: masaki@merit.edu (Masaki Hirabaru) Date: Mon, 23 Dec 1996 15:45:38 -0500 Subject: RIPng In-Reply-To: Your message of "Thu, 19 Dec 1996 10:16:39 +0100." <199612190916.KAA24913@mackabee> Message-ID: <199612232045.PAA13888@merit.edu> Thomas, One of RIPng implementations which runs on Linux, INRIA FreeBSD, and Solaris IPv6 is available at ftp://ftp.merit.edu/net-research/mrt/mrt-1.3.3A.tar.gz. Information page is also available at http://compute.merit.edu/mrt/. Currently, it can communicates with other router-based RIPng implementations over configured tunnels only when it runs on Linux IPv6. I know GateD team here is also trying to incorporate another gated-based RIPng implementation contributed. Masaki > From: Thomas.Eklund@era-t.ericsson.se (Thomas Eklund T/N) > Date: Thu, 19 Dec 1996 10:16:39 +0100 > Message-Id: <199612190916.KAA24913@mackabee> > To: 6bone@ISI.EDU > Subject: RIPng > > Hi, > I'm wondering where I can get a RIPng implementation. It was mentioned in the > 6bone BOF but I didn't get the address where to download it from. Could someone > please help me out here. > Thomas Eklund From ben@ibs-us.net Thu Dec 26 23:34:21 1996 From: ben@ibs-us.net (Ben Kirkpatrick) Date: Thu, 26 Dec 1996 15:34:21 -0800 (PST) Subject: Form to create IPv6 addr's fixed. Message-ID: The form I mentioned before had a minor byte swapping problem that has since been fixed. See http://www.ibs-us.net/ipv6 Thanks to Rick Chiang and Mark Constable for pointing this out. Sideways to the Sun, www.ibs-us.net/~ben 45.5183754N/-122.6750031W --Ben Kirkpatrick IBS 503.227.7010 fax 503.227.5778 page 503.229.3199 From boggs@cs.colorado.edu Sat Dec 28 08:23:50 1996 From: boggs@cs.colorado.edu (Adam Boggs) Date: Sat, 28 Dec 1996 01:23:50 -0700 Subject: Connection to 6bone (request) Message-ID: <199612280823.BAA05331@are.cs.colorado.edu> Hi there, I'd like to get a couple of machines here at the University of Colorado up on the 6bone. I have one machine with two network interfaces running Linux (2.1.17), and another which will probably run BSDi. I would like the Linux machine to route from a tunnel to a native IPv6 net on the other side. (yeah, it'll only have one machine for now...) Does anybody see an immediate problem with this? I'm just starting with this stuff, so comments are appreciated. I guess there are a couple of issues I need resolved still: 1) I need a tunnel. I checked out the RIPE database but was not sure how to go about finding someone close. (is closeness an issue right now?) Any offers or suggestions on where I might look further? 2) RIPE entry. The FAQ I read said to ask here for the anonymous ftp password. Is this still the way entries are updated? If so, would someone please send me the password(s)? Here is my so far incomplete entry. site: University of Colorado location: Boulder, CO, USA loc-string: 40 0 0n 106 0 0w 1760m prefix: ping: tunnel: contact: Adam Boggs status: planned remark: changed: boggs@cs.colorado.edu Dec. 28, 1996 source: RIPE 3) Address space. I understand we're using the test addresses from RFC 1897, but I'm still unclear on what to use for the AS number. I assume it is the AS number of the person providing the IPv6 tunnel and it will be given to me, and not of our IPv4 provider? 4) Name service. I have the ipv6.cs.colorado.edu domain and have set up a bogus forward entry in there for the moment (the nameserver is running bind 4.9.5). I can not figure out how (or if) I'm supposed to add the reverse maps to named.boot and the actual datafile. If someone could point me to some info on this or paste in their named configs with some brief explanation, that would help a lot. Any help would be appreciated. Thanks.. -Adam Boggs Undergraduate Operations, University of Colorado, Boulder From jstewart@metro.isi.edu Mon Dec 30 19:05:41 1996 From: jstewart@metro.isi.edu (John W. Stewart III) Date: Mon, 30 Dec 1996 14:05:41 EST Subject: a different proposal for ipv6 in bgp Message-ID: <199612301905.AA24223@metro.isi.edu> attached below is a proposal for a multi-protocol (including ipv6) bgp while there are a number of differences between this one and the bates/chandra/katz/rekhter one, one of the main motivating factors for this one is to support longer-than-two-byte ASs. it is our view that making bgp multi-protocol significantly extends its life. so, although in a narrow sense the length of the AS is orthogonal to being multi-protocol, the logistics of transitions and the need to adequeately engineer the protocol up-front, to us, suggests the need for longer-than- two-byte ASs /jws ################################################################## Network Working Group Dimitry Haskin Internet-Draft Bay Networks Expires June 1997 John W. Stewart, III ISI Multiprotocol Extensions for BGP draft-stewart-bgp-multiprotocol-00.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document outlines a proposal for a BGP Version 5 (BGP5) which has the ability to carry routing information for a variety of network protocols. The proposed BGP modifications are intended to be simple enough to be easily added to the existing BGP implementations and, at the same time, provide for a longer than 16-bit AS number space. This document only describes BGP5 support for IPv4 and IPv6 networks. 3. Overview BGP [BGP4-RFC] is widely deployed as an inter-domain routing protocol for IPv4 and there is a large operational experience with it. Though currently BGP can only carry routing information for IPv4, the existence of the mature BGP implementation base provides a strong motivation for extending it to support the Internet Protocol version 6 (IPv6) and possibly other network protocols. This document outlines a proposal for creating a BGP Version 5 (BGP5) which has the ability to carry routing information for a variety of network protocols. Adding this multi-protocol support to BGP significantly increases its lifetime, so care should be taken for BGP5 to not be under-engineered. For this reason, BGP5 supports longer than 2-byte ASs. At the same time, in the authors' view, the proposed modifications are simple enough to be easily added to the existing BGP implementations as not to impede BGP5 deployment. As a matter of fact no changes to the BGP4 data structures are required to support IPv4 routing in BGP5. To ensure a smooth transition from BGP4 to BGP5 on IPv4 networks it is recommended that upgraded BGP implementations continue BGP4 support at least until BGP5 is universally deployed. The BGP5 proposal ensures that IPv4 routing information that is advertised with BGP5 is fully re-advertisable via BGP4 and vice versa. In this sense BGP4 and BGP5 are fully compatible as far as IPv4 routing is concerned. This paper presents an overview of the protocol messages used by BGP5. Where details of the protocol (e.g., the state machine and fields of protocol messages) have the same meaning as BGP4, those details are left out of this outline for the sake of brevity. 4. Autonomous System Number Space This document proposes to adopt a 32-bit Autonomous System number space for IPv6 to accommodate for the aggressive Internet growth. The 32-bit number space is large enough to ensure that no future IPv6 transition to a larger number space will be necessary. In order to minimize implementation changes that are needed to support IPv4 routing, 16-bit AS number space will continue to be supported with BGP5. In addition BGP5 will provide a mechanism to gradually introduce the 32-bit AS number space to IPv4 routing. 5. Message Formats This section describes message formats used by BGP. 5.1 Message Header Format The fixed header for BGP5 is the same as BGP4, namely: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | Marker | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is as described in BGP4. 5.2 OPEN Message Format The OPEN message has the following format: +---------------------------------------+ | Version (1 octet) | +---------------------------------------+ | Len of My Autonomous System (1 octet) | +---------------------------------------+ | My Autonomous System (variable) | +---------------------------------------+ | Hold Time (2 octets) | +---------------------------------------+ | Router ID (4 octets) | +---------------------------------------+ | Opt Parm Len (1 octet) | +---------------------------------------+ | Optional Parameters (variable) | +---------------------------------------+ "Version" is a one-octet unsigned integer specifying the protocol version. This paper describes BGP version 5. "Len of My Autonomous System" is a one-octet unsigned integer specifying the length in octets of the "My Autonomous System" field. To carry IPv4 ASs this field should be 2; to carry IPv6 ASs this field should be 4. The presence of this field permits routing domain identifiers of any length, though this paper only discusses the use of 2-byte ASs and 4-byte [fixed-length] ASs. "My Autonomous System" identifies the AS of which the sender is a member. "Hold Time" is as described in BGP4. "Router ID" is a 32-bit unsigned integer identifying the sender. Because the size of the Router ID is smaller than an IPv6 address, it cannot be set to one of the router's IPv6 addresses (as is commonly done for IPv4). Possible Router ID assignment procedures for IPv6 include: a) assign the IPv6 Router ID as one of the router's IPv4 addresses or b) assign IPv6 Router IDs through some local administrative procedure (similar to procedures used by manufacturers to assign product serial numbers). The Router ID of 0.0.0.0 is reserved, and should not be used. "Opt Parm Len" and "Optional Parameters" are as described in BGP4. 5.3 UPDATE Message Format The UPDATE message always includes the fixed-size BGP header that is followed by one-octet Format Type field which indicates the format and content of the rest of the UPDATE message. The following UPDATE Format Type values are defined in this document: 1 - BGP4 compatible update with IPv4 routing information 2 - IPv6 routing update 3 - IPv4 routing update with the 4-octet AS numbers Implementations are not required to support all possible update formats. To allow for future enhancements, implementations are required to ignore UPDATES with format types that they do not support. 5.3.1 BGP4 Compatible Update This type of UPDATE message has the following format: +-----------------------------------------------------+ | Format Type (1 octet) == 1 | +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ "Format Type" is a value indicating the format of the UPDATE message. It is 1 for the BGP4 compatible format type. All other fields are as described in BGP4. 5.3.2 IPv6 Routing Update This type of UPDATE message has the following format: +-----------------------------------------------------+ | Format Type (1 octet) == 2 | +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ "Format Type" is a value indicating the format of the UPDATE message. It is 2 for UPDATE messages that carry IPv6 routes. "Withdrawn Routes Length" is a two-octet unsigned integer specifying the length in octets of the "Withdrawn Routes" field. "Withdrawn Routes" is a variable-length field containing a list of address prefixes being withdrawn from service. Each address prefix is encoded as described in BGP4, except that the "Length" component of the tuple isn't limited to what would make sense for IPv4 addresses. "Total Path Attribute Length" is as described in BGP4. "Path Attributes" field is as described in BGP4 except: - The NEXT-HOP attribute is interpreted as a 16-byte IPv6 global or site scope address. - The AGGREGATOR attribute contains the AS number that formed the aggregate route (encoded as 4 octets), followed by the 16-byte IPv6 global or site scope address of the BGP speaker that formed the aggregate route. - The AS-PATH attribute contains four-byte ASs. Two-byte ASs can be mapped to four-byte ASs with zero-padding to the left. - A new LINK-LOCAL-NEXT-HOP attribute. LINK-LOCAL-NEXT-HOP is a well-known discretionary attribute that contains the link-local address of the router interface associated with the global-scope IPv6 address specified in the NEXT-HOP attribute of the same UPDATE message. LINK-LOCAL-NEXT-HOP shall be included in all IPv6 UPDATE messages that a given BGP speaker sends to other BGP speakers located in a neighboring autonomous system. Such a link local address should be used as the immediate next hop for forwarding packets to the destinations listed in the UPDATE message. A BGP speaker shall not include this attribute in IPv6 UPDATE messages that it sends to BGP speakers located in its own autonomous system. If it is contained in an UPDATE message that is received from a BGP speaker which is located in the same AS as the receiving speaker, then this attribute shall be ignored by the receiving speaker. For the routes received from a BGP speaker in the same AS as the receiving speaker, the link-local address of the immediate next hop should be based on the IGP route to the global-scope address provided in the NEXT-HOP attribute. "Network Layer Reachability Information" is as described in BGP4, except that the "Length" component of the tuple isn't limited to what would make sense for IPv4 addresses. 5.3.3 IPv4 Routing Update With the 32-bit AS Numbers This type of UPDATE message provides support for a larger than 16-bit AS number space that is currently supported in BGP4. Introducing this type of UPDATE well in advance of the 16-bit AS number space exhaustion will allow for smoother IPv4 transition to a larger AS number space. 16-bit AS numbers can be mapped into 32-bit AS numbers by with zero-padding to the left. Therefore it is expected that for an extended period, until BGP5 which supports this type of UPDATE message is universally deployed, bacwards compatibility will be achieved by simply mapping 16-bit AS numbers to zero- extended 32-bit AS numbers and vice versa. This type of UPDATE message has the following format: +-----------------------------------------------------+ | Format Type (1 octet) == 3 | +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ "Format Type" is a value indicating the format of the UPDATE message. It is 3 for this format type. "Withdrawn Routes Length" is as described in BGP4. "Withdrawn Routes" is as described in BGP4 "Total Path Attribute Length" is as described in BGP4. "Path Attributes" field is as described in BGP4 except: - The AGGREGATOR attribute contains the 32-bit AS number that formed the aggregate route (encoded as 4 octets), followed by the IPv4 address of the BGP speaker that formed the aggregate route. - The AS-PATH attribute contains 32-bit ASs. 6. Acknowledgements [TBA] 7. Security Considerations [TBA] 8. References [BGP4-RFC] -- RFC1771 [ASSIGNED-NUMBERS-RFC] -- RFC1700 9. Authors' Addresses John W. Stewart, III USC/ISI 4350 North Fairfax Drive Suite 620 Arlington, VA 22203 +1 703 812 3704 email: jstewart@isi.edu Dimitry Haskin Bay Networks 2 Federal St. Billerica, MA +1 508 916 8124 email: dhaskin@baynetworks.com From RLFink@lbl.gov Mon Dec 30 19:55:39 1996 From: RLFink@lbl.gov (Bob Fink LBNL) Date: Mon, 30 Dec 1996 11:55:39 -0800 Subject: 6bone BOF Minutes Message-ID: I've enclosed the draft of the San Jose IETF 6bone BOF minutes, kindly taken by Alain and Pedro, and post-edited by me. By the 6th of January I will forward them to the IETF secretariat, so please send any corrections to me before then. Thanks, Bob _______________________cut here_______________________________________ 6bone BOF Meeting December 10, 1996 San Jose, CA Bob Fink / LBNL, Chair Minutes by Alain Durand, Pedro Roque, and Bob Fink. -------------------------------------------------------------------- Agenda -------------------------------------------------------------------- 1. Introduction and Agenda Bashing / Bob Fink (5 mins) 2. Formation of a 6bone WG - do we? / Bob Fink (10 mins) 3. If so, what might we set as an initial WG goal? / Bob Fink (5 mins) 4. Topology / Alain Durand (30 mins) 5. Addressing / (30 mins) 6. Routing / Pedro Roque (15 mins) 7. RIPE Registry cleanup & changes / David Kessens (15 mins) 8. Maps / Bob Fink (5 mins) -------------------------------------------------------------------- 1. Introduction and Agenda Bashing / Bob Fink -------------------------------------------------------------------- Bob Fink convened the meeting, and reviewed the agenda and its order, asking for changes. Rough time estimates were allocated for each item to keep the meeting on track. The agenda was acceptable to the group and the meeting continued. Fink noted that there was a 6bone web page at: http://www-6bone.lbl.gov/6bone/ and a mail list that one can subscribe to: majordomo@isi.edu subscribe 6bone -------------------------------------------------------------------- 2. Formation of a 6bone WG - do we? / Bob Fink -------------------------------------------------------------------- Bob Fink presented his view of the pros and cons of forming a working group. Advantages: - getting a meeting place at IETF meetings - formalization of process of feedback to other IETF ipv6 efforts Disadvantage: - need a goal and some work products - need to incur administrative overhead Fink contended that we've already succumbed to the admin. overhead and have most processes in place because of the existing 6bone testbed effort, and that 6bone participants are already producing useful products. Thus we (the 6bone participants) may just need to document some of them . Thus Bob concluded that it was worth forming a working group. Fink also presented a possible draft charter: The 6bone Working Group is a forum for information concerning the deployment, engineering, and operation of ipv6 protocols and procedures in the global Internet. This activity will include, but not be limited to: - Deployment of ipv6 transport and routing in the global Internet via a "6bone" testbed to assist in the following. - Creation of "practice and experience" informational RFC documents that capture the experiences of those who have deployed, and are deploying, various ipv6 technologies. - Feedback to various IETF ipv6-related activities, based on testbed experience, where appropriate. - Development of mechanisms and procedures to aid in the transition to native ipv6, where appropriate. - Development of mechanisms and procedures for sharing operational information to aid in operation of global ipv6 routing. Fink noted that the 6bone, though originally formed from the model of the mbone, was not like the current Mboned WG effort as the early 6bone is not a real start at deployment, rather a testbed for developers and users to try out implemenations and operational experiences to feed back into IPng IETF efforts and also provide advocacy for IPv6 deployment. There was broad consensus that Fink should proceed with forming a working group. There were also comments that supported Bob Fink acting as the chair, which he agreed to do at least initially for the formation effort. -------------------------------------------------------------------- 3. If so, what might we set as an initial WG goal? / Bob Fink -------------------------------------------------------------------- Bob Fink then presented several possible work products of a working group that were basicallyt generating a series of informational RFCs: - documentation of the RIPE registry - documentation of 6bone testbed participation procedures - documentation of relevant experiences with the testbed It was noted that currently the 6bone effort would be under the Operations area (Bradner/O'Dell are directors). Bob Fink agreed to proceed with filing the necessary charter and plan with the area directors as well as generating a discussion of the charter on the mailer. -------------------------------------------------------------------- 4. Topology / Alain Durand -------------------------------------------------------------------- Alain Durain proposed converting the 6bone testbed topology to a three level system of core backbone routers, second tier transit routers and leaf routers (for node sites not doing transit). He proposed this to better structure the 6bone for effective routing and to simplify its topology. Tunnels could then be built for either production or experimental uses. Durand noted his main point is that tunnels are per nature layer 2 items, and that if one wants the 6-bone to grow, it needs to do some kind of routing. From hiss experience, it's not such an easy task and probably not all nodes are willing to do it completely. Thus the reason for his proposed reorganized routing/topology into a three level system. It was agreed to continue this discussion on the mailer. -------------------------------------------------------------------- 6. Routing / Pedro Roque -------------------------------------------------------------------- Pedro Roque led off a discussion of routing in the 6bone with his concern that RIPng was slow to converge and caused him much trouble on the less reliable trans-Atlantic links. Others expressed their opinion that RIPng was able to converge and work in the 6bone. It was clear that there was a need for lively debate on the relative merits of routing approaches for the 6bone. The chair suggested that it was best to pursue this on the mailer. -------------------------------------------------------------------- 5. Addressing -------------------------------------------------------------------- Alain Durand presented his request for a change in the prefix notation for IPv6 addressing (draft-durand-ipv6prefix-00.txt). It was agreed that this was an oversight in RFC 1844 specifying address notation, and that this topic should be brought up at the IPng meetings this IETF week (it was and there was agreement there to incorporate Alain's suggested prefix format). Durand noted that this is not a "change" per se, just something that is not standardized yet. Someone pointed out that this notation could conflict with another notation that was used by the RPS group. Durand checked this with them later after the meeting, and thinks that in fact there is no problem at all. Pedro Roque presented his suggested address allocation policy for use in the 6bone. This was an elaboration of RFC 1897 that basically suggests that for leaf nodes (in the 6bone) that the prefix should be constructed using the first 32 bits of the prefix used by the transit site they are connected to. Some thought this was a reasonable idea. Geert Jan de Groot said that this was maybe not necessary because a dynamic routing algorithm would solve most problems. The discussion went back to RIPng, with some saying that RIPng is maybe not enough, and that what is needed are better protocols like BGP or IDRP. The question was raised about sites connecting to "big" nodes, and which prefix they should use. The answer was both, as it's a case of multihoming. Matt Crawford proposed using the 6bone testbed to experiment with Mike O'Dell's 8+8 addressing proposal. He identified various issues relating to this effort: - Host issues - modified pseudo header checksum for 8+8 addresses - Router isssues - insertion of RG - DNS issues - DNS lookup in 2 different parts AA & RG - Discover bootstrap troubles - Security issue - should we mandate IPsec? It was noted that IPsec is not currently in the tested. Jim Bound noted that a new draft was needed to explain what the differences are with the present addressing implementation. He also noted that he (Digital) was interested in attempting an implementation of 8+8 that co-existed with the existing addressing as his staff believes that can be done. Bob Hinden expressed his concern that until the IPbg working group decided if 8+8 was possible that it was premature for the 6bone efforts to deal with it. The chair agreed with this concern but also noted that the 6bone effort might assist the IPng 8+8 design effor in giving feedback as it moved along. It was agreed to continue discussion of possible 6bone 8+8 efforts on the mailer. -------------------------------------------------------------------- 7. RIPE Registry cleanup & changes / David Kessens -------------------------------------------------------------------- David Kessens presented the RPSL work in relation to a modified format for the RIPE-NCC 6bone routing registry. He contended that a well defined (and new) syntax was necessary before cleaning up the current RIPE-NCC 6bone registry. There were some comments on various fields. It was noted that an IPv6 end point address should be added. It was agreed to continue the discussion on RIPE-NCC 6bone registry restructuring on the mailer. -------------------------------------------------------------------- 8. Maps / Bob Fink -------------------------------------------------------------------- Bob Fink noted that he was at the useful limits of the current 6bone diagram, but that he intended to experiment with other forms of drawing it as the topology discussions and restructuring proceeded. The preferred solution would be to have the maps drawn automatically from registry data. Until such mechanisms are in use for the 6bone, Fink noted that he was willing to try to keep a 6bone map up to date manually. -------------------------------------------------------------------- --------------------------------------------------------------------