- ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] Glueing to the "."...
by Carlos Friacas 04 May '05

04 May '05

Hi, As far as i know, the possibility of having AAAA glue records on the root zone was a long and hard quest... Now that we have it for some time, is it important to ask what is being done with this possibility??? Well, i do think YES... and by reading the DNS root zone what i can see is: - 42 ccTLDs glued - 4 gTLDs glued (.com, .int, .aeros, .net) - only 35 different servers/names with AAAAs on the root zone (NS0.JA.NET has 2!) - most of the TLDs supported by nameservers with AAAAs has only one or two. Should we expect an improvement in these numbers soon? :-) Comments...? ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (150665/657), naming (millions) and... people!"

1 0

[ipv6-wg@ripe.net] Agenda for ipv6 wg RIPE50
by David Kessens 03 May '05

03 May '05

Please see below for the ipv6 working group agenda. David Kessens --- Interesting topics (from an ipv6 perspective) in the presentation sections: Monday, 2 May 2005 14:00-15:30 * Quality of Service Measurement in IPv6, Issues and Solutions (Alessandro Bassi, Hitachi) * How to set an Internet2 Land Speed Record (Anders Magnusson, Lulea Tekniska Universiteit) Tuesday, 3 May 2005 16:00-17:30 * Global IPv6 routing table status (Gert Doering) --- Agenda for the IPv6 Working Group Meeting RIPE50 When: Friday, 6 May 2005, 09:00 - 10:30 Where: C58, Clarion Hotel, Stockholm, SE A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. Discussion on: Global IPv6 routing table status (Gert Doering) D. Revisiting the /48 recommendation (Gert Doering, Thomas Narten, David Kessens) Discussion, read rfc3177 as preparation E. Renumbering ipv6 networks (Stig Venaas, Tim Chown) F. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) G. Developments/initiatives regarding IPv6 in the RIPE region and beyond - IPv6 - Advanced Network Developments's first year (Carlos Friacas) - 9K IPv6 Schools' Network Initiative (Carlos Friacas) - About the IPv6 Steering Commitee: (Carlos Friacas) - Point6 (http://www.point6.net/) (Francis Dupont) - New Operational IPv6 maillist: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ (Gert Doering) - ... H. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

4 4

[ipv6-wg@ripe.net] Call for agenda items & Draft Agenda (v1) for ipv6 wg RIPE50
by David Kessens 26 Apr '05

26 Apr '05

Please see below for a draft (v1) of the ipv6 working group agenda. I am interested in your input for agenda items: whether you want to discuss a particular topic, or do a presentation that affects ipv6 deployment in the RIPE region (and beyond), everything *technical* is welcome. As you might have noticed, the meeting format of the RIPE meeting was changed. The intention is to do most of the presentations in the EOF part of the meeting while the practical working group work is done in the actual working group. As of this writing, I have not received final details on how this will work out exactly. At first, I planned to wait with my solicitation for agenda items until the details regarding this new approach were more clear and announced to the community. However, as the actual date of the meeting is getting closer, I have decided not to wait any longer. I hope this helps and see you all in Stockholm, David Kessens --- Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE50 When: ?, May 2005 Where: ?, Clarion Hotel, Stockholm, SE [ Presentation section ] A. Global IPv6 routing table status (Gert Doering) [ Working group section ] B. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) C. Quick update from the RIPE NCC regarding ipv6 services (tentative) D. Discussion on: Global IPv6 routing table status (Gert Doering) E. Renumbering ipv6 networks (Stig Venaas, Tim Chown) F. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) G. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) H. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

2 1

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to the RIPE NCC
by Filiz Yilmaz 20 Apr '05

20 Apr '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2A00::/21 from the IANA in April 2005. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- Filiz Yilmaz RIPE NCC

1 0

[ipv6-wg@ripe.net] New international IPv6 operators forum
by Daniel Roesen 16 Apr '05

16 Apr '05

Dear RIPE IPv6 WG, people were missing a global mailing list (not regional RIR/NOG) dedicated to _operational_ matters of the global IPv6 (production, not 6BONE) Internet. To fill this void I've created such a mailing list: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ So if you're taking part in IPv6 BGP or are interested in global IPv6 operational matters, feel more than invited to join the list! We do have IPv6 ops people from all regions on board to foster exchange of experience and resolve problems which require someone non-local coordination as well as discuss problems people face while deploying IPv6. Please also let your collegues/upstreams/peers/downstreams know. Currently, there are ~250 people subscribed (after only 3 days or so of existence), including many vendors. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

1 0

[ipv6-wg@ripe.net] New IPv6 Cluster publication: IPv6 and Broadband
by JORDI PALET MARTINEZ 14 Mar '05

14 Mar '05

http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=98 8

2 2

[ipv6-wg@ripe.net] IPv6 access to K-root
by Andrei Robachevsky 28 Feb '05

28 Feb '05

Colleagues, K-root server has now IPv6 transport enabled. k.root-servers.net. AAAA 2001:7fd::1 A 193.0.14.129 This information is also available from www.root-servers.org webiste. Regards, Andrei Robachevsky RIPE NCC

11 21

[ipv6-wg@ripe.net] RV:Call for Papers - Next Global IPv6 Summit in Spain
by JORDI PALET MARTINEZ 27 Feb '05

27 Feb '05

Hi all, Several people requested an extension of the deadline for the submission of the short abstracts for their presentations. So we decided to extend the deadline until midnight of March 4th. Please make sure to not miss it this time. We only require a title for your presentation and 3-4 lines short abstract. The final agenda will be announced at the end of the following week. Regards, Jordi Hi all, As indicated in the email below, the next Global IPv6 Summit in Spain, the bigger IPv6 European event, in its 4th edition (after a very successful organization and broad international attendance in 2001, 2002 and 2003), will be organized this time in Barcelona, next June 2005, with a expected audience over 2.600 key decisions makers from ICT sectors. The main target of the event is business oriented talks, as well as talks oriented to policy makers, information/knowledge society, education and public sectors. This Call for Papers doesn't require that you submit a complete paper (which is welcome also), but instead, a short plain text abstract of your presentation topic, by email. Talks regarding deployment experiences, new services and applications will be of key interest for the expected attendance, and hence highly encouraged. We believe that key topics will be also those regarding: 1) IPv6 and business 2) IPv6 and Broadband 3) New IPv6-based services and applications 4) IPv6 and the Digital Home 5) IPv6 and Multimedia, Voice/Video applications 6) IPv6, Mobility, Wireless and 3G 7) IPv6 and Ambient Intelligence/Ubiquitous Computing/Distributed Systems 8) IPv6 and GRIDs 9) IPv6 and logistics, transport and eSafety 10) IPv6 for eHealth, eGoverment, eLearning and other "e-whatever" 11) IPv6 and gamming 12) IPv6 and peer-to-peer 13) IPv6 and security 14) IPv6 and Open Source 15) IPv6 and marketing/branding Also topics regarding Standards, Research, Development and Innovation experiences are welcome, including R&D projects results. The Agenda will be drafted early in March, so the dead-line for submitting your topic is only until 25th February, but as said only a short abstract is required. If you're interested in participating, or you have any special idea, even if your topic is not in the list above, please don't hesitate to contact me (jordi.palet(a)consulintel.es) ASAP, so we can work out any options. Regards, Jordi PS: Please, feel free to circulate this email among your contacts. ------ Mensaje reenviado De: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> Responder a: <jordi.palet(a)consulintel.es> Fecha: Mon, 07 Feb 2005 18:25:42 +0100 Para: "members(a)ipv6forum.com" <members(a)ipv6forum.com>, <tf-sc(a)ipv6tf.org> Asunto: Next Global IPv6 Summit in Spain Hi all, As I already informed a few weeks ago, the next Global IPv6 Summit in Spain will be held this time in Barcelona next June (instead of Madrid in March as previously forecasted). This will happen starting on June 6th, with a tutorial in the morning, the opening ceremony in the afternoon, with some keynotes and then 2-3 days of IPv6 conference, depending on the success of the call for papers. If required we can extend our event up to Friday 10th (total 4 days, plus opening ceremony, plus half day tutorial). In this occasion, we will try a completely new model, integrating the IPv6 conference in a bigger event, more business oriented, even when technical sessions will be still present. The "umbrella" event is Internet Global Congress (IGC), with has been organized in Barcelona already during the 6 previous years. The Internet Global Congress, the leading Internet and New Technologies congress in Spain, is organized by the Fundació Barcelona Digital, a non-profit organization, which also provides space for exhibition and delivers the IGC awards for Digital Innovation (aimed to students and professionals with embryonic Internet projects, aims to be a launch platform for all those people involved in research and innovation in the field of Internet and the New Technologies). IGC provides us all the infrastructure for organizing the Global IPv6 Summit track, and we only need to manage our own agenda, and consequently our own call for papers (see next email). They also they care about all the issues related to registration, proceedings and publicity, at no cost for us. We expect that this will be the bigger IPv6 event in Europe during 2005, with an expected attendance over 2.600 people, which of course, will be able to attend not just to the IPv6 track but also to other IT tracks (already depicted at http://www.igcweb.net, then click at Program). The attendance is mainly CTOs, CEOs and other key decision makers related to ICT, so its a very nice opportunity for IPv6 in Europe to meet a large audience which probably has not been in touch with IPv6 until now. I count with the support from all of you, and please do not hesitate to let me know any ideas that you may have to make an even more successful event that what for sure we will have in a so nice city as Barcelona. More information will be soon available at http://www.ipv6-es.com and http://www.igcweb.net. Regards, Jordi ------ Fin del mensaje reenviado ************************************ Barcelona 2005 Global IPv6 Summit Call for Papers and information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

[ipv6-wg@ripe.net] New Document available: RIPE-343
by RIPE NCC Document Announcement Service 26 Feb '05

26 Feb '05

[apologies for duplicate e-mails] New RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-343 Title: IPv6 Address Space Management Author: Paul Wilson, Raymond Plzak, Axel Pawlik Date: 22 February 2005 Format: PS=53986 TXT=13567 Obsoletes: ripe-261 Short content description ------------------------- This document provides the management process for IPv6 global unicast address space whereby address allocations are made from a single global pool according to a "sparse allocation" algorithm. In this version, previously published as ripe-261, we fixed an error in the 6-bit address space table. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ipv6-sparse.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-343.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-343.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

7 9

[ipv6-wg@ripe.net] Call for Papers - Next Global IPv6 Summit in Spain
by JORDI PALET MARTINEZ 07 Feb '05

07 Feb '05

