Hi, Please see below for the minutes of our session. I would like to thank Petra Zeidler for being so kind to take the minutes. Please send minor corrections directly to me. I will declare the minutes with corrections final when no major comments are received in two weeks from now. David K. --- ----- Forwarded message from "S.P.Zeidler" <spz@serpens.de> ----- Minutes of the IPv6 WG meeting at RIPE 33 Agenda: - Administrative Stuff Scribe is Petra Zeidler Agenda bashing was rather bashful (no changes) - Status of 6BONE (presented by David Kessens) http://www.ip.qwest.net/~david/presentations/ Questions: 1) what about efforts to harden the 6BONE? was being discussed at the last IETF, see minutes of that 2) what's the status of 6REN? 6REN was being in full progress, and one should contact Bob Fink for specifics - IPv6 in practice (presented by Jan Czmok) http://engr.gigabell.net/ipv6/pres/ Questions: 1) what was the difficulty with multi-homing? unresolved issue as to how to do that with customer-type address ranges 2) why was porting applications to IPv6 so important? "Bump-in-the-stack" exists, but one reason to go to IPv6 right now are the IPv6 network client configuration niceties 3) there are reverse DNS tools for IPv6, why was this considered a problem? The current tools need too much know-how, they're not "customer-safe" 4) which applications needed porting the most? those that users won't want to do without in the context of using the Internet, i.e. mainly web browsers 5) (Comment, rather) IPv6 over IPv4 with dynamically assigned addresses wasn't a problem any more with the availability of the tunnel brokers. - European developments and initaitives regarding IPv6 (audience) - Bernard Tuy was working on IPv6 over ATM and can be contacted regarding that - Wilfried Woeber reported having held a presentation about a test program lately. An IPv6 native backbone in Europe would be desirable, one should look out for 6EIX and also see the developments until September. Deploying IPv6 in a production environment would be more an administrative than a technical problem. - Francis Dupont asked who actually used IPv4 non-tunneled multicast and if the current lack of IPv6 multicast capabilities in the current IPv6 Cisco IOS was perceived as a problem - IPv6 should be on the terminal-LAN of RIPE 34 as well - IPv6 allocation progress (presented by Miriam Kuehne) see slides for the talk Discussion: - the documentation mentions default-free zones, a definition ought to be added - Q: Allocations are based on track record, why not use IPv4 address usage track record? A: the two need not necessarily compare - Q: why mention the future possible end of this Sub-TLA-space in the document? A: Decision processes slow down, one should be kept aware that new provisions will have to have been taken by then - Q: what is the term of the policy? A: it will be under constant review - Q: how would one get IPv6 customers or peerings without address space? A: in the beginning one'd have gotten space by the bootstrap procedures, or via 6BONE, later through ones upstream - Q: are the numbers (>= 3 peerings, >= 42 customers) ok? A: there was no dispute that 42 was the answer - Q: why have 2 valid reasons to get space currently, wouldn't the latter suffice? A: it should give those considering a request a frame of for what size a Sub-TLA would be seen appropriate; also, it's a heirloom from the ARIN allocation policy - a rewording of "immediate intent" was suggested, as it sounded none too realistic - Q: is further delay in the accepting of the policies expected? A: Not really, there were unwritten parts, but that shouldn't stop starting out. - Q: are there essential parts that should go in before this becomes policy? A: there were no objections to go ahead with the current state of the document - Q: was there input on the missing sections? A: - - address space not being owned by the assignee ought to be worded more clearly - "you might be required to renumber in the future" was very vague, suggestion to clarify that to: "in order to continue taking part in the Internet a renumbering may be neccessary for technical reasons". - the policy should reference the appropriate IETF documents - Q: why bother to slow-start S-TLAs? A: in order to get a range of prefix-lengths - Q: how long will the period to comment the policy be? A: not much longer - this policy is a common product of all the RIRs and will be shared Action points: 33.1 RIPE NCC and the other regional registries will finalize the allocation draft document and start allocating IPv6 addresses as soon as possible ----------------------------------------------------------------------