- ipv6-wg - mailman.ripe.net

Draft Minutes (v1) IPv6 wg RIPE42
by David Kessens 04 Jun '02

04 Jun '02

Please see below for the first version of the draft minutes of the IPv6 wg at the last RIPE meeting. I would like to thank the scribe for writing down the minutes. The minutes will be declared final by June 7th if there are no objections raised and/or major changes required. Thanks, David K. --- Draft Minutes of the IPv6 Working Group session of the RIPE 42 Meeting, 29 April - 3 May 2002 at the Krasnapolsky Hotel, Amsterdam, Netherlands. The session was held on May 2, 14:00 - 17:30 ----------------------------------- Chair: David Kessens Scribe: Rainer R|cker Attendees: 113 ----------------------------------- Agenda: 1st slot A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. IPv6 roadmaps of network equipment vendors a. Juniper (Jean-Marc Uze, Elise Gerich) b. Cisco (Simon Pollard) C. Global IPv6 routing table status (Gert Dvring) D. Tunnelbrokers & ipv6 in practice (Pim van Pelt) related discussion topic: do we prefer to use 6to4 instead of tunnelbrokers ?!? 2nd slot E. IPv6 Promotion Council Activities Overview (Kosuke Ito) F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? (Joao Luis Silva Damas, RIPE NCC) G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? (Joao Luis Silva Damas, RIPE NCC) related topic: 6to4 reverse delegations H. lbnamed Bug Discussion I. IPv6 allocation survey (Mirjam K|hne, RIPE NCC) J. Euro6IX and layer 3 IX addressing (Raffaele D'Albenzio) K. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) - French NIC initiative regarding DNSv6 deployment (Mohsen Souissi) L. LIR-WG session on IPv6 policy Z. AOB ======================== A: Scribe, Agenda bashing ======================== Two scribes from the RIPE NCC. One additional presentation from the tipster project was accepted for point K on the agenda. The Agenda was accepted. ======================== B. IPv6 roadmaps of network equipment vendors a. Juniper ======================== Jean Marc Uze (JMU) presented Junipers Roadmap for IPv6. The slides are available at Pim van Pelt (PVP): What about Filtering and OSPF6 ? JMU: OSPF6 for Junos will come in the second half of 2002 Filtering will come soon. ?: Are you working on 6-to-4 transition? JMU: Are there already applications that need it? ?: 6-to-4 relays will need it, these will be important for the users ?: What about 6PE? (MPLS over IPv6) JMU: Should be avoided on core routers, since it degrades performance. ?: Will you implement NAT/PAT for v6? JMU: Not on the short term. ======================== B. IPv6 roadmaps of network equipment vendors b. Cisco ======================== Simon Pollard (SP) presented Ciscos Roadmap for IPv6. The slides are available at Gert Dvring (GD): The IOS upgrade is not really free available - you need to buy the IP+ option package before you can make the upgrade. SP: This is true for the low-end platforms - but most people have IP+ anyway PVP: What about filtering and OSPF6. SP: Available - a beta of OSPFv3 will be out in October 2002. ?: What about Layer3 Switches? SP: They will come in Q3/2002 ?: Will there be a Ciso-PIX for IPv6? SP: This is planned for Q1/2003 ?: Is there 6PE and NAT/PAT for v6? SP: Yes, we have this for the PE-routers GD: IOS has become very large - you can't fit it into the small routers without upgrading Flash and Memory. Customers are not willing to spend money in order to upgrade. Make IOS smaller. An Image-size of 4MB would be good. SP: Customers will pay for the router-upgrade if they see the business drive of IPv6. However, Cisco is working on re-packaged IOS for the lower platforms. The memory-footprint will probably be 8 MB. GD: 4MB should be the target. ======================== C. Global IPv6 routing table status ======================== Gert Dvrings presentation is available at http://www.space.net/~gert/RIPE/R42-v6-table/ Conclusions: - Downstream filtering recommended - You should watch the announcements of your peers. PVP: 6bone has changed it's policy to give out /32 now, four of these prefixes should be visible. 15 are in the table. ?: Is there a canonical filter-list for IPv6 ? GD: Not yet. ?: Would you be up to maintain such a list? GD: I will discuss this with David Kessens and we should move the discussion on this topic to the mailing-list. === ;7777777;7777777;7777777 COFFEE BREAK ;7777777;7777777;7777777 10:35 - 10:50 ;7777777;7777777;7777777 === ?: Is it easy to filter unassigned ASNs ? GD: Technically this is possible but it's preferable to talk to the people that are making the mistakes. ======================== D. Tunnelbrokers & ipv6 in practice ======================== Pim van Pelts presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… PVP: Sixxs, a IPv6 tunnel-broker for LIRs in the RIPE-region is looking for participants that are willing to be a POP for this service. ?: What about the 6-to-4 tunnels? PVP: At the time we started, static tunneling was the only thing available. Today, if you run a 6-to-4 relay, it's easy for everyone to join, so it's also easy for everyone to abuse the service. If you host the relay, you also have to filter the incoming IPv4 traffic which is not easy. Attacks by script-kiddies on the next-hop of the relay (which is IPv4) are common today. DK: There have also been native V6-DoS-attacks, it's really scary. ======================== E. IPv6 Promotion Council Activities Overview ======================== Kosuke Ito's presentation can be found at ??? See also http://www.v6pc.jp/index_e.html - The audience had no questions or comments. ======================== F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? ======================== DK: IPv6 capable RR DNS Servers should be discussed in the LIR-WG. - the audience agreed ======================== G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? ======================== Joao Luis Silva Damas presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… The recommendation is to populate ip6.arpa and phase out ip6.int - but what is wanted and how shall we proceed? ?: Software currently relies on ip6.int - you can't just switch it off. ?: Can't we just duplicate the delegation-records? GD: A good solution would be a CNAME very high in the hierarchy DK: Can't we just do automatic delegation in both domains? Joao: ip6.int should be abandoned soon - if we duplicate it will not go away. GD: But older machines all use ip6.int. Joao: OK, for the time being both delegations are possible. But should it be done automatically or do we only delegate in ip6.int if someone really wants it? GD: RIPE NCC should investigate if it's possible to do away with ip6.int and make a solution with CNAMEs. Make some experiments and report at RIPE 43 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation. Wilfried Woeber: Automatic delegation for ip6.int and ip6.arpa appears the best solution, but if someone requests different delegations in ip6.arpa and ip6.int, RIPE NCC should not prevent this. Mohsen Suissis: RIPE NCC did this in the past, at least for 2002:0660::/35 both delegations were made. DK: RIPE NCC, could you investigate the possibilities? Joao: OK, we will do the automatic delegation in both trees by default and we will allow different configuration if the user wants it. ?: But would this approach not lead to inconsistent data in the two domains? DK: It's only reverse delegation, that should have no big impact. DK: OK, 6-to-4 reverse delegation will also happen in ip6.arpa. What about this? Joao: The draft on 6 to 4 DNS (draft-ietf-ngtrans-6to4-dns-00.txt) is not very specific. RIRs will do the delegation based on the IPv4 /8s that they are authoritative for, but anything else is not clear yet. DK: What about the 6bone addresses and ip6.arpa Joao: I am not familiar with that. DK: Could you investigate this and give a more specific presentation at RIPE 43? Joao: Sure. ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43 ======================== H. lbnamed Bug Discussion ======================== Francis Dupont explained that an updated version of lbnamed is available and urged everyone using lbnamed to update to the latest version. ======================== I. IPv6 allocation survey ======================== Mirjam K|hne announced that the survey will be published on the web. The presentation was not given in this session due to shortage of time. The survey is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… ======================== J. Euro6IX and layer 3 IX addressing ======================== Raffaele D'Albenzio's presentation is available at http://www.euro6ix.net/mantenimientos/e-doc_subidos/D1.1_Project_Presentati… (needs to be verified!) - The audience had no questions or comments. == DK reminded that there is not much time left. The time for each of the following presentations was restricted to less than 5 minutes. == ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond The Hungarian Tipster6 project ======================== Geza Turchanyi gave a short overview on the tipster6-project and provided some statistics on the v6-capability of several unix-distributions. (Sun, BSD, Linux) ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond French NIC initiative regarding DNSv6 deployment ======================== Mohsen Suissis presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… Mohsen Suissis pointed out that currently not many TLD-Nameservers are native v6-speakers. AFNIC is willing to help other NICs to roll out v6 DNS. AFNIC also applied to become secondary for ip6.arpa. The request was submitted to IANA but nothing happened so far. ======================== L. LIR-WG session on IPv6 policy ======================== The iproposal for a global interim IPv6 Allocation Policy was accepted by the LIR-WG. ======================== Z. AOB ======================== Nothing reported ======================== Summary of actions arising from this meeting ======================== 42.1 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation in the ip6.int tree. 42.2 ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43

7 11

New IPv6 blcok allocated to RIPE NCC
by leo vegoda 04 Jun '02

04 Jun '02

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:0800::/23 from the IANA in May 2002. 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: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

1 0

RE: New Document available: RIPE-233
by Michel Py 30 May '02

30 May '02

Havard, > Havard Eidnes wrote: > I have to ask a rhetorical question here, what is a "block" in > this context? > Is it a single routing announcement? Surely, it cannot be, > because the different root name servers are placed at different > points in the topology. The very purpose of placing them at different points is to have redundancy; so yes, for the same reason they must have different blocks. > I'll claim that the actual numeric sequence (or non-sequence) of > the IPv6 address blocks allocated to the root name servers do not > matter; the identity of the blocks will be well-known anyway, so > there is no robustness gain to be had from picking "obscure" or > "scattered" numbers. There is an advantage to scattered numbers, IMHO. Since they are scattered, nobody will try to aggregate them and suppress the specific announcements. Martian configs do happen; not often but they do. > I do however agree with those which have said that a root name server > should not have its address changed when it moves between RIR regions; > the whole point of this "special" assignment to the root name servers > is to avoid *any* renumbering because the DNS bootstrap data is > (currently) distributed in a static configuration file. There are (at least) two ways to achieve this: 1. Two-space systems (the servers would have a unique identifier and multiple changeable locators). 2. "special assignement" otherwise called PI. I think the RIRs have acted responsibly so far in not showing the bad example of allocating themselves a PI block. A short-term fix to this would be a two-space system where the locator initially assigned could be transformed into the identifier later. Michel.

1 0

New Document available: RIPE-233
by RIPE NCC Document Announcement Service 30 May '02

30 May '02

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-233 Title: IPv6 Addresses for Internet Root Servers in the RIPE Region Author: Joao Luis Silva Damas Date: 24 May 2002 Format: PS=9362 TXT=2362 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- The "IPv6 Addresses for Internet Root Servers in the RIPE Region" document describes the special case assignment policy for Internet DNS root servers in the RIPE region. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The document will be available shortly on the FTP-server at: ftp://ftp.ripe.net/ripe/docs/ripe-233.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-233.txt plain text version You can already access the RIPE document in HTML format via WWW at: http://www.ripe.net/docs/ipv6-rootservers.html Kind Regards, Jeroen Bet RIPE NCC Webmaster

10 14

RE: Draft Minutes (v1) IPv6 wg RIPE42
by Jean-Marc Uze 29 May '02

29 May '02

Hi David, > ======================== > B. IPv6 roadmaps of network equipment vendors > a. Juniper > ======================== > Jean Marc Uze (JMU) presented Junipers Roadmap for IPv6. > The slides are available at > > Pim van Pelt (PVP): What about Filtering and OSPF6 ? > JMU: OSPF6 for Junos will come in the second half of 2002 > Filtering will come soon. I think you mean OSPFv3. Regarding IPv6 filtering, I said that it will be available in a couple of weeks. Which is true ;-), as it is now available in last release: JUNOS 5.3 http://www.juniper.net/techpubs/software/junos53/swconfig53-ipv6/download/f… > ?: Are you working on 6-to-4 transition? > JMU: Are there already applications that need it? > ?: 6-to-4 relays will need it, these will be important for the users > ?: What about 6PE? (MPLS over IPv6) > JMU: Should be avoided on core routers, since it degrades performance. I think what I said is that 6PE will be attractive for SP that want to deploy native IPv6 service with an existing core backbone that can't implement IPv6. With 6PE, the core is not involved in IPv6 forwarding, just MPLS forwarding. So 6PE is a good solution to integrate native IPv6 service in existing backbone, as it required IPv6 routers only in the edges. This is in our plan for second half 2002. > ?: Will you implement NAT/PAT for v6? > JMU: Not on the short term. > Regarding the transition mechanisms, the message I wanted to give is that the mechanisms are numerous. 6to4 had gained a lot of traction last year but in recent times IETF has come up with even newer transition mechanisms. The priority was dual stack, IPv6 in v4 tunnels, as well as Circuit Cross Connect support for IPv6 (layer 2 VPN over MPLS). This phase is achieved. 6to4 as well as other mechanisms like NAT-PT are under investigation but we didn't get a strong push from our customers so far. Inviting the vendor to the RIPE IPv6 WG is a good way to discuss this topic. After the first feedback received at the conference we would be more than happy to get more feedback from you. David, I'm going to send you my presentation separately (big file) so you can put it on your web server. Thank you for your invitation. Regards, Jean-Marc Jean-Marc Uzï¿½ Liaison R&E Networks and Institutions, EMEA Juniper Networks 70 Boulevard de Courcelles - Paris 75017 - France Tel: +33 (0)1 44 01 60 24 Fax: +33 (0)1 44 01 60 90 Mobile: +33 (0)6 15 43 25 12