Hi all, As indicated in the email below, the next Global IPv6 Summit in Spain, the bigger IPv6 European event, in its 4th edition (after a very successful organization and broad international attendance in 2001, 2002 and 2003), will be organized this time in Barcelona, next June 2005, with a expected audience over 2.600 key decisions makers from ICT sectors. The main target of the event is business oriented talks, as well as talks oriented to policy makers, information/knowledge society, education and public sectors. This Call for Papers doesn't require that you submit a complete paper (which is welcome also), but instead, a short plain text abstract of your presentation topic, by email. Talks regarding deployment experiences, new services and applications will be of key interest for the expected attendance, and hence highly encouraged. We believe that key topics will be also those regarding: 1) IPv6 and business 2) IPv6 and Broadband 3) New IPv6-based services and applications 4) IPv6 and the Digital Home 5) IPv6 and Multimedia, Voice/Video applications 6) IPv6, Mobility, Wireless and 3G 7) IPv6 and Ambient Intelligence/Ubiquitous Computing/Distributed Systems 8) IPv6 and GRIDs 9) IPv6 and logistics, transport and eSafety 10) IPv6 for eHealth, eGoverment, eLearning and other "e-whatever" 11) IPv6 and gamming 12) IPv6 and peer-to-peer 13) IPv6 and security 14) IPv6 and Open Source 15) IPv6 and marketing/branding Also topics regarding Standards, Research, Development and Innovation experiences are welcome, including R&D projects results. The Agenda will be drafted early in March, so the dead-line for submitting your topic is only until 25th February, but as said only a short abstract is required. If you're interested in participating, or you have any special idea, even if your topic is not in the list above, please don't hesitate to contact me (jordi.palet(a)consulintel.es) ASAP, so we can work out any options. Regards, Jordi PS: Please, feel free to circulate this email among your contacts. ------ Mensaje reenviado De: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> Responder a: <jordi.palet(a)consulintel.es> Fecha: Mon, 07 Feb 2005 18:25:42 +0100 Para: "members(a)ipv6forum.com" <members(a)ipv6forum.com>, <tf-sc(a)ipv6tf.org> Asunto: Next Global IPv6 Summit in Spain Hi all, As I already informed a few weeks ago, the next Global IPv6 Summit in Spain will be held this time in Barcelona next June (instead of Madrid in March as previously forecasted). This will happen starting on June 6th, with a tutorial in the morning, the opening ceremony in the afternoon, with some keynotes and then 2-3 days of IPv6 conference, depending on the success of the call for papers. If required we can extend our event up to Friday 10th (total 4 days, plus opening ceremony, plus half day tutorial). In this occasion, we will try a completely new model, integrating the IPv6 conference in a bigger event, more business oriented, even when technical sessions will be still present. The "umbrella" event is Internet Global Congress (IGC), with has been organized in Barcelona already during the 6 previous years. The Internet Global Congress, the leading Internet and New Technologies congress in Spain, is organized by the Fundació Barcelona Digital, a non-profit organization, which also provides space for exhibition and delivers the IGC awards for Digital Innovation (aimed to students and professionals with embryonic Internet projects, aims to be a launch platform for all those people involved in research and innovation in the field of Internet and the New Technologies). IGC provides us all the infrastructure for organizing the Global IPv6 Summit track, and we only need to manage our own agenda, and consequently our own call for papers (see next email). They also they care about all the issues related to registration, proceedings and publicity, at no cost for us. We expect that this will be the bigger IPv6 event in Europe during 2005, with an expected attendance over 2.600 people, which of course, will be able to attend not just to the IPv6 track but also to other IT tracks (already depicted at http://www.igcweb.net, then click at Program). The attendance is mainly CTOs, CEOs and other key decision makers related to ICT, so its a very nice opportunity for IPv6 in Europe to meet a large audience which probably has not been in touch with IPv6 until now. I count with the support from all of you, and please do not hesitate to let me know any ideas that you may have to make an even more successful event that what for sure we will have in a so nice city as Barcelona. More information will be soon available at http://www.ipv6-es.com and http://www.igcweb.net. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

Re: [ipv6-wg@ripe.net] Re: New IPv6 Address Block Allocated to RIPE NCC
by Wilfried Woeber, UniVie/ACOnet 19 Jan '05

19 Jan '05

>"ICANN folly that we're in the process of changing" >(and this has taken far too long already). I propose to suggest the phrase "this has taken far too long already" as the new trademark for IANA/ICANN operations... >Gert Doering > -- NetMaster Sorry, couldn't resist... Wilfried ( https://cert.aco.net/ ) [ not wearing any hat for this message, just typing as a regular network citizen] _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or ::1/128 ?)

2 1

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 17 Jan '05

17 Jan '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2003:0000::/18 from the IANA in January 2005. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

5 6

[ipv6-wg@ripe.net] Announcement: Policy Development Process in RIPE
by Rob Blokzijl 21 Dec '04

21 Dec '04

To the RIPE Community, later today I will publish a draft document that describes the policy making process in RIPE. It is draft, so your input is requested in order to come to a generally accepted final document. Logistics: - deadline for comments on the first draft: 1 Februari 2005 - discussion takes place on ripe-list(a)ripe.net - if you are not subscribed to ripe-list(a)ripe.net yet, go to http://www.ripe.net/mailman/listinfo/ripe-list#subscribers - for any questions, don't hesitate to contact chair(a)ripe.net As always, apologies for receiving multiple copies of this announcement. Best regards, Rob Blokzijl RIPE Chairman

2 1

[ipv6-wg@ripe.net] RPSLng in the RIPE Whois Database
by Shane Kerr 21 Dec '04

21 Dec '04

Dear Colleagues, Beginning Wednesday 29 December 2004, the RIPE Database will support RPSLng. RPSLng extends the Routing Policy Specification Language (RPSL) allowing description of IPv6 and multicast routing policies. It includes a new object type, ROUTE6, and new attributes, such as "mp-import:" and "mp-export:". RPSLng was submitted to the IETF to become an RFC. You can read the most recent draft at: http://www.radb.net/rpslng-08.html This change will not affect the current contents of the database. It is optional for any objects you maintain. The main differences for query users are as follows: - Currently a query for an IPv4 address or network may return INETNUM, ROUTE, and INET-RTR objects. A query for an IPv6 address or network can only return an INET6NUM object. After we put RPSLng into production, IPv6 queries will start to also return ROUTE6 and INET-RTR objects, if they are in the database. - Currently an inverse query (using the "-i" flag) for AUT-NUM objects may return ROUTE objects. After we put RPSLng into production, a query will return both ROUTE and ROUTE6 objects. If you want to limit your query, you can use the "-T" flag. For example, if you only want ROUTE objects returned to an inverse query, you can type: whois -h whois.ripe.net -T route -i origin AS3333 Please change your scripts if necessary. We will not move the contents of the RPSLng prototype Whois server to the RIPE Whois Database. You will have to create any objects that define your routing policy in the production RIPE Whois Database. You can update the RPSLng prototype Whois server until the start of January 2005. The query interface will be available until the end of January 2005. -- Shane Kerr Software Manager RIPE NCC

3 2

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 16 Dec '04

16 Dec '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4C00::/23 from the IANA in December 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

[ipv6-wg@ripe.net] rootzone -> .com and .net in place :-)
by Carlos Friacas 29 Oct '04

29 Oct '04

Hi, Anybody noticed this? Connectivity still not that good to 2001:503:..., however, happy to have it in place :-) They "IPv6-ized" A and B (2 out of 13 servers). -------------------- ; <<>> DiG 8.3 <<>> @192.5.5.241 com ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15 ;; QUERY SECTION: ;; com, type = NS, class = IN ;; AUTHORITY SECTION: com. 2D IN NS C.GTLD-SERVERS.NET. com. 2D IN NS D.GTLD-SERVERS.NET. com. 2D IN NS E.GTLD-SERVERS.NET. com. 2D IN NS F.GTLD-SERVERS.NET. com. 2D IN NS G.GTLD-SERVERS.NET. com. 2D IN NS H.GTLD-SERVERS.NET. com. 2D IN NS I.GTLD-SERVERS.NET. com. 2D IN NS J.GTLD-SERVERS.NET. com. 2D IN NS K.GTLD-SERVERS.NET. com. 2D IN NS L.GTLD-SERVERS.NET. com. 2D IN NS M.GTLD-SERVERS.NET. com. 2D IN NS A.GTLD-SERVERS.NET. com. 2D IN NS B.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 A.GTLD-SERVERS.NET. 2D IN AAAA 2001:503:a83e::2:30 B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30 B.GTLD-SERVERS.NET. 2D IN AAAA 2001:503:231d::2:30 C.GTLD-SERVERS.NET. 2D IN A 192.26.92.30 D.GTLD-SERVERS.NET. 2D IN A 192.31.80.30 E.GTLD-SERVERS.NET. 2D IN A 192.12.94.30 F.GTLD-SERVERS.NET. 2D IN A 192.35.51.30 G.GTLD-SERVERS.NET. 2D IN A 192.42.93.30 H.GTLD-SERVERS.NET. 2D IN A 192.54.112.30 I.GTLD-SERVERS.NET. 2D IN A 192.43.172.30 J.GTLD-SERVERS.NET. 2D IN A 192.48.79.30 K.GTLD-SERVERS.NET. 2D IN A 192.52.178.30 L.GTLD-SERVERS.NET. 2D IN A 192.41.162.30 M.GTLD-SERVERS.NET. 2D IN A 192.55.83.30 ;; Total query time: 12 msec ;; FROM: atlas.fccn.pt to SERVER: 192.5.5.241 ;; WHEN: Fri Oct 29 16:16:43 2004 ;; MSG SIZE sent: 21 rcvd: 509 ; <<>> DiG 8.3 <<>> @192.5.5.241 net ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15 ;; QUERY SECTION: ;; net, type = NS, class = IN ;; AUTHORITY SECTION: net. 2D IN NS J.GTLD-SERVERS.net. net. 2D IN NS K.GTLD-SERVERS.net. net. 2D IN NS L.GTLD-SERVERS.net. net. 2D IN NS M.GTLD-SERVERS.net. net. 2D IN NS A.GTLD-SERVERS.net. net. 2D IN NS B.GTLD-SERVERS.net. net. 2D IN NS C.GTLD-SERVERS.net. net. 2D IN NS D.GTLD-SERVERS.net. net. 2D IN NS E.GTLD-SERVERS.net. net. 2D IN NS F.GTLD-SERVERS.net. net. 2D IN NS G.GTLD-SERVERS.net. net. 2D IN NS H.GTLD-SERVERS.net. net. 2D IN NS I.GTLD-SERVERS.net. ;; ADDITIONAL SECTION: A.GTLD-SERVERS.net. 2D IN A 192.5.6.30 A.GTLD-SERVERS.net. 2D IN AAAA 2001:503:a83e::2:30 B.GTLD-SERVERS.net. 2D IN A 192.33.14.30 B.GTLD-SERVERS.net. 2D IN AAAA 2001:503:231d::2:30 C.GTLD-SERVERS.net. 2D IN A 192.26.92.30 D.GTLD-SERVERS.net. 2D IN A 192.31.80.30 E.GTLD-SERVERS.net. 2D IN A 192.12.94.30 F.GTLD-SERVERS.net. 2D IN A 192.35.51.30 G.GTLD-SERVERS.net. 2D IN A 192.42.93.30 H.GTLD-SERVERS.net. 2D IN A 192.54.112.30 I.GTLD-SERVERS.net. 2D IN A 192.43.172.30 J.GTLD-SERVERS.net. 2D IN A 192.48.79.30 K.GTLD-SERVERS.net. 2D IN A 192.52.178.30 L.GTLD-SERVERS.net. 2D IN A 192.41.162.30 M.GTLD-SERVERS.net. 2D IN A 192.55.83.30 ;; Total query time: 8 msec ;; FROM: atlas.fccn.pt to SERVER: 192.5.5.241 ;; WHEN: Fri Oct 29 16:18:33 2004 ;; MSG SIZE sent: 21 rcvd: 506 ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!"

2 1

[ipv6-wg@ripe.net] RPSLng database deployment?
by Bernhard Schmidt 20 Oct '04

20 Oct '04

Dear all, having missed the last RIPE meeting I'm unfortunately somewhat out of date regarding this, but could someone please enlighten me about the current plans for deployment of RPSLng in the regular RIPE database? I am using rpslng.ripe.net, but unfortunately almost noone else does. Running a network without any sustainable prefix authorization sucks quite hard, it is a real pain to have to contact your upstream by mail if you have a new prefix (besides other things). Are there any problems with RPSLng currently? Thanks Bernhard

