Hi, Please see below for the minutes of RIPE 35. I would like to thank Monica Cortes for doing the hard work of taking the minutes and turning them in to me quickly after the meeting. Please let me know if you find any typos, errors or omissions. The minutes will become final by April 7, 2000 if no problems are found besides typographical errors. David K. --- ------------------------------------------------------------------------- RIPE 35 Amsterdam, 23rd January 2000 IPv6 Working Group Chair: David Kessens Scribe: Monica Cortes A. Administrative stuff - Appointment of scribe - Agenda bashing B. Comments on the Provisional Assignment and Allocation of IPv6 Addresses Policy Document (IPv6 WG - LIR WG) (Mirjam Kuehne) - Why is the dial-up link treated differently - should such users get a /48 or a /64? - Public or private addresses for point-to-point links? - What constitutes 80% utilisation? C. Status of 6bone (David Kessens) D. Issues with filtering of 'IPv6 in IPv4' packets (Thomas Trede) E. IPv6 Meeting in Berlin (Thomas Trede) && IPv6 Forum (Juergen Rauschenbach) F. Quick summary of EOF morning session (Wilfried Woeber) G. European developments/initiatives regarding IPv6 (input from audience) H. Reports on on-going projects, success & failure stories on IPv6 (input from audience) I. Input from other working groups Z. AOB Action points from RIPE 34: NONE Action points from RIPE 35: NONE -------------------------------------------------------------------------- -- A -- Administrative stuff Scribe was appointed, the agenda was approved without changes --B -- IPv6 Policy Document Review (ripe-196) (Mirjam Kuehne) Mirjam presented the open issues and possible points of disagreements of the Allocation of IPv6 addresses document currently in use (ripe-196). It was created in April of last year, it was reviewed by all RIR's regions and the IETF. More discussions on all RIR regions will take place in the near future and the input is welcomed: RIPE meeting this week, next week is the APNIC/APRICOT meeting, ARIN meeting is the first week of April, RIRs will have a retreat the second week of April, where this document will be discussed. New draft document will be available before RIPE 36. 11 allocations have been made so far. Open Issues: * section 4.2.3.2 on multi-homing, to be written, currently missing Mirjam: There is little experience in multimhoming and is still an open issue being discussed at the IETF and EOF. Should the multi-homed have two NLAs assigned each from one provider? Person1: It is better to assign only one NLA as otherwise he would need to AS numbers and which should he use? Person2: What is multi homing? one node with several ip addresses or better one address accessed via multiple paths? David Kessens: Multi-homing is a non solved problem but needs an allocation policy. Wilfried Woeber: The definition of multi-homing is not clear yet, we should use multi-homing with the current understanding of this term. PI addresses are not valid for IPv6, we don't want to allocate a TLA for all multi-homed sites. Person1: Then multi-homing can only be done by big organisations Person3: What is wrong with multiple AS numbers? Person4: BGP does work, but will stop working if the number of ASN keep growing as now. There will be a shortage of ASN and huge tables. BGP does not scale and won't work. David Kessens: Aggregation is the only solution for this Person1: Ok, then let's renumber when a solution is in place David Kessens: IPv6 design tells you how to do things. The allocation document should not have things different than what the standard defines. It is not politically correct Mirjam: We should have some text on the document Person5: Lets add to the text that it is provisional as there are no standards yet * section 4.2.8 on allocations to NLA registries * section 4.3.1 on assignments to end users Mirjam: There is no sufficient experience available still, there are no policies and procedures available, input from the community is appreciated. Bernard Tuy: A proposal would be that they come back when your TLA is allocated an 80% on one level of hierarchy. Person: Why not indicate that this is a life document and that it can be reviewed in the future? Daniel Karrenberg: Lets put a date for review. * definition of "transit-provider" mentioned in the document. Mirjam: The IETF would not come to a definition of this either and they recommended to remove it altogether from the text. This is our recommendation as well. WG agrees. * definition of TLA/NLA/SLA registry Mirjam: Is a TLA registry the one allocation or assigning TLAs or the one receiving the allocation? The proposed idea is that a TLA registry is the one that allocating or assigning TLA addresses. The same goes for NLA and SLA registries. WG agrees. * section 3.2 on Point-to-Point links Mirjam: should they have public or private addresses? The IETF chair suggests them to be public addresses. Should we remove the paragraph altogether? David Kessens: I agree with the chair, aggregation is the important thing not conservation. This is not the time to save address space. Person: (Nods) it is valuable to drop it and have global addresses for debugging purposes WG agrees. * section 4.3.1 on Dial-up Assignments Mirjam: There is controversy about what subnet size should be assigned to a Dial-up customer: a /48 or a /64? There is no enough experience on this; only on NLA allocations or assignments reassigned from the 11 sTLAs. IETF suggests to give a /48. Person1: What if we just put a magic number, nobody really knows what makes sense. We could indicate that this will be reviewed. Wilfried Woeber: I agree with the IETF on the Point-to-Point links, but why a /48 instead of a /64 for my dial-up host at home? Mirjam: Should we create a group that investigates this issue? Wilfried Woeber: Technical aspects should be investigated and then come up with a recommendation or a BCP. Person2: Every user of mobile phones will get a /48? It is difficult to discuss where to put the boundary for a /48 or /64. We need more experience? David Kessens: One possibility would be to have a /64 for one single network and a /48 for more than that. Mirjam: We will have more discussions with the other RIRs and come back with a proposal. * section 4.2.5 on 80% Utilisation Mirjam: There is a question on what is meant by 80% Utilisation, is this on only one level of hierarchy or all the address space allocated? Do all the allocations and assignments need to be registered? Person: 80% is a xxx million customers. Will that ever be full? Daniel Karrenberg: This was a safeguard for people who wanted to be assured that they could grow and have more addresses in a future point in time. Person1: How to use the NLA field? One can imagine all types of possibilities from the bad two extremes: - NLA1 has 1 bit which means 2 ISPs and NLA2 field 8bits or 256 end sites or - NLA1 has 8bits or 256 possible ISPs and NLA2 field 1 bit so 2 end sites each David Kessens: IETF WG chairs say that a /29 is already a slow start, a /35 is not much. There is a fear that conservation is the main argument and not aggregation Mirjam: Aggregation is the key of the document, we allocate a /35 but we reserve the rest of the /29. We will give more space depending on the usage rate. If the usage rate is high the next allocation will be the full /29. If it is slow only a few more bits will be given. Wilfried Woeber: We need more real life experience before changing the document David Kessens: What expiry date should the document have? After WG input agreed upon: 12 months Bernard Tuy: I would like to say to the RIPE NCC: keep it going! It is very useful to have this discussions also months after the first document was drafted. COFFEE BREAK -- C -- Status of the 6bone (David Kessens) Presentation can be found at: http://www.kessens.com/~david/presentations/ In the last 4 months the 6bone registry as seen a 15% growth. The number of countries that have joined the 6bone is stable now. The number of queries have decreased about 20% to 2400 queries a day. This is because a heavy user of the database is now running a mirror of his own. The number of updates is stable as well, about 8 update a day. -- D -- Issues with filtering of 'IPv6 in IPv4' packets (Thomas Trede) Presentation can be found at: http://www.tu-darmstadt.de/hrz/staff/data/trede/RIPE35-trede-ipv6conf.ppt Thomas asked the audience if anyone had experienced any type of filtering of IPv6 traffic by filtering IPv6 in IPv4 packets. This had been seen by some people although it was not confirmed. Wilfried Woeber: Is it general tunnel filtering or targeted filtering? Thomas Trede: Only one site experienced this, and it is not clear what type of filtering it is. It is good to see that no-one else in the audience had experience something similar. -- E1 -- IPv6 Meeting in Berlin (Thomas Trede) This is the second IPv6 forum meeting and was held in Berlin. There were many talks so only the highlights of the talks will be presented here. More about this meeting can be found in http://www.berkom.de/ipv6 Presentations: - NTT plans a world wide IPv6 native network. NTT won't charge for access to their IPv6 network from USA or EU. - NATO announced in 1999 the principal decision to go for IPv6 The German Navy have an IPv6 Application with QoS for the Navy. - Deutsche Telekom outlined the DTAG, ecomerce and end-to-end security - CSELT had a demo of tunnel-broker. In less than 1 minute one could have ipv6 connectivity - IPv6 forum Chair talked about the Forum Mission and membership (70 members) - Vendors & ISPs are moving forward: - Sun, Compaq (Digital) will have IPv6 in their new OS version - Routers: Telebit has IPv6, Cisco say: 'by the 2nd half of 2000', their IOS has still bugs in their current version - Microsoft: Windows 2000 won't have IPv6 - Kame project has been prolonged until 3/2002 - 3Com had a presentation about 6over4. Support fro IPv6 in the USA is increasing Conclusions: - The implementations are stable and ready, in the router market Cisco is the mayor obstacle. - More engagement of ISPs is needed. More connectivity tests need to be performed, tests on Exchange Points, and customer connectivity. - Are we ready? There is the chicken and egg problem: Hardware or software, everyone points to the other-one. -- E2 -- IPv6 Forum (Juergen Rauschenbach) Presentation can be found at: http://www.kessens.com/~david/presentations/ The Forum's Mission is to promote IPv6 by improving the market and user awareness of IPv6, creating a quality and secure Internet. It promotes new IPv6-based applications and solutions, promotes the knowledge and experience sharing among members, resolve issues that create barriers to IPv6 deployment. There are 78 members per 17th February: 29 in North America, 36 in Europe, 13 in Asia/Pacific. There are 12 research organisations and the biggest group are network suppliers, though bit telco's and ISPs are also present. The IPv6 Forum consists of a Board of 8 members, a Promotion Group (15 Marketers) and a Deployment Group (34 Experts). In this last group is the IPv6 Technical Directorate that is responsible for the technical part of the Forum, gives direction and advice to the Forum and the industry and makes the link between IETF and the industry. The Promotion Group has IPv6 education and awareness programs, organises global IPv6 Summit/Conferences, has a Strategic Alliance Program and Strategic Alliances with the UMTS Forum, the GSM Association, Stardust.com, GIPF (France), ETSI (EU) and 3GPP. IPv6 Summit Program: - Oct 1999 Paris - Dec 1999 Berlin NEW: - 14-15th March 2000 in Colorado, US Summit - 10th May 2000 in Birmingham, UK IPv6 Event - Oct 2000 in Tokyo, IPv6 Summit - 29th Nov - 1st Dec 2000 in Madrid (Spain), IPv6 Summit IPv6 Forum participates and cooperates in other events: - 14-16th March 2000 in Paris, on Mobile.ISP - 15-17th March 2000 in UK, on IP QoS - 28-29 Oct 1999 in Paris, on IPSec 6INIT (IPv6 INternet IniTiative) is one of the projects of IPv6 Forum. Some links: - IPv6 Forum: www.ipv6forum.com - Berlin Summit: www.berkom.de/ipv6 - US Summit: www.stardust.com/ipv6summit - sTLA allocations: www.dfn.de/service/ipv6/ipv6aggis.html - 6INIT: www.6init.org -- F -- Quick Summary of EOF morning session (Wilfried Woeber) There were two presentations one from Stuart and the other from Woeber. Both presentations were largely in agreement about the results and future way to go. There is still work needed on IPv6 routing and DNS infrastructure of IPv6 transport. Person: We found two mayor problems on our setup. One is finding the bit boundaries and having new procedures, and the second is that we found problems in our accounting and billing infrastructure. David Kessens: I will try to organise an IPv6 tutorial, something more hands-on -- G -- European developments / initiatives regarding IPv6 (input from audience) Bernard Tuy: We want to deploy an IPv6 native backbone in our topology. There will be more info in slides in Budapest. -- H -- Reports on ongoing projects, success & failure stories (input from audience) no input -- I -- Input from other working groups David Kessens: EIX working group was talking about allocations of TLA to exchange points and could not take any resolution on this, so this point has come back to the IPv6 WG. Mirjam Kuehne: The IX points don't think it is a good idea to act as an NLA registry for their members. The RFC has this possibility as a concept, but the EIX did not see it as feasible at this point in time. Christian Panigl: The IX would have to give transit to the transit points of members. This is a contradiction of the neutrality of an IX point. Mirjam Kuehne: The IETF worked on the possibility of the existence of a different type of IX point. Bernard Tuy: Where should these policy discussions take place: LIR WG, IPv6 WG the EIX WG? How can we have better interactions? David Kessens: For this reason we hold a joint WG session with LIR WG in the first half. Wilfried Woeber: In order to tackle the problem, we should set up an editorial commity that puts comments and suggestions together and forward the document to the mailing list or move the IP address issues to the LIR mailing list to focus the discussions. David Kessens: It is an LIR issue, but IPv6 is still experimental and should be kept in this WG. Bernard Tuy: Let's keep it like today in shared sessions. Mirjam Kuehne: After the meetings with the other RIRs, we will submit the document to the IPv6 WG and LIR WG. In the IPv6 WG the people are more involved in these issues. -- Z -- AOB none. Session closed