- ipv6-wg - mailman.ripe.net

New Document available: RIPE-349
by RIPE NCC Document Announcement Service 27 Jul '05

27 Jul '05

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE Document store. Ref: ripe-349 Title: Address Space Managed by the RIPE NCC Author: Leo Vegoda RIPE NCC Date: 27 July 2005 Format: PDF=31257 TXT=2986 Obsoletes: ripe-348 Short content description ------------------------- This document details the address space managed by the RIPE NCC and the longest prefixes allocated or assigned from different address ranges. The new version was needed to correct errors in the previous document. Accessing the RIPE Document store --------------------------------- You can access this RIPE Documents in HTML format at: http://www.ripe.net/docs/ripe-349.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 document on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-349.pdf PDF version ftp://ftp.ripe.net/ripe/docs/ripe-349.txt plain text version

1 0

Re: raw ipv6 sockets - sin6_scope_id field
by Aviraj Saha 25 Jul '05

25 Jul '05

Hi This value needs to be set to the interface index which is returned by the "ip link" command if you are using link local address, and if the 3 rd and 4 th byte is zero. Otherwise the value which is set in the third and fourth byte of the in6_addr structure. Hope this answers your question. With Regards Aviraj Saha

1 0

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

22 Jul '05

Dear Colleagues, The RIPE NCC received the IPv6 address range 2A01:0000::/23 from the IANA in July 2005. We will begin making allocations from this block in the near future. 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/ripe-ncc-managed-address-space.html This document has been updated to to provide extra information about the IPv6 address space we manage, following some requests we received. I hope people find the new format useful. Regards, -- leo vegoda Registration Services Manager RIPE NCC

2 3