9 13

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
by Filiz Yilmaz 18 Oct '04

18 Oct '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4A00::/23 from the IANA in October 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- Filiz Yilmaz RIPE NCC

1 0

[ipv6-wg@ripe.net] IPv6 wg minutes RIPE48
by David Kessens 16 Oct '04

16 Oct '04

Please see below for the minutes of RIPE 48 as approved during the working group session in Manchester. Only a few minor typographical corrections were made compared to the draft minutes as posted earlier. I hope this helps, David Kessens --- IPv6 Working Group Minutes RIPE48 When: 14:00 - 18:00, Wednesday May 5, 2004 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe: Timothy Lowe, RIPE NCC - agenda bashing ACTIONS - Chair, ask the mailing list if this document should become a RIPE document http://ip6.de.easynet.net/ipv6-minimum-peering.txt - Community, provide feedback update on larger then default v6 allocations - Pim van Pelt (BIT BV) is looking for people who would like to run public 6to4 relays e-mail: pim(a)bit.nl or pim(a)ipng.nl B. Global IPv6 routing table status (Gert Doering, SPACENET) <http://www.space.net/~gert/RIPE/R48-v6-table/> The rate of growth in IPv6 allocations is tapering off. There is public data available on the difference between allocated IPv4 space and BGP routed IPv4 space here: <http://bgp.potaroo.net/index-ale.html> This site contains a number of reports on the status of the IPv4 address space, together with some observations about its trends in consumption of this resource. C. "per country view" about IPv6 allocation on the RIPE/NCC (Carlos Friacas, FCCN) <http://www.ip6.fccn.pt/v6top.html> D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) Questions: Pim van Pelt, BIT BV - 6to4 public relays are at 80 Mbs sustained. We would like people who want to run public 6to4 relays to contact us: pim(a)bit.nl or pim(a)ipng.nl E. Raising RPSLng Awareness (Carlos Friacas, Simon Leinen and Joao Damas, ISC) The RPSLng protocol draft is nearing completion (http://www.radb.net/rpslng.html) F. Discussion of: http://ip6.de.easynet.net/ipv6-minimum-peering.txt Should this document become a RIPE document? ACTION on Chair - to take this to the mailing list H. Latest IPv6 Land Speed Record (Edoardo Martelli, CERN) <http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ipvy-lsr.pdf>- 15:08 G. IETF multi6 update (Kurtis Erik Lindqvist, Netnod Internet Exchange) There are two main camps in this discussion: Dividing the Identifier and addressing functions of the IP by a.) Using identifier tokens b.) Lightweight version without ID token distribution I. What are the deployment plans behind the larger then default ipv6 allocations (Jordi Palet Martinez as a liaison for Vodafone, TeliaSonera and others) ACTION on Chair - keep this agenda point as an ongoing action. ACTION on community - send feedback for next RIPE meeting J. IPv6 home automation (Jordi Palet Martinez, Consulintel) There is a commercial powerline connectivity service operating in Spain, and other countries, which started with a big trial (3.000) in Zaragoza. Currently in IPv4 but possibly in IPv6 in future (some customers are using IPv6 but on experimental basis for the 6POWER project). K. (brief) update from the RIPE NCC on ipv6 enabled services (Andrei Robachevsky, RIPE NCC) Verbal: These services are IPv6 enabled: DNS, whois, ttm, plan, new webserver, K root. N. Input for the RIPE NCC Activity Plan (input from the audience) NONE M. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) NONE L. IPv6 network management - IETF MIBs status, NetFlow v9, SNMPv6, and monitoring tools (Bernard Tuy - RENATER) K. AOB Skidder ip mapping tool for topology research. Trying to do this in v6 www.caida.org/~mjl/

1 0

[ipv6-wg@ripe.net] IPv6 wg minutes RIPE47
by David Kessens 16 Oct '04

16 Oct '04

Please see below for the minutes of RIPE 47 as approved during last working group session in Manchester. David Kessens --- ________________________________________________ Draft (v1) minutes for the IPv6 Working Group Meeting RIPE 47 When: 14:00 - 15:30, Tuesday January 27, 2004 Where: St Johns II, Hotel Krasnapolsky, Amsterdam A. Administrative stuff Scribe: Timothy Lowe (RIPE NCC) Attendees: 132 B. Ranges of ipv6 addresses and their use (Jeroen Massar) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-ghost-r… C. Global IPv6 routing table status (Gert Doering) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-global-… D. Report(s) about *actual* v6 traffic volume as compared to v4 - Tunnel Detection Tool (Lorenzo Colitti, RIPE NCC, TTM project) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-… - IPv6 Network Management (Bernard Tuy) E. Operational issues with IPv6: RPSLng testing, policy issues, filtering practices, peering (Simon Leinen, Swiss IPv6 task force & ops group) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-swiss-p… F. Developments/initiatives regarding IPv6 in the RIPE region and beyond - latest IPv6 Land Speed Record (Edoardo Martelli (CERN)) ---

1 0

[ipv6-wg@ripe.net] Draft Minutes (v1) from IPv6 WG - RIPE 49
by David Kessens 12 Oct '04

12 Oct '04

Please see below for the draft (v1) minutes of the ipv6 working group session for RIPE 49. The minutes will be declared final if no substantial changes are proposed before Fri Oct 22. I hope this helps, David Kessens --- RIPE 49 Manchester IPv6 Working Group Wednesday 22 September 2004 WG Chair David Kessens Scribe Adrian Bedford (RIPE NCC) Attendees: 121 Administration and Agenda Presented by David Kessens Adrian Bedford of the RIPE NCC was appointed scribe. Agenda was agreed Minutes from both RIPE 47 and 48 were approved. Update from the RIPE NCC Presented by Andrei Robachevsky, RIPE NCC As of August, k-root is IPv6 enabled The new version of the RIPE website (to be launched shortly) will also be IPv6 enabled. An Overview of the Global IPv6 Routing Table Presented by Gert Doering (Spacenet) A number of anomalies have been observed in the Global IPv6 Routing table, though in most cases these could be explained by traffic engineering, internal transitions and in one case a prefix leak. One person used the Jabber Remote Feedback system to ask why IXPs are announcing /48s with no export. It was explained that, for example, AMSIX doesn't want it's neighbors to make it's prefix globally visible. It remains a contentious issue as to whether something should be globally visible. What are the Deployment Plans Behind the Larger IPv6 Allocations? Presented by: Mikael Lind (TeliaSonera) David Kessens asked whether there were plans to allocate /64s for mobile use. Mikael confirmed that this was likely and that TeliaSonera was also looking at /48s for this use. Kurtis Lindqvist asked whether TeliaSonera has been talking with vendors to co-ordinate hardware and equipment. Mikael explained that this has not yet happened, as they feel right now there is little incentive to do so. David asked if Mikael would consider returning to a future RIPE Meeting to provide an update when TeliaSonera is further along in the development and deployment process, Mikael indicated that he would be happy to do so. Deployment Plans Behind Larger IPv6 Allocations Presented by Jordi Palet (Consulintel) Jordi will continue to keep the Working Group posted on feedback. He will also encourage non-respondents to contribute. Geant IPv6 Presented by Jordi Palet (Consulintel) Guidelines for ISPs on IPv6 Assignments to Customers Presented by Jordi Palet (Consulintel) This presentation was a follow on from the one given at RIPE 48. < BREAK > IPv6 Glue for the Root Nameservers Presented by Johan Ihrén (Autonomica) Iljitsch van Beijnum asked how long the process is likely to take. Johan commented that it would depend on who was prepared to take on the task, Johan is willing to do this, though added that nothing is root server specific, if people argue that we need v6 glue now, then they should step up and offer to help out. There is no specific target date for this to happen, since testing needs to be completed. Randy Bush asked that since we tend to assume that we should upgrade when something breaks, how is he to know when something has in fact broken. How, as an operator will he actually know there is something wrong? Johan agreed with Randy, there needs to be an agreed process. This could mean that things may not happen universally at the same time. Much will depend on the level of ambition of those involved - the tasks could be more or less complex. Gert Doering commented that as we see ccTLDs adding v6 glue, they might already know some of the issues that could arise. He suggested that someone speak to the ccTLD Operators and find someone who is willing to help with testing. It was also suggested that prudence might be a good idea. If a ccTLD Operator decides to deploy v6 transitions to their nameservers, in the end it will be their own decision. A question was asked about whether anything could be done to improve I-root connectivity to Europe. Johan commented that this would fall into his domain and promised to provide more feedback on this by RIPE 50. Bill Manning commented that the group appeared to be talking as if testing had not in fact started, whereas people are doing tests, ccTLD Operators at already looking at the impacts of these tests. A timeframe was agreed at the last ISOC meeting to finish testing before their next report at the end of the year, enabling a report to made to ICANN. One obstacle here is that the last report to the ICANN board took six months to have approved. Doug Barton of ICANN commented that the process has been streamlined and lessons learned, it is felt that any such future report would receive a far quicker response. David Kessens asked if all root servers planned to have IPv6 connectivity at the same time. Johan replied that he thought it unlikely that everyone would approach this in the same way, adding that he felt diversity was not a bad thing. It would, he said, be likely that we would see some TLDs using basic glue with others holding off during the early phases. The day when we will see the v6 glue globally is still somewhere in the distant future as there are no specific plans at this point to co-ordinate such a deployment. To date eight have basic glue in place. David asked if this community could help and Johan said he felt it certainly could. There was discussion about asking the RIPE NCC for help, though Johan this was not necessary at this stage. From his point of view he did not feel the issue was who did this, rather thought needed to be given to identifying which tests are relevant. Time would need to be taken over inventory to find out what code is already out there. David rounded up the discussion by saying that volunteers would be welcomed, though this was not be taken as a specific action point. An Update on Multihoming in IPv6 Presented by Geoff Huston (APNIC) A comment was made that the slide detailing issues appeared to not consider the update rates for bindings and third party referrals. Geoff said that design decisions should avoid relying on DNS. Randy Bush commented that there had been some mission drift from multi-homing to mobility. A comment was made that if an opportunistic solution does not meet all the needs in the architecture, you are forced to use a structured identifier. Such an identifier would have to be unique to avoid collisions. This could give rise to a very complex registration infrastructure, which might be painful to administer. Geoff replied that uniqueness never comes cheap and needs enormous effort at a global level. This lead to a suggestion that it may be preferable to choose opportunistic styles. Geoff felt that this was down to personal taste; there were certainly benefits in avoiding global costs if set up problems could be avoided. A suggestion was made that we should consider developing a whole new protocol that could handle routing table growth, Geoff replied that it would be ideal to think that we could do both, groups do exist with experience in both fields. The IETF have working groups that work together to engineer solutions and ensure routing tables do not become too complex. Geoff agreed that many people do feel routing could provide a better answer Kuris Lindqvist pointed to work that had been done during an interim meeting in Santa Monica in June 2004, this looked at the architectural work done by Geoff and the 30-40 drafts submitted. The drafts were split into four or five categories and based upon these; a simple poll was carried out. In some categories, the authors withdrew their proposals and in others, there was little support. The consensus was that the architecture proposed by Geoff was the way the group wished to move forward at the moment. A speaker announced that he had prepared a draft on the use of PI to reduce pressures on routing tables, intended as a compromise and is accepting comments on this. A speaker added that during his presentation Geoff dismissed mobile IP for security and state management reasons. The IETF has already addressed security and state management could throw up more problems. He felt that having two solutions for these issues problem was unwise and we need to work towards a single solution for what seem like related problems. He felt that using security, as a reason to reject the architecture draft was a red herring. Geoff pointed out that this is not yet in the draft, though will be in the next version. Geoff agreed that some of the assumptions we made previously in mobile IPv6 now seem less secure. Security locators assume a stable home base - if it fails, everything else fails. Multi6 looks at the homeless vagrants of the world that do not have a home all of the time and the home is not reachable. It then assumes that there is not a home locator that can always be contacted. The Multi6 team looked at the other approaches and aimed to learn from them. He remains unsure if this kind of binding works in mobile environments, it is far too early to make this assessment. David Kessens asked whether the group found updates from Multi6 useful, Kurtis suggested that it would be nice to have Geoff make a similar presentation in future Address Policy Working Group Sessions too. Gert Doering suggested that as co-chair of the Address Policy Working Group, he would like to see the drafts on PI Addressing discussed through the Address Policy Mailing List. Moonv6 Update Presented by Jim Bounds Kurtis Lindqvist asked whether security testing had been carried out in an isolated test environment. Jim clarified that filters had only been tested on IPv6 ports, addresses and protocols. He added that it showed there was confusion. Just because dual stack is not a security problem, IPv6 in itself is not an insecure protocol. Intrusion detection needs to be included into work. Kurtis asked what stage of the evolution process the project had reached. Jim replied that in this respect, research was still quite basic. Deploying 5,000 IPv6 Sites - XTEC Presented by Jordi Palet (Consulintel) Input to RIPE NCC Activity Plan Presented by David Kessens David asked if the group had any items to include in the 2005 RIPE NCC Activity Plan. There was no response.