1 0

RE: New Document available: RIPE-233
by matthew.ford＠bt.com 24 May '02

24 May '02

" It is not associated with the organisation(s) that operate the root server at a particular point in time and these organisations should not use the address space to provide any services not related to the root server." s/should/must/ Mat. > -----Original Message----- > From: RIPE NCC Document Announcement Service [mailto:ncc@ripe.net] > Sent: 24 May 2002 16:01 > To: ipv6-wg(a)ripe.net > Cc: lir-wg(a)ripe.net > Subject: New Document available: RIPE-233 >

1 0

Implementation of Global IPv6 Policy
by Mirjam Kuehne 24 May '02

24 May '02

Dear Colleagues, We are pleased to announce that the RIPE NCC will implement the new Global IPv6 Policy on 1 July 2002. This policy has been agreed by the communities of all the Regional Internet Registries (RIRs). Before 1 July 2002 we will publish and announce the following as RIPE Documents: - Global IPv6 Policy Document - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region (for prefixes shorter than a /48) Regards, -- Mirjam Kuehne RIPE NCC

7 6

Re: Getting addresses
by João Carlos Neves Cabral 21 May '02

21 May '02

Hi everyone, Perhaps this has been mentioned on the thread before, if so I must have missed it with so many messages, sorry :( Could someone point me out to the RIPE allocation policy? Which of the two below applies now ? I was under the impression that: IPv6 Address Allocation and Assignment Global Policy applied now, but I can't find a form @ RIPE for requesting IPv6 addresses with this policy. Is the old policy still in place ? Sorry if it is a dummy question, Thanks for any information, Best Regards, Joao Cabral. JC310-RIPE ---------------------------------------------------------------------------- ------------- in ripe-196: http://www.ripe.net/ripe/docs/ripe-196.html Subject to sections 4.2.2, and 4.2.3, Regional IRs will only make an initial allocation of sub-TLA address space to organisations that meet criterion (a) AND at least one part of criterion (b), as follows: a. The requesting organisation's IPv6 network must have exterior routing protocol peering relationships with the IPv6 networks of at least three other organisations that have a sub-TLA allocated to them. AND either b(i). The requesting organisation must have reassigned IPv6 addresses received from its upstream provider or providers to 40 SLA customer sites with routed networks connected by permanent or semi-permanent links. OR b(ii). The requesting organisation must demonstrate a clear intent to provide IPv6 service within 12 months after receiving allocated address space. This must be substantiated by such documents as an engineering plan or deployment plan. ---------------------------------------------------------------------------- -------------- in IPv6 Address Allocation and Assignment Global Policy: ftp://ftp.cs.duke.edu/pub/narten/ietf/global-ipv6-assign-2002-04-25.txt quote: To qualify for an initial allocation of IPv6 address space, an organizaion must: a) be an LIR; b) not be an end site; c) plan to provide IPv6 connectivity to organizations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organizations within two years. ---------------------------------------------------------------------------- -------------- --- Joao Cabral Vodafone - Portugal Engineering - Network Planning and Design Tel: +351 - 23 - 0915818 Mobile: +351 91 8736538 ---------- This message may contain confidential information or privileged material, and is intended only for the individual(s) named. If you are not in the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

1 0

RE: Getting addresses
by Michel Py 20 May '02

20 May '02

Gert, > Gert Doering wrote: > I'm strictly against IPv6 PI. The problem in saying this is that you do not have a replacement solution. The reason we never got rid of the v4 swamp crap is because we do not have to offer people that have a prefix in the swamp any alternative that makes business sense. I hear a swamp /24 sells for $10,000. When IPv6 becomes a real business, becoming a LIR will just be "cost of doing business". > IPv4 PI nowadays is far too cheap, at least in RIPE land I know lots of people in RIPE land that says it's far too pricey. > I do not say that there won't be anyone doing this - but I am fairly > sure it *will* reduce the number of "pseudo-PI-for-multihoming" > prefixes we'll see. I do not agree. I have been known to get stuff from RIRs that I am not supposed to have, and becoming a LIR is no different. You just have to fill the paperwork the way it is supposed to. I am not saying that cheating (to become a LIR when all you need is to be multihomed) is good, but thinking that RIRs can enforce a no-cheat policy is worse. > /48s from LIR-/32s being visible in "the table". At least > "regionally", like "two AS hops away from the originating AS", or > something like this. This is not enough for most multihomers. Actually, it might be considered worse than being singlehomed: It gives the primary LIR even more leverage. It seems to me that you might not have realized something fundamental about IPv6: it is never going to fly if it does not offer _better_ than IPv4 does; just being even would be having some form of address independent from the provider, and you still have to come up with a good reason to go through the migration headache. Michel.

1 0

RE: Getting addresses
by Michel Py 16 May '02

16 May '02

Pekka and Gert, > Pekka Savola wrote: > I don't think university-like organizations ever need more than > a /48. One and the only really problematic thing is if they > provide access to students/staff/etc., e.g. via DSL, dial-up, > dorms or what. /64 would usually be ok (except very large > universities and the like), /48 would not. Universities are ISPs, and it is perfectly legitimate to assign /48s to students. Invariably, each class I teach IPv6 subnetting, students ask me "ok, now what if want to try this?" and my answer is "go to freenet6 and get a /48". Yes, they're going to use only two or three subnets possibly with only with one host each but they do need more than a /64 and I do not think that allocating anything between a /48 and a /64 is debatable at this point. > How do you think that e.g. Nokia, Cisco or Microsoft will do this? > I think everyone agrees that /48 should be very well enough, Pekka, I am sorry but this is wrong. One of the valuable participants we have in ipv6mh is Craig Huegen, the lead network architect for Cisco, and the _first_ question he asked about the protocols we are developing is how they would work for people that need more than a /48. With an HD of 0.8 Cisco needs between a /46 and a /45. > Gert Doering: > So with some reason instead of a "this can't work!" attitude, I think > this can work well - if one insists on doing non-useful things, it will > break (but yes, this is a problem with the "one site" = /48 rule, because > it's too vague to work unless people are reasonable). Yes, the "one site" = /48 rule leads to terrible HD, but a university with 50K students would indeed fit within a /32. The question is: will people be reasonable. Michel.

12 28