[ipv6-wg@ripe.net] Allocation behaviour (organisations getting multiple /32's)]
by John Tran 19 Jul '05

19 Jul '05

Hi Jeroen, It is great to know that you are paying attention to allocations that are being made in other region. I would like to clarify the reason why APNIC made muliple allocations to UUNET. UUNET have multiple memberships with APNIC based on the networks in the region. As each economy, membership, managing their own address space therefore they also requesting for IP address separately. For aggregation purpose APNIC normally make allocations from contiguous block, as you can see from these allocations. This is similar to making a large allocation to an organisation then they further splitting between network for each economy. I hope the above explanation answered some of your queries if you need further information please feel free to contact us. Regards Son APNIC > > -------- Original Message -------- > Subject: [ipv6-wg(a)ripe.net] Allocation behaviour (organisations getting > multiple /32's) > Date: Sat, 09 Jul 2005 12:52:33 +0200 > From: Jeroen Massar <jeroen(a)unfix.org> > Organization: Unfix > To: ipv6-wg(a)ripe.net > > I just noticed that UUNET/MCI got an additional 3 /32's: > > inet6num: 2001:4441::/32 > netname: UUNET-AU-NETBLOCK-20050708 > descr: UUNET Australia Limited > descr: UUNET Network > country: AU > > inet6num: 2001:4440::/32 > netname: UUNET-HK-NETBLOCK-20050708 > descr: UUNET Worldcom Hong Kong Ltd > descr: UUNET Network > country: HK > > inet6num: 2001:4442::/32 > netname: UUNET-JP-NETBLOCK-20050708 > descr: UUNET Japan, Ltd > descr: UUNET Network > country: JP > > They where all assigned to 1 person, who apparently works for UUNET/MCI > in the US, not even the APNIC region, not even a role. > > Did somebody say goodbye to aggregation? > > Btw UUNET also has: > 2001:600::/32 (Europe) > > Apparently nothing in the US, in total 4x /32. 4 slots gone away. > Are all global companies going to request separate /32's ? > > Greets, > Jeroen > > > > -- > > _____________________________________________________________________ > Anne Lord, Communications Director <anne(a)apnic.net> > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 > --------------------------------------------------------------------- >

3 3

[ipv6-wg@ripe.net] ipv6-enabled webserver
by Thu Thuy 18 Jul '05

18 Jul '05

Hi, all I'm in my way to investigate on ipv6 trial and implementation. Now i'm stucking with a quite big question on ipv6-enabled software. As i saw, ipv6 web services is entirely implemented in almost such large ipv6 research projects as KAME, WIDE, GEANT... In Japan, some ISPs offer ipv6 web hosting to their customers. Many websites support native ipv6 such as RIPE, APNIC... Could you pls show me what kind of webserver software be used in above-mentioned projects and organisations to fully implement ipv6 web service to users. Thanks.

6 9

[ipv6-wg@ripe.net] Allocation behaviour (organisations getting multiple /32's)
by Jeroen Massar 09 Jul '05

09 Jul '05

I just noticed that UUNET/MCI got an additional 3 /32's: inet6num: 2001:4441::/32 netname: UUNET-AU-NETBLOCK-20050708 descr: UUNET Australia Limited descr: UUNET Network country: AU inet6num: 2001:4440::/32 netname: UUNET-HK-NETBLOCK-20050708 descr: UUNET Worldcom Hong Kong Ltd descr: UUNET Network country: HK inet6num: 2001:4442::/32 netname: UUNET-JP-NETBLOCK-20050708 descr: UUNET Japan, Ltd descr: UUNET Network country: JP They where all assigned to 1 person, who apparently works for UUNET/MCI in the US, not even the APNIC region, not even a role. Did somebody say goodbye to aggregation? Btw UUNET also has: 2001:600::/32 (Europe) Apparently nothing in the US, in total 4x /32. 4 slots gone away. Are all global companies going to request separate /32's ? Greets, Jeroen

1 0

[ipv6-wg@ripe.net] Minutes IPv6 WG RIPE 50
by David Kessens 18 Jun '05

18 Jun '05

I did not receive any comments on the draft minutes (v1) by June 10. Therefore, the draft minutes (v1) are now the official minutes of our session during RIPE 50 except for one typo that I found myself, in the last sentence, please replace 'exepected' by 'expected'. Thanks, David Kessens --- ----- Forwarded message from David Kessens <david.kessens(a)nokia.com> ----- Date: Tue, 31 May 2005 20:42:40 -0700 From: David Kessens <david.kessens(a)nokia.com> To: ipv6-wg(a)ripe.net Cc: meeting(a)ripe.net Please see below for our first cut of the minutes for our working group session during RIPE 50. Please let me know if you have any comments or corrections. The minutes will be declared final by Friday, June 10, 2005 if no significant changes (other than typo fixes and minor editorial issues) are found. David Kessens --- Draft Minutes (v1) IPv6 WG RIPE 50 When: Friday, 6 May 2005, 09:00 - 10:30 Where: C58, Clarion Hotel, Stockholm, SE Minute Taker: Adrian Bedford Quick Update from the RIPE NCC Regarding IPv6 Services (Ruud de Kooter - RIPE NCC) After the presentation, Ruud was asked if there were plans to integrate the IPv6 whois interface with the main whois. Currently the proxy cannot talk to the interface and this hampers some functionality (such as rate limiting). Ruud asked Shane Kerr to answer this. Shane explained that the RIPE NCC has a v6 proxy running over a v4 database backend. The RIPE NCC has been looking at how people use the database for two years and patterns suggest that now would be a good time to integrate native IPv6 into the server using /48 as a client identifier. Discussion on: Global IPv6 Routing Table Status (Gert Doering, Spacenet) Gert indicated that the Routing Working Group was discussing best practices for BGP filters. The overall thrust of the presentation was that v6 is growing smoothly with no big disasters so far. A question was asked about ratio comparison between the numbers of Autonomous Systems (AS) announced by IPv6 networks as opposed to v4. The current data suggests that there are 1.419 announced entries per originating AS for v6 and 10.308 for v4. A point was made that Deutsche Telecom (DT), who have one of the largest v6 allocations made to date would not announce their block as one AS, they would be more likely to split this and allocate blocks to different service providers for political reasons. Someone from DT commented that the company has the right to do this, though denied that the move was in any way politically motivated. Renumbering IPv6 Networks (Stig Venaas, Uninett & Tim Chown, University of Southampton) After the presentation, it was mentioned that we are assuming that customers of service providers will keep their space, yet ten years ago major providers did force renumbering onto customers. It was agreed that renumbering of IPv6 is, at least in principal, no different to what happened with v4. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond - Francis Dupont: Point6 (http://www.point6.net/ - Gert Doering: A new maillist for discussion of ipv6 operational issues was started: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ After the announcement of the list, it was agreed that having a publicly available archive of this new list would be a good idea. Although it exists on the site that hosts the list, this is a personal website and for stability purposes, maybe a copy of the archive should be placed elsewhere. It was felt that the RIPE website was unsuitable for this. - Carlos Friacas: o IPv6 - Advanced Network Developments's first year in Portugal o 9K IPv6 Schools' Network Initiative o About the IPv6 Steering Committee Revisiting the /48 recommendation There was a lengthy discussion around RFC 3177. It was made clear that the discussion was not intended to reach final consensus on all the issues involved, but merely to serve as a way to get an idea about the general direction on where the community would like to go to make it possible to write up an initial proposal. Many agreed that the /48 is too much for many users for now and in the future. A discussion followed about how we should define a site with the suggestion that we need to accept that this can remain a grey area, which is not at all well defined right now. Discussion is needed around this topic, though the group tended to accept that it might not be easy to put down limits in black and white. Most people in the room felt that RFC3177 needs a revision. Most people felt that the /48 limit itself doesn't need to be changed, but most agreed that there is a need for a new category that falls somewhere between /48 and /64 for users that have a need for subnetting but for which a /48 seems excessive. This category would fit the mass consumermarket or (very) small office market, however, it was noted that we should base the category on technical needs of the user, not in economic terms like mass consumer market. It is exepected that an Internet Draft will be written that can be discussed at RIPE 51. ----- End forwarded message -----

1 0

[ipv6-wg@ripe.net] documenting RIPE critical infrastructure/micro allocations
by Bjoern A. Zeeb 02 Jun '05

02 Jun '05

Hi, while updating some prefix filters I started a link collection documenting the entries. I have found that other RIRs (ARIN, APNIC) have neat documentation about the critical infrastructure/micro allocations assigned but I only found two references of the Block RIPE uses for v6 IXP assignments. | ARIN Critical infrastructure, micro allocations | http://www.arin.net/reference/micro_allocations.html | APNIC Critical infrastructure, micro allocations | http://www.apnic.net/db/ranges.html For LACNIC I haven't found any assignments but following documentation: | LACNIC Critical infrastructure, micro allocations | http://lacnic.net/en/politicas/ipv6.html 5.5. IPv6 micro allocations | http://lacnic.net/documentos/politicas/micro-asignaciones_ipv6-sp.pdf For RIPE Gert's page is talking about 2001:7F8::/29 and the DB entry. | http://www.ripe.net/whois?searchtext=EU-ZZ-2001-07F8 | http://www.ripe.net/ripe/docs/ipv6-policy-ixp.html Could someone add documentation/web page stating that RIPE is doing /48 assignments from this Block for critical infrastructure (read: IXPs)? Perhaps also giving a list of which prefixes got assigned already as these won't show up in delegated-ripencc-latest. Greetings Bjoern A. Zeeb -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT bz @ FreeBSD dot org

6 8

[ipv6-wg@ripe.net] Draft Minutes (v1) IPv6 WG RIPE 50
by David Kessens 01 Jun '05

01 Jun '05

Please see below for our first cut of the minutes for our working group session during RIPE 50. Please let me know if you have any comments or corrections. The minutes will be declared final by Friday, June 10, 2005 if no significant changes (other than typo fixes and minor editorial issues) are found. David Kessens --- Draft Minutes (v1) IPv6 WG RIPE 50 When: Friday, 6 May 2005, 09:00 - 10:30 Where: C58, Clarion Hotel, Stockholm, SE Minute Taker: Adrian Bedford Quick Update from the RIPE NCC Regarding IPv6 Services (Ruud de Kooter - RIPE NCC) After the presentation, Ruud was asked if there were plans to integrate the IPv6 whois interface with the main whois. Currently the proxy cannot talk to the interface and this hampers some functionality (such as rate limiting). Ruud asked Shane Kerr to answer this. Shane explained that the RIPE NCC has a v6 proxy running over a v4 database backend. The RIPE NCC has been looking at how people use the database for two years and patterns suggest that now would be a good time to integrate native IPv6 into the server using /48 as a client identifier. Discussion on: Global IPv6 Routing Table Status (Gert Doering, Spacenet) Gert indicated that the Routing Working Group was discussing best practices for BGP filters. The overall thrust of the presentation was that v6 is growing smoothly with no big disasters so far. A question was asked about ratio comparison between the numbers of Autonomous Systems (AS) announced by IPv6 networks as opposed to v4. The current data suggests that there are 1.419 announced entries per originating AS for v6 and 10.308 for v4. A point was made that Deutsche Telecom (DT), who have one of the largest v6 allocations made to date would not announce their block as one AS, they would be more likely to split this and allocate blocks to different service providers for political reasons. Someone from DT commented that the company has the right to do this, though denied that the move was in any way politically motivated. Renumbering IPv6 Networks (Stig Venaas, Uninett & Tim Chown, University of Southampton) After the presentation, it was mentioned that we are assuming that customers of service providers will keep their space, yet ten years ago major providers did force renumbering onto customers. It was agreed that renumbering of IPv6 is, at least in principal, no different to what happened with v4. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond - Francis Dupont: Point6 (http://www.point6.net/ - Gert Doering: A new maillist for discussion of ipv6 operational issues was started: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ After the announcement of the list, it was agreed that having a publicly available archive of this new list would be a good idea. Although it exists on the site that hosts the list, this is a personal website and for stability purposes, maybe a copy of the archive should be placed elsewhere. It was felt that the RIPE website was unsuitable for this. - Carlos Friacas: o IPv6 - Advanced Network Developments's first year in Portugal o 9K IPv6 Schools' Network Initiative o About the IPv6 Steering Committee Revisiting the /48 recommendation There was a lengthy discussion around RFC 3177. It was made clear that the discussion was not intended to reach final consensus on all the issues involved, but merely to serve as a way to get an idea about the general direction on where the community would like to go to make it possible to write up an initial proposal. Many agreed that the /48 is too much for many users for now and in the future. A discussion followed about how we should define a site with the suggestion that we need to accept that this can remain a grey area, which is not at all well defined right now. Discussion is needed around this topic, though the group tended to accept that it might not be easy to put down limits in black and white. Most people in the room felt that RFC3177 needs a revision. Most people felt that the /48 limit itself doesn't need to be changed, but most agreed that there is a need for a new category that falls somewhere between /48 and /64 for users that have a need for subnetting but for which a /48 seems excessive. This category would fit the mass consumermarket or (very) small office market, however, it was noted that we should base the category on technical needs of the user, not in economic terms like mass consumer market. It is exepected that an Internet Draft will be written that can be discussed at RIPE 51.

1 0

[ipv6-wg@ripe.net] Minutes from IPv6 WG - RIPE 49
by David Kessens 01 Jun '05

01 Jun '05

Please see below for the final minutes of our session during RIPE 49. The minutes are mostly the same as the v1 draft minutes that were posted earlier. Only differences are a typo fix and an improved summary of Jordi's presentation on 'Guidelines for ISPs on IPv6 Assignments to Customers'. I will sent out the draft minutes for our meeting during RIPE 50 in a couple of minutes. David Kessens --- Minutes from IPv6 WG - RIPE 49 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 provided an initial attempt on creating guidelines on how to interpret the official ipv6 assignment policy in practical terms. < 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 Bound 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