1 0

RE: [ipv6-wg@ripe.net] RPSLng database deployment?
by Tony Hain 07 Oct '04

07 Oct '04

Sorry, this was a reply to the wrong message. Tony > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, October 06, 2004 5:09 PM > To: 'Bernhard Schmidt'; 'db-wg(a)ripe.net' > Cc: 'ipv6-wg(a)ripe.net' > Subject: RE: [ipv6-wg(a)ripe.net] RPSLng database deployment? > > A few additional comments now that the text is cleaned up: > > The last sentence of 2.1 is out of context to the heading. The point it is > making really belongs in 2.2. It makes a nice lead-in sentence, and taking > the word 'these' out would probably fix the sentence to make sense as the > start of the next section. > > 2.2 ... ', and hence there is no specific security value in the NAT > function.' That should probably be a stand alone sentence with the 'NAT' > string replaced by 'address translation'. > > The perceived security comes from the lack of pre-established mapping > state. Dynamically establishing state in response to internal requests > prevents unexpected external connections to internal devices. > > ... the security policy is already likely to consist of multiple > components such as Firewalls, data-filters activity logging and intrusion > detection systems. Simplified forms of these for the less security aware > users could assist to make their private networks more secure. > -delete list- > > 2.4 ... they do prevent the external tracking and profiling of individual > host computers by means of their IP addresses. > -(2.3 just talked about how to track if one has access to the NAT, so this > one needs to be explicit about external)- > > ... which some enterprises believe is a useful ... > - replace 'enterprises' with 'network managers' - > > 2.5 ... unique and routable IPv4 address will continue increasing as > allocation policies tighten so that they become more difficult to obtain. > > 'This mechanism allows the simultaneous usage of certain IPv4 prefix for > various end-customers or end-systems. The overall benefit to the provider > is that fewer globally unique IPv4 addresses are required.' > - This is confusing unless the reader understands the need for stability > in IPv4 end system configurations. RE: how does simultaneous use of an > IPv4 address allow the ISP to use fewer addresses? It really doesn't. The > ISP will use as many addresses as it takes for independent instances of an > application. What NAT does in this situation is allow the IPv4 end systems > to have stable addresses that may overlap with other organizations, and > the ISP only needs as many public addresses as there are simultaneous > instances of a given app. - > > This type of local control of address resources allow a clean and > hierarchical addressing structure in the network that is not restricted by > the size of the publicly routed address pool. > > 2.6.1 ... larger (probably with less-administrative overhead) IPv4 address > range ... > > 2.6.2 'only have only' -->> 'have' > > 'For this type of private networks mainly RFC 1918 addressing is used > internally to reduce the needed amount of global routable prefixes, > because there no need for owned IPv4 prefixes by the enterprise and for > simplicity of the administrative overhead by the lack of a dedicated NOC.' > - I don't buy the argument to begin with. 'Lack of need' is bogus and we > shouldn't propagate it here because it will deflate the value of the IPv6 > argument later. We should put this in the context of a cost trade-off, > forfeiting some applications in favor of reduced access costs. How about: > Small networks typically deploy RFC 1918 addressing internally to limit > the explicit charges for publicly routable addresses. This approach also > has the advantage of avoiding the administrative overhead and dedicated > NOC associated with acquiring blocks of publicly routed address space. > > 2.6.3 ... 'due to the operational stateful operation' ... > - I think the first operational should go. > > 2.7 - drop the last sentence. For one those savings are only short term, > the long term costs of dealing with conflicting space will be higher. For > two, the point of the paper is to show how IPv6 makes things better, and > even the simplified renumbering will appear to be more expensive than > throwing a NAT at the problem. If you really want to say something about > cost, put it in the context of -perception-, -short term-, and -simple-. > - > > Why is 2.8 different from 2.2? > > I though you were going to align the numbering. > 2.1 -> 3.2 > 2.2 -> 3.3 > I think we should be able to summarize with a table like: > Function 2.x (IPv4) 3.x (IPv6) > x.1 Simple Gateway simple management DHCP-PD > x.2 Simple security stateful filter reflexive acl > x.3 tracking nat state table global uniqueness > x.4 topology hiding nat as virtual presence MIPv6 > x.5 addressing control RFC 1918 RFC 3177 & ULA > x.6 address allocation RFC 1918 RFC 3177 & ULA > x.7 renumbering RFC 1918 Multiple addr/interface > > Just trying to populate that table might clean up the overlaps and make it > clear what the point of each section should be. If we can delineate the > functions in crisp one or two word labels we can both make it simpler to > understand and more consistent between the versions. As it is even I am > having trouble figuring out if that table is correct. For example 3041 is > listed in 3.5, but it does absolutely nothing for topology hiding. Yes > privacy is one aspect of topology hiding, but end system privacy has > nothing to do with masking the network topology. > > 3.2 - why are renumbering & firewalls being discussed in the simple > gateway section? - > > 3.3 - the first two paragraphs are really summary material about ongoing > evolution in best practices and shouldn't be here. The last paragraph is > somewhat unrelated to the NAT->IPv6 effort. If it stays, comparable text > should be in the IPv4 section that makes it clear that open ports through > a nat will map to multiple machines, so configured state to run servers in > the private space are just as exposed as they would be without the nat. - > > 3.4 - all of this appears to be too much detail except the next to last > paragraph. The last paragraph is about IPv4 and is already stated there so > it should not be here. - > > 3.5 - End system privacy and network topology privacy are very separate > topics and shouldn't be in the same section. - > > - recommending that people use different subnet structures for internal & > external is just asking for trouble. Most 1st level ops have a hard enough > time with subnets anyway, so making this unnecessarily complex is just a > bad idea. 'Untraceable'/host-routes are a much better plan yet not even > mentioned here. - > > 3.6 - should be replaced with: > IPv6 provides for autonomy in local use addresses through ULAs (draft-???). > At the same time IPv6 simplifies simultaneous use of multiple addresses > per interface so that a NAT is not required (or even defined) between the > ULA and the public Internet. Nodes that need access to the public Internet > should have a global use address, and may simultaneously have a local use > ULA. Since the IPv6 address space for global use is not a scarce resource > like it is in IPv4, each network should be able to acquire a sufficient > quantity for its needs. While global IPv6 allocation policy is managed > through the Regional Internet Registries, it is expected that they will > continue with derivatives of RFC 3177 for the foreseeable future. > > 3.7.1 - seems to wander over several topics without a point. - > > 3.7.3 - if the ISP is allocating /128's then 3041 is not possible. > > 3.7.x - I still don't see the point in separating these out. There is > nothing that says an ISP can't or shouldn't use DHCP-PD for *every* > customer interface. The point is the length is flexible so any size > network fits. If there is to be a static mapping it should be done on the > back side of the DHCP server. The only time you might get into size > distinction here is if the customer is not part of the ISP aggregate and > is therefore injecting routes. The thing is injecting routes is not a > function of IPv4/NAT, so it really doesn't belong in this document. - > > 3.9 is really a subset of 3.3 > > I need to call it a day. I don't have a problem with the current draft > going out as a -00, but we should follow it with a fixed up -01 asap. > > Tony > > > > -----Original Message----- > > From: ipv6-wg-admin(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf > Of > > Bernhard Schmidt > > Sent: Wednesday, October 06, 2004 2:24 PM > > To: db-wg(a)ripe.net > > Cc: ipv6-wg(a)ripe.net > > Subject: [ipv6-wg(a)ripe.net] RPSLng database deployment? > > > > Dear all, > > > > having missed the last RIPE meeting I'm unfortunately somewhat out of > > date regarding this, but could someone please enlighten me about the > > current plans for deployment of RPSLng in the regular RIPE database? > > > > I am using rpslng.ripe.net, but unfortunately almost noone else does. > > Running a network without any sustainable prefix authorization sucks > > quite hard, it is a real pain to have to contact your upstream by mail > > if you have a new prefix (besides other things). > > > > Are there any problems with RPSLng currently? > > > > Thanks > > Bernhard

1 0

[ipv6-wg@ripe.net] New Ghost Route Hunter Utility: Prefix Compare
by Jeroen Massar 19 Sep '04

19 Sep '04

Always wonder what was wrong with a prefix? Wondering which ISP's are not able to reach you and where it stops? GRH (Ghost Router Hunter *1) now has a new utility for doing prefix comparisons (*2). This feature was requested by Daniel Rösen for the purpose of comparing: 2001:5000::/21 with 2001:650::/32 (*3). Which are originated from the same ASN, but as the /21 is filtered at some places, have different or no paths to the participants (*4) that provide routes to GRH and many more ISP"s around the world. This utility thus allows you to see which participants of GRH do have the routes in question and the difference in the paths towards those participants. This allows a very quick view where a prefix is not accepted, most possibly of misconfigured filters. People who don't have, for instance, 2001:5000::/21 in their BGP, please figure out where the filtering is wrongly applied by looking at the utility and applying the current set of recommended filters, available from: http://www.space.net/~gert/RIPE/ipv6-filters.html It is good to see that ISP's have prefix filtering, but they really should update them. Though I'd rather see no prefix filtering but that they do RPF filtering on their customers. When you have (near) 0 IPv6 prefixes in your BGP, then you better start catching on ;) At the moment of writing you should have at least IPv6 499 prefixes, as then you have all the allocated, and currently announced, TLA's in your router, if you have less you are missing a number of them. For interested ISP's, GRH signup is, of course, free and can be done through the website (*5), the more peers join, the better the statistics of all the GRH utilities will be. Also, if you, like Daniel, miss a good utility, don't hesitate to bring it up. I would also like to thank all the already participating ISP's for providing their tables which have made it able to fix a large number of problems already over the almost 2 years GRH has been running. Last but not least, thanks to Daniel Rösen for the brilliant idea. Greets, Jeroen *1 = http://www.sixxs.net/tools/grh/ *2 = http://www.sixxs.net/tools/grh/compare/ *3 = http://www.sixxs.net/tools/grh/compare/?a=2001:5000::/21&b=2001:650::/32 *4 = http://www.sixxs.net/tools/grh/participants/ *5 = http://www.sixxs.net/tools/grh/signup/

