From rh@concepts.nl Sun Jun 1 17:17:42 2003 From: rh@concepts.nl (Richard Hartensveld) Date: Sun, 01 Jun 2003 18:17:42 +0200 (CEST) Subject: [6bone] Return of 3ffe:4007::/32 Message-ID: Hi, After a successful testing period of 1 year and 1 month as of today, we would like to return our pTLA, as we have now switched over to using ripe space. We have deleted all of our objects from the 6bone database, some cruft was left that was inserted by users of our tunnelserver which we leave to the appriopriate persons to clean up. We would like to thank the 6bone for giving us this testing oppertunity, it has been very educative to us. -- --------------------------------- Richard Hartensveld Concepts ICT St. Ignatiusstraat 265 4817 KK Breda tel. +31-76-5221555 fax. +31-76-5310531 From JORDI PALET MARTINEZ" Message-ID: <034d01c3284a$71e35280$870a0a0a@consulintel.es> I'm not sure if this is within our scope, but I guess isn't a mayor problem. Can we ask to all the people that is returning pTLAs, a brief information about their deployment/production plans (if any), timing, and so on ? Regards, Jordi ----- Original Message ----- From: "Richard Hartensveld" To: Cc: <6bone@ISI.EDU> Sent: Sunday, June 01, 2003 6:17 PM Subject: [6bone] Return of 3ffe:4007::/32 > > Hi, > > After a successful testing period of 1 year and 1 month as of today, we would > like to return our pTLA, as we have now switched over to using ripe space. > > We have deleted all of our objects from the 6bone database, some cruft was left > that was inserted by users of our tunnelserver which we leave to the > appriopriate persons to clean up. > > We would like to thank the 6bone for giving us this testing oppertunity, it has > been very educative to us. > > > > -- > --------------------------------- > Richard Hartensveld > Concepts ICT > St. Ignatiusstraat 265 > 4817 KK Breda > tel. +31-76-5221555 > fax. +31-76-5310531 > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From bob@thefinks.com Sun Jun 1 16:44:33 2003 From: bob@thefinks.com (Bob Fink) Date: Sun, 01 Jun 2003 08:44:33 -0700 Subject: [6bone] Re: Return of 3ffe:4007::/32 In-Reply-To: Message-ID: <5.2.0.9.0.20030601083840.028b9f48@mail.addr.com> Richard, Thanks for the return of the pTLA and the kind words. I will list your prefix as returned. Thanks, Bob === At 06:17 PM 6/1/2003 +0200, Richard Hartensveld wrote: >Hi, > >After a successful testing period of 1 year and 1 month as of today, we would >like to return our pTLA, as we have now switched over to using ripe space. > >We have deleted all of our objects from the 6bone database, some cruft was >left >that was inserted by users of our tunnelserver which we leave to the >appriopriate persons to clean up. > >We would like to thank the 6bone for giving us this testing oppertunity, >it has >been very educative to us. > > > >-- >--------------------------------- >Richard Hartensveld >Concepts ICT >St. Ignatiusstraat 265 >4817 KK Breda >tel. +31-76-5221555 >fax. +31-76-5310531 From bob@thefinks.com Sun Jun 1 16:45:49 2003 From: bob@thefinks.com (Bob Fink) Date: Sun, 01 Jun 2003 08:45:49 -0700 Subject: [6bone] Return of 3ffe:4007::/32 In-Reply-To: <034d01c3284a$71e35280$870a0a0a@consulintel.es> References: Message-ID: <5.2.0.9.0.20030601084458.02890ac8@mail.addr.com> At 10:30 AM 6/1/2003 -0400, JORDI PALET MARTINEZ wrote: >I'm not sure if this is within our scope, but I guess isn't a mayor problem. > >Can we ask to all the people that is returning pTLAs, a brief information >about their deployment/production plans (if any), timing, >and so on ? If anyone wishes they can ask in private or on the list. Bob From hank@att.net.il Mon Jun 2 08:29:59 2003 From: hank@att.net.il (Hank Nussbacher) Date: Mon, 02 Jun 2003 09:29:59 +0200 Subject: [6bone] Checkpoint IPv6 firewall available for attacking :-) Message-ID: <5.1.0.14.2.20030602092456.00fed550@max.att.net.il> IUCC (AS378) has installed and made available a Checkpoint firewall (NG FP4 Early Availability 2) that is working on IPv6. The firewall is located at: fw.ipv6.technion.ac.il -> 3ffe:2024:4100:1::2 and a web server located behind it: www.ipv6.technion.ac.il -> 3ffe:2024:4100:2:2d0:b7ff:fe09:a5bb This server runs a few more services (including ssh) which are blocked by the FireWall. We welcome attacks on this firewall and webserver. We just ask that if you succeed in breaking something, that you send the results to: Hank Nussbacher - hank@mail.iucc.ac.il Dani Arbel - darbel@tx.technion.ac.il We are willing to share our experiences with this list if it is interesting to the list. Regards, Hank & Dani From bob@thefinks.com Mon Jun 2 16:11:58 2003 From: bob@thefinks.com (Bob Fink) Date: Mon, 02 Jun 2003 08:11:58 -0700 Subject: [6bone] Fwd: I-D ACTION:draft-fink-6bone-phaseout-02.txt Message-ID: <5.2.0.9.0.20030602080854.01c1e030@mail.addr.com> 6bone Folk, The draft-fink-6bone-phaseout-02.txt just released should be the one to forward to the IESG for BCP. There are no real changes, just cleanup and formatting. If I don't hear anything (substantive) against forwarding in the next few days I will forward it at the end of the week. Thanks, Bob === >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-fink-6bone-phaseout-02.txt >Date: Mon, 02 Jun 2003 07:28:52 -0400 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : 6bone (IPv6 Testing Address Allocation) Phaseout > Author(s) : R. Fink, R. Hinden > Filename : draft-fink-6bone-phaseout-02.txt > Pages : 6 > Date : 2003-5-30 > >The 6bone was established in 1996 by the IETF as an IPv6 Testbed >network to enable various IPv6 testing as well as to assist in the >transitioning of IPv6 into the Internet. It operates under the IPv6 >address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its >production deployment it is appropriate to plan for the phaseout of >the 6bone. This note establishes a plan for a multi-year phaseout of >the 6bone and its address allocation on the assumption that the IETF >is the appropriate place to determine this. >This document is intended to obsolete RFC 2471, 'IPv6 Testing Address >Allocation', December, 1998. RFC 2471 will become historic. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-fink-6bone-phaseout-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-fink-6bone-phaseout-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-fink-6bone-phaseout-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-5-30152047.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-fink-6bone-phaseout-02.txt > > From bob@thefinks.com Thu Jun 5 03:14:00 2003 From: bob@thefinks.com (Bob Fink) Date: Wed, 04 Jun 2003 19:14:00 -0700 Subject: [6bone] pTLA request by RETINA - review closes 30 June 2003 Message-ID: <5.2.0.9.0.20030604190938.01c43090@mail.addr.com> 6bone Folk, RETINA has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 30 June 2003 (longer than usual... see below). Please send your comments to me or the list. I am doing a longer time period on this pTLA request as I will be leaving on a 2 week vacation on the 12th of June and won't be in email contact until 1 July. Also, I won't process any more pTLA requests (there aren't many :-) until after I return from vacation (this one was in just before my deadline). Thanks, Bob === Date: Mon, 19 May 2003 19:34:47 -0300 From: Daniel Bellomo Subject: RETINA: pTLA prefix requests To: Bob Fink Dear Bob, I am a member of the RETINA ipv6 project, RETINA would like to apply a 6bone pTLA. Thank you. Daniel Bellomo RFC 2772: 7. Guidelines for 6Bone pTLA sites 1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period the Applicant must be operationally providing the following: <=================================================================> We have been connected to the 6BONE since April 2002 <=================================================================> a. Fully maintained, up to date, 6Bone Registry entries for their ipv6-site inet6num, mntner, and person objects, including each tunnel that the Applicant has. <=================================================================> $ whois -h whois.6bone.net RETINA ... ipv6-site: RETINA origin: AS3597 descr: Red TeleInformatica Academica country: AR prefix: 3FFE:8070:1019::/48 application: ping 6bone.ipv6.retina.ar <=================================================================> b. Fully maintained, and reliable, BGP4+ peering and connectivity between the Applicant's boundary router and the appropriate connection point into the 6Bone. This router must be IPv6 pingable. This criteria is judged by members of the 6Bone Operations Group at the time of the Applicant's pTLA request. <=================================================================> tunnel: IPv6 in IPv4 6bone.retina.ar -> unam-ipv6-1.ipv6.unam.mx UNAM BGP4+ tunnel: IPv6 in IPv4 6bone.retina.ar -> 146.83.248.2 UACH BGP4+ tunnel: IPv6 in IPv4 6bone.retina.ar -> 6bone-gw.rediris.es REDIRIS BGP4+ tunnel: IPv6 in IPv4 6bone.retina.ar -> ipv6.rau.edu.uy RAU STATIC tunnel: IPv6 in IPv4 6bone.retina.ar -> gwipv6.mty.itesm.mx ITESM BGP4+ <=================================================================> c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system. <=================================================================> Our DNS server: ns1.ipv6.retina.ar. 3ffe:8070:1019:200::10 <=================================================================> d. A fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing the Applicant's IPv6 services. This server must be IPv6 pingable. <=================================================================> Our WEB server: www.ipv6.retina.ar. 3ffe:8070:1019:200::5 <=================================================================> 2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following: a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA applicant. <=================================================================> 4 persons: Guillermo Cicileo gcicileo@retina.ar Mariela Rocha mrocha@retina.ar Santiago Aggio slaggio@criba.edu.ar Daniel Bellomo dbellomo@retina.ar <=================================================================> b. A common mailbox for support contact purposes that all support staff have acess to, pointed to with a notify attribute in the ipv6-site object for the pTLA Applicant. <=================================================================> notify: ipv6@retina.ar <=================================================================> 3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest. Applicant must provide a statement and information in support this claim. <=================================================================> RETINA (REd TeleINformatica Academica) is a project launched by Asociacion Civil Ciencia Hoy, (a non profit NGO) in 1990 in order to assure data communication for the Academic and Research area in Argentina, among themselves and with the international community. The web page is www.retina.ar <=================================================================> 4. The pTLA Applicant MUST commit to abide by the current 6Bone operational rules and policies as they exist at time of its application, and agree to abide by future 6Bone backbone operational rules and policies as they evolve by consensus of the 6Bone backbone and user community. <=================================================================> We agree to all current and future operational rules and policies. <=================================================================> When an Applicant seeks to receive a pTLA allocation, it will apply to the 6Bone Operations Group (see section 8 below) by providing to the Group information in support of its claims that it meets the criteria above. 8. 6Bone Operations Group The 6Bone Operations Group is the group in charge of monitoring and policing adherence to the current rules. Membership in the 6Bone Operations Group is mandatory for, and restricted to, sites connected to the 6Bone. The 6Bone Operations Group is currently defined by those members of the existing 6Bone mailing list who represent sites participating in the 6Bone. Therefore it is incumbent on relevant site contacts to join the 6Bone mailing list. Instructions on how to join the list are maintained on the 6Bone web site at < http://www.6bone.net>. Thank you! Daniel Bellomo ----- End forwarded message ----- From bob@thefinks.com Thu Jun 5 15:21:05 2003 From: bob@thefinks.com (Bob Fink) Date: Thu, 05 Jun 2003 07:21:05 -0700 Subject: [6bone] pTLA request by PL-CDP6 - review closes 30 June 2003 Message-ID: <5.2.0.9.0.20030605071624.024bb890@mail.addr.com> 6bone Folk, PL-CDP6 has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 30 June 2003 (longer than usual... see below). Please send your comments to me or the list. I am doing a longer time period on this pTLA request as I will be leaving on a 2 week vacation on the 12th of June and won't be in email contact until 1 July. I won't process any more pTLA requests until after I return from vacation. Thanks, Bob === >From: =?iso-8859-2?Q?Piotr_=AFurawski?= >To: "Bob Fink" >Subject: pTLA request for Crowley Data Poland >Date: Thu, 5 Jun 2003 12:32:43 +0200 > >Dear Bob, > >I'd like to request a test pTLA assignment on the 6bone for Crowley Data >Poland Ltd. , Telecom solutions provider. > > > >1. The pTLA Applicant must have a minimum of three (3) months > > qualifying experience as a 6Bone end-site or pNLA transit. >During > > the entire qualifying period the Applicant must be operationally > > providing the following: > >CDP6 works since 01/09/2002 as a end-site. Since 01/10/2002 it works as >pNLA site. > > > > a. Fully maintained, up to date, 6Bone Registry entries for their > > ipv6-site inet6num, mntner, and person objects, including each > > tunnel that the Applicant has. > >Please check following entries: >ipv6-site: PL-CDP6 >inet6num: CROWLEY6 >mnter: CROWLEY6-MNT >and the persons: >PZ1-6BONE >GZ1-6BONE >PM7-6BONE >AC8-6BONE >GS22-6BONE > > > b. Fully maintained, and reliable, BGP4+ peering and connectivity > > between the Applicant's boundary router and the appropriate > > connection point into the 6Bone. This router must be IPv6 > > pingable. This criteria is judged by members of the 6Bone > > Operations Group at the time of the Applicant's pTLA request. > >Connectivity is provided through ICM-PL (first polish pTLA with large >ammount of tunnels set up), ICP (Internet Cable Provider) and POZMAN - >supercomputing and networking center in Poznan (which is a part of Major >polish educational backbone - POL34). >As in whois, you might ping and traceroute (both in IPv4 and IPv6 >address family) min.waw.cdp.pl. > > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > > entries for the Applicant's router(s) and at least one host > > system. > >Please try following hosts: >min.waw.cdp.pl , min6.waw.cdp.pl >hathor.waw.cdp.pl , hathor6.waw.cdp.pl >isis.waw.cdp.pl , isis6.waw.cdp.pl >osiris.waw.cdp.pl , osiris6.waw.cdp.pl >reverse zone 8.1.0.8.e.f.f.3.ip6.int. is being done for both hosts and >the links to the peers. > > > d. A fully maintained, and reliable, IPv6-accessible system > > providing, at a mimimum, one or more web pages, describing the > > Applicant's IPv6 services. This server must be IPv6 pingable. > >Please try http://min.waw.cdp.pl/ (accessible both via IPv4 and IPv6). > > > 2. The pTLA Applicant MUST have the ability and intent to provide > > "production-quality" 6Bone backbone service. Applicants must > > provide a statement and information in support of this claim. > > This MUST include the following: > > a. A support staff of two persons minimum, three preferable, with > > person attributes registered for each in the ipv6-site object > > for the pTLA applicant. > >As above, see mnter and person objects. > > > b. A common mailbox for support contact purposes that all support > > staff have acess to, pointed to with a notify attribute in the > > ipv6-site object for the pTLA Applicant. > >That's 6bone@crowley.pl , as mentioned in whois records. We're considering >running trouble-ticketing system. > > > 3. The pTLA Applicant MUST have a potential "user community" that > > would be served by its becoming a pTLA, e.g., the Applicant is a > > major provider of Internet service in a region, country, or focus > > of interest. Applicant must provide a statement and information >in > > support this claim. > >Crowley Data Poland is a major Polish Broadband Services provider with >over 1500 customers served. For more details, please see >http://www.crowley.pl/eng/info.html > > > 4. The pTLA Applicant MUST commit to abide by the current 6Bone > > operational rules and policies as they exist at time of its > > application, and agree to abide by future 6Bone backbone > > operational rules and policies as they evolve by consensus of the > > 6Bone backbone and user community. > >We commit any current and any future 6Bone operational rules and policies. > > > > When an Applicant seeks to receive a pTLA allocation, it will apply > > to the 6Bone Operations Group (see section 8 below) by providing to > > the Group information in support of its claims that it meets the > > criteria above. > >Best Regards, > >Piotr From jwenzel@netline.lu Thu Jun 5 15:45:35 2003 From: jwenzel@netline.lu (Jerome Wenzel) Date: Thu, 5 Jun 2003 16:45:35 +0200 Subject: [6bone] Cisco, NAT-PT : establish connection from IPv6 to IPv4 Message-ID: <43A8949ABE91D346956F3E2DCD1E9B921F13EB@netsrv01.netline.lu> Hello, I'm testing NAT-PT on a 7200 Cisco router, and I would like to establish connection between the IPv6 and the IPv4 networks. I've mapped the IPv6 address of my PC, which is on an IPv6 only network, to an IPv4 address. So, my IPv6 PC is accessible by any IPv4 PC. If I ping it, I can see the encapsulation of the packet coming from the IPv4 PC, it's like PREFIX::IPv4_address_in_hexadecimal_form. The translation table of the router is updated. Then, the IPv6 PC can ping the IPv4 PC, because of this update. But now I want to ping another IPv4 PC, so I type : ping6 PREFIX::another_IPv4_address. The router receives IPv6 packets, but drop them (I saw this with debug ipv6 packet). On the url join below, it seems to be normal, because translation doesn't exists for the incoming packet. How can I process to access any IPv4 adress ? I must create a mapping ? It doesn't seem to be practical. Why from IPv6 to IPv4 isn't the IPv6 header (like PREFIX::IPv4_address) automatically translated to an IPv4 header, as it is done from IPv4 to IPv6 ? Thanks. This the url where I've found some informations : http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_data_she et09186a008011ff51.html ... 5 NAT-PT translations and Application Level Gateway 5.1 IP header translation 5.1.1 From IPv6 to IPv4 The Protocol Translator translates the IPv6 header to an IPv4 header under the following conditions: IPv6 packet is received with an IPv4-mapped IPv6 address (i.e. pre-configured /96 prefix) Translation exists for the incoming packet ... 5.1.2 From IPv4 to IPv6 When NAT-PT receives a packet addressed to a destination that lies outside of the attached IPv4 realm, the IPv4 header is translated to an IPv6 header. ... From joao.cabral@vodafone.com Thu Jun 5 17:17:41 2003 From: joao.cabral@vodafone.com (=?iso-8859-1?Q?Jo=E3o_Carlos_Neves_Cabral?=) Date: Thu, 5 Jun 2003 17:17:41 +0100 Subject: [6bone] Cisco, NAT-PT : establish connection from IPv6 to IPv 4 Message-ID: Hi, You configure an IPv4 pool for your IPv6 addresses to be translated into. You need one v4 address per NAT-PT session/V6 client (until overload is supported). Any traffic that you originate from your v6 client to a v4 address will reach its destination Nated. The problem is when the reply reaches the NAT-PT router. The router doesn't know which IPv6 address it should map the v4 reply source address into. AFAIK, there are two ways to overcome this: 1) MAP each individual v4 address you want to access, to a v6 address with v4v6 2) Force the use of DNS-ALG: On V6 client configure v6 DNS server with an v4 mapped address. I.E. V6 client <-> DNS is PREFIX::v4 <-NAT-PT-> V4 network <-> v4 DNS server And map statically with v6v4 the v4 DNS server address into a v6 address from the prefix. This will make the v6 DNS request reach the v4 DNS server after being nated. The v4 reply is then back nated into v6 because you configure static translation for this address. And becase the router sees the DNS request passing trough it, also intercepts it and: a) Opens a NAT mapping for the v4 address you queried b) Converts the v4 DNS reply into V6 AAAA format to send back to you And then you can access any v4 site as long as you use its DNS name and use the DNS-ALG scheme above. You could also try to use a V6 only DNS server (i.e. not require the v6v4 NAT DNS server) but I don't know if this will activate DNS-ALG. Perhaps it might do. This would be 3) i.e. DNS-ALG with a native DNS server. Aparently there's a 4) which is, if your first packet comes from the v4 world then the required maping is kept on the table as you describe in your email. AFAIK there isn't another way. If you discover one please let me know as I'd also be interested in knowing how to do it. It's a shame the router can't simply map any V4 packet sources to v6 sources on a given prefix but I suppose this would break all incoming v4 packets and hence, routing protocols, tunnels, 6PE or whatever you wanted to use there (v4 wise). Hope this helps, Regards, Joao. -----Original Message----- From: Jerome Wenzel [mailto:jwenzel@netline.lu] Sent: 05 June 2003 15:46 To: 6bone@mailman.isi.edu Subject: [6bone] Cisco, NAT-PT : establish connection from IPv6 to IPv4 Hello, I'm testing NAT-PT on a 7200 Cisco router, and I would like to establish connection between the IPv6 and the IPv4 networks. I've mapped the IPv6 address of my PC, which is on an IPv6 only network, to an IPv4 address. So, my IPv6 PC is accessible by any IPv4 PC. If I ping it, I can see the encapsulation of the packet coming from the IPv4 PC, it's like PREFIX::IPv4_address_in_hexadecimal_form. The translation table of the router is updated. Then, the IPv6 PC can ping the IPv4 PC, because of this update. But now I want to ping another IPv4 PC, so I type : ping6 PREFIX::another_IPv4_address. The router receives IPv6 packets, but drop them (I saw this with debug ipv6 packet). On the url join below, it seems to be normal, because translation doesn't exists for the incoming packet. How can I process to access any IPv4 adress ? I must create a mapping ? It doesn't seem to be practical. Why from IPv6 to IPv4 isn't the IPv6 header (like PREFIX::IPv4_address) automatically translated to an IPv4 header, as it is done from IPv4 to IPv6 ? Thanks. This the url where I've found some informations : http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_data_she et09186a008011ff51.html ... 5 NAT-PT translations and Application Level Gateway 5.1 IP header translation 5.1.1 From IPv6 to IPv4 The Protocol Translator translates the IPv6 header to an IPv4 header under the following conditions: IPv6 packet is received with an IPv4-mapped IPv6 address (i.e. pre-configured /96 prefix) Translation exists for the incoming packet ... 5.1.2 From IPv4 to IPv6 When NAT-PT receives a packet addressed to a destination that lies outside of the attached IPv4 realm, the IPv4 header is translated to an IPv6 header. ... _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone From nicolas.deffayet@ndsoftware.net Sun Jun 8 20:17:27 2003 From: nicolas.deffayet@ndsoftware.net (Nicolas DEFFAYET) Date: 08 Jun 2003 21:17:27 +0200 Subject: [6bone] AS1654/SICS announce 178 prefixes ! Message-ID: <1055099846.25189.58.camel@w1-2-aub.fr.corp.ndsoftware.com> Hello, AS1654/SICS announce 178 prefixes: cr1.par1.fr.ip.ndsoftware.net> sh ipv6 bgp regexp _1654_ BGP table version is 0, local router ID is 80.245.47.81 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 2001:210::/35 2001:748:200:a0::6 100 0 5430 13285 6939 6939 3320 9112 2847 1654 i *> 2001:7f8:2:c01d::2 100 0 1752 6830 3320 9112 2847 1654 i *> 2001:230::/32 2001:7f8:2:c01d::2 100 0 1752 6830 3320 9112 2847 1654 i * 2001:748:200:a0::6 100 0 5430 13285 6939 6939 3320 9112 2847 1654 i *> 2001:280::/32 2001:7f8:2:c01d::2 100 0 1752 6830 3320 9112 2847 1654 i * 2001:748:200:a0::6 100 0 5430 13285 6939 6939 3320 9112 2847 1654 i *> 2001:2d8::/32 2001:7f8:2:c01d::2 100 0 1752 6830 3320 9112 2847 1654 i * 2001:748:200:a0::6 100 0 5430 13285 6939 6939 3320 9112 2847 1654 i *> 2001:300::/32 2001:7f8:2:c01d::2 100 0 1752 6830 3320 9112 2847 1654 i * 2001:748:200:a0::6 100 0 5430 13285 6939 6939 3320 9112 2847 1654 i *> 2001:348::/32 2001:7f8:2:c01d::2 100 0 1752 6830 3320 9112 2847 1654 i * 2001:748:200:a0::6 100 0 5430 13285 6939 6939 3320 9112 2847 1654 i Total number of prefixes 178 cr1.par1.fr.ip.ndsoftware.net> aut-num: AS1654 as-name: SKOGEN descr: Skogen Network ipv6-site: SICS origin: AS1654 descr: Swedish Institute of Computer Science Kista, SWEDEN It's not the first time that AS1654 do some trouble in the world routing table... http://mailman.isi.edu/pipermail/6bone/2002-August/006027.html Note: Message resent with not the full BGP table because the message with the full BGP table is not accepted by the 6bone mailing-list (Message body is too big: 49897 bytes but there's a limit of 40 KB) -- Nicolas DEFFAYET, NDSoftware NDSoftware IP Network: http://www.ip.ndsoftware.net/ FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ EuroNOG: http://www.euronog.org/ From gert@space.net Sun Jun 8 22:11:34 2003 From: gert@space.net (Gert Doering) Date: Sun, 8 Jun 2003 23:11:34 +0200 Subject: [6bone] AS1654/SICS announce 178 prefixes ! In-Reply-To: <1055099846.25189.58.camel@w1-2-aub.fr.corp.ndsoftware.com>; from nicolas.deffayet@ndsoftware.net on Sun, Jun 08, 2003 at 09:17:27PM +0200 References: <1055099846.25189.58.camel@w1-2-aub.fr.corp.ndsoftware.com> Message-ID: <20030608231134.P67740@Space.Net> Hi, On Sun, Jun 08, 2003 at 09:17:27PM +0200, Nicolas DEFFAYET wrote: > Network Next Hop Metric LocPrf Weight Path > * 2001:210::/35 2001:748:200:a0::6 > 100 0 5430 13285 > 6939 6939 3320 9112 2847 1654 i Seconded, I see that as well - 1654 is originating half of the prefixes as their own. BGP bug or human goof... The interesting part is that 1654 does have a number of links, but these prefixes only go out via 2847 1654. Someone from 2847 around who can figure out what's happening and make it stop? Does anybody know the background of this? Any peers of 1654 around? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55295 (54837) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From lalle@sics.se Mon Jun 9 15:00:28 2003 From: lalle@sics.se (Lars Albertsson) Date: 09 Jun 2003 16:00:28 +0200 Subject: [6bone] AS1654/SICS announce 178 prefixes ! In-Reply-To: <20030608231134.P67740@Space.Net> References: <1055099846.25189.58.camel@w1-2-aub.fr.corp.ndsoftware.com> <20030608231134.P67740@Space.Net> Message-ID: Gert Doering writes: > Hi, > > On Sun, Jun 08, 2003 at 09:17:27PM +0200, Nicolas DEFFAYET wrote: > > Network Next Hop Metric LocPrf Weight Path > > * 2001:210::/35 2001:748:200:a0::6 > > 100 0 5430 13285 > > 6939 6939 3320 9112 2847 1654 i > > Seconded, I see that as well - 1654 is originating half of the prefixes > as their own. BGP bug or human goof... > > The interesting part is that 1654 does have a number of links, but these > prefixes only go out via 2847 1654. Someone from 2847 around who can > figure out what's happening and make it stop? > > Does anybody know the background of this? Any peers of 1654 around? I am sorry if we are causing problems again. I try to keep a very simple configuration in order to avoid routing problems, and I don't understand the cause for this. AS2847 (Litnet) is one of our delegations. We announce the full IPv6 routing table, including the prefixes mentioned by Nicolas, to our downstream sites, but prefixes other than ours are of course not meant to be announced with our AS as last hop, and I don't understand why they end up that way. And I expect the sites downstream from us not to announce prefixes outside their address space to other sites. I looked through our configuration files and bgpd log, and couldn't see anything suspicious. I restarted zebra and monitored the traffic to litnet's router with tcpdump, and it seems we are announcing correct AS paths to them: 15:22:38.755586 alt.sics.se > gw.ipv6.lt: alt-litnet.ipv6.sics.se.3895 > 3ffe:20 0:1:e::2.bgp: P 8029:8588(559) ack 29731 win 355: BGP [|BGP] (UPDATE: (Path attr ibutes: (ORIGIN[T] IGP) (AS_PATH[T] 1654 6342 2549) (MP_REACH_NLRI[O] IPv6 Unicast, nexthop alt-litnet.ipv6.sics.se, NLRI 2001:b18::/32))) (UPDATE: (Path attributes: (ORIGIN[T] IGP) (AS_PATH[T] 1654 3274 16023) (MP_REACH_NLRI[O] IPv6 Unicast, nexthop alt-litnet.ipv6.sics.se, NLRI 2001:b30::/32))) (UPDATE: (Path attributes: (ORIGIN[T] IGP) (AS_PATH[T] 1654 3274 790 6667) (MP_REACH_NLRI[O] IPv6 Unicast, nexthop alt-litnet.ipv6.sics.se, NLRI yggdrasil-gw.ipv6.sevenlevels.net/32))) (UPDATE: (Path attributes: (ORIGIN[T] IGP) (AS_PATH[T] 1654 6342 6435 13944 25396) (MP_REACH_NLRI[O] IPv6 Unicast, nexthop alt-litnet.ipv6.sics.se, NLRI 2001:b70::/32))) (UPDATE: (Path attributes: (ORIGIN[T] IGP) (AS_PATH[T] 1654 6342 2549 3320) (MP_REACH_NLRI[O] IPv6 Unicast, nexthop alt-litnet.ipv6.sics.se, NLRI 2001:bb8::/32))) (UPDATE: (Path attributes: (ORIGIN[T] IGP) (AS_PATH[T] 1654 6342) (MP_REACH_NLRI[O] IPv6 Unicast, nexthop alt-litnet.ipv6.sics.se, NLRI 2001:c00::/32))) (UPDATE: (Path attributes: (ORIGIN[T] IGP) (AS_PATH[T] 1654 6342 109) (MP_REACH_NLRI[O] IPv6 Unicast, nexthop alt-litnet.ipv6.sics.se, NLRI 2001:c08::/32))) [hlim 1] (len 579) (ttl 45, id 53505) I am clueless on what could be wrong, and where. If anyone has any ideas on something I can look for, feel free to speak up. If you want, you can also look at the state and configuration for our router at http://www.ipv6.sics.se/6bone_config/. The last Merit routing report (http://www.merit.edu/mail.archives/html/6bone-routing-report/msg00100.html) claims that weird prefixes from us are leaking through AS64734 as well. It is owned by VSH, which is one of our NLAs. I am therefore CC:ing their contact person. Regards, Lalle From lalle@sics.se Mon Jun 9 15:54:58 2003 From: lalle@sics.se (Lars Albertsson) Date: 09 Jun 2003 16:54:58 +0200 Subject: [6bone] AS1654/SICS announce 178 prefixes ! In-Reply-To: References: <1055099846.25189.58.camel@w1-2-aub.fr.corp.ndsoftware.com> <20030608231134.P67740@Space.Net> Message-ID: Lars Albertsson writes: > Gert Doering writes: > > > Hi, > > > > On Sun, Jun 08, 2003 at 09:17:27PM +0200, Nicolas DEFFAYET wrote: > > > Network Next Hop Metric LocPrf Weight Path > > > * 2001:210::/35 2001:748:200:a0::6 > > > 100 0 5430 13285 > > > 6939 6939 3320 9112 2847 1654 i > > > > Seconded, I see that as well - 1654 is originating half of the prefixes > > as their own. BGP bug or human goof... Some additional information: It seems that there is some confusion about the ownership of AS1654, and that we are not the only site announcing AS1654 for IPv6 routing. I don't know whether that has anything to do with the problems you saw or not. We are working on sorting out the ownership issue. /Lalle From bob@thefinks.com Tue Jun 10 14:52:30 2003 From: bob@thefinks.com (Bob Fink) Date: Tue, 10 Jun 2003 06:52:30 -0700 Subject: [6bone] Fwd: I-D ACTION:draft-fink-6bone-phaseout-03.txt Message-ID: <5.2.0.9.0.20030610065121.01cb09e0@mail.addr.com> 6bone Folk, I have corrected a typo in this version and having heard no other comments will now forward it for BCP processing. Bob === >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-fink-6bone-phaseout-03.txt >Date: Tue, 10 Jun 2003 07:50:44 -0400 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : 6bone (IPv6 Testing Address Allocation) Phaseout > Author(s) : R. Fink, R. Hinden > Filename : draft-fink-6bone-phaseout-03.txt > Pages : 6 > Date : 2003-6-9 > >The 6bone was established in 1996 by the IETF as an IPv6 Testbed >network to enable various IPv6 testing as well as to assist in the >transitioning of IPv6 into the Internet. It operates under the IPv6 >address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its >production deployment it is appropriate to plan for the phaseout of >the 6bone. This note establishes a plan for a multi-year phaseout of >the 6bone and its address allocation on the assumption that the IETF >is the appropriate place to determine this. >This document is intended to obsolete RFC 2471, 'IPv6 Testing Address >Allocation', December, 1998. RFC 2471 will become historic. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-fink-6bone-phaseout-03.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-fink-6bone-phaseout-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-fink-6bone-phaseout-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-6-9150801.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-fink-6bone-phaseout-03.txt > > From JORDI PALET MARTINEZ" Message-ID: <035c01c32f5a$df9b39c0$8700000a@consulintel.es> Agreed, thanks ! Regards, Jordi ----- Original Message ----- From: "Bob Fink" To: "6BONE List" <6bone@mailman.isi.edu> Sent: Tuesday, June 10, 2003 3:52 PM Subject: [6bone] Fwd: I-D ACTION:draft-fink-6bone-phaseout-03.txt > 6bone Folk, > > I have corrected a typo in this version and having heard no other comments > will now forward it for BCP processing. > > > Bob > > === > >To: IETF-Announce: ; > >From: Internet-Drafts@ietf.org > >Reply-to: Internet-Drafts@ietf.org > >Subject: I-D ACTION:draft-fink-6bone-phaseout-03.txt > >Date: Tue, 10 Jun 2003 07:50:44 -0400 > >Sender: owner-ietf-announce@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : 6bone (IPv6 Testing Address Allocation) Phaseout > > Author(s) : R. Fink, R. Hinden > > Filename : draft-fink-6bone-phaseout-03.txt > > Pages : 6 > > Date : 2003-6-9 > > > >The 6bone was established in 1996 by the IETF as an IPv6 Testbed > >network to enable various IPv6 testing as well as to assist in the > >transitioning of IPv6 into the Internet. It operates under the IPv6 > >address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its > >production deployment it is appropriate to plan for the phaseout of > >the 6bone. This note establishes a plan for a multi-year phaseout of > >the 6bone and its address allocation on the assumption that the IETF > >is the appropriate place to determine this. > >This document is intended to obsolete RFC 2471, 'IPv6 Testing Address > >Allocation', December, 1998. RFC 2471 will become historic. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-fink-6bone-phaseout-03.txt > > > >To remove yourself from the IETF Announcement list, send a message to > >ietf-announce-request with the word unsubscribe in the body of the message. > > > >Internet-Drafts are also available by anonymous FTP. Login with the username > >"anonymous" and a password of your e-mail address. After logging in, > >type "cd internet-drafts" and then > > "get draft-fink-6bone-phaseout-03.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-fink-6bone-phaseout-03.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > >Content-Type: text/plain > >Content-ID: <2003-6-9150801.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-fink-6bone-phaseout-03.txt > > > > > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From michel@arneill-py.sacramento.ca.us Wed Jun 11 03:42:46 2003 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 10 Jun 2003 19:42:46 -0700 Subject: [6bone] Fwd: I-D ACTION:draft-fink-6bone-phaseout-03.txt Message-ID: <963621801C6D3E4A9CF454A1972AE8F50671DB@server2000.arneill-py.sacramento.ca.us> > Bob Fink wrote: > 6bone Folk, > I have corrected a typo in this version and having heard no > other comments will now forward it for BCP processing. I'm all for it. Michel. From nakahara@mesh.ad.jp Wed Jun 11 05:41:12 2003 From: nakahara@mesh.ad.jp (Kazuhiko NAKAHARA) Date: Wed, 11 Jun 2003 13:41:12 +0900 (LMT) Subject: [6bone] 2001:260::/35 ghost route Message-ID: <20030611.134112.01366847.nakahara@ipv6.nec.co.jp> 6Bone Folk, We (BIGLOBE,Japanese ISP provided NEC, AS2518) have migrated from 2001:260::/35 to 2001:260::/32. We stopped announcement of 2001:260::/35 on Oct 22, 2002. However, junk routes are still floadting from Jun 10 (Maybe). On Jun 10, We got a report from ISP conneced japanese internet exchange(called NSPIXP6)that it is possible to hear via around 3257, 6762, 3263, 6939 and/or 4716. So, As temporary handing, We started announcement of 2001:260::/35 on Jun 10, 2003. (time is 20:37 JST) but still unstable. Now, We stopped announce of 2001:260::/35 again. So, could you check (1) if you see 2001:260::/35, filter them out. (2) if you see 2001:260::/35 from someone other than AS2518, please report to ix@mesh.ad.jp (3) if you are AS contact for the above ASes (3257, 6762, 3263, 6939, 4716) check if your router is behaving correctly. ----- Kazuhiko NAKAHARA BIGLOBE Design and Operations Div, NEC Corporation From jwenzel@netline.lu Wed Jun 11 14:24:33 2003 From: jwenzel@netline.lu (Jerome Wenzel) Date: Wed, 11 Jun 2003 15:24:33 +0200 Subject: [6bone] Cisco, NAT-PT : establish connection from IPv6 to IPv4 Message-ID: <43A8949ABE91D346956F3E2DCD1E9B921F13EC@netsrv01.netline.lu> Hello, First I would like to thanks Joao for his help. But now, I have a new problem when trying to map the DNS server, or any devices which is not in the directly connected network of the router. I apologize if I'm on the wrong mailing-list to ask for help, if somebody have good web sites or other information sources about Cisco and NAT-PT, these informations are welcome ! I don't gather a lot of useful tips on Cisco web site ... I want to access the IPv4 network and internet from the IPv6-only computer PC1, using the ip addresses, I'll try later with names. There are below the network scheme, an extract of the Cisco 7200 router configuration file, and the results of the tests (using ping) I performed. I think that the router block some traffic from PC1, I give further information below with the tests and results. NAT-PT is configured on the router, with static mappings. PC1's OS is Win 2k Pro SP1, it's configuration is done with : ipv6 adu 3/2002:1:1::2 ipv6 rtu 2002:1:1::/48 3 ipv6 rtu 2002:1:2::/96 3/2002:1:1::1 >From PC1, I can access the IPv4 network A.B.1.0/24, which is directly connected to the router, but I can't reach the other IPv4 addresses with nat translations, even with a static mapping configured (for example to the DNS server). The first question is, because I have a doubt : Can NAT-PT work in a such network topology ? If yes, I think it's a routing problem or a command missing on the router, but I don't find the matter. I check the rules on the firewall, it shouldn't block my traffic. Thanks. Jérôme ------------ |DNS Server| ------------ A.B.2.9 | | ----- -------- ----- ---------- ---------------- ----------------- |PC1|------- f0/0 |Router| f0/1 --|hub|-----|firewall|-----| IPV4 network |---| IPv4 Internet | ----- -------- ----- ---------- ---------------- ----------------- 2002:1:1::2 2002:1:1::1 A.B.1.2 | A.B.1.1 A.B.3.1 | | | ----- ----- |PC2| |PC3| ----- ----- A.B.1.3 A.B.4.5 Router#sh run Building configuration... ! hostname Router ! boot system flash c7200-js-mz.122-15.T1.bin ! ! ! interface FastEthernet0/0 no ip address duplex auto speed auto ipv6 address 2002:1:1::1/48 ipv6 nat ! interface FastEthernet0/1 ip address A.B.1.2 255.255.255.0 duplex auto speed auto ipv6 nat ! ip classless ip route 0.0.0.0 0.0.0.0 A.B.1.1 no ip http server ! ! ! ipv6 nat v4v6 source A.B.2.9 2002:1:2::A.B.2.9 ipv6 nat v4v6 source A.B.1.1 2002:1:2::A.B.1.1 ipv6 nat v6v4 source 2002:1:1::2 A.B.1.4 ipv6 nat prefix 2002:1:2::/96 ! On the router : ping ipv4 A.B.1.1 is successful ping ipv4 A.B.2.9 is successful On PC1 : ping ipv6 2002:1:2::A.B.1.1 is successful ping ipv6 2002:1:2::A.B.2.9 -> request timed out The command "debug ipv6 nat" on the router shows : IPv6 NAT: icmp src (2002:1:1::2) -> (A.B.1.4), dst (2002:1:2::A.B.2.9) -> (A.B.2.9) But there is no reply ... I use a frame analyser (Ethereal) on PC2, to see the outgoing traffic of the router : I only see broadcast ARP requests from the router : "who has A.B.2.9 ? Tell A.B.1.2" When I ping ipv4 A.B.2.9 from router or ping ipv6 2002:1:2::A.B.1.1 from PC1, I capture both request and reply ICMP packets with PC2. I've pinged PC1 from PC3, it udpates the ipv6 nat translation table, and with "debug ipv6 nat" I can see both requests and replies packets : IPv6 NAT: icmp src (A.B.4.5) -> (2002:1:2::A.B.4.5), dst (A.B.1.4) -> (2002:1:1::2) IPv6 NAT: icmp src (2002:1:1::2) -> (A.B.1.4), dst (2002:1:2::A.B.4.5) -> (A.B.4.5) Using Ethereal on PC1, I also see the ICMP requests and replies. So, PC1 is responding. When I capture frames with PC2, I see the ICMP requests from PC3 A.B.4.5 to PC1 A.B.1.4, but I don't see the ICMP replies, and I see broadcast ARP requests from the router : "who has A.B.4.5 ? Tell A.B.1.2" On the router, the command ping A.B.4.5 is successful. So, the packets from PC1 seemed to be lost in a black hole somewhere in the router ... With the command "show ip traffic", I've seen that each time I perform a command like ping ipv6 2002:1:2::A.B.2.9 on PC1 or ping A.B.1.4 on PC3, it increases the number X in the following counter : "Drop : X encapsulation failed ...". Encapsulation failed because the router doesn't know where to send the packet ? Or the router doesn't send the packet because encapsulation has failed for an unknown reason ? I sometimes wonder that in this case, the router doesn't use the defined "ip route 0.0.0.0 0.0.0.0 A.B.1.1", and so doesn't know where to send the packets. The commands "show ipv6 nat" and "show ip packet" displays this : Ping PC3 from PC1 : 03:09:36: IPv6 NAT: icmp src (2002:1:1::2) -> (A.B.1.4), dst (2002:1:2::A.B.4.5) -> (A.B.4.5) 03:09:37: IP: s=A.B.1.4 (local), d=A.B.4.5 (FastEthernet0/1), len 60, sending 03:09:37: IP: s=A.B.1.4 (local), d=A.B.4.5 (FastEthernet0/1), len 60, encapsulation failed Ping PC2 from PC1 : 03:10:31: IPv6 NAT: icmp src (A.B.1.3) -> (2002:1:2::A.B.1.3), dst (A.B.1.4) -> (2002:1:1::2) 03:10:32: IP: s=A.B.1.4 (local), d=A.B.1.3 (FastEthernet0/1), len 60, sending Ping PC3 from router : 03:15:09: IP: s=A.B.4.5 (FastEthernet0/1), d=A.B.1.2 (FastEthernet0/1), len 100, rcvd 3 03:15:09: IP: s=A.B.1.2 (local), d=A.B.4.5 (FastEthernet0/1), len 100, sending From bob@thefinks.com Wed Jun 11 15:16:33 2003 From: bob@thefinks.com (Bob Fink) Date: Wed, 11 Jun 2003 07:16:33 -0700 Subject: [6bone] 6bone pTLA 3FFE:4018::/32 allocated to CBR-TPSA Message-ID: <5.2.0.9.0.20030611071221.02b06150@mail.addr.com> CBR-TPSA has been allocated pTLA 3FFE:4019::/32 having finished its review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration in e.f.f.3.ip6.int for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to hostmaster@ep.net.] [Note: The effort to startup e.f.f.3.ip6.arpa is well underway with the draft http://www.ietf.org/internet-drafts/draft-ymbk-6bone-arpa-delegation-01.txt now approved by the IETF/IESG as a BCP RFC. We are in the process of getting IANA to do the actual delegation to the 6bone ip6.arpa servers. There will be an announcement of progress soon.] Thanks, Bob From bob@thefinks.com Fri Jun 13 14:44:10 2003 From: bob@thefinks.com (Bob Fink) Date: Fri, 13 Jun 2003 06:44:10 -0700 Subject: [6bone] Fwd: I-D ACTION:draft-fink-6bone-phaseout-04.txt Message-ID: <5.2.0.9.0.20030613063214.00b729c0@mail.addr.com> 6bone Folk, I have submitted the 6bone-phaseout plan to the IESG for BCP RFC processing. It will have a 4 week review on the IETF list, I believe. When Randy Bush and Erik Nordmark looked it over they had me change it back to Informational RFC, and suggested that I change the wording in section 2: " Thus after the 6bone phaseout date June 6, 2006, it is REQUIRED that no 6bone 3FFE prefixes, of any size/length, be used on the Internet in any form. " as the IETF cannot place such requirements on use. So I changed it to: " Thus after the 6bone phaseout date June 6, 2006, it is the intent that no 6bone 3FFE prefixes, of any size/length, be used on the Internet in any form. Network operators may filter 3FFE prefixes on their borders to ensure these prefixes are not misused. " this new version, which will be the one circulated to the IETF, is at: Also, I will be on vacation from today until 30 June so will not be able to reply to any email until 1 July, Thanks, Bob From rain@bluecherry.net Sat Jun 14 23:25:12 2003 From: rain@bluecherry.net (Ben Winslow) Date: 14 Jun 2003 18:25:12 -0400 Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? Message-ID: <1055629512.16678.12.camel@portal.home> --=-5smdX4aIhoOlnxFObmVJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I was wondering if I was the only person seeing this (I don't think that's the case), or if it's a known problem, or whatever. I'm also guessing the maintainers of the nameservers in question read the 6bone list, but I'm CCing the addresses on the SOA records for each. y.ip6.int and munnari.oz.au both seem to be returning SERVFAIL for reverse DNS queries under e.f.f.3.ip6.int: ip6.int. 86400 IN NS y.ip6.int. ip6.int. 86400 IN NS z.ip6.int. ip6.int. 86400 IN NS ns3.nic.fr. ip6.int. 86400 IN NS flag.ep.net. ip6.int. 86400 IN NS imag.imag.fr. ip6.int. 86400 IN NS munnari.oz.au. ;; Received 353 bytes from 137.39.1.3#53(NS.UU.NET) in 81 ms ; <<>> DiG 9.2.2 <<>> 9.2.e.f.f.3.ip6.int any @y.ip6.int ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21949 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;9.2.e.f.f.3.ip6.int. IN ANY ;; Query time: 388 msec ;; SERVER: 3ffe:50e::1#53(y.ip6.int) ;; WHEN: Sat Jun 14 18:16:20 2003 ;; MSG SIZE rcvd: 37 ; <<>> DiG 9.2.2 <<>> 9.2.e.f.f.3.ip6.int any @munnari.oz.au ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 289 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;9.2.e.f.f.3.ip6.int. IN ANY ;; Query time: 768 msec ;; SERVER: 2001:388:c02:4000::1:21#53(munnari.oz.au) ;; WHEN: Sat Jun 14 18:21:48 2003 ;; MSG SIZE rcvd: 37 (munnari also SERVFAILs over ipv4, y has no ipv4 address) --=20 Ben Winslow --=-5smdX4aIhoOlnxFObmVJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Fingerprint: 17F8 0D02 A7DA 7C7F A661 183D 6E2A 04FD 410A 2DCF iQIVAwUAPuugx24qBP1BCi3PAQLEhBAAlyHIvnUiPV1pZVPSWz/QWb6CgfC5dE4Z 0wF5KFB5KRN3062YjLR0QWzc/EuL4OT0ar+dYhojFsm3mKs3m1cyZ9Swj1BSX+5Q BqB4yetLB4x94/ICZpjqR0VMdM3rJs94EUAKMaLGQHFy24NkxjDnTrCH6wlRV8YM KbAaNtB81iGJk3AnHBfK3BXnc4rULtZcmAge4WuulcOkTqSJAAl/fqAMseeRpFAP 9iKRN4an4Vx3wiRay1LvPEIcWGYQmXIvf75LvVsQDO3FOX8PHY4dXBlLEK/6IGcY lC0DNies6WJibJ55dIiqJGXktT14c163rRDV9rMw8ZMEx0Jpo/4oHygYSX2GruJD Gv+tlD5h4URKpDFFCdBIQW4dofZHc30d2zEKG0gJuM/eZITUulo0iVrSV+oHAnjJ ZAzoCPBM7AluxB7SsPExL+znXe8zN3JFtGHSSmQlbgtLpbEcjoiqtmjwgwZMp3Vg iI+xfV5odyWhGx2+bfSZ24gKQeJ1O2tMpCvQ/jbrcOTDmKmwHg+lCbGFbJRe5/xK Mv/MHCP3+PGPSi6w9yHHdq1AGTjZ8a1ho9HTZxfeH2B79+20QZ0aY3XUQ3DhNQtq norBLSa0cgtiHmP6sFkmNLl+AEuMOpykS9/qklAsCuHpCkyp1zl88dyXq2C2JRSZ xefti6TPi4w= =dkl0 -----END PGP SIGNATURE----- --=-5smdX4aIhoOlnxFObmVJ-- From md@Linux.IT Sun Jun 15 03:11:01 2003 From: md@Linux.IT (Marco d'Itri) Date: Sun, 15 Jun 2003 04:11:01 +0200 Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? In-Reply-To: <1055629512.16678.12.camel@portal.home> References: <1055629512.16678.12.camel@portal.home> Message-ID: <20030615021101.GA8735@wonderland.linux.it> --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jun 15, Ben Winslow wrote: >I was wondering if I was the only person seeing this (I don't think >that's the case), or if it's a known problem, or whatever. I'm also I think munnari has been lame for ip6.int most of the time, you can find old threads about this in the archive (but I cannot remember any good explanation of this situation). Y used to work some weeks ago, IIRC. BTW, this is even nicer: dig +norec 8.1.4.1.1.0.0.2.ip6.int ns @z.ip6.int --=20 ciao, | Marco | [1521 suqKOOW.dH4lI] --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+69W1FGfw2OHuP7ERAkwYAJ9x0HUb1TeGsmBTlJVOBaPm4vmwcwCdFgAx k2ILZvnsdvJeLkIF7zhNuyc= =twBt -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From kre@munnari.OZ.AU Sun Jun 15 12:44:12 2003 From: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 15 Jun 2003 18:44:12 +0700 Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? In-Reply-To: <20030615021101.GA8735@wonderland.linux.it> References: <20030615021101.GA8735@wonderland.linux.it> <1055629512.16678.12.camel@portal.home> Message-ID: <19908.1055677452@munnari.OZ.AU> Date: Sun, 15 Jun 2003 04:11:01 +0200 From: "Marco d'Itri" Message-ID: <20030615021101.GA8735@wonderland.linux.it> | I think munnari has been lame for ip6.int most of the time, you can find | old threads about this in the archive (but I cannot remember any good | explanation of this situation). Munnari was lame for this some time ago (some drongo went and changed things and didn't bother to tell me about it so munnari could be updated). That was fixed (eventually). But now I see it has gone lame again... I will see if I can work out what changed this time, and get it fixed again. One would expect that people running primary servers for upper level domains would have some kind of a clue as to how to go about it. kre From pim@ipng.nl Sun Jun 15 16:09:14 2003 From: pim@ipng.nl (Pim van Pelt) Date: Sun, 15 Jun 2003 17:09:14 +0200 Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? In-Reply-To: <19908.1055677452@munnari.OZ.AU> References: <20030615021101.GA8735@wonderland.linux.it> <1055629512.16678.12.camel@portal.home> <19908.1055677452@munnari.OZ.AU> Message-ID: <20030615150914.GA14123@bfib.colo.bit.nl> Hi Kre, | One would expect that people running primary servers for upper level | domains would have some kind of a clue as to how to go about it. Question: are these the same servers supposed to be running the ip6.arpa tree ? It was often said that it should be the same set of servers "because that would be the technically sound solution" but I've seen far too many problems with the current set. Servers joining and being dropped, servers forgetting to load zones, otherwise becoming lame for a delegation. Can we have any assurance that: a. admins will be responsible b. admins will be responsive c. delegations will remain in place d. servers will remain reachable, also with IPv6 ? Thanks. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From kre@munnari.OZ.AU Sun Jun 15 16:52:24 2003 From: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 15 Jun 2003 22:52:24 +0700 Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? In-Reply-To: <20030615150914.GA14123@bfib.colo.bit.nl> References: <20030615150914.GA14123@bfib.colo.bit.nl> <20030615021101.GA8735@wonderland.linux.it> <1055629512.16678.12.camel@portal.home> <19908.1055677452@munnari.OZ.AU> Message-ID: <11707.1055692344@munnari.OZ.AU> Date: Sun, 15 Jun 2003 17:09:14 +0200 From: Pim van Pelt Message-ID: <20030615150914.GA14123@bfib.colo.bit.nl> | Question: are these the same servers supposed to be running the ip6.arpa | tree ? I don't know for sure, but I think not. No-one has asked me about munnari being one of the servers, and the set to which ip6.arpa is currently delegated looks more like the normal "standard registry" set. Which is as you'd expect really. | It was often said that it should be the same set of servers "because | that would be the technically sound solution" By whom? It actually makes almost no difference at all (might potentially mean that one registration could cause entries in both domains) but that's about it. kre From bmanning@ISI.EDU Mon Jun 16 17:19:59 2003 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 16 Jun 2003 09:19:59 -0700 (PDT) Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? In-Reply-To: <20030615021101.GA8735@wonderland.linux.it> from Marco d'Itri at "Jun 15, 3 04:11:01 am" Message-ID: <200306161619.h5GGJxE00344@boreas.isi.edu> % On Jun 15, Ben Winslow wrote: % % >I was wondering if I was the only person seeing this (I don't think % >that's the case), or if it's a known problem, or whatever. I'm also % I think munnari has been lame for ip6.int most of the time, you can find % old threads about this in the archive (but I cannot remember any good % explanation of this situation). % Y used to work some weeks ago, IIRC. % % % BTW, this is even nicer: % dig +norec 8.1.4.1.1.0.0.2.ip6.int ns @z.ip6.int % % -- % ciao, | % Marco | [1521 suqKOOW.dH4lI] first off, several of these systems are IPv6 -ONLY- and there is the interesting issue of route propogation... :( that said: $ dig +norec 8.1.4.1.1.0.0.2.ip6.int ns @z.ip6.int ; <<>> DiG 9.3.0s20021217 <<>> +norec 8.1.4.1.1.0.0.2.ip6.int ns @z.ip6.int ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58647 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;8.1.4.1.1.0.0.2.ip6.int. IN NS ;; AUTHORITY SECTION: 4.1.1.0.0.2.ip6.int. 86400 IN NS noserver. ;; Query time: 0 msec ;; SERVER: 3ffe:0:1::c620:242#53(z.ip6.int) ;; WHEN: Mon Jun 16 09:18:05 2003 ;; MSG SIZE rcvd: 63 .... so, whats the big problem here? other than they were given a delegation and never registered their nameserverss? --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From bmanning@ISI.EDU Mon Jun 16 17:25:17 2003 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 16 Jun 2003 09:25:17 -0700 (PDT) Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? In-Reply-To: <20030615150914.GA14123@bfib.colo.bit.nl> from Pim van Pelt at "Jun 15, 3 05:09:14 pm" Message-ID: <200306161625.h5GGPHA04338@boreas.isi.edu> % Hi Kre, % % | One would expect that people running primary servers for upper level % | domains would have some kind of a clue as to how to go about it. % Question: are these the same servers supposed to be running the ip6.arpa % tree ? % % It was often said that it should be the same set of servers "because % that would be the technically sound solution" but I've seen far too % many problems with the current set. Servers joining and being dropped, % servers forgetting to load zones, otherwise becoming lame for a % delegation. % % Can we have any assurance that: % a. admins will be responsible % b. admins will be responsive % c. delegations will remain in place % d. servers will remain reachable, also with IPv6 ? yes. can we have any assurance that: a. routes to these servers will be propgated by ISPs b. the ietf will quit changing the DNS anchor point c. cooperation so that the delegations in one anchor are reflected in the other anchor. d. admins will populate both trees for the next 10 years, about as long as it will take to flush out the resolver code that has been shipping since 1997. % % Thanks. % -- % ---------- - - - - -+- - - - - ---------- % Pim van Pelt Email: pim@ipng.nl % http://www.ipng.nl/ IPv6 Deployment % ----------------------------------------------- % _______________________________________________ % 6bone mailing list % 6bone@mailman.isi.edu % http://mailman.isi.edu/mailman/listinfo/6bone % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From md@Linux.IT Mon Jun 16 18:23:57 2003 From: md@Linux.IT (Marco d'Itri) Date: Mon, 16 Jun 2003 19:23:57 +0200 Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? In-Reply-To: <200306161619.h5GGJxE00344@boreas.isi.edu> References: <20030615021101.GA8735@wonderland.linux.it> <200306161619.h5GGJxE00344@boreas.isi.edu> Message-ID: <20030616172356.GA1521@wonderland.linux.it> On Jun 16, Bill Manning wrote: > first off, several of these systems are IPv6 -ONLY- > and there is the interesting issue of route propogation... :( I know this and I punched appropriate holes in my filter, so at least for me this is not relevant: I can ping them, but Y still replies with SERVFAIL to queries for "ip6.int NS" or even "e.f.f.3.ip6.int NS". >;; AUTHORITY SECTION: >4.1.1.0.0.2.ip6.int. 86400 IN NS noserver. >.... so, whats the big problem here? other than they were given >a delegation and never registered their nameserverss? I'm not sure who is to blame here, but RIPE happily delegated me 8.1.4.1.1.0.0.2.ip6.int without actually having the parent zone delegated to them. I opened a ticket, but the hostmaster did not really look familiar with DNS issues and I am still waiting. (I suppose that the lame delegation is to stop the flood of queries, but why force other servers to hit the root for "noserver."?) -- ciao, | Marco | [1556 paqmiQP4pzWBA] From andrei@ripe.net Thu Jun 19 08:16:30 2003 From: andrei@ripe.net (Andrei Robachevsky) Date: Thu, 19 Jun 2003 09:16:30 +0200 Subject: [6bone] y.ip6.int, munnari.oz.au broken (ip6.int)? References: <20030615021101.GA8735@wonderland.linux.it> <200306161619.h5GGJxE00344@boreas.isi.edu> <20030616172356.GA1521@wonderland.linux.it> Message-ID: <3EF1634E.5030100@ripe.net> Dear Marco, Marco d'Itri wrote: > On Jun 16, Bill Manning wrote: > > > first off, several of these systems are IPv6 -ONLY- > > and there is the interesting issue of route propogation... :( > I know this and I punched appropriate holes in my filter, so at least > for me this is not relevant: I can ping them, but Y still replies with > SERVFAIL to queries for "ip6.int NS" or even "e.f.f.3.ip6.int NS". > > >;; AUTHORITY SECTION: > >4.1.1.0.0.2.ip6.int. 86400 IN NS noserver. > > >.... so, whats the big problem here? other than they were given > >a delegation and never registered their nameserverss? > I'm not sure who is to blame here, but RIPE happily delegated me > 8.1.4.1.1.0.0.2.ip6.int without actually having the parent zone > delegated to them. I opened a ticket, but the hostmaster did not really > look familiar with DNS issues and I am still waiting. The delegation path is now restored. The problem was caused by a slight miscommunication between ours and the parent zone's administrators. Sorry for the delay. > > (I suppose that the lame delegation is to stop the flood of queries, but > why force other servers to hit the root for "noserver."?) > Regards, Andrei Robachevsky CTO, RIPE NCC From gert@space.net Fri Jun 27 15:04:08 2003 From: gert@space.net (Gert Doering) Date: Fri, 27 Jun 2003 16:04:08 +0200 Subject: [6bone] AS1654/SICS announce 178 prefixes ! In-Reply-To: ; from lalle@sics.se on Mon, Jun 09, 2003 at 04:54:58PM +0200 References: <1055099846.25189.58.camel@w1-2-aub.fr.corp.ndsoftware.com> <20030608231134.P67740@Space.Net> Message-ID: <20030627160408.X67740@Space.Net> Hi, On Mon, Jun 09, 2003 at 04:54:58PM +0200, Lars Albertsson wrote: > > > Seconded, I see that as well - 1654 is originating half of the prefixes > > > as their own. BGP bug or human goof... > > Some additional information: It seems that there is some confusion > about the ownership of AS1654, and that we are not the only site > announcing AS1654 for IPv6 routing. I don't know whether that has > anything to do with the problems you saw or not. We are working on > sorting out the ownership issue. To followup on this (because I'm curious) - has this been sorted out? Two different organizations using the same AS number for routing doesn't sound very healthy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Daniel Austin" <20030608231134.P67740@Space.Net> <20030627160408.X67740@Space.Net> Message-ID: <038501c33cba$d2b97920$1700a8c0@dancompaq> Hi Gert, SICS are now using a new AS number - we recently re-peered with their new AS (AS29155). With Thanks, Daniel Austin, Managing Director, Kewlio.net Limited. ----- Original Message ----- From: "Gert Doering" To: "Lars Albertsson" Cc: "Gert Doering" ; "Nicolas DEFFAYET" ; <6bone@mailman.isi.edu>; "Raimundas Tuminauskas" ; "Linas Gudonavicius" ; "Markus Paluschek" ; Sent: Friday, June 27, 2003 3:04 PM Subject: Re: [6bone] AS1654/SICS announce 178 prefixes ! > Hi, > > On Mon, Jun 09, 2003 at 04:54:58PM +0200, Lars Albertsson wrote: > > > > Seconded, I see that as well - 1654 is originating half of the prefixes > > > > as their own. BGP bug or human goof... > > > > Some additional information: It seems that there is some confusion > > about the ownership of AS1654, and that we are not the only site > > announcing AS1654 for IPv6 routing. I don't know whether that has > > anything to do with the problems you saw or not. We are working on > > sorting out the ownership issue. > > To followup on this (because I'm curious) - has this been sorted out? Two > different organizations using the same AS number for routing doesn't > sound very healthy. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 55442 (55636) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From bmanning@ISI.EDU Sat Jun 28 20:53:13 2003 From: bmanning@ISI.EDU (Bill Manning) Date: Sat, 28 Jun 2003 12:53:13 -0700 (PDT) Subject: [6bone] Re: FYI: Notification of 6BONE Database changes (fwd) Message-ID: <200306281953.h5SJrDg00820@boreas.isi.edu> the hijackers are now active w/ IPv6. it must be viable :) ----- Forwarded message from Bill Manning ----- >From bmanning@ISI.EDU Sat Jun 28 12:52:05 2003 From: Bill Manning Message-Id: <200306281951.h5SJpxk00098@boreas.isi.edu> Subject: Re: FYI: Notification of 6BONE Database changes In-Reply-To: <200306281648.h5SGm3T3026728@mail1.nokia.net> from 6BONE Database Notifications at "Jun 28, 3 09:48:03 am" To: auto-dbm-mgr@whois.6bone.net Date: Sat, 28 Jun 2003 12:51:58 -0700 (PDT) Cc: bmanning@ISI.EDU X-Mailer: ELM [version 2.4ME+ PL39 (25)] X-AntiVirus: scanned by AMaViS 0.2.1 this is a hijacking attempt. % Dear Colleague, % % This is to notify you that some object(s) in the 6BONE database % which you either maintain or are listed as to-be-notified have % been added, deleted or changed. % % The objects below are the old and new entries for these objects % in the database. In case of DELETIONS, the deleted object is % displayed. NOOPs are not reported. % % The update causing these changes came from the following host: % % - From-Host: jazz.viagenie.qc.ca(206.123.31.2) % - Date: 20030628 % - Time: 09:48:02 % % 6BONE Registry Notification Department % % --- % PREVIOUS OBJECT: % % inet6num: 3FFE::/24 % netname: ROOT66 % descr: pTLA for DNS root servers % country: US % admin-c: BM2-6BONE % tech-c: BM2-6BONE % remarks: This object is automatically converted from the RIPE181 registry % mnt-by: MNT-ISI-LAP % changed: bmanning@isi.edu 20000203 % changed: auto-dbm@whois.6bone.net 20010117 % source: 6BONE % % REPLACED BY: % % inet6num: 3FFE::/24 % netname: ONLINE % descr: IPv6 Network of online.org.ua % country: UA % admin-c: EAG-6BONE % tech-c: EAG-6BONE % notify: admin@online.org.ua % mnt-by: ONLINE-MNT % changed: admin@online.org.ua 20030628 % source: 6BONE % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ----- End of forwarded message from Bill Manning ----- -- "When in doubt, Twirl..." -anon From cfaber@fpsn.net Sun Jun 29 09:10:36 2003 From: cfaber@fpsn.net (Colin Faber) Date: Sun, 29 Jun 2003 02:10:36 -0600 Subject: [6bone] Re: FYI: Notification of 6BONE Database changes (fwd) In-Reply-To: <200306281953.h5SJrDg00820@boreas.isi.edu> References: <200306281953.h5SJrDg00820@boreas.isi.edu> Message-ID: <3EFE9EFC.5050204@fpsn.net> I guess I can look forward to my first IPv6 spam here pretty soon. Bill Manning wrote: > the hijackers are now active w/ IPv6. it must be viable :) > > > > > ----- Forwarded message from Bill Manning ----- > >>From bmanning@ISI.EDU Sat Jun 28 12:52:05 2003 > From: Bill Manning > Message-Id: <200306281951.h5SJpxk00098@boreas.isi.edu> > Subject: Re: FYI: Notification of 6BONE Database changes > In-Reply-To: <200306281648.h5SGm3T3026728@mail1.nokia.net> from 6BONE Database Notifications at "Jun 28, 3 09:48:03 am" > To: auto-dbm-mgr@whois.6bone.net > Date: Sat, 28 Jun 2003 12:51:58 -0700 (PDT) > Cc: bmanning@ISI.EDU > X-Mailer: ELM [version 2.4ME+ PL39 (25)] > X-AntiVirus: scanned by AMaViS 0.2.1 > > this is a hijacking attempt. > > > % Dear Colleague, > % > % This is to notify you that some object(s) in the 6BONE database > % which you either maintain or are listed as to-be-notified have > % been added, deleted or changed. > % > % The objects below are the old and new entries for these objects > % in the database. In case of DELETIONS, the deleted object is > % displayed. NOOPs are not reported. > % > % The update causing these changes came from the following host: > % > % - From-Host: jazz.viagenie.qc.ca(206.123.31.2) > % - Date: 20030628 > % - Time: 09:48:02 > % > % 6BONE Registry Notification Department > % > % --- > % PREVIOUS OBJECT: > % > % inet6num: 3FFE::/24 > % netname: ROOT66 > % descr: pTLA for DNS root servers > % country: US > % admin-c: BM2-6BONE > % tech-c: BM2-6BONE > % remarks: This object is automatically converted from the RIPE181 registry > % mnt-by: MNT-ISI-LAP > % changed: bmanning@isi.edu 20000203 > % changed: auto-dbm@whois.6bone.net 20010117 > % source: 6BONE > % > % REPLACED BY: > % > % inet6num: 3FFE::/24 > % netname: ONLINE > % descr: IPv6 Network of online.org.ua > % country: UA > % admin-c: EAG-6BONE > % tech-c: EAG-6BONE > % notify: admin@online.org.ua > % mnt-by: ONLINE-MNT > % changed: admin@online.org.ua 20030628 > % source: 6BONE > % > > -- Colin Faber (303) 859-1491 fpsn.net, Inc. * Black holes are where God divided by zero. * From jeroen@unfix.org Sun Jun 29 16:52:11 2003 From: jeroen@unfix.org (Jeroen Massar) Date: Sun, 29 Jun 2003 17:52:11 +0200 Subject: [6bone] Re: FYI: Notification of 6BONE Database changes (fwd) In-Reply-To: <200306281953.h5SJrDg00820@boreas.isi.edu> Message-ID: <001b01c33e56$6b2d0d10$210d640a@unfix.org> Bill Manning wrote: > the hijackers are now active w/ IPv6. it must be viable :) That the 6bone registry doesn't have any mnt-lower mechanism is the biggest problem. The second problem is that most person objects don't have a maintainer field, thus can be played around at will. One could attempt to clean the database from 'odd' entries, but because of the simple point that there is no mnt-lower one can't protect against this and it will be dirt all over again in a few moments time. Registering multiple person objects and not throwing out the bad ones is also one thing that can be seen quite easily in the 6bone db. If one really wants to 'hijack' some space, just announce it in BGP, nearly all 'transits' (if you can call them that) will happily announce anything you push into them. This is not hijacking, it's just simple mere usage. If it was RIPE/APNIC/ARIN db's that where toyed with then it would have been hijacking... but they fortunatly have mnt-lowers ;) But apparently the 6bone db doesn't check for maintainer attributes, so that would be futile then. We have to be glad that the notify attribute works. > % - From-Host: jazz.viagenie.qc.ca(206.123.31.2) > % - Date: 20030628 > % - Time: 09:48:02 Shouldn't From-Host include the original source address. As this probably just is the Viagenie webinterface but which host really triggered this registration? Also why doesn't jazz communicate in IPv6 ? :) Maybe the webinterface could quite easily prevent the hijacking behaviour by checking for existing objects? And ofcourse check the maintainer attribute. Greets, Jeroen From Marcin Markowski Mon Jun 30 02:14:50 2003 From: Marcin Markowski (Marcin Markowski) Date: Mon, 30 Jun 2003 03:14:50 +0200 Subject: [6bone] Strange problem with BGP Message-ID: <12696084522.20030630031450@chabrowa.net> Hi, Few days ago our server was DDoSed and when DDoS attack was stoped, some peers can't connect... they have idle state. I tried to clean bgp, restarted bgpd but this doesn't work... anyone know something about this? In logs have one error, but i don't know why :( Other peers works fine 2003/06/30 03:07:21 BGP: [Event] BGP connection from host 3ffe:400c:feed::6 2003/06/30 03:07:21 BGP: [Event] BGP connection IP address 3ffe:400c:feed::6 is Idle state 2003/06/30 03:08:05 BGP: 3ffe:400c:feed::6 [Event] Connect start to 3ffe:400c:feed::6 fd 12 2003/06/30 03:08:05 BGP: 3ffe:400c:feed::6 [Error] bgp_read_packet error: Connection reset by peer I'm using zebra-pj 0.94 -- Marcin Markowski mail: max@chabrowa.net From lalle@sics.se Mon Jun 30 13:21:03 2003 From: lalle@sics.se (Lars Albertsson) Date: 30 Jun 2003 14:21:03 +0200 Subject: [6bone] AS1654/SICS announce 178 prefixes ! In-Reply-To: <20030627160408.X67740@Space.Net> References: <1055099846.25189.58.camel@w1-2-aub.fr.corp.ndsoftware.com> <20030608231134.P67740@Space.Net> <20030627160408.X67740@Space.Net> Message-ID: Gert Doering writes: > Hi, > > On Mon, Jun 09, 2003 at 04:54:58PM +0200, Lars Albertsson wrote: > > > > Seconded, I see that as well - 1654 is originating half of the prefixes > > > > as their own. BGP bug or human goof... > > > > Some additional information: It seems that there is some confusion > > about the ownership of AS1654, and that we are not the only site > > announcing AS1654 for IPv6 routing. I don't know whether that has > > anything to do with the problems you saw or not. We are working on > > sorting out the ownership issue. > > To followup on this (because I'm curious) - has this been sorted out? Two > different organizations using the same AS number for routing doesn't > sound very healthy. This is now sorted out. I shut down our router a few days after the issue was brought to my attention, and we are now peering with a new AS number. I guess the AS number conflict caused the problem. I also upgraded zebra from 0.93a to 0.93b, in case the cause was there. Thanks for notifying us of the problem. /Lalle