From bmanning@ISI.EDU Sat May 2 04:47:24 1998 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 30 Apr 1998 20:47:24 -3100 (PDT) Subject: some 6bone backbone cleanup recommendations In-Reply-To: from "Bob Fink" at Apr 30, 98 11:21:03 am Message-ID: <199805010347.UAA26701@zephyr.isi.edu> > Setup a 6bone-ops list consisting of only mail handles registered in the > 6bone registry: > should include email handles from: (David Kessens has volunteered to do > this list) > the person: object, e-mail: field > the mntner: object, mnt-nfy: field > remove duplicates > all 6bone sites, not just backbone pTLAs Perhaps the better way to do this is to track the delegations and use the SOA contacts. Its' being done to soem degree with the walking of the inverse tree already. -- --bill From rlfink@lbl.gov Mon May 4 13:48:50 1998 From: rlfink@lbl.gov (Bob Fink) Date: Mon, 04 May 1998 05:48:50 -0700 Subject: some 6bone backbone cleanup recommendations In-Reply-To: <199805010347.UAA26701@zephyr.isi.edu> References: Message-ID: <1317861546-172778432@cnrmail.lbl.gov> Bill, At 08:47 PM 4/30/98 -3100, Bill Manning wrote: >> Setup a 6bone-ops list consisting of only mail handles registered in the >> 6bone registry: >> should include email handles from: (David Kessens has volunteered to do >> this list) >> the person: object, e-mail: field >> the mntner: object, mnt-nfy: field >> remove duplicates >> all 6bone sites, not just backbone pTLAs > > > Perhaps the better way to do this is to track the delegations > and use the SOA contacts. > > Its' being done to soem degree with the walking of the inverse > tree already. If we do try to create a new list my concern with your idea is that SOAs might miss folk at 6bone sites that should be on our list but for some local DNS management reason aren't SOA contacts. Thanks, Bob From bmanning@ISI.EDU Mon May 4 14:19:41 1998 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Mon, 4 May 1998 06:19:41 -0700 (PDT) Subject: some 6bone backbone cleanup recommendations In-Reply-To: <1317861546-172778432@cnrmail.lbl.gov> from "Bob Fink" at May 4, 98 05:48:50 am Message-ID: <199805041319.AA25684@zed.isi.edu> > Bill, > > At 08:47 PM 4/30/98 -3100, Bill Manning wrote: > >> Setup a 6bone-ops list consisting of only mail handles registered in the > >> 6bone registry: > >> should include email handles from: (David Kessens has volunteered to do > >> this list) > >> the person: object, e-mail: field > >> the mntner: object, mnt-nfy: field > >> remove duplicates > >> all 6bone sites, not just backbone pTLAs > > > > > > Perhaps the better way to do this is to track the delegations > > and use the SOA contacts. > > > > Its' being done to soem degree with the walking of the inverse > > tree already. > > If we do try to create a new list my concern with your idea is that SOAs > might miss folk at 6bone sites that should be on our list but for some > local DNS management reason aren't SOA contacts. > > Thanks, > Bob Well, the list already exists and it is for zones that are expressly for the purposes of deployment of IPv6. And if there are local reasons for not linking the two groups together, then by using the SOA values as a means to track deployment, we bring a hitherto disenfranchised group into the IPv6 arena by making them aware. -- --bill From cgw@nas.nasa.gov Mon May 4 19:45:12 1998 From: cgw@nas.nasa.gov (Christopher G. Williams) Date: Mon, 04 May 1998 11:45:12 -0700 Subject: USENIX IPv6 BoF? Message-ID: <199805041845.LAA04768@madrugada.nas.nasa.gov> Is anyone on planning to do an IPv6 BoF at the 1998 USENIX Technical Conference? -cgw- From Y.Adamopoulos@noc.ntua.gr Tue May 5 13:55:44 1998 From: Y.Adamopoulos@noc.ntua.gr (Yiorgos Adamopoulos) Date: Tue, 5 May 1998 15:55:44 +0300 Subject: pTLA address space plans Message-ID: <19980505155544.27472@noc.ntua.gr> Hi, pTLA managers, do you have any policies under which you assign addresses for connected parties? How have you splitted the pTLA space? -- Yiorgos Adamopoulos -- #include mailto: Y.Adamopoulos@noc.ntua.gr -- Network Operations Center, NTUA, GREECE From rlfink@lbl.gov Tue May 5 14:36:37 1998 From: rlfink@lbl.gov (Bob Fink) Date: Tue, 05 May 1998 06:36:37 -0700 Subject: draft-ietf-ngtrans-6bone-routing-00.txt Message-ID: <1317771964-178167375@cnrmail.lbl.gov> > From: Buclin, Bertrand > Sent: Friday, May 01, 1998 10:15 AM > To: '6bone@isi.edu' > Subject: draft-ietf-ngtrans-6bone-routing-practice-00.txt > > Dear all, > > you'll find below the new draft for the 6Bone Routing Practices. It > replaces the draft-ietf-ngtrans-6bone-routing-issues-02.txt that was > presented at the Los Angeles IETF meeting, and includes the comments > made there and through private mail messages. > > Unfortunately, my co-author Alain has had an accident recently (not > life threatening) which will keep him out of business for a couple of > months. Please provide your comments either directly to me or more > generally to the 6Bone mailing list (6Bone@isi.edu). > > Regards, > > Bertrand Buclin > AT&T Labs Europe INTERNET DRAFT Alain Durand NGTRANS WG IMAG 30 April, 1998 Bertrand Buclin Expires 30 October, 1998 AT&T Labs Europe 6Bone Routing Practice 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This draft expires October 30, 1998. 1 Introduction The 6Bone is an environment supporting experimentation with the IPv6 protocols and products implementing it. As the network grows, the need for common operation rules emerged. In particular, operation of the 6bone backbone is a challenge due to the frequent insertion of bogus routes by leaf or even backbone sites. This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6bone for the configuration of both Interior Gateway Protocols (like RIPng) and Exterior Gateway Protocols (like BGP4+). 2 Basic principles The 6bone is structured as a hierarchical network with pseudo TLA (pTLA), pseudo NLA (pNLA) and leaf sites. The 6bone backbone is made of a mesh interconnecting pTLAs only. pNLAs connect to one or more pTLAs and provide transit service for leaf sites. BGP4+ is the mandatory routing protocol used for exchanging routing information among pTLAs. Multi-homed sites or pNLAs SHOULD also use BGP4+. Regular sites MAY use a simple default route to their ISP. 3 Common Rules This section details common rules governing the routing on the 6Bone. They are derived from issues encountered on the 6Bone, with respect to the routes advertised, handling of special addresses, and aggregation: 1) link local prefixes 2) site local prefixes 3) loopback prefix & unspecified prefix 4) multicast prefixes 5) IPv4-compatible prefixes 6) IPv4-mapped prefixes 7) default routes 8) Yet undefined unicast prefixes (from a different /3 prefix) 9) Inter site links issues 10) aggregation & advertisement issues 3.1 Link-local prefix The link-local prefix (FE80::/10) MUST NOT be advertised through either an IGP or an EGP. By definition, the link-local prefix has a scope limited to a specific link. Since the prefix is the same on all IPv6 links, advertising it in any routing protocol does not make sense and, worse, may introduce nasty error conditions. Well known cases where link local prefixes could be advertised by mistake include: - a router advertising all directly connected network prefixes including the link-local one. - Subnetting of the link-local prefix. In such cases, vendors should be urged to correct their code. 3.2 Site-local prefixes Site local prefixes (in the FEC0::/10 range) MAY be advertized by IGPs or EGPs within a site. The precise definition of a site is ongoing work discussed in the IPng working group. Site local prefixes MUST NOT be advertised to transit pNLAs or pTLAs. 3.3 Loopback and unspecified prefixes The loopback prefix (::1/128) and the unspecified prefix (::0/128) MUST NOT be advertised by any routing protocol. 3.4 Multicast prefixes Multicast prefixes MUST NOT be advertised by any unicast routing protocol. Multicast routing protocols are designed to respect the semantics of multicast and MUST therefore be used to route packets with multicast destination addresses (in the range FF00::/8). Multicast address scopes MUST be respected on the 6Bone. Only global scope multicast addresses MAY be routed across transit pNLAs and pTLAs. There is no requirement on a pTLA to route multicast packets. Organization-local multicasts (in the FF08::/16 or FF18::/16 ranges) MAY be routed across a pNLA to its leaf sites. Site-local multicasts MUST NOT be routed toward transit pNLAs or pTLAs. Obviously, link-local multicasts and node-local multicasts MUST NOT be routed at all. 3.5 IPv4-compatible prefixes Sites may choose to use IPv4 compatible addresses (::a.b.c.d) internally. As there is no real rationale today for doing that, these addresses SHOULD NOT be used in the 6Bone. The ::/96 IPv4-compatible prefixes MAY be advertised by IGPs. IPv4-compatible prefixes MUST NOT be advertised by EGPs to transit pNLAs or pTLAs. 3.6 IPv4-mapped prefixes IPv4-mapped prefixes (::FFFF:a.b.c.d where a.b.c.d is an IPv4 address) MAY be advertised by IGPs within a site. It may be useful for some IPv6 only nodes within a site to have such a route pointing to a translation device. IPv4-mapped prefixes MUST NOT be advertised by EGPs. 3.7 Default routes 6bone core pTLA routers MUST be default-free. pTLAs MAY advertise a default route to their pNLAs. Transit pNLAs MAY do the same for their leaf sites. 3.8 Yet undefined unicast prefixes Yet undefined unicast prefixes from a format prefix other than 2000::/3 MUST NOT be advertised by any routing protocol in the 6bone. In particular, RFC1897 test addresses MUST NOT be advertised on the 6bone. Routing of global unicast prefixes outside of the 6Bone range (3FFE::/16) is discussed in section 4, Routing policies, below. 3.9 Inter-site links Global IPv6 addresses MUST be used for the end points of the inter- site links. In particular, IPv4 compatible addresses MUST NOT be used for tunnels. Prefixes for those links MUST NOT be injected in the global routing tables. 3.10 Aggregation & advertisement issues Route aggregation MUST be performed by any border router. Sites or pNLAs MUST only advertise to their upstream provider the prefixes assigned by that ISP unless otherwise agreed. Site border router MUST NOT advertise prefixes more specific than the /48 ones allocated by their ISP. pTLA MUST NOT advertise prefixes longer than 24 to other pTLAs unless special peering agreements are implemented. When such special peering agreements are in place between any two or more pTLAs, care MUST be taken not to leak the more specific prefixes to other pTLAs not participating in the peering agreement. 4 Routing policies 6Bone backbone sites maintain the mesh into the backbone and provide an as reliable as possible service, granted the 6Bone is an experimentation tool. To achieve their mission, 6Bone backbone sites MUST maintain peerings with at least 5 other backbone sites. The peering agreements across the 6Bone are by nature non-commercial, and therefore SHOULD allow transit traffic through. Eventually, the Internet registries will assign other TLAs than the 6Bone one (currently 3FFE::/16). The organizations bearing those TLAs will establish a new IPv6 network, parallel to the 6Bone. The 6Bone MIGHT interconnect with this new IPv6 Internet, but transit across the 6Bone will not be guaranteed. It will be left to each 6Bone backbone site to decide whether it will carry traffic to or from the IPv6 Internet. 5 The 6Bone registry The 6Bone registry is an RPSL database used to store information about the 6Bone. Each 6Bone site MUST maintain the relevant entries in the 6Bone registry (whois.6bone.net). In particular, the following objects MUST be present: - IPv6-site: site description - Inet6num: prefix delegation - Mntner: coordinate of site maintenance staff Other objects MAY be maintained at the discretion of the sites, such as routing policy descriptors, person or role objects. 6 Guidelines for new sites joining the 6Bone New sites joining the 6bone should seek to connect to a transit pNLA or a pTLA within their region. The 6Bone registry is available to find out candidate ISPs. Any site connected to the 6Bone MUST maintain a DNS server for forward name looking and reverse address translation. The joining site MUST maintain the 6Bone registry objects relative to its site, and in particular the IPv6-site and the MNTNER objects. The upstream ISP MUST delegate the reverse address translation zone in DNS to the joining site. The ISP MUST also create 6Bone registry objects reflecting the delegated address space (inet6num:). Up to date information about how to join the 6Bone is available on the 6Bone Web site at http://www.6bone.net. 7 Guidelines for 6Bone pTLA sites 6Bone pTLA sites are altogether forming the backbone of the 6Bone. In order to ensure the highest level possible of availability and stability for the 6Bone environment, a few constraints are placed onto sites wishing to become or stay a 6Bone pTLA: 1. The site MUST have experience with IPv6 on the 6bone, at least as a leaf site and preferably as a transit pNLA under an existing pTLA. 2. The site MUST have the ability and intent to provide "production- like" 6bone backbone service to provide a robust and operationally reliable 6bone backbone. 3. The site MUST have a potential "user community" that would be served by becoming a pTLA, e.g., the requester is a major player in a region, country or focus of interest. 4. Must commit to abide by the 6bone backbone operational rules and policies as defined in the present document. When a candidate site seeks to become a pTLA site, it will apply for it to the 6Bone Operations group (see below) by bring evidences it meets the above criteria. 8 6Bone Operations group The 6Bone Operations group is the body in charge of monitoring the adherence to the present rules, and will take the appropriate actions to correct deviations. Membership in the 6Bone Operations group is mandatory for, and restricted to, any site connected to the 6Bone. The 6Bone Operations group takes the form of a mailing list (operations@6bone.net) and is derived from the data in the 6Bone registry. 9 Common rules enforcement Participation in the 6Bone is a voluntary and benevolent undertaking. However, participating sites are expected to adhere to the rules described in this document, in order to maintain the 6Bone as quality tool for experimenting with the IPv6 protocols and products implementing them. The following processes are proposed to help enforcing the 6Bone rules: - Each pTLA site has committed when requesting their pTLA to implement the rules, and to ensure they are respected by sites within their administrative control (i.e. those to who prefixes have been delegated). - When a site detects an issue, it will first use the 6Bone registry to contact the site maintainer and work the issue. - If nothing happens, or there is disagreement on what the right solution is, the issue can be brought to the 6Bone Operations group. - When the problem is related to a product issue, the site(s) involved is responsible for contact the product vendor and work toward its resolution. - When an issue causes major operational problems, backbone sites may decide to temporarily set filters in order to restore service. 10 Security considerations The result of bogus entries in routing tables is usually unreachable sites. Having guidelines to aggregate or reject routes will clean up the routing tables. It is expected that using these guidelines, routing on the 6Bone will be less sensitive to denial of service attacks due to misleading routes. The 6bone is a test network. Therefore, denial of service, packet disclosure,... are to be expected. 11 Acknowledgements This document is the result of shared experience on the 6Bone. Special thanks go to Bob Fink for the hard work make to date to direct the 6Bone effort, to David Kessens for the 6Bone registry, and to Guy Davies for his insightful contributions. 12 Author address Alain Durand Institut d'Informatique et de Mathematiques Appliquees de Grenoble IMAG BP 53 38041 Grenoble CEDEX 9 France Phone : +33 4 76 63 57 03 Fax : +33 4 76 51 49 64 E-Mail: Alain.Durand@imag.fr Bertrand Buclin AT&T International S.A. Route de l'aeroport 31 CP 72 CH-1215 Geneve 15 (Switzerland) Phone : +41 22 929 37 40 Fax : +41 22 929 39 84 E-Mail: Bertrand.Buclin@ch.att.com From Ivano.Guardini@CSELT.IT Thu May 7 15:17:43 1998 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Thu, 07 May 1998 16:17:43 +0200 Subject: some 6bone backbone cleanup recommendations Message-ID: Hi Bob, you wrote: > 6bone Folk, > > Per the 6bone backbone cleanup discussions at the LA IETF I have > generated > a first pass set of recommendations on how to proceed. > > The first basic rule to note is that there was almost complete > consensus to > avoid hard rule enforcement that forced a pTLA site off the 6bone > backbone > with no discourse or allowance for a site to try to clean up their > act. In > fact, it was recommended that we be driven to the greatest extent > possible, > by reports that point out the problems (a bit of public exposure and > humiliation so to speak). Then arbitrate. > > > Various ideas: > > Setup a 6bone-ops list consisting of only mail handles registered in > the > 6bone registry: > should include email handles from: (David Kessens has volunteered to > do > this list) > the person: object, e-mail: field > the mntner: object, mnt-nfy: field > remove duplicates > all 6bone sites, not just backbone pTLAs > > Use the current version of Buclin/Durand I-D on "IPv6 routing issues" > as > policy: > should rename this draft "6bone routing practices" (Bertrand is > doing this) > publish reports of variance with them, per pTLA > > Require a minimum amount of peering for robustness sake: > say 3-5 other pTLAs, but not too many > > Publish daily lists of following information: > as above, publish reports of variance with the I-D rules, per pTLA > pTLA routes longer than /24 > those pTLAs not carrying all routes (not so easy without special > effort/tools) > those pTLA tunnels not using BGP4+ (already covered above) > those pTLAs having too many flaps (publish the Merit 6bone routing > report) > the CSELT ASpath-tree results > ping tests across all tunnels > > Directed email to offending sites, especially those significantly > affecting > much of the 6bone > > > So... comments and volunteers for bits of the work appreciated. > > > Now I am making available over the Internet a new html page showing the anomalous BGP4+ prefixes (according to current version of Buclin/Durand I-D on "IPv6 routing issues") advertised inside the 6Bone backbone. In particular two kind of anomalous prefixes are displayed: - Invalid prefixes: prefixes outside of the 6Bone range (e.g. the old RFC1897 test addresses) - Unaggregated prefixes: prefixes belonging to the 6Bone range but longer than /24 This html page is available at http://carmen.cselt.it/ipv6/bgp/odd-routes.html and is automatically updated every 5 mim. I have added a link to this new page also inside the main CSELT's BGP4+ routing info page (http://carmen.cselt.it/ipv6/bgp/index.html) which is accessible from the official 6Bone home page. I hope this will be of help in cleaning up the 6bone backbone. Bye Ivano > Thanks, > > Bob > > > > From rlfink@lbl.gov Thu May 7 22:53:03 1998 From: rlfink@lbl.gov (Bob Fink) Date: Thu, 07 May 1998 14:53:03 -0700 Subject: some 6bone backbone cleanup recommendations In-Reply-To: Message-ID: Ivano, At 04:17 PM 5/7/98 +0200, Guardini Ivano wrote: ... >Now I am making available over the Internet a new html page showing the >anomalous BGP4+ prefixes (according to current version of Buclin/Durand >I-D on "IPv6 routing issues") advertised inside the 6Bone backbone. In >particular two kind of anomalous prefixes are displayed: >- Invalid prefixes: prefixes outside of the 6Bone range (e.g. the old >RFC1897 test addresses) >- Unaggregated prefixes: prefixes belonging to the 6Bone range but >longer than /24 > >This html page is available at >http://carmen.cselt.it/ipv6/bgp/odd-routes.html and is automatically >updated every 5 mim. I have added a link to this new page also inside >the main CSELT's BGP4+ routing info page >(http://carmen.cselt.it/ipv6/bgp/index.html) which is accessible from >the official 6Bone home page. > >I hope this will be of help in cleaning up the 6bone backbone. This is most definitely good stuff to help with cleaning up the backbone. Thank you for doing it. The odd-routes page is now listed prominently on the 6bone homepage. Thanks, Bob From Marc.Blanchet@viagenie.qc.ca Fri May 8 01:44:39 1998 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Thu, 07 May 1998 20:44:39 -0400 Subject: registry update Message-ID: <3.0.3.32.19980507204439.040807ac@mail.viagenie.qc.ca> Hi, I updated an entry in the isi registry two days ago but if I look at the lancaster tunnels description, the old entry is still there. I was thinking that Lancaster was querying the isi registry db, isn't it? Or Lancaster have a copy/mirror of it, in this case, what is the refresh time? Regards, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp: 57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifié, Éditions Logiques, 1997 ------------------------------------------------------------ From rlfink@lbl.gov Fri May 8 15:45:48 1998 From: rlfink@lbl.gov (Bob Fink) Date: Fri, 08 May 1998 07:45:48 -0700 Subject: welcome to LINET in Lithuania (our 34th country on the 6bone) Message-ID: <1317508934-193990188@cnrmail.lbl.gov> Welcome to LITNET, in Lithuania, the 34th country to join the 6bone. ipv6-site: LITNET origin: AS2839 descr: Academical and Research Network in Lithuania country: LT prefix: 3FFE:200:C::/48 application: ping 6bone-gw.litnet.lt tunnel: IPv6 in IPv4 6bone-gw.litnet.lt -> 6bone-gw.sics.se SICS STATI Ccontact: MB2-6BONE remarks: Running test IPv6 implemenatation on CISCO routers notify: martynas@sc-uni.ktu.lt changed: martynas@sc-uni.ktu.lt 19980507 source: 6BONE From sst2258@omega.uta.edu Fri May 8 21:14:29 1998 From: sst2258@omega.uta.edu (S Tadepalli) Date: Fri, 8 May 1998 15:14:29 -0500 (CDT) Subject: Questions Message-ID: Can anyone please answer the following questions as soon as possible? Thank you for your help. 1. Can you tell me the advantages and disadvantages of IPv6's automatic configuration protocols, "plug-n-play" over the way it is done in IPv4? 2. Can you tell me a scheduling discipline I can use to implement all of IPv6's real-time support and tell me something of its advantages? 3. Can you tell me the potential strengths and weaknesses of the IPv6 nested header structure. If there is a weakness in this structure, can you propose an alternative? Thank you very much for your time and please have a nice day. Sriram From Bertrand.Buclin@ch.att.com Mon May 11 00:43:08 1998 From: Bertrand.Buclin@ch.att.com (Buclin, Bertrand) Date: Mon, 11 May 1998 01:43:08 +0200 Subject: draft-ietf-ngtrans-6bone-routing-00.txt Message-ID: <71203AED30DAD111AFEF0000C09940BE155D@gvamsx1.ch.att.com> Hi Rebecca, I'm copying the 6Bone mailing list on the reply to your question, if you don't mind. > >8 6Bone Operations group > > > > The 6Bone Operations group is the body in charge of monitoring the > > adherence to the present rules, and will take the appropriate actions > > to correct deviations. Membership in the 6Bone Operations group is > > mandatory for, and restricted to, any site connected to the 6Bone. > > > > The 6Bone Operations group takes the form of a mailing list > > (operations@6bone.net) and is derived from the data in the 6Bone > > registry. > > How exactly is this mailer derived? As you might have seen on the 6Bone mailing list, there was some discussion recently on this topic. The intent is to use the electronic mail address specified in the MTNER object of each site. I consider this topic to be still under discussion on the mailing list, but once conclusion is reached, I'll update the draft to reflect it. Cheers, Bertrand From bmanning@ISI.EDU Mon May 11 15:08:40 1998 From: bmanning@ISI.EDU (bmanning@ISI.EDU) Date: Mon, 11 May 1998 07:08:40 -0700 (PDT) Subject: draft-ietf-ngtrans-6bone-routing-00.txt In-Reply-To: <71203AED30DAD111AFEF0000C09940BE155D@gvamsx1.ch.att.com> from "Buclin, Bertrand" at May 11, 98 01:43:08 am Message-ID: <199805111408.AA02993@zed.isi.edu> > > > The 6Bone Operations group takes the form of a mailing > list > > > (operations@6bone.net) and is derived from the data in the > 6Bone > > > registry. > > > > How exactly is this mailer derived? > > As you might have seen on the 6Bone mailing list, there was some > discussion recently on this topic. The intent is to use the electronic > mail address specified in the MTNER object of each site. I consider this > topic to be still under discussion on the mailing list, but once > conclusion is reached, I'll update the draft to reflect it. > > Cheers, Bertrand I still beleive that simple use of the MTNER object will lead to problems, the principle issue is that there is no requirement, in protocol or otherwise to maintain such a registration. However, there exists a listing of email address that are required for gaining a delegation, that being the email address which is encoded in each delegation cut point. -- --bill From aboujao@okstate.edu Tue May 12 21:05:41 1998 From: aboujao@okstate.edu (Dani Aboujaoude) Date: Tue, 12 May 1998 15:05:41 -0500 Subject: Question? Message-ID: <3558AB94.E78A9AD@okstate.edu> i am still unclear on the exact procedure needed to be taken for Oklahoma State University to be connected to the 6Bone backbone. If you can please send me a clear procedure which our university can follow in order to attain such a connection, it would be greatly appriciated. i.e.. where we can find a connection within our area? How we can contact that perticular university, company, or organization?And the equipment upgrade needed to support such a connection. Dani Aboujaoude Oklahoma State University From mikec@twiddle.com Mon May 18 13:59:48 1998 From: mikec@twiddle.com (Mike Crawfurd) Date: Mon, 18 May 1998 14:59:48 +0200 Subject: IPv6 Question Message-ID: <356030C4.554EEA33@cmg.nl> Hello People, I've read many papers about IPv6, but I want to know how IPv6 implements the private space addresses. Some of CMG's clients are running out of private Address space. How does IPv6 solve this problem ? Thanks in advance, Mike Crawfurd. -- Mike Crawfurd Telephone. (+31) 10 253 7000 CMG Advanced Technologies Industries Telefax. (+31) 10 253 7033 Kralingseweg 241, 3062 CE Rotterdam Mobile. (+31) 65 534 7574 The Netherlands Email. mike.crawfurd@cmg.nl From rlfink@lbl.gov Mon May 18 15:34:08 1998 From: rlfink@lbl.gov (Bob Fink) Date: Mon, 18 May 1998 07:34:08 -0700 Subject: IPv6 Question In-Reply-To: <356030C4.554EEA33@cmg.nl> Message-ID: <1316645646-245923389@cnrmail.lbl.gov> Mike, At 02:59 PM 5/18/98 +0200, Mike Crawfurd wrote: >Hello People, > >I've read many papers about IPv6, but I want to know how IPv6 implements >the private space addresses. > >Some of CMG's clients are running out of private Address space. How does >IPv6 solve this problem ? There is no private address space defined for IPv6, nor does there need to be (so seems to me). There is site local addressing, but that is only useful if your "private space" needs span only one site and you have no external/wide-area ISP connectivity. However, I don't see why you need private space at all with IPv6 given the very large address size, as you will need a wide area service to talk to the outside anyway, and thus you automatically have an address space that is more than generous. As an aside, you should take this kind of question to the IPng mailer (ipng@sunroof.eng.sun.com). Regards, Bob From mikec@twiddle.com Mon May 18 15:56:02 1998 From: mikec@twiddle.com (Mike Crawfurd) Date: Mon, 18 May 1998 16:56:02 +0200 Subject: IPv6 Question Message-ID: <35604C02.99327465@cmg.nl> Dear Bob & the rest of the v6 world, > >Some of CMG's clients are running out of private Address space. How does > >IPv6 solve this problem ? IPv6 has a very large address space, but it doesn't solve the problem for running out of private address space... Converting your entire network to IPv6 requires for at least an A-net, and I don't know how many addresses are supplied to companies... Does anyone know the answer to this problem ? > There is no private address space defined for IPv6, nor does there need to be (so seems to me). There is site local addressing, but that is only useful if your "private space" needs span only one site and you have no external/wide-area ISP connectivity. This is one of the possibilities, I assume that not everybody wants to connect to the Internet, but at least configures their network to be ipv6-capable. You can always use your local-link address, etc. etc. Private space was always a good security option, by using private space addresses the hosts were not directly reachable, with right configuration an excellent security feature. For example the demiliterized zone in combination with firewalls. Is the security so advance and so sure of itself to dare and make every host reachable for the outside world ? > However, I don't see why you need private space at all with IPv6 given the very large address size, as you will need a wide area service to talk to the outside anyway, and thus you automatically have an address space that is more than generous. IPV6 has a very large address size, I agree, but will the same mistake not take place like IPv4 ? Then people thought that the IPv4 range would last forever, the same mistake can be made by thinking the same way about IPv6... A small company with let's say 1024 hosts should not have an In-arpa network range... > As an aside, you should take this kind of question to the IPng mailer (ipng@sunroof.eng.sun.com). > Regards, > > Bob Thanks, Mike Crawfurd. -- Mike Crawfurd Telephone. (+31) 10 253 7000 CMG Advanced Technologies Industries Telefax. (+31) 10 253 7033 Kralingseweg 241, 3062 CE Rotterdam Mobile. (+31) 65 534 7574 The Netherlands Email. mike.crawfurd@cmg.nl From brian@hursley.ibm.com Mon May 18 16:45:14 1998 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Mon, 18 May 1998 16:45:14 +0100 Subject: IPv6 Question References: <356030C4.554EEA33@cmg.nl> Message-ID: <3560578A.9C89B7CD@hursley.ibm.com> You don't need private address space with IPv6. Private address space is an unfortunate side effect of IPv4 addresses being so small. The IPv6 address space is big enough to avoid this problem. Brian Carpenter Mike Crawfurd wrote: > > Hello People, > > I've read many papers about IPv6, but I want to know how IPv6 implements > the private space addresses. > > Some of CMG's clients are running out of private Address space. How does > IPv6 solve this problem ? > > Thanks in advance, > > Mike Crawfurd. > -- > Mike Crawfurd Telephone. (+31) 10 253 7000 > CMG Advanced Technologies Industries Telefax. (+31) 10 253 7033 > Kralingseweg 241, 3062 CE Rotterdam Mobile. (+31) 65 534 7574 > The Netherlands Email. mike.crawfurd@cmg.nl From preed@psd.k12.co.us Tue May 19 00:40:58 1998 From: preed@psd.k12.co.us (J. Paul Reed) Date: Mon, 18 May 1998 17:40:58 -0600 (MDT) Subject: IPv6 Question In-Reply-To: <356030C4.554EEA33@cmg.nl> Message-ID: On Mon, 18 May 1998, Mike Crawfurd wrote: > Hello People, > > I've read many papers about IPv6, but I want to know how IPv6 implements > the private space addresses. > > Some of CMG's clients are running out of private Address space. How does > IPv6 solve this problem ? I should really have a better idea of how to answer this question, as I wrote a 4000 word essay on the dumb thing. :-) ANYway, I thought I'd point out that IPv4 addresses are valid within IPv6, so you could always just assign your clients the private space addresses in IPv4, and append null bits in IPv6 to fill the 128 bits. This is assuming the IANA or whoever isn't going to reclaim those IPv4 addresses. Of course, I may be reading your problem incorrectly, and you're saying you're running out of IPv4 private space addresses as well, in which case what I've said won't help at all. Later, Paul ------------------------------------------------------------------------- J. Paul Reed Among other things, just another perl hacker #!/usr/bin/perl unless ($you =~ /spammer/) { print "Email me!\n"; } @MyEmailAddresses = ("preed@psd.k12.co.us","paul@619pro.com"); $MyWebPage = "http://www.psd.k12.co.us/~preed"; From sprunk@paranet.com Tue May 19 00:57:27 1998 From: sprunk@paranet.com (Stephen Sprunk) Date: Mon, 18 May 1998 18:57:27 -0500 Subject: IPv6 Question References: <356030C4.554EEA33@cmg.nl> <3560578A.9C89B7CD@hursley.ibm.com> Message-ID: <3560CAE7.6946EFB0@paranet.com> Actually, address depletion is not necessarily the motivating factor behind private addressing. Private addresses also provide a degree of security, since it's not possible to route them over the Internet, meaning that someone must get into your network via other means before they can hack internal resources. I always thought that FE80::/10 was available for private addressing, and would make a very effective NAT space. For instance, a company could be allocated a 64-bit global prefix, and they could use private addresses inside, simply translating FE80::/64 to their assigned block and back, leaving the extra 16 bits (plus mac) for internal network addressing. Since there's no dynamic nature to this, it works both in firewalled and non-firewalled environments, even with multiple internet connections. Stephen Brian E Carpenter wrote: > > You don't need private address space with IPv6. Private address > space is an unfortunate side effect of IPv4 addresses being so small. > The IPv6 address space is big enough to avoid this problem. > -- Stephen Sprunk, KD5DWP "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W From dfries@mail.win.org Tue May 19 02:09:37 1998 From: dfries@mail.win.org (David Fries) Date: Mon, 18 May 1998 20:09:37 -0500 Subject: IPv6 Question In-Reply-To: <3560578A.9C89B7CD@hursley.ibm.com>; from Brian E Carpenter on Mon, May 18, 1998 at 04:45:14PM +0100 References: <356030C4.554EEA33@cmg.nl> <3560578A.9C89B7CD@hursley.ibm.com> Message-ID: <19980518200937.46766@AeroSpace> On Mon, May 18, 1998 at 04:45:14PM +0100, Brian E Carpenter wrote: > You don't need private address space with IPv6. Private address > space is an unfortunate side effect of IPv4 addresses being so small. > The IPv6 address space is big enough to avoid this problem. > > Brian Carpenter So, when/if ipv6 completely replaces ipv4 will my local ISP give me more than 1 ip address? Currently with ipv4 the majority of ISPs give one ip address to the computer dialing in. Why would this change for ipv6? I have three computers with each a local ip address and another four that gets used occasionally. Is there anything in ipv6 that guarantees that I get a block of 16 even if I get connected with a dial up occasionally? Some of the ISPs don't allocate a static ip address just so customers can't use the dialup as a server and only pay as a regular user. I don't see why this would change for ipv6. Even if we were guaranteed a block of ip addresses I would think ISPs would still allocate them dynamically, so when I get connected all my computers on the local network would either have to be re-numbered or there would be problems. That doesn't even begin to address the problems with figuring out after I'm connected what all my computers are numbered. It seems to me that having a set of ip address that are defined to not be valid internet address so everyone knows they are free to use them on local computers is necessary no matter how big your address space is. -- +---------------------------------+ | David Fries | | dfries@mail.win.org | +---------------------------------+ From szarka@downcity.net Tue May 19 03:21:17 1998 From: szarka@downcity.net (Robert Szarka) Date: Mon, 18 May 1998 22:21:17 -0400 Subject: IPv6 Question In-Reply-To: <3560578A.9C89B7CD@hursley.ibm.com> References: <356030C4.554EEA33@cmg.nl> Message-ID: At 11:45 AM 5/18/98 , you wrote: >You don't need private address space with IPv6. Private address >space is an unfortunate side effect of IPv4 addresses being so small. >The IPv6 address space is big enough to avoid this problem. I'm new to this list and I think Mike's question was a very good. I just got back from doing a customer install using the private IP space, precisely to enhance security and not because I don't have enough address space to give him. Using private IP space does not in itself guarantee security, of course, but I am as surprised as Mike to hear that it doesn't not exist in IPv6. Can someone provide more background (a paper perhaps?) on the reasoning behind this? Also, a related question comes to mind... Are there multicast addresses set aside in IPv6 as in IPv4? ...and, as long as I'm already sending a message to list... I sent email to someone at Cisco quite a while ago asking what I needed to participate in the 6bone with my Cisco routers. No reply. :( Can anyone point me to more info? Thanks, Robert Szarka Managing Partner, Operations DownCity, LLC +1 860 823 3000 From bmanning@ISI.EDU Tue May 19 05:04:30 1998 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 18 May 1998 21:04:30 -0700 (PDT) Subject: IPv6 Question In-Reply-To: <3560CAE7.6946EFB0@paranet.com> from "Stephen Sprunk" at May 18, 98 06:57:27 pm Message-ID: <199805190404.VAA10824@zephyr.isi.edu> > > Actually, address depletion is not necessarily the motivating factor > behind private addressing. Private addresses also provide a degree of > security, since it's not possible to route them over the Internet, > meaning that someone must get into your network via other means before > they can hack internal resources. > > -- > Stephen Sprunk, KD5DWP "Oops." Email: sprunk@paranet.com > Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W False premise. Nothing prevents ISPs from routing private address space other than the notation that the space is not for use in the public Internet. Some other steps have been taken to discourage RFC 1918 address space from use within the public Internet, but that still does not prohibit the routing of these addresses. -- --bill From deering@cisco.com Tue May 19 06:34:06 1998 From: deering@cisco.com (Steve Deering) Date: Mon, 18 May 1998 22:34:06 -0700 Subject: IPv6 Question In-Reply-To: References: <3560578A.9C89B7CD@hursley.ibm.com> <356030C4.554EEA33@cmg.nl> Message-ID: At 7:21 PM -0700 5/18/98, Robert Szarka wrote: > Using private IP space does not in itself guarantee security, of course, > but I am as surprised as Mike to hear that it doesn't not exist in IPv6. IPv6 *does* have private address space: the link-local and site-local unicast addresses. You can use site-local addresses exactly like IPv4's net 10, if you wish. The point that others have been making is that IPv6 has enough global addresses that customers need not be forced to use private address space for lack of sufficient global address space. If they have other reasons to want to do so, then IPv6 has what they want. > Also, a related question comes to mind... Are there multicast addresses set > aside in IPv6 as in IPv4? Set aside for what? If you are asking if IPv6 has non-globally-scoped multicast addresses, the answer is yes. > ...and, as long as I'm already sending a message to list... I sent email to > someone at Cisco quite a while ago asking what I needed to participate in the > 6bone with my Cisco routers. No reply. :( Can anyone point me to more >info? Oops. I'm not in the group at Cisco that does IPv6 support, but I'll pass your message on. Have you already checked out ? Steve From smurf@noris.de Tue May 19 06:41:25 1998 From: smurf@noris.de (Matthias Urlichs) Date: Tue, 19 May 1998 07:41:25 +0200 Subject: IPv6 Question In-Reply-To: <19980518200937.46766@AeroSpace>; from David Fries on Mon, May 18, 1998 at 08:09:37PM -0500 References: <356030C4.554EEA33@cmg.nl> <3560578A.9C89B7CD@hursley.ibm.com> <19980518200937.46766@AeroSpace> Message-ID: <19980519074125.02414@noris.de> Hi, David Fries: > > So, when/if ipv6 completely replaces ipv4 will my local ISP give me more > than 1 ip address? Currently with ipv4 the majority of ISPs give one ip > address to the computer dialing in. Why would this change for ipv6? I Because that one IP address actually is a /64. You can put a whole lot of hosts behind that, just use a decent access router. The problem of the ISP charging more for more addresses, on the assumption that more hosts are going to generate more traffic, isn't going to go away, however, and they still can filter out all but one EID unless they agree not to. But that's not an IPv6 issue. > > It seems to me that having a set of ip address that are defined to not be > valid internet address so everyone knows they are free to use them on local > computers is necessary no matter how big your address space is. > Uh, yes, but there already are such addresses in IPv6. -- Matthias Urlichs noris network GmbH From dfries@mail.win.org Tue May 19 06:53:31 1998 From: dfries@mail.win.org (David Fries) Date: Tue, 19 May 1998 00:53:31 -0500 Subject: IPv6 Question In-Reply-To: <19980519074125.02414@noris.de>; from Matthias Urlichs on Tue, May 19, 1998 at 07:41:25AM +0200 References: <356030C4.554EEA33@cmg.nl> <3560578A.9C89B7CD@hursley.ibm.com> <19980518200937.46766@AeroSpace> <19980519074125.02414@noris.de> Message-ID: <19980519005331.11803@AeroSpace> On Tue, May 19, 1998 at 07:41:25AM +0200, Matthias Urlichs wrote: > > It seems to me that having a set of ip address that are defined to not be > > valid internet address so everyone knows they are free to use them on local > > computers is necessary no matter how big your address space is. > > > Uh, yes, but there already are such addresses in IPv6. Good, the way the dicussion was going before it sounded as if it didn't. If it has a equivalent of 192.168.* and 10.* then I have no further arguments. -- +---------------------------------+ | David Fries | | dfries@mail.win.org | +---------------------------------+ From deering@cisco.com Tue May 19 06:57:33 1998 From: deering@cisco.com (Steve Deering) Date: Mon, 18 May 1998 22:57:33 -0700 Subject: IPv6 Question In-Reply-To: <35604C02.99327465@cmg.nl> Message-ID: At 7:56 AM -0700 5/18/98, Mike Crawfurd wrote: > IPv6 has a very large address space, but it doesn't solve the problem > for running out of private address space... Converting your entire > network to IPv6 requires for at least an A-net, and I don't know how > many addresses are supplied to companies... Are you asking about global space or private space? The proposed global unicast address plan allocates a 16-bit subnet field plus a 64-bit host (actually, interface) field to every customer site. That's way bigger than an IPv4 Class A network number. The straightforward use of site-local addresses would use the same amount of private addresses space (16+64), but if you want the hassle of maintaining and routing different subnet numbering plans for private address and global addresses, you can use up to 54 bits to number your private subnets. And if you want to give up stateless autoconfiguration, you can have even more bits by cutting into the interface ID field. In other words, there's no problem of inadequate private address space in IPv6. > Private space was always a good security option, by using private space > addresses the hosts were not directly reachable, with right > configuration an excellent security feature. Most customers using private addresses also use NATs or proxies or some other means of allowing some internal machines to communicate to external machines. Thus, the lack of a global address does not prevent an external machine from communicating with an internal machine. Rather, it is the careful configuration of who can talk to whom that achieves whatever security is achieved, not the use of private addresses. > Is the security so advance and so sure of itself to dare and make every > host reachable for the outside world ? If Internet telephony really takes off, this idea that only a small number of machines in an organization need be reachable by the outside world will probably pass away. Steve From deering@cisco.com Tue May 19 07:21:41 1998 From: deering@cisco.com (Steve Deering) Date: Mon, 18 May 1998 23:21:41 -0700 Subject: IPv6 Question In-Reply-To: <19980518200937.46766@AeroSpace> References: <3560578A.9C89B7CD@hursley.ibm.com>; from Brian E Carpenter on Mon, May 18, 1998 at 04:45:14PM +0100 <356030C4.554EEA33@cmg.nl> <3560578A.9C89B7CD@hursley.ibm.com> Message-ID: At 6:09 PM -0700 5/18/98, David Fries wrote: > So, when/if ipv6 completely replaces ipv4 will my local ISP give me more > than 1 ip address? It is the intent that ISPs should assign 2^80 (!) addresses (16-bit SLA field plus 64-bit interface ID field) to *each* of their customers, *including* residential customers. IPv6 is designed to support the existence of many subnets within a home, with plug-and-play, stateless address allocation for many, many devices (appliances, TV & stereo components, sensors and actuators of many kinds, children and pets,...) Now, there may well be ISPs who refuse to go along with that intent, but they will not be able to use lack of address space as a reason. And it would be a good reason to look for a different ISP. > Some of the ISPs don't allocate a static ip address just so customers can't > use the dialup as a server and only pay as a regular user. Well that's a beaut! Anyway, I hope and expect that the distortions of the "dial-up" model will eventually go away, as the newer "Always On" access technologies (cable, xDSL, whatever) catch on. One of the things that will help them catch on will be marketing promises of full-time Internet connectivity and more stable addresses, which are clearly features that appeal to customers. > It seems to me that having a set of ip address that are defined to not be > valid internet address so everyone knows they are free to use them on local > computers is necessary no matter how big your address space is. IPv6 does have lots of those kinds of addresses too (the site-local addresses). Steve From MOSTHAVM@plcman.siemens.co.uk Tue May 19 08:46:34 1998 From: MOSTHAVM@plcman.siemens.co.uk (MOSTHAVM@plcman.siemens.co.uk) Date: Tue, 19 May 1998 08:46:34 +0100 Subject: IPv6 Question Message-ID: I might be thinking along the wrong lines, but wouldn't it be very easy to define an other address range for this? Shurely we got quit a few left. All that is used is the 5f and the 3f range. Marc Mosthav From jonheg@ifi.uio.no Tue May 19 10:32:13 1998 From: jonheg@ifi.uio.no (Jon Arne Hegge) Date: Tue, 19 May 1998 11:32:13 +0200 (MET DST) Subject: IPv6 and QoS? Message-ID: Hey, I'm working on a masters thesis in University of Oslo, and I'm wondering if anyone have a link or document describing how to use the support for QoS in IPv6? Spesifically how to set the flow-label field and the class-field. Or is this up to the TCP/IP stack? I have been looking at Winsock 2, because this project will be based on NT, and it contains support for some types of real-time traffic and multimedia transfer. The question is basically if the IPv6 spec. incorporates some standard for setting the values in these fields(flow-label & class-field)? Or maybe its an RFC I have missed..:) ?(RFC1363 comes to mind) If this is off topic here, I apologize. Greetings, Jon Arne |tlf:22 23 67 57 - *Jon Arne Hegge* - mob: 90 78 52 48| |Email:jonheg@ifi.uio.no|URL:http://www.ifi.uio.no/~jonheg| --===> Wherever you are, there you are <===-- From asabigue@nada.kth.se Tue May 19 11:25:28 1998 From: asabigue@nada.kth.se (Ariel Sabiguero) Date: Tue, 19 May 1998 12:25:28 +0200 (MET DST) Subject: IPv6 Question In-Reply-To: <19980519005331.11803@AeroSpace> Message-ID: Ok, 010/8 network is other IANA network for "Private Use". You can see both http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space and ftp://ftp.isi.edu/in-notes/rfc1466.txt for more detailed info. Regards Ariel On Tue, 19 May 1998, David Fries wrote: > On Tue, May 19, 1998 at 07:41:25AM +0200, Matthias Urlichs wrote: > > > It seems to me that having a set of ip address that are defined to not be > > > valid internet address so everyone knows they are free to use them on local > > > computers is necessary no matter how big your address space is. > > > > > Uh, yes, but there already are such addresses in IPv6. > > Good, the way the dicussion was going before it sounded as if it didn't. > If it has a equivalent of 192.168.* and 10.* then I have no further > arguments. > > -- > +---------------------------------+ > | David Fries | > | dfries@mail.win.org | > +---------------------------------+ > ----------------------------------------------------------- Ing. Ariel Sabiguero Yawelak Centro de Calculo asabigue@fing.edu.uy Facultad de Ingenieria Herrera y Reissig 565/5to.piso CP 11300 - Montevideo U R U G U A Y "Guess there are still a few bugs in it" Bill Gates - apr/98 - Win98 demo -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From rlfink@lbl.gov Tue May 19 15:16:00 1998 From: rlfink@lbl.gov (Bob Fink) Date: Tue, 19 May 1998 07:16:00 -0700 Subject: flap rate drop - 05/18/98 6Bone Routing Report (from Merit) Message-ID: <1316559857-251084394@cnrmail.lbl.gov> Someone must be doing something right to reduce the 6bone flap rate. Today's routing report for the 18th shows the least Announcement/Withdraw rate yet: 3861/150. Least you think I exagerate, look at the reports for the last 8 days: May 17-46135/22059 May 16-153132/73394 May 15-154237/74892 May 14-143464/69092 May 13-97585/51533 May 12-112330/61222 May 11-77148/48238 May 10-113953/92209 And before this there were days in he millions of announcments! Anyone know what's going on? Or is this just the natual evolution of folks moving to more compatible BGP4+ versions? Bob =================================================================== See http://www.merit.edu/ipma for a more detailed report on routing problems and recommendations on ways service providers can limit the spread of invalid routing information. Send comments and questions to ipma-support@merit.edu To unsubscribe from this list, send mail to 6bone-routing-report-request@merit.edu. A hypermail archive is available at http://www.merit.net/mail.archives/html/6bone-routing-report/ Also see http://www.caida.org for more information about Internet statistics collection research efforts. --------------------------------------------- This report is for 05/18/98, peering with VIAGENIE (AS10566) CISCO (AS109) CICNET (AS1225) WIDE (AS2500) TELEBIT (AS3263) --------------------------------------------- Size of 6Bone Routing Table: Max = 90, Min = 20, Average = 75 40 Unique Autonomous System (AS) numbers BGP4+ Traffic Summary: Announcements = 3861 Withdraws = 150 Unique Routes = 71 Non-6Bone Prefixes (outside of 3ffe::/16): -------------------------------- 5f00:4700::/32 path 109 (CISCO) 5f00:6d00::/32 path 109 (CISCO) 5f01:7800::/32 path 109 1225 (CICNET) 5f02:ad00:8ca0::/64 path 109 (CISCO) 5f04:c500:cb26:1100::/64 path 109 (CISCO) 5f0d:e900:ce9c:9400::/64 path 109 1225 (CICNET) 5f0f:8800::/32 path 109 (CISCO) 5f10:8800::/32 path 109 (CISCO) 5f11:d000:cca2:e400::/64 path 109 (CISCO) Poorly Aggregated Prefixes (>24): -------------------------------- MERIT (3ffe:1c00::/24) had 9 route(s) 3ffe:1c00::/64 path (?) 3ffe:1c00::/48 path (?) 3ffe:1c01::/48 path (?) 3ffe:1c02::/48 path (?) 3ffe:1c03::/48 path (?) 3ffe:1cfa::/48 path (?) 3ffe:1cff::/48 path (?) 3ffe:1cf9::/48 path (?) 3ffe:1cf8::/48 path (?) CISCO (3ffe:c00::/24) had 4 route(s) 3ffe:c00:e:b::1/128 path 2500 237 (MERIT) 3ffe:c00:8004:1::/80 path 109 8176 () 3ffe:c00:8009::/48 path 109 302 (BCM) 3ffe:c00:8004::/48 path 109 8176 () UUNET-UK (3ffe:1100::/24) had 3 route(s) 3ffe:1100:0:cc03::/64 path 1225 1103 293 (ESNET) 3ffe:1100:0:c01::/64 path 109 48 1752 (BT-LABS) 3ffe:1108:40a::/48 path 1225 1103 1835 1273 5539 (SPACENET) CICNET (3ffe:900::/24) had 2 route(s) 3ffe:900:0:3::1/128 path 2500 237 (MERIT) 3ffe:900:1::/48 path 109 1225 1312 (LORE/VT) JANET (3ffe:2100::/24) had 2 route(s) 3ffe:2101:0:ffff::2/127 path 109 48 1752 (BT-LABS) 3ffe:2101::/48 path 109 48 1752 3185 (ULANC) ESNET (3ffe:700::/24) had 2 route(s) 3ffe:710:20::/48 path 1225 1103 293 2505 (KEK) 3ffe:7a0:20::/48 path 1225 1103 293 50 () INFN-CNAF (3ffe:2300::/24) had 2 route(s) 3ffe:23ff::/32 path 109 1849 1835 1717 137 8253 (DUTHNET) 3ffe:23f0::/28 path 109 1849 5623 559 137 8253 (DUTHNET) WIDE (3ffe:500::/24) had 2 route(s) 3ffe:500::1/128 path 2500 237 (MERIT) 3ffe:501:811:2::/64 path 2500 65533 () CSELT (3ffe:1000::/24) had 1 route(s) 3ffe:1001:1:ffff::1/126 path 1225 1103 293 (ESNET) TELEBIT (3ffe:100::/24) had 1 route(s) 3ffe:100:1:2::5/128 path 2500 237 (MERIT) ANSNET (3ffe:d00::/24) had 1 route(s) 3ffe:dfe:fffe::8/126 path 2500 237 (MERIT) VBNS (3ffe:2800::/24) had 1 route(s) 3ffe:2800:2::/48 path 109 1225 1312 (LORE/VT) SURFNET (3ffe:600::/24) had 1 route(s) 3ffe:608:1::/48 path 109 1225 (CICNET) UO (3ffe:1500::/24) had 1 route(s) 3ffe:1500:fffe::d/128 path 2500 237 (MERIT) NRL (3ffe:f00::/24) had 1 route(s) 3ffe:f01:0:ffff::7/127 path 109 48 1752 (BT-LABS) UNI-C (3ffe:1400::/24) had 1 route(s) 3ffe:1402:1:1::/64 path 109 1849 5539 1273 (ECRC) SMS (3ffe:2600::/24) had 1 route(s) 3ffe:2610:4::/48 path 109 1849 5539 3274 1741 (OTOL) The Top Five Most Active Prefixes: ---------------------------------- 1. G6 (3ffe:300::/24) had 1823 BGP+ updates (26 unique aspaths) 1225 5609 5623 1717 (319) 1225 1849 5623 559 1717 (288) 109 1225 5609 5623 1717 (288) 109 1849 5623 559 1717 (288) 2500 33 5609 5623 1717 (199) 2500 109 1849 5623 559 1717 (188) 2500 109 1225 5609 5623 1717 (165) 2500 109 1225 1103 1275 1717 (19) 1225 1103 1717 (18) 1225 1103 1835 1717 (11) 2500 237 1225 1103 1717 (9) ...Truncated... 2. STUBA (3ffe:2200::/24) had 141 BGP+ updates (57 unique aspaths) 109 1849 1103 2607 (9) 2500 109 1849 1103 2607 (9) 1225 1849 1103 2607 (8) 2500 109 1849 2607 (8) 1225 1103 2607 (7) 2500 109 1225 1103 2607 (7) 109 1225 1103 2607 (6) 109 1225 1849 2607 (5) 109 1849 2607 (5) 1225 1849 2607 (4) 2500 109 1225 1849 2607 (4) ...Truncated... 3. DUTHNET (3ffe:23ff::/32) had 109 BGP+ updates (31 unique aspaths) 2500 109 1849 5623 559 137 8253 (11) 109 1849 5623 559 137 8253 (8) 1225 1849 5623 559 137 8253 (7) 2500 109 1225 1103 1717 137 8253 (5) 1225 1849 1103 1717 1835 2839 5623 559 137 8253 (4) 1225 1849 786 1717 1835 2839 5623 559 137 8253 (4) 109 1225 1849 1103 1717 1835 2839 5623 559 137 8253 (4) 109 1225 1103 1717 137 8253 (4) 109 1225 1849 786 1717 1835 2839 5623 559 137 8253 (4) 109 1849 786 1717 1835 2839 5623 559 137 8253 (4) 109 1849 1103 1717 1835 2839 5623 559 137 8253 (4) ...Truncated... 4. NUS-IRDU (3ffe:1600::/24) had 64 BGP+ updates (20 unique aspaths) 2500 109 7610 (11) 1225 109 7610 (8) 109 7610 (7) 2500 33 109 7610 (5) 2500 33 1849 109 7610 (3) 1225 5609 1849 109 7610 (3) 2500 237 109 7610 (2) 2500 237 1225 109 7610 (2) 1225 48 109 7610 (2) 2500 33 5609 1225 109 7610 (2) 1225 5609 5623 1849 109 7610 (1) ...Truncated... 5. UIO (3ffe:2a00::/24) had 63 BGP+ updates (26 unique aspaths) 2500 33 5609 2839 (11) 1225 1103 2839 (8) 109 1225 1103 2839 (5) 109 1849 1835 2839 (4) 1225 1849 1835 2839 (4) 2500 109 1225 1103 2839 (3) 109 1849 1103 2839 (3) 109 1849 2839 (2) 2500 237 1225 1849 1835 2839 (2) 2500 109 1849 2839 (2) 1225 1849 2839 (2) ...Truncated... From rlfink@lbl.gov Tue May 19 15:31:43 1998 From: rlfink@lbl.gov (Bob Fink) Date: Tue, 19 May 1998 07:31:43 -0700 Subject: IPv6 Question (about Cisco IOS for IPv6) In-Reply-To: References: <3560578A.9C89B7CD@hursley.ibm.com> <356030C4.554EEA33@cmg.nl> Message-ID: <1316558389-251172644@cnrmail.lbl.gov> Robert, At 10:21 PM 5/18/98 -0400, Robert Szarka wrote: ... >...and, as long as I'm already sending a message to list... I sent email to >someone at Cisco quite a while ago asking what I needed to participate in the >6bone with my Cisco routers. No reply. :( Can anyone point me to more info? I have been in touch with Cisco this week and their intentions are as follows: ==== IPv6 is targetted for the 12.0T mainline release but it is not decided yet which maintenance window it will be in, i.e. 12.0(1, 2, 3, 4 etc.)T, pending BGP4+ integration results. This release is not likely to occur until late this year. Given this situation, Cisco plans on putting links to the IOS Beta version up on the Cisco IPv6 pages so that anybody who's interested in running IPv6 on Cisco gear and connecting to the 6bone can pull down the appropriate image. That way Cisco makes it more available than with the current mechanism where Cisco customers have to officially apply via EFT/Beta paperwork ... ==== I am trying to get more details on this from Cisco, and this list will know as soon as I do. I intend to also (finally) put the info on the 6bone web pages so it's easier for the newcomer to the 6bone. So...stay tuned. Thanks, Bob From brian@hursley.ibm.com Tue May 19 15:50:50 1998 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 19 May 1998 15:50:50 +0100 Subject: IPv6 and QoS? References: Message-ID: <35619C4A.5E8FED2E@hursley.ibm.com> Hi, The traffic class field is being defined by the diffserv working group: http://www.ietf.org/html.charters/diffserv-charter.html Brian Carpenter Jon Arne Hegge wrote: > > Hey, > > I'm working on a masters thesis in University of Oslo, and I'm > wondering if anyone have a link or document describing how to > use the support for QoS in IPv6? Spesifically how to set the > flow-label field and the class-field. Or is this up to the TCP/IP > stack? I have been looking at Winsock 2, because this project will be > based on NT, and it contains support for some types of real-time traffic > and multimedia transfer. > > The question is basically if the IPv6 spec. incorporates some standard for > setting the values in these fields(flow-label & class-field)? > Or maybe its an RFC I have missed..:) ?(RFC1363 comes to mind) > > If this is off topic here, I apologize. > > Greetings, > Jon Arne > |tlf:22 23 67 57 - *Jon Arne Hegge* - mob: 90 78 52 48| > |Email:jonheg@ifi.uio.no|URL:http://www.ifi.uio.no/~jonheg| > --===> Wherever you are, there you are <===-- From rlfink@lbl.gov Tue May 19 15:49:26 1998 From: rlfink@lbl.gov (Bob Fink) Date: Tue, 19 May 1998 07:49:26 -0700 Subject: IPv6 and QoS? In-Reply-To: Message-ID: <1316556725-251272777@cnrmail.lbl.gov> Jon, At 11:32 AM 5/19/98 +0200, Jon Arne Hegge wrote: >Hey, > >I'm working on a masters thesis in University of Oslo, and I'm >wondering if anyone have a link or document describing how to >use the support for QoS in IPv6? Spesifically how to set the >flow-label field and the class-field. Or is this up to the TCP/IP >stack? I have been looking at Winsock 2, because this project will be >based on NT, and it contains support for some types of real-time traffic >and multimedia transfer. > >The question is basically if the IPv6 spec. incorporates some standard for >setting the values in these fields(flow-label & class-field)? >Or maybe its an RFC I have missed..:) ?(RFC1363 comes to mind) At the moment I don't believe there are any standards for the IPv6 Traffic Class and Flow Label field. The basic presumption now in use for the IPv6 Traffic Class field is that it will follow work on the IPv4 TOS field. This is why there is now a full 8-bits in the recently created Traffic Class field as opposed to the now defunct 4-bit Priority field. The current IPv6 spec talks about this as follows: >7. Traffic Classes > The 8-bit Traffic Class field in the IPv6 header is available for use > by originating nodes and/or forwarding routers to identify and > distinguish between different classes or priorities of IPv6 packets. > At the point in time at which this specification is being written, > there are a number of experiments underway in the use of the IPv4 > Type of Service and/or Precedence bits to provide various forms of > "differentiated service" for IP packets, other than through the use > of explicit flow set-up. The Traffic Class field in the IPv6 header > is intended to allow similar functionality to be supported in IPv6. > It is hoped that those experiments will eventually lead to agreement > on what sorts of traffic classifications are most useful for IP > packets. Detailed definitions of the syntax and semantics of all or > some of the IPv6 Traffic Class bits, whether experimental or intended > for eventual standardization, are to be provided in separate documents. > The following general requirements apply to the Traffic Class field: > o The service interface to the IPv6 service within a node must > provide a means for an upper-layer protocol to supply the value > of the Traffic Class bits in packets originated by that upper- > layer protocol. The default value must be zero for all 8 bits. > o Nodes that support a specific (experimental or eventual > standard) use of some or all of the Traffic Class bits are > permitted to change the value of those bits in packets that > they originate, forward, or receive, as required for that > specific use. Nodes should ignore and leave unchanged any bits > of the Traffic Class field for which they do not support a > specific use. > o An upper-layer protocol must not assume that the value of the > Traffic Class bits in a received packet are the same as the > value sent by the packet's source. So the real place to learn what's going on with these bits is the new IETF Diffserv working group: http://www.ietf.org/html.charters/diffserv-charter.html >If this is off topic here, I apologize. Sending to the IPng list is the right place on protocol questions/topics (ipng@sunroof.eng.sun.com). Thanks, Bob From Bertrand.Buclin@ch.att.com Tue May 19 17:24:58 1998 From: Bertrand.Buclin@ch.att.com (Buclin, Bertrand) Date: Tue, 19 May 1998 18:24:58 +0200 Subject: flap rate drop - 05/18/98 6Bone Routing Report (from Merit) Message-ID: <71203AED30DAD111AFEF0000C09940BE7B19@gvamsx1.ch.att.com> Maybe it could come from U Oregon (pTLA 3ffe:1500::/24)? Until today, they were leaking a lot of poorly aggregated prefixes (consistently reported in the Merit report), and today they appear to be off the air... /Bertrand > -----Original Message----- > From: Bob Fink [mailto:rlfink@lbl.gov] > Sent: Tuesday, May 19, 1998 4:16 PM > To: 6bone@ISI.EDU > Subject: flap rate drop - 05/18/98 6Bone Routing Report (from Merit) > > > Someone must be doing something right to reduce the 6bone > flap rate. Today's routing report for the 18th shows the > least Announcement/Withdraw rate yet: 3861/150. > > Least you think I exagerate, look at the reports for the last 8 days: > > May 17-46135/22059 > May 16-153132/73394 > May 15-154237/74892 > May 14-143464/69092 > May 13-97585/51533 > May 12-112330/61222 > May 11-77148/48238 > May 10-113953/92209 > > And before this there were days in he millions of announcments! > > Anyone know what's going on? Or is this just the natual > evolution of folks moving to more compatible BGP4+ versions? > > > Bob > > =================================================================== > See http://www.merit.edu/ipma for a more detailed report on routing > problems and recommendations on ways service providers can limit the > spread of invalid routing information. > Send comments and questions to ipma-support@merit.edu > > To unsubscribe from this list, send mail to > 6bone-routing-report-request@merit.edu. > A hypermail archive is available at > http://www.merit.net/mail.archives/html/6bone-routing-report/ > > Also see http://www.caida.org for more information about Internet > statistics collection research efforts. > > --------------------------------------------- > This report is for 05/18/98, peering with > VIAGENIE (AS10566) CISCO (AS109) CICNET (AS1225) WIDE > (AS2500) TELEBIT (AS3263) > --------------------------------------------- > > Size of 6Bone Routing Table: > Max = 90, Min = 20, Average = 75 > 40 Unique Autonomous System (AS) numbers > > BGP4+ Traffic Summary: > Announcements = 3861 Withdraws = 150 Unique Routes = 71 > > Non-6Bone Prefixes (outside of 3ffe::/16): > -------------------------------- > 5f00:4700::/32 path 109 (CISCO) > 5f00:6d00::/32 path 109 (CISCO) > 5f01:7800::/32 path 109 1225 (CICNET) > 5f02:ad00:8ca0::/64 path 109 (CISCO) > 5f04:c500:cb26:1100::/64 path 109 (CISCO) > 5f0d:e900:ce9c:9400::/64 path 109 1225 (CICNET) > 5f0f:8800::/32 path 109 (CISCO) > 5f10:8800::/32 path 109 (CISCO) > 5f11:d000:cca2:e400::/64 path 109 (CISCO) > > Poorly Aggregated Prefixes (>24): > -------------------------------- > MERIT (3ffe:1c00::/24) had 9 route(s) > 3ffe:1c00::/64 path (?) > 3ffe:1c00::/48 path (?) > 3ffe:1c01::/48 path (?) > 3ffe:1c02::/48 path (?) > 3ffe:1c03::/48 path (?) > 3ffe:1cfa::/48 path (?) > 3ffe:1cff::/48 path (?) > 3ffe:1cf9::/48 path (?) > 3ffe:1cf8::/48 path (?) > > CISCO (3ffe:c00::/24) had 4 route(s) > 3ffe:c00:e:b::1/128 path 2500 237 (MERIT) > 3ffe:c00:8004:1::/80 path 109 8176 () > 3ffe:c00:8009::/48 path 109 302 (BCM) > 3ffe:c00:8004::/48 path 109 8176 () > > UUNET-UK (3ffe:1100::/24) had 3 route(s) > 3ffe:1100:0:cc03::/64 path 1225 1103 293 (ESNET) > 3ffe:1100:0:c01::/64 path 109 48 1752 (BT-LABS) > 3ffe:1108:40a::/48 path 1225 1103 1835 1273 5539 (SPACENET) > > CICNET (3ffe:900::/24) had 2 route(s) > 3ffe:900:0:3::1/128 path 2500 237 (MERIT) > 3ffe:900:1::/48 path 109 1225 1312 (LORE/VT) > > JANET (3ffe:2100::/24) had 2 route(s) > 3ffe:2101:0:ffff::2/127 path 109 48 1752 (BT-LABS) > 3ffe:2101::/48 path 109 48 1752 3185 (ULANC) > > ESNET (3ffe:700::/24) had 2 route(s) > 3ffe:710:20::/48 path 1225 1103 293 2505 (KEK) > 3ffe:7a0:20::/48 path 1225 1103 293 50 () > > INFN-CNAF (3ffe:2300::/24) had 2 route(s) > 3ffe:23ff::/32 path 109 1849 1835 1717 137 8253 (DUTHNET) > 3ffe:23f0::/28 path 109 1849 5623 559 137 8253 (DUTHNET) > > WIDE (3ffe:500::/24) had 2 route(s) > 3ffe:500::1/128 path 2500 237 (MERIT) > 3ffe:501:811:2::/64 path 2500 65533 () > > CSELT (3ffe:1000::/24) had 1 route(s) > 3ffe:1001:1:ffff::1/126 path 1225 1103 293 (ESNET) > > TELEBIT (3ffe:100::/24) had 1 route(s) > 3ffe:100:1:2::5/128 path 2500 237 (MERIT) > > > ANSNET (3ffe:d00::/24) had 1 route(s) > 3ffe:dfe:fffe::8/126 path 2500 237 (MERIT) > > VBNS (3ffe:2800::/24) had 1 route(s) > 3ffe:2800:2::/48 path 109 1225 1312 (LORE/VT) > > SURFNET (3ffe:600::/24) had 1 route(s) > 3ffe:608:1::/48 path 109 1225 (CICNET) > > UO (3ffe:1500::/24) had 1 route(s) > 3ffe:1500:fffe::d/128 path 2500 237 (MERIT) > > NRL (3ffe:f00::/24) had 1 route(s) > 3ffe:f01:0:ffff::7/127 path 109 48 1752 (BT-LABS) > > UNI-C (3ffe:1400::/24) had 1 route(s) > 3ffe:1402:1:1::/64 path 109 1849 5539 1273 (ECRC) > > SMS (3ffe:2600::/24) had 1 route(s) > 3ffe:2610:4::/48 path 109 1849 5539 3274 1741 (OTOL) > > The Top Five Most Active Prefixes: > ---------------------------------- > 1. G6 (3ffe:300::/24) had 1823 BGP+ updates (26 unique aspaths) > 1225 5609 5623 1717 (319) > 1225 1849 5623 559 1717 (288) > 109 1225 5609 5623 1717 (288) > 109 1849 5623 559 1717 (288) > 2500 33 5609 5623 1717 (199) > 2500 109 1849 5623 559 1717 (188) > 2500 109 1225 5609 5623 1717 (165) > 2500 109 1225 1103 1275 1717 (19) > 1225 1103 1717 (18) > 1225 1103 1835 1717 (11) > 2500 237 1225 1103 1717 (9) > ...Truncated... > > 2. STUBA (3ffe:2200::/24) had 141 BGP+ updates (57 unique aspaths) > 109 1849 1103 2607 (9) > 2500 109 1849 1103 2607 (9) > 1225 1849 1103 2607 (8) > 2500 109 1849 2607 (8) > 1225 1103 2607 (7) > 2500 109 1225 1103 2607 (7) > 109 1225 1103 2607 (6) > 109 1225 1849 2607 (5) > 109 1849 2607 (5) > 1225 1849 2607 (4) > 2500 109 1225 1849 2607 (4) > ...Truncated... > > 3. DUTHNET (3ffe:23ff::/32) had 109 BGP+ updates (31 unique aspaths) > 2500 109 1849 5623 559 137 8253 (11) > 109 1849 5623 559 137 8253 (8) > 1225 1849 5623 559 137 8253 (7) > 2500 109 1225 1103 1717 137 8253 (5) > 1225 1849 1103 1717 1835 2839 5623 559 137 8253 (4) > 1225 1849 786 1717 1835 2839 5623 559 137 8253 (4) > 109 1225 1849 1103 1717 1835 2839 5623 559 137 8253 (4) > 109 1225 1103 1717 137 8253 (4) > 109 1225 1849 786 1717 1835 2839 5623 559 137 8253 (4) > 109 1849 786 1717 1835 2839 5623 559 137 8253 (4) > 109 1849 1103 1717 1835 2839 5623 559 137 8253 (4) > ...Truncated... > > 4. NUS-IRDU (3ffe:1600::/24) had 64 BGP+ updates (20 unique aspaths) > 2500 109 7610 (11) > 1225 109 7610 (8) > 109 7610 (7) > 2500 33 109 7610 (5) > 2500 33 1849 109 7610 (3) > 1225 5609 1849 109 7610 (3) > 2500 237 109 7610 (2) > 2500 237 1225 109 7610 (2) > 1225 48 109 7610 (2) > 2500 33 5609 1225 109 7610 (2) > 1225 5609 5623 1849 109 7610 (1) > ...Truncated... > > 5. UIO (3ffe:2a00::/24) had 63 BGP+ updates (26 unique aspaths) > 2500 33 5609 2839 (11) > 1225 1103 2839 (8) > 109 1225 1103 2839 (5) > 109 1849 1835 2839 (4) > 1225 1849 1835 2839 (4) > 2500 109 1225 1103 2839 (3) > 109 1849 1103 2839 (3) > 109 1849 2839 (2) > 2500 237 1225 1849 1835 2839 (2) > 2500 109 1849 2839 (2) > 1225 1849 2839 (2) > ...Truncated... > > > From szarka@downcity.net Tue May 19 22:08:58 1998 From: szarka@downcity.net (Robert Szarka) Date: Tue, 19 May 1998 17:08:58 -0400 Subject: IPv6 Question In-Reply-To: References: <3560578A.9C89B7CD@hursley.ibm.com> <356030C4.554EEA33@cmg.nl> Message-ID: At 01:34 AM 5/19/98 , you wrote: >At 7:21 PM -0700 5/18/98, Robert Szarka wrote: >> Using private IP space does not in itself guarantee security, of course, >> but I am as surprised as Mike to hear that it doesn't not exist in IPv6. > >IPv6 *does* have private address space: the link-local and site-local unicast >addresses.  You can use site-local addresses exactly like IPv4's net 10, if >you wish. Ahh.. glad to hear it. Perhaps I got the wrong impression from an earlier message, then. >The point that others have been making is that IPv6 has enough global >addresses that customers need not be forced to use private address space >for lack of sufficient global address space.  If they have other reasons >to want to do so, then IPv6 has what they want. Right. It was those other reasons I was interested in... Yes, as someone else pointed out, the "non-routability" of the private space depends on the ISP in fact not routing them, but, in my case, *I* am the ISP and it makes my customers sleep a little better at night... :) Robert Szarka Managing Partner, Operations DownCity, LLC +1 860 823 3000 From szarka@downcity.net Tue May 19 22:00:10 1998 From: szarka@downcity.net (Robert Szarka) Date: Tue, 19 May 1998 17:00:10 -0400 Subject: IPv6 Question (about Cisco IOS for IPv6) In-Reply-To: <1316558389-251172644@cnrmail.lbl.gov> References: <3560578A.9C89B7CD@hursley.ibm.com> <356030C4.554EEA33@cmg.nl> Message-ID: At 10:31 AM 5/19/98 , you wrote: >[...] >I am trying to get more details on this from Cisco, and this list will know as soon as I do.  I intend to also (finally) put the info on the 6bone web pages so it's easier for the newcomer to the 6bone. Thanks, Bob, and thank you to the others who sent info. We would like participate in the 6bone with at least one host here at DownCity, if possible, so I will stay tuned! Also, if anyone here is a CERFnet or Goodnet customer and has comments or observations for a newbie using those backbone providers, I'd love to receive some email from you. :) Awaiting the day when his blender will be pingable, Robert Szarka Managing Partner, Operations DownCity, LLC +1 860 823 3000 From mgoeydem@crcg.edu Wed May 20 02:53:45 1998 From: mgoeydem@crcg.edu (Murat Goekdemir) Date: Tue, 19 May 1998 21:53:45 -0400 Subject: traffic generator for Digital Unix Message-ID: <356237A8.FCE148BC@crcg.edu> This is a multi-part message in MIME format. --------------904475A723C5834B37AF8C37 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi folks, i am currently working on my thesis and i need a traffic generator and other analyzing tools for Digital Unix IPv6 spec. Does anybody know if some tools are available ? And i would really like to know how far the implementation of IPv6 over ATM is. Are there some other information materials, except the draft-ietf-ion-ipv6-atm-02 ? If this is off topic here, I apologize. thanks Murat Goekdemir --------------904475A723C5834B37AF8C37 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Murat Goekdemir Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Murat Goekdemir n: Goekdemir;Murat org: Fraunhofer Center for Research in Computer Graphics adr: 321 South Main Street;;;Providence;Rhode Island;02903;USA email;internet: mgoeydem@crcg.edu tel;work: +1 401 453 63 63 xx 107 tel;fax: +1 401 453 0444 x-mozilla-cpt: ;0 x-mozilla-html: FALSE end: vcard --------------904475A723C5834B37AF8C37-- From rlfink@lbl.gov Thu May 21 17:12:02 1998 From: rlfink@lbl.gov (Bob Fink) Date: Thu, 21 May 1998 09:12:02 -0700 Subject: ETRI/KR added as pTLA Message-ID: <1316380571-261869907@cnrmail.lbl.gov> ETRI/KR has been added as a pTLA per their request and subsequent review on this list. Please welcome them and help them to come up on the backbone. http://www.isi.edu/cgi-bin/davidk/whois.pl?etri Thanks, Bob From danny@public.bjnet.edu.cn Sun May 24 07:28:34 1998 From: danny@public.bjnet.edu.cn (Chen Maoke) Date: Sun, 24 May 1998 15:28:34 +0900 Subject: No subject Message-ID: <199805240628.PAA12790@bjnet.edu.cn> I am in Beijing, China. Which backbone site of 6bone is appropriate to me? Futher, how to contact with the backbone site? Thank you much! From raphael@icu.ac.kr Sun May 24 08:36:36 1998 From: raphael@icu.ac.kr (Raphael Lee) Date: Sun, 24 May 1998 16:36:36 +0900 Subject: How can I install IPv6 Message-ID: <002801bd86e6$b136ca80$2e32fe81@raphael.etri.re.kr> Hello. This is Raphael Lee. I'm a student of ICU in Korea. I have a question about router setup a INRIA IPv6 router for FreeBSD 2.2.5. first rc.ipv6 file options..(It is rc.ipv6-duvel) # IPv6 setup for duvel{-v6.ipv6}.inria.fr (FreeBSD 2.2.5) autoconf6 -v >/tmp/autoconf6 2>&1 & cat /home/dupont/cache.au > /dev/audio #else # sysctl net.inet6.ipv6.multi_homed # # ifconfig de0 inet6 fe80::220:feff:fe00:8781/128 # route -n add -iface -inet6 ff02::/16 fe80::220:feff:fe00:8781 # route -n add -iface -inet6 ff12::/16 fe80::220:feff:fe00:8781 # # ifconfig fpa0 inet6 fe80::a00:2bff:feb4:8ff3/128 # # ifconfig ll0 inet6 fe80::220:feff:fe00:8781/64 # # ifconfig sit0 inet6 ::128.93.9.50/96 # ifconfig sit1 inet6 ::193.51.193.60/123 # # ifconfig lo0 inet6 ::1/128 # route -n add -inet6 ff01::/16 -iface ::1 # route -n add -inet6 ff11::/16 -iface ::1 # route -n add -iface -cloning -inet6 ::/0 fe80::220:feff:fe00:8781 #fi # eui64 magic option can easily used here! ifconfig de0 inet6 firstalias 3ffe:0306:1051:8300::/64 eui64 ifconfig fpa0 inet6 firstalias 3ffe:0306:1051:d6d2::/64 eui64 -> What is a prefix of router duvel? and.. where do I write my prefix for route? -> why 2 prefix exist? -> What is magic option? comment file is written by French.. (sorry.. I can't speak french.. !_! ) # route to 6bone via a configured tunnel #(cticonfig -v -4 -l -s 128.93.9.50 cti0 129.88.26.1; # cticonfig -v -4 -s 128.93.9.50 cti1 192.44.68.18) >/tmp/cticonfig 2>&1 # #ifconfig cti0 inet6 3ffe:0306:1051:8300:1:0:805d:932/128 ::129.88.26.1 # #ifconfig cti1 inet6 firstalias 3ffe:0306:1051:8300:1:0:805d:932/128 ::192.44.68.18 - > Is it tunnel for connection to 6bone from duvel? what is duvel? and.. what is 6bone connection point? #route -n add -inet6 ::/0 ::129.88.26.1 #route -n add -inet6 3ffe:306:1051:d6d0::/60 fe80::240:bff:fe40:94bb -ifa 3ffe:0306:1051:d6d2:a00:2bff:feb4:8ff3 # turn IP forwarding on sysctl -w net.inet6.ipv6.forwarding=1 sysctl -w net.inet6.ipv6.mforwarding=1 #ndpd-router -s -g ndpd-router -s and.. 1. 'make world in /usr/src/', 2. kernel compile, 3. update rc.ipv6 file. are all methods to setup router? My IPv6 machine is not works in above methods.. I guess... ... inetd.conf or rc.conf file has to fix ? how? Bye... From peterdd@gto.net.om Sun May 31 20:11:27 1998 From: peterdd@gto.net.om (peter dawson) Date: Sun, 31 May 1998 23:11:27 +0400 Subject: Requirments for IPv6 routers Message-ID: <3571AB5C.8656FF91@gto.net.om> Hi 6bone folk : Is there any std or draft for 'Requirements for IPv6 Routers' - Similar to RFC1812 ? or is there a draft in the pipeline ?? some pointers appreciated. If not, can I assume that the following IETF drafts are best reference's avialable as on date ? Alain Durand draft Alain Durand / Bertrand Buclin Thks Pete