2 1

[ipv6-wg@ripe.net] Agenda for ipv6 wg RIPE49
by David Kessens 16 Sep '04

16 Sep '04

Please see below for the agenda for the agenda for our session at RIPE49. Note that we have one topic on the agenda (Discussion of issues involved in deploying ipv6 in the DNS root) that is of interest for both DNS working group and ipv6 working group participants. Due to time considerations, we decided to have this topic discussed during the ipv6 working group session. Thanks & hope to see you all at RIPE 49, David Kessens --- Agenda for the IPv6 Working Group Meeting RIPE49 When: 14:00 - 18:00, Wednesday September 22, 2004 Where: Medici Room, Renaissance Hotel, Manchester, UK A. Administrative stuff - appointment of scribe - agenda bashing - approval of the minutes (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (Andrei Robachevsky) C. Global IPv6 routing table status (Gert Doering) D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) o IPv6 traffic in Geant (tentative) E. What are the deployment plans behind the larger ipv6 allocations ? o TeliaSonera (Mikael Lind) o Other big allocations (Jordi Palet Martinez) o Others ? F. Guidelines for ISPs on IPv6 assignments (Jordi Palet Martinez) http://www.europe.ipv6tf.org/PublicDocuments/guidelines_for_isp_on_ipv6_ass… -- break --- G. Discussion of issues involved in deploying ipv6 in the DNS root Speakers from the following root nameservers: B (tentative) F (speaker from ISC) I (speaker from Autonomica) K (tentative) H. Update on multihoming solutions from IETF (Geoff Huston) I. moonv6 (Jim Bound) J. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) K. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

1 0

[ipv6-wg@ripe.net] Draft (v1) IPv6 WG minutes RIPE 48
by David Kessens 14 Sep '04

14 Sep '04

Please see below for the draft minutes of RIPE 48. The minutes will be declared final at the next meeting if no substantial comments that require a revision of the minutes are received before next working group session at RIPE 49. I hope this helps, David Kessens --- Draft (v1) IPv6 Working Group Minutes RIPE48 When: 14:00 - 18:00, Wednesday May 5, 2004 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe: Timothy Lowe, RIPE NCC - agenda bashing ACTIONS - Chair, ask the mailing list if this document should become a RIPE document http://ip6.de.easynet.net/ipv6-minimum-peering.txt - Community, provide feedback update on larger then default v6 allocations - Pim van Pelt (BIT BV) is looking for people who would like to run public 6to4 relays e-mail: pim(a)bit.nl or pim(a)ipng.nl B. Global IPv6 routing table status (Gert Doering, SPACENET) <http://www.space.net/~gert/RIPE/R48-v6-table/> The rate of growth in IPv6 allocations is tapering off. There is public data available on the difference between allocated IPv4 space and BGP routed IPv4 space here: <http://bgp.potaroo.net/index-ale.html> This site contains a number of reports on the status of the IPv4 address space, together with some observations about its trends in consumption of this resource. C. "per country view" about IPv6 allocation on the RIPE/NCC (Carlos Friacas, FCCN) <http://www.ip6.fccn.pt/v6top.html> D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) Questions: Pim van Pelt, BIT BV - 6to4 public relays are at 80 Mbs sustained. We would like people who want to run public 6to4 relays to contact us: pim(a)bit.nl or pim(a)ipng.nl E. Raising RPSLng Awareness (Carlos Friacas, Simon Leinen and Joao Damas, ISC) The RPSLng protocol draft is nearing completion (http://www.radb.net/rpslng.html) F. Discussion of: http://ip6.de.easynet.net/ipv6-minimum-peering.txt Should this document become a RIPE document? ACTION on Chair - to take this to the mailing list H. Latest IPv6 Land Speed Record (Edoardo Martelli, CERN) <http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-ipvy-lsr.pdf>- 15:08 G. IETF multi6 update (Kurtis Erik Lindqvist, Netnod Internet Exchange) There are two main camps in this discussion: Dividing the Identifier and addressing functions of the IP by a.) Using identifier tokens b.) Lightweight version without ID token distribution I. What are the deployment plans behind the larger then default ipv6 allocations (Jordi Palet Martinez as a liaison for Vodafoon) ACTION on Chair - keep this agenda point as an ongoing action. ACTION on community - send feedback for next RIPE meeting J. IPv6 home automation (Palet Jordi, Consulintel) There is a commercial powerline connectivity service operating in Zaragoza Spain. Currently in IPv4 but possibly in IPv6 in future. K. (brief) update from the RIPE NCC on ipv6 enabled services (Andrei Robachevsky, RIPE NCC) Verbal: These services are IPv6 enabled: DNS, whois, ttm, plan, new webserver, K root. N. Input for the RIPE NCC Activity Plan (input from the audience) NONE M. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) NONE L. IPv6 network management - IETF MIBs status, NetFlow v9, SNMPv6, and monitoring tools (Bernard Tuy - RENATER) K. AOB Skidder ip mapping tool for topology research. Trying to do this in v6 www.caida.org/~mjl/

1 0

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 13 Sep '04

13 Sep '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:5000::/20 from the IANA in September 2004. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

Re: [ipv6-wg@ripe.net] DNS Weather Report 2004-09-07
by Daniel Karrenberg 13 Sep '04

13 Sep '04

Since a storm seems to be rising about this and it threatens to leave the tea cup here is some perspective. Daniel ----- Forwarded message from Daniel Karrenberg <daniel.karrenberg(a)ripe.net> ----- Date: Wed, 8 Sep 2004 08:21:23 +0200 From: Daniel Karrenberg <daniel.karrenberg(a)ripe.net> To: Daniel Roesen <dr(a)cluenet.de> Subject: Re: [ipv6-wg(a)ripe.net] DNS Weather Report 2004-09-07 On 08.09 00:00, Daniel Roesen wrote: > On Tue, Sep 07, 2004 at 11:49:48AM +0200, Daniel Karrenberg wrote: > > On 07.09 01:08, Daniel Roesen wrote: > > > DNS WEATHER REPORT for selected infrastructure zones > > > ==================================================== > > > > Please stop spamming mailing lists. > > OK, you made me curious. Why do you (you are the first, all the other > feedback was overly positive) consider this "spamming"? Sending *unsolicited* automatic reports to *multiple* mailing lists is considered bad netiquette. In your case even more so since similar and better defined reports are available on demand from more than one source. It would have been more acceptable to say something like: "Hey, I have made this useful report. What do you think about it? If you are interested you can subscribe to regular reports here." These days netiquette is violated so frequently that most people do not even care to point things out to violators; they just ignore messages from people who do not behave socially. Procmail is an easy tool. [I spent 6 minutes composing this message. Multiply by n>20 / day] > And: was your request as a representant of the RIPE NCC, or as a > private person? Take it as advice from me as a person. The RIPE NCC does not police RIPE mailing lists. Daniel ----- End forwarded message -----

4 7

[ipv6-wg@ripe.net] Draft agenda (v2) for ipv6 wg RIPE49
by David Kessens 11 Sep '04

11 Sep '04

Hi, Please see below for the second version of our proposed agenda. We still have some time left, so proposals for additional agenda items that are useful for ipv6 Internet service providers are still welcome. You might have noticed that the minutes for RIPE 48 are still missing. I am working with the RIPE NCC to get them posted as soon as possible. I hope this helps, David Kessens --- Updated agenda for the IPv6 Working Group Meeting RIPE49 When: 14:00 - 18:00, Wednesday September 22, 2004 Where: Medici Room, Renaissance Hotel, Manchester, UK A. Administrative stuff - appointment of scribe - agenda bashing - approval of the minutes (David Kessens) B. Global IPv6 routing table status (Gert Doering) C. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) D. What are the deployment plans behind the larger ipv6 allocations ? o TeliaSonera (Mikael Lind) o Others ? E. Guidelines for ISPs on IPv6 assignments (Jordi Palet Martinez) http://www.europe.ipv6tf.org/PublicDocuments/guidelines_for_isp_on_ipv6_ass… F. moonv6 (Jim Bound) -- break --- G. Update on multihoming solutions from IETF (Geoff Huston) H. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) I. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

1 0

[ipv6-wg@ripe.net] Draft (v1) IPv6 wg minutes at RIPE 47
by David Kessens 11 Sep '04

11 Sep '04

Please see below for the draft minutes of RIPE 47. My apologies for the late publication. The minutes will be approved if no significant comments will be received before the next working roup session in Manchester. David Kessens --- ________________________________________________ Draft (v1) minutes for the IPv6 Working Group Meeting RIPE 47 When: 14:00 - 15:30, Tuesday January 27, 2004 Where: St Johns II, Hotel Krasnapolsky, Amsterdam A. Administrative stuff Scribe: Timothy Lowe (RIPE NCC) Attendees: 132 B. Ranges of ipv6 addresses and their use (Jeroen Massar) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-ghost-r… C. Global IPv6 routing table status (Gert Doering) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-global-… D. Report(s) about *actual* v6 traffic volume as compared to v4 - Tunnel Detection Tool (Lorenzo Colitti, RIPE NCC, TTM project) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-tunnel-… - IPv6 Network Management (Bernard Tuy) E. Operational issues with IPv6: RPSLng testing, policy issues, filtering practices, peering (Simon Leinen, Swiss IPv6 task force & ops group) http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-ipv6-swiss-p… F. Developments/initiatives regarding IPv6 in the RIPE region and beyond - latest IPv6 Land Speed Record (Edoardo Martelli (CERN)) ---

1 0

[ipv6-wg@ripe.net] Re: [dns-wg] IPv6 in .ie
by Jim Reid 09 Sep '04

09 Sep '04

>>>>> "Daniel" == Daniel Karrenberg <daniel.karrenberg(a)ripe.net> writes: Daniel> If I was IANA I would advise .ie strongly to rationalise Daniel> the names in their glue to save space. Yeah. Somebody needs to write up a draft on this as a BCP: using efficient label compression to avoid truncated responses.

5 5

[ipv6-wg@ripe.net] IPv6 in .ie (fwd)
by Carlos Friacas 08 Sep '04

08 Sep '04

One more today... Belgium (.BE), supported by BRUSSELS.NS.DNS.BE. (2001:6a8:3c60::be) ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" ---------- Forwarded message ---------- Date: Tue, 7 Sep 2004 08:54:30 +0100 (WEST) From: Carlos Friacas <cfriacas(a)fccn.pt> To: ipv6-wg(a)ripe.net Subject: [ipv6-wg(a)ripe.net] IPv6 in .ie (fwd) FYI, 19 TLDs already served by IPv6 nameservers w/glue-record on ".". Tue Sep 7 08:50:45 WEST 2004 ----------------------------- CH. DOMREG.NIC.CH. LI. DOMREG.NIC.CH. DE. A.NIC.DE. FR. C.NIC.FR. IE. NS6.IEDR.IE. JP. A.DNS.JP. JP. D.DNS.JP. JP. E.DNS.JP. JP. F.DNS.JP. KR. G.DNS.KR. IE. NS3.NS.ESAT.NET. TP. NS3.NS.ESAT.NET. AN. NS0.JA.NET. GB. NS0.JA.NET. GG. NS0.JA.NET. INT. NS0.JA.NET. JE. NS0.JA.NET. AN. NS0.JA.NET. GB. NS0.JA.NET. GG. NS0.JA.NET. INT. NS0.JA.NET. JE. NS0.JA.NET. INT. NS-SEC.RIPE.NET. AQ. NS-EXT.ISC.ORG. IL. NS-EXT.ISC.ORG. NL. NS-EXT.ISC.ORG. PH. NS-EXT.ISC.ORG. TN. NS.ATI.TN. TW. A.DNS.TW. TW. C.DNS.TW. TW. D.DNS.TW. ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" ---------- Forwarded message ---------- Date: Mon, 06 Sep 2004 18:05:11 +0100 From: Billy Glynn <billy.glynn(a)domainregistry.ie> To: ipv6-wg(a)ripe.net Cc: dns-wg(a)ripe.net, tech(a)lists.centr.org, ga(a)centr.org Subject: [ipv6-wg(a)ripe.net] IPv6 in .ie Hi, FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new IPv6 compatible name server ns6.iedr.ie. Additionally, we have added AAAA glue for one of our slaves ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Kind regards -- ________________________________ Billy Glynn Network Operations Centre IE Domain Registry Ltd Tel: +353 (0)1 2365404 Mobile: +353 (0)87 9188317 billy.glynn(a)domainregistry.ie ________________________________

1 0

[ipv6-wg@ripe.net] Re: [dns-wg] IPv6 in .ie
by Andrei Robachevsky 08 Sep '04

08 Sep '04

Andreas S. Kerber wrote: > On Tue, Sep 07, 2004 at 08:39:08AM +0200, Jeroen Massar wrote: > >>I also see that you have ns2.nic.fr listed in there, ns3.nic.fr has IPv6 >>for sure. >>You should maybe ask RIPE NCC if they can stick glue for ns.ripe.net >>into the . also with an IPv6 address, which would also give quite a >>number of other TLD's etc an IPv6 capable nameserver all of a sudden. > > > uuh, I guess that would get pretty close to 512 bytes when querying ie. > > # dig -t NS ie. @a.root-servers.net | grep MSG > ;; MSG SIZE rcvd: 493 I think adding another AAAA record will actually exceed this limit. Daniel wrote: > So what? See below for examples of what could happen: > soem glue is omitted. > But also the IANA procedure will not permit it: "5. If the number of name servers or IP addresses in the delegation exceeds eight (8), the size of responses to reasonable queries with the intended delegation will be checked to ensure that such responses fit into a 512 byte UDP packet. This is the standard size limitation for UDP response packets for most resolving name server software on the Internet today." Coming back to the issue with ns.ripe.net. The fact that it is a secondary for about 90 ccTLDs makes it impossible to insert AAAA record in the root for any of the zone, because that will affect others. Currently, we are planning to introduce a scheme whereby each ccTLD has its own name in the ripe.net domain, eg: ns-ie.ripe.net A 193.0.12.107 AAAA 2001:610:240:0:53:cc:12:107 All of the addresses for ccTLDs (ns-XX.ripe.net) are simply IP aliases on a shared machine. Regards, Andrei Robachevsky RIPE NCC

2 1

[ipv6-wg@ripe.net] IPv6 Deployment Conference at RIPE 49
by Tim Chown 07 Sep '04

07 Sep '04

Hi, The UK IPv6 Task Force, in conjunction with RIPE and the European IST IPv6 Cluster, is presenting a programme of IPv6 events from 23rd-24th September 2004. The UK IPv6 Deployment Conference, sponsored by BT and Cisco, is targeted at those interested in the current state of play in IPv6 deployment. It aims to present an overview of state-of-the-art in the latest IPv6 deployment technology, including: * Advanced testbeds, including the US Moonv6 project * Early IPv6 production deployments, in backbones and enterprises * IPv4-IPv6 transition and integration technologies * IPv6 opportunities: new technologies, delivery media and applications The Conference is co-located with the 49th RIPE Meeting of 20th-24th September, at which Europe's ISPs will gather to discuss technology and policy. We have scheduled a free European IST IPv6 Cluster meeting on the afternoon before the UK IPv6 Deployment Conference to allow our delegates the opportunity of attending an attractive, fuller one-and-a-half day programme of leading edge IPv6 talks and discussion should they wish to do so. For full details and registration information, please see: http://www.uk.ipv6tf.org/events/manchester.html Hope to see you in Manchester! Regards, Tim Chown UK IPv6 Task Force Steering Committee

1 0

[ipv6-wg@ripe.net] IEEE SAINT2005 workshop CPF: IPv6 Deployment Status and Challenges
by JORDI PALET MARTINEZ 07 Sep '04

07 Sep '04

Hi all, The call for papers for this international workshop is now open until October 7. Authors are kindly requested to submit papers as early as possible to facilitate a review process. IEEE SAINT2005 workshop CPF: IPv6 Deployment Status and Challenges http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=6… Please forward this email to all your contacts. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

1 0

[ipv6-wg@ripe.net] DNS Weather Report 2004-09-07
by Daniel Roesen 07 Sep '04

07 Sep '04

DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-09-07 Zones analyzed and their SOA contacts: - . - arpa. nstld(a)verisign-grs.com - int. noc(a)icann.org - in-addr.arpa bind(a)arin.net - ip6.arpa. hostmaster(a)icann.org - ip6.int. hostmaster(a)ep.net Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily! Some people have approached me wether it would be possible to receive personal copies of the report. Please let me know wether you are interested in such a service yourself. If there is enough interest, I will set up a distro list for that. Executive summary: * the IP6.ARPA problems regarding delegation NS RRset got fixed! * ns.isi.edu is _still_ out of sync for the INT zone. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004090400, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== fine! The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel

1 1

[ipv6-wg@ripe.net] Re: [dns-wg] IPv6 in .ie
by Daniel Karrenberg 07 Sep '04

07 Sep '04

On 07.09 08:49, Andreas S. Kerber wrote: > > uuh, I guess that would get pretty close to 512 bytes when querying ie. So what? See below for examples of what could happen: soem glue is omitted. If the client supports IPv6 it almost certainly supports EDNS(0), so the 512 byte limit is no issue. If the lient does not support EDNS some glue may be dropped for very long names without problems. See http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf for a little more detail. (It can be argued that dropping AAAA glue first is a good tactic here because "see above". This will be implemented on all root name servers in the near future.) Daniel ----- ; <<>> DiG 8.2 <<>> @k.root-servers.net. short.ie. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 12 ;; QUERY SECTION: ;; short.ie, type = A, class = IN ;; AUTHORITY SECTION: ie. 2D IN NS ns2.nic.fr. ie. 2D IN NS ns.ripe.net. ie. 2D IN NS banba.domainregistry.ie. ie. 2D IN NS uucp-gw-1.pa.dec.com. ie. 2D IN NS uucp-gw-2.pa.dec.com. ie. 2D IN NS ns3.ns.esat.net. ie. 2D IN NS gns1.domainregistry.ie. ie. 2D IN NS gns2.domainregistry.ie. ie. 2D IN NS ice.netsource.ie. ie. 2D IN NS ns6.iedr.ie. ;; ADDITIONAL SECTION: ns2.nic.fr. 2D IN A 192.93.0.4 ns.ripe.net. 2D IN A 193.0.0.193 banba.domainregistry.ie. 2D IN A 193.1.142.2 uucp-gw-1.pa.dec.com. 2D IN A 204.123.2.18 uucp-gw-2.pa.dec.com. 2D IN A 204.123.2.19 ns3.ns.esat.net. 2D IN A 192.111.39.100 ns3.ns.esat.net. 2D IN AAAA 2001:7c8:2:a::64 gns1.domainregistry.ie. 2D IN A 198.133.199.102 gns2.domainregistry.ie. 2D IN A 198.133.199.103 ice.netsource.ie. 2D IN A 212.17.32.2 ns6.iedr.ie. 2D IN A 213.190.149.221 ns6.iedr.ie. 2D IN AAAA 2001:bb0:ccc3::2 ;; Total query time: 71 msec ;; FROM: dienst.karrenberg.net to SERVER: k.root-servers.net. 193.0.14.129 ;; WHEN: Tue Sep 7 11:29:37 2004 ;; MSG SIZE sent: 26 rcvd: 499 ; <<>> DiG 8.2 <<>> @k.root-servers.net. something.verylogindeed.fordemopurposes.ie ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 11 ;; QUERY SECTION: ;; something.verylogindeed.fordemopurposes.ie, type = A, class = IN ;; AUTHORITY SECTION: ie. 2D IN NS ns2.nic.fr. ie. 2D IN NS ns.ripe.net. ie. 2D IN NS banba.domainregistry.ie. ie. 2D IN NS uucp-gw-1.pa.dec.com. ie. 2D IN NS uucp-gw-2.pa.dec.com. ie. 2D IN NS ns3.ns.esat.net. ie. 2D IN NS gns1.domainregistry.ie. ie. 2D IN NS gns2.domainregistry.ie. ie. 2D IN NS ice.netsource.ie. ie. 2D IN NS ns6.iedr.ie. ;; ADDITIONAL SECTION: ns2.nic.fr. 2D IN A 192.93.0.4 ns.ripe.net. 2D IN A 193.0.0.193 banba.domainregistry.ie. 2D IN A 193.1.142.2 uucp-gw-1.pa.dec.com. 2D IN A 204.123.2.18 uucp-gw-2.pa.dec.com. 2D IN A 204.123.2.19 ns3.ns.esat.net. 2D IN A 192.111.39.100 ns3.ns.esat.net. 2D IN AAAA 2001:7c8:2:a::64 gns1.domainregistry.ie. 2D IN A 198.133.199.102 gns2.domainregistry.ie. 2D IN A 198.133.199.103 ice.netsource.ie. 2D IN A 212.17.32.2 ns6.iedr.ie. 2D IN A 213.190.149.221 ;; Total query time: 69 msec ;; FROM: dienst.karrenberg.net to SERVER: k.root-servers.net. 193.0.14.129 ;; WHEN: Tue Sep 7 11:29:43 2004 ;; MSG SIZE sent: 60 rcvd: 505 ; <<>> DiG 8.2 <<>> @k.root-servers.net. something.verylogindeed.fordemopurposes.evenlonger.toforceommittingmoreglue.ie ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 9 ;; QUERY SECTION: ;; something.verylogindeed.fordemopurposes.evenlonger.toforceommittingmoreglue.ie, type = A, class = IN ;; AUTHORITY SECTION: ie. 2D IN NS ns2.nic.fr. ie. 2D IN NS ns.ripe.net. ie. 2D IN NS banba.domainregistry.ie. ie. 2D IN NS uucp-gw-1.pa.dec.com. ie. 2D IN NS uucp-gw-2.pa.dec.com. ie. 2D IN NS ns3.ns.esat.net. ie. 2D IN NS gns1.domainregistry.ie. ie. 2D IN NS gns2.domainregistry.ie. ie. 2D IN NS ice.netsource.ie. ie. 2D IN NS ns6.iedr.ie. ;; ADDITIONAL SECTION: ns2.nic.fr. 2D IN A 192.93.0.4 ns.ripe.net. 2D IN A 193.0.0.193 banba.domainregistry.ie. 2D IN A 193.1.142.2 uucp-gw-1.pa.dec.com. 2D IN A 204.123.2.18 uucp-gw-2.pa.dec.com. 2D IN A 204.123.2.19 ns3.ns.esat.net. 2D IN A 192.111.39.100 ns3.ns.esat.net. 2D IN AAAA 2001:7c8:2:a::64 gns1.domainregistry.ie. 2D IN A 198.133.199.102 gns2.domainregistry.ie. 2D IN A 198.133.199.103 ;; Total query time: 67 msec ;; FROM: dienst.karrenberg.net to SERVER: k.root-servers.net. 193.0.14.129 ;; WHEN: Tue Sep 7 11:33:53 2004 ;; MSG SIZE sent: 96 rcvd: 509

2 2

[ipv6-wg@ripe.net] IPv6 in .ie (fwd)
by Carlos Friacas 07 Sep '04

07 Sep '04

FYI, 19 TLDs already served by IPv6 nameservers w/glue-record on ".". Tue Sep 7 08:50:45 WEST 2004 ----------------------------- CH. DOMREG.NIC.CH. LI. DOMREG.NIC.CH. DE. A.NIC.DE. FR. C.NIC.FR. IE. NS6.IEDR.IE. JP. A.DNS.JP. JP. D.DNS.JP. JP. E.DNS.JP. JP. F.DNS.JP. KR. G.DNS.KR. IE. NS3.NS.ESAT.NET. TP. NS3.NS.ESAT.NET. AN. NS0.JA.NET. GB. NS0.JA.NET. GG. NS0.JA.NET. INT. NS0.JA.NET. JE. NS0.JA.NET. AN. NS0.JA.NET. GB. NS0.JA.NET. GG. NS0.JA.NET. INT. NS0.JA.NET. JE. NS0.JA.NET. INT. NS-SEC.RIPE.NET. AQ. NS-EXT.ISC.ORG. IL. NS-EXT.ISC.ORG. NL. NS-EXT.ISC.ORG. PH. NS-EXT.ISC.ORG. TN. NS.ATI.TN. TW. A.DNS.TW. TW. C.DNS.TW. TW. D.DNS.TW. ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" ---------- Forwarded message ---------- Date: Mon, 06 Sep 2004 18:05:11 +0100 From: Billy Glynn <billy.glynn(a)domainregistry.ie> To: ipv6-wg(a)ripe.net Cc: dns-wg(a)ripe.net, tech(a)lists.centr.org, ga(a)centr.org Subject: [ipv6-wg(a)ripe.net] IPv6 in .ie Hi, FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new IPv6 compatible name server ns6.iedr.ie. Additionally, we have added AAAA glue for one of our slaves ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Kind regards -- ________________________________ Billy Glynn Network Operations Centre IE Domain Registry Ltd Tel: +353 (0)1 2365404 Mobile: +353 (0)87 9188317 billy.glynn(a)domainregistry.ie ________________________________

1 0

[ipv6-wg@ripe.net] IPv6 in .ie
by Billy Glynn 07 Sep '04

07 Sep '04

Hi, FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new IPv6 compatible name server ns6.iedr.ie. Additionally, we have added AAAA glue for one of our slaves ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Kind regards -- ________________________________ Billy Glynn Network Operations Centre IE Domain Registry Ltd Tel: +353 (0)1 2365404 Mobile: +353 (0)87 9188317 billy.glynn(a)domainregistry.ie ________________________________

3 2

[ipv6-wg@ripe.net] Portuguese Mirror also in IPv6 (fwd)
by Carlos Friacas 03 Sep '04

03 Sep '04

Hello, Just to report yet another very small step... (the 3rd ripe meetings' webcast mirror, acessible via IPv6 - following Cesnet's and Surfnet's) Regards, ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!" ---------- Forwarded message ---------- Date: 3 Sep 2004 14:33:31 +0100 From: Nuno Gonçalves <nuno(a)fccn.pt> To: ripecast(a)ripe.net Cc: 'Carlos Friacas' <cfriacas(a)fccn.pt>, Subject: Portuguese Mirror also in IPv6 Hello! My name is Nuno Gonçalves and I work at FCCN on the streaming area. I saw on your website at http://www.ripe.net/ripe/meetings/ripe-49/webcast.html , that there is an URL to our mirror here at Lisbon among the other mirrors across Europe! Our mirror already has IPv6 enabled, so is it possible to add the IPv6 next to Portugal Mirror: on the web page? Thanks in advance Best Regards Nuno Gonçalves _____________________ Nuno Gonçalves - FCCN Work Group Multimedia nuno(a)fccn.pt http://www.fccn.pt _____________________

1 0

[ipv6-wg@ripe.net] Call for agenda items RIPE49 & draft agenda (v1)
by David Kessens 02 Sep '04

02 Sep '04

Please see below for the first version of the draft agenda. As usual, we don't have enough interesting topics (yet). That is bad news and good news: I need your help in finding interesting topics but the good news is that we will have time to accommodate your suggestions. Let me know if you want to volunteer for an agenda topic, but also feel free to suggest a topic that I or the list might know volunteers for. Thanks, David Kessens --- Updated agenda for the IPv6 Working Group Meeting RIPE49 When: 14:00 - 18:00, Wednesday September 22, 2004 Where: Medici Room, Renaissance Hotel, Manchester, UK A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Global IPv6 routing table status (Gert Doering) C. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) D. What are the deployment plans behind the larger ipv6 allocations ? o TeliaSonera (Mikael Lind) E. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) F. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB ---

2 1

[ipv6-wg@ripe.net] DNS Weather Report 2004-08-31
by Daniel Roesen 31 Aug '04

31 Aug '04

[sorry! resent, wrong subject date!] DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-31 Zones analyzed and their SOA contacts: - . - arpa. nstld(a)verisign-grs.com - int. noc(a)icann.org - in-addr.arpa bind(a)arin.net - ip6.arpa. hostmaster(a)icann.org - ip6.int. hostmaster(a)ep.net [Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily!] Executive summary: * m.root out-of-sync problem got fixed within one hour after I've sent out report 2004-08-24. Thanks WIDE! * The INT problem with the non-matching NS RRset (in-zone and delegation) was also fixed. Unfortunately ns.isi.edu is _still_ out of sync. * The IP6.ARPA NS RRset discrepancy got worse over the last week. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004082300, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ---------------- ----------------- ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. ns.lacnic.net. Problem known, RIPE sent a reminder to ip6.arpa operators two weeks ago, obviously without any outcome. Since the last DNS weather report last week, ns.lacnic.net. was added. Looks like now at least two change requests for the ip6.arpa delegation are pending. Problem exists since in various degrees since at least 2004-08-24 The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel

1 0

[ipv6-wg@ripe.net] DNS Weather Report 2004-08-24
by Daniel Roesen 31 Aug '04

31 Aug '04

DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-31 Zones analyzed and their SOA contacts: - . - arpa. nstld(a)verisign-grs.com - int. noc(a)icann.org - in-addr.arpa bind(a)arin.net - ip6.arpa. hostmaster(a)icann.org - ip6.int. hostmaster(a)ep.net [Operators: please let me know wether you do want a copy when there's no problem with your zone(s) or not. Don't want to annoy anyone unnecessarily!] Executive summary: * m.root out-of-sync problem got fixed within one hour after I've sent out report 2004-08-24. Thanks WIDE! * The INT problem with the non-matching NS RRset (in-zone and delegation) was also fixed. Unfortunately ns.isi.edu is _still_ out of sync. * The IP6.ARPA NS RRset discrepancy got worse over the last week. * ns.isi.edu is _still_ auth for IP6.INT where it shouldn't be. The state of the root zone =========================== fine! The state of the ARPA zone ========================== fine! The state of the INT zone ========================= - ns.isi.edu is not in sync with the other nameservers Current SOA serial of the INT TLD: 2004082300, ns.isi.edu has still 2002080104 and is publishing stale data (e.g. an old NS RRset for the zone). Problem exists since at least 2004-08-24 The state of the IN-ADDR.ARPA zone ================================== fine! The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ---------------- ----------------- ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. ns.lacnic.net. Problem known, RIPE sent a reminder to ip6.arpa operators two weeks ago, obviously without any outcome. Since the last DNS weather report last week, ns.lacnic.net. was added. Looks like now at least two change requests for the ip6.arpa delegation are pending. Problem exists since in various degrees since at least 2004-08-24 The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so induces no operational problems so far. Problem exists since at least 2004-08-24 Regards, Daniel

1 0

[ipv6-wg@ripe.net] Re: [address-policy-wg] Re: IANA to RIR IPv6 Allocation
by Wilfried Woeber, UniVie/ACOnet 25 Aug '04

25 Aug '04

>> My proposal would be that IANA would have to perform the subsequent >> allocation within this 30 day period, even if they might not be able to >> obtain advice or an expertise (for whatever reason) from any other party >> they might have decided to ask for advice. > >sure, if we can we do the same for rir to lir No problem with that, although I don't see the need for global coordination here. To me this sounds like a RIR-Customer service-contract aspect. Wilfried.

1 0

Re: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR ipv6 Allocation
by Iljitsch van Beijnum 24 Aug '04

24 Aug '04

On 24-aug-04, at 4:48, Jeff Williams wrote: > Iljitsch and all, ^^^^^ No kidding... > None of this addresses the outstanding problems with Ipv6 or ipv6 > allocation concerns and existing as well as discussed problems. > They are "at least" the following: I don't think I get what you're talking about. > 1. ) Invalid or incorrect minimal allocation. What is invalid or incorrect here? > 2.) Still existing cost increases for allocations. What cost? > 3.) Still existing security/privacy "holes" in ipv6 What holes? There is no difference with IPv4. > 4.) Routing notification for new allocation practice or method. What on Earth is a "routing notification"? > 5.) Routing table maintenance Best practices and/or policy, Well, there is some of this but since the RIRs seem to have trouble living up to their own policies this is problematic. (See http://www.bgpexpert.com/archive2003q4.php ) > and enforcement of same. Yes, we don't do this in the internet. (And go fix the IPv4 table first if you feel so inclined.) > 6.) Dealing with "Dark" existing and/or future allocated addresses. Again, I have no idea what you're talking about. Now if we could have a mechanism to determine resolving DNS servers automatically in IPv6 and have visible IPv6 addresses for the root DNS servers we'd be well on our way. And of course we still need multihoming in IPv4 and the IETF has to quit rewriting the RFCs all the time. > Iljitsch van Beijnum wrote: I know what I wrote, so P L E A S E don't repeat it in its entirety!!! I'm really getting sick and tired of people who are too lazy to quote in a decent manner.

1 0

[ipv6-wg@ripe.net] DNS Weather Report 2004-08-24
by Daniel Roesen 23 Aug '04

23 Aug '04

DNS WEATHER REPORT for selected infrastructure zones ==================================================== Issue 2004-08-24 Zones analyzed and their SOA contacts: - . nstld(a)verisign-grs.com - arpa. nstld(a)verisign-grs.com - int. noc(a)icann.org - in-addr.arpa bind(a)arin.net - ip6.arpa. hostmaster(a)icann.org - ip6.int. hostmaster(a)ep.net Executive summary: not a single zone without any problems, but ip6.int situation improved significantly. The state of the root zone =========================== - m.root-servers.net is lagging behind the others... general SOA serial is 2004082201, m.root has 2004082101 The state of the ARPA zone ========================== - same SOA serial problem as in the root zone, m.root out-of-sync. Interestingly, all the same SOA serial numbers as the root zone (coincidence?) The state of the INT zone ========================= - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ns0.ja.net. ns0.ja.net. ns1.cs.ucl.ac.uk. ns1.cs.ucl.ac.uk. ns.icann.org. ns.icann.org. ns.isi.edu. ns.isi.edu. ns.uu.net. ns.uu.net. ns.ripe.net. z.ip6.int. - ns.isi.edu started to be auth again (was lame a few days ago), but is not in sync. current SOA serial of the INT TLD: 2004080300, ns.isi.edu has 2002080104 The state of the IN-ADDR.ARPA zone ================================== - same problem with m.root as with the root zone. m.root seems to lag exactly one day behind, judging from the SOA serial number. The state of the IP6.ARPA zone ============================== - in-zone NS RRset doesn't match the delegation NS RRset. in-zone RRset: delegation RRset: ns.apnic.net. ns.apnic.net. ns.icann.org. ns.icann.org. ns-sec.ripe.net. ns.ripe.net. tinnie.arin.net. tinnie.arin.net. Problem known, RIPE sent a reminder to ip6.arpa operators a week ago, obviously without any outcome. The state of the IP6.INT zone ============================= - ns.isi.edu (one of the INT TLD servers) feels authoritative for the IP6.INT zone, but is neither listed in the delegation NS RRset, nor in the in-zone NS RRset of IP6.INT. Luckily, ns.isi.edu carries ip6.int with the same SOA serial as the official servers, so introduces no operational problems so far. Regards, Daniel

1 0

[ipv6-wg@ripe.net] Re: IANA to RIR IPv6 Allocation
by Wilfried Woeber, UniVie/ACOnet 21 Aug '04

21 Aug '04

I've got one comment here on section 7. paragraph 4. "Subsequent Allocation": While the wording might be sufficiently clear for a native speaker by referring to "set of administrative procedures....", I am missing clear guidance for the IANA that there should _not_ be any incentive or responsibilty to consult with other groups, entities or third parties (irrespective of their, say, credibility for e.g. protocol development or technical specifications) which would require extending that 30 day period. My proposal would be that IANA would have to perform the subsequent allocation within this 30 day period, even if they might not be able to obtain advice or an expertise (for whatever reason) from any other party they might have decided to ask for advice. Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or ::1/128 ?) From: David Kessens <david.kessens(a)nokia.com> To: Jeroen Massar <jeroen(a)unfix.org> Date: Fri, 20 Aug 2004 01:48:52 -0700 CC: ipv6-wg(a)ripe.net Subject: Re: [ipv6-wg(a)ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation Jeroen, On Fri, Aug 20, 2004 at 09:25:59AM +0200, Jeroen Massar wrote: > For people not on the arin-council (not likely ;) or the ppml@arin > lists: All policy discussions for the RIPE region are now conducted at the RIPE policy working group maillist: address-policy-wg(a)ripe.net David Kessens --- > -----Forwarded Message----- > From: "Sweeting, John" <John.Sweeting(a)teleglobe.com> > To: 'ppml(a)arin.net' <ppml(a)arin.net> > Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation > Date: Thu, 19 Aug 2004 17:36:56 -0400 > > I am submitting the following proposal IAW ARIN's Internet Resource Policy > Evaluation Process. In the interest of all I would like to disclose up front > that the information used to prepare this template was provided by ARIN > staff. > > > ############################################ > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet > Assigned Numbers Authority (IANA) Policy to Regional Internet Registries > > 2. Author > > a. name: John Sweeting > b. email: john.sweeting(a)teleglobe.com > c. telephone: 703-766-3042 > d. organization: ARIN Advisory Council > > 3. Proposal Version: 1 > > 4. Submission Date: 8/17/04 > > 5. Proposal type: new, global > > 6. Policy term: permanent > > 7. Policy statement: > > 1. Minimum Allocation Size. > > The minimum size of any allocation of IPv6 address space from IANA to an RIR > is prefix length /12. If this address space is not sufficient to meet the > needs of an RIR for a projected 18 month period, IANA shall allocate to that > RIR the address space for which it can provide justification. > > 2. Reservation of Unicast Address space. > > 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 > addresses beginning at binary value 001 (prefix length /3) for its > allocations of unicast address space. In order to support regional > aggregation of IPv6 address space IANA shall establish a reservation of a > prefix length of /6 from this space for each established RIR and for each > emerging RIR. Allocations to each RIR will be from the appropriate > reservation. > > 2.2. RIRs. Each RIR may apply its own respective chosen allocation and > reservation strategy in order to meet the needs of its community and to > ensure the efficiency and efficacy of its work. Such reservations made by > an RIR will be considered as being allocated by that RIR when that RIR > applies for an allocation of address space from the IANA. > > 3. Initial Allocation. > > 3.1. Upon implementation of this policy IANA shall allocate to each > established RIR a /12 from the reservation established for each particular > RIR. > > 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from > the reservation set aside for that RIR. > > > 4. Subsequent Allocation. > > An RIR shall be eligible for an allocation of at least a minimal allocation > from the IANA when its current holdings are less than 50% of its 18 month > requirement or when it has less than 180 days of holdings available. The > IANA shall evaluate the requested allocation using a set of administrative > procedures that are mutually agreed to by the IANA and the NRO. This set of > procedures shall be enacted within 30 days of the implentation of this > policy. > > > 5. Announcement of IANA allocations to the RIRs > > When address space is allocated to a RIR, the IANA will send a detailed > announcement to the receiving RIR. The IANA will also make announcements to > all other RIRs, informing them of the recent allocation. > > The IANA will make appropriate modifications to the "Internet Protocol V6 > Address Space" page of the IANA website and may make announcements to only > its own global announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry they > have been allocated. > > > 8. Rationale: > > The current IANA allocation policy for IPv6 is an interim policy that was > promulgated in 1999. Operational experience has demonstrated the current > minimum allocation size is too small; that the built in reservation system > that must be followed by the RIRs does not allow for efficient and effective > management of the resource by the RIR; and does not provide for an well > known evaluation criteria. This document does not stipulate performance > requirements in the provision of services by IANA to an RIR in accordance > with the policy. Such requirements should be specified by appropriate > agreements between the NRO and ICANN. > > > 9. Timetable for implementation: Thirty days after ratification by the ICANN > Board of Directors in accordance with the global policy development process _______________________________________________

5 6

[ipv6-wg@ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation
by Jeroen Massar 20 Aug '04

20 Aug '04

For people not on the arin-council (not likely ;) or the ppml@arin lists: -----Forwarded Message----- From: "Sweeting, John" <John.Sweeting(a)teleglobe.com> To: 'ppml(a)arin.net' <ppml(a)arin.net> Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation Date: Thu, 19 Aug 2004 17:36:56 -0400 I am submitting the following proposal IAW ARIN's Internet Resource Policy Evaluation Process. In the interest of all I would like to disclose up front that the information used to prepare this template was provided by ARIN staff. ############################################ Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries 2. Author a. name: John Sweeting b. email: john.sweeting(a)teleglobe.com c. telephone: 703-766-3042 d. organization: ARIN Advisory Council 3. Proposal Version: 1 4. Submission Date: 8/17/04 5. Proposal type: new, global 6. Policy term: permanent 7. Policy statement: 1. Minimum Allocation Size. The minimum size of any allocation of IPv6 address space from IANA to an RIR is prefix length /12. If this address space is not sufficient to meet the needs of an RIR for a projected 18 month period, IANA shall allocate to that RIR the address space for which it can provide justification. 2. Reservation of Unicast Address space. 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 addresses beginning at binary value 001 (prefix length /3) for its allocations of unicast address space. In order to support regional aggregation of IPv6 address space IANA shall establish a reservation of a prefix length of /6 from this space for each established RIR and for each emerging RIR. Allocations to each RIR will be from the appropriate reservation. 2.2. RIRs. Each RIR may apply its own respective chosen allocation and reservation strategy in order to meet the needs of its community and to ensure the efficiency and efficacy of its work. Such reservations made by an RIR will be considered as being allocated by that RIR when that RIR applies for an allocation of address space from the IANA. 3. Initial Allocation. 3.1. Upon implementation of this policy IANA shall allocate to each established RIR a /12 from the reservation established for each particular RIR. 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from the reservation set aside for that RIR. 4. Subsequent Allocation. An RIR shall be eligible for an allocation of at least a minimal allocation from the IANA when its current holdings are less than 50% of its 18 month requirement or when it has less than 180 days of holdings available. The IANA shall evaluate the requested allocation using a set of administrative procedures that are mutually agreed to by the IANA and the NRO. This set of procedures shall be enacted within 30 days of the implentation of this policy. 5. Announcement of IANA allocations to the RIRs When address space is allocated to a RIR, the IANA will send a detailed announcement to the receiving RIR. The IANA will also make announcements to all other RIRs, informing them of the recent allocation. The IANA will make appropriate modifications to the "Internet Protocol V6 Address Space" page of the IANA website and may make announcements to only its own global announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. 8. Rationale: The current IANA allocation policy for IPv6 is an interim policy that was promulgated in 1999. Operational experience has demonstrated the current minimum allocation size is too small; that the built in reservation system that must be followed by the RIRs does not allow for efficient and effective management of the resource by the RIR; and does not provide for an well known evaluation criteria. This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with the policy. Such requirements should be specified by appropriate agreements between the NRO and ICANN. 9. Timetable for implementation: Thirty days after ratification by the ICANN Board of Directors in accordance with the global policy development process. 10. Meeting presenter: Elected AC Member or the President of ARIN. END OF TEMPLATE ################################################

4 5

[ipv6-wg@ripe.net] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 : ip6.int shutdown?)
by Daniel Roesen 20 Aug '04

20 Aug '04

On Wed, Aug 04, 2004 at 03:59:35AM +0000, bmanning(a)vacation.karoshi.com wrote: > > So the whole delegation thing is broken. The int. TLD servers delegate > > ip6.int to imag.imag.fr which feels it self authoritative, but isn't > > in the NS RRset of the ip6.int zone. And ip6.int is delegated to > > munnari.oz.au which doesn't know about this (anymore). > > so... this was apparently enough to get the attention it > deserved. the long postponed migration from imag.imag.fr. > to ns3.nic.fr. is now "done" and imag.imag.fr. has been removed > from the NS list in the INT zone. > and munnari.oz.au has been removed. - more cleanup in the > next week or two. Well, two weeks down the road and things got even worse: NS list summary for ip6.int. from parent (int.) servers == flag.ep.net. ns3.nic.fr. y.ip6.int. == z.ip6.int. $ dig @flag.ep.net. int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9740 $ dig @ns3.nic.fr int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 334 $ dig @y.ip6.int int. SOA +norec | fgrep status: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17872 $ dig @z.ip6.int int. SOA +norec ;; connection timed out; no servers could be reached So we have 3 out of 4 servers totally broken. Looks like the importance of ip6.int is way overstated by some folks. Regards, Daniel

6 6

[ipv6-wg@ripe.net] RE: [sig-ipv6] Re: 9/9/2004 IP6.INT Removal (Was: 9/9/2006 :ip6.int shutdown?)
by Bound, Jim 20 Aug '04

20 Aug '04

> Can you identify those vendors which didn't react to a RFC > from 3 years ago? No that is up to those vendors product managers etc. What I know is from interoperability testing and cannot reveal. You missed mine and Bill's entire point. No one is against doing this it is a matter getting it into the production DNS code base. I think Bill should answer your other questions as you integrated my mail with Bill's. Your complaining here in IETF at least is irrelevant. And not the purpose of the IETF list IMO. I will not respond to other mail. If you want to discuss offline send me mail and I suggest you copy Bill. Ipv6.arpa is supported in the latest BIND releases and IMO all should be doing it, but I don't attribute it to being lazy at all. Again IPv6 is production code now vendors can't just change it as we do the public domain and university code base, it requires QA et al per the customer and that has cost and all changes to IPv6 at this point. /jim

2 1

[ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC
by leo vegoda 18 Aug '04

18 Aug '04

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:4600::/23 from the IANA in August 2004. You may want to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0