August 2002 - ipv6-wg - mailman.ripe.net

Re: Getting addresses
by Wilfried Woeber, UniVie/ACOnet 25 Oct '02

25 Oct '02

Hi Rudolf! >I am new to these discussions on the list, so if I am saying something >stupid, please tell me so. Not at all! The worst thing that is happening here is that we re-iterate things. So what.... >>I don't have a point of view. A lot of people are telling me they will >>choose the /48 road. Without a detailed definition of site, almost >>everyone's view will have to be accepted. That's what I am seeing in all >>these discussions. > >That is what has been bothering me the most in the whole discussion about >who gets a /32 assignment and who doesn't. This is one thing that is so surprising for me in these discussions: There seems to be an implicit assumption that we SHOULD come up with all sorts of criteria to BLOCK distributing IPv6 addresses, rather than getting the technology rolled out :-(). As an aside, I still see IPv6 address space as a *global resource*, not something which a (roughly) self-defined group of entities partitions amongst them (tier-X ISPs). Becoming an LIR is possible for (almost) every type and shape and size of organisations (at least in the RIPE region) - but it is not for free. There are quite some good reasons for distributing globally unique IPv6 addresses to entities which would not fit the "classical" ISP (or even tier-X ISP) definition. And those amongst us who worry about end-to-restoration, making things simple(r), looking into the future, should recognize that there is no "rfc1918" space in v6-land. (Yes, I know about the site-local address concept. But why should we plant time-bombs ticking when there are plenty of those magic bit combinations around?). >Both the number of /48 >assignments as well as the determination of what an end-site is, are >completely arbitrary I agree. It's the same level of "arbitray-ness" that is wired into "200 sites", trying to define an ISP, and the like. It's better than nothing at all (i.e. no consensus) - at least for now. >and therefore in the long run unworkable. We'll see. We havent tried yet. And by the way, we have tried to define "ISP" in v4-land for years, and we failed. > Almost >everyone that is an LIR now, is able through one trick or another to >justify an allocation of a /32 Actually, this was the point of view that had emerged in the RIPE region during the Jan'02 meeting. "Every LIR should get an allocation" if they can document the need for 1 address. The "tricking" started to come into the game when we again tried to impose (artificial) criteria/ limits/ restrictions/... Btw, I still do remember the days (around '93) when a LIR was allowed to give away a /23 to every "site", no questions asked. And it didn't *break* the Internet, it made it *succeed*! In the end every policy is a compromise. Some of us don't like the version we do have on the table right now because we think it is too restrictive. Some of us dislike the thing because we perceive it as too liberal. Such is life. > and as Joao points out, the RIR's won't be >able to do anything against it. The RIRs should not act *against* "something"! They are supposed to execute a consensus, written down in a document and agreed by the community! It took a loong time, and many discussions, to arrive at the doc we do have on the table right now. And there are things in it which are "fuzzy". That was done deliberately, after trying (and failing) to come to more precise (and sometimes restrictive) definitions that would still be acceptable to all the 3(4) regions. On the other hand quite a few things were straightend out (like the exclusive reference to a /48 holder), and I'd really urge all of you to *completely read* the final doc. > And then I wonder if in the long run we >won't see a global routing mess, because many more organisations will be >able to register as LIR and justify a /32 in the same way. This is exactly >what the requirement for 200 potential sites tries to achieve, but fails to >do. Well, again one of those "assumptions" that this is bad :-) I still think that we can accommodate a *lot* of IPv6 routing with the slack from the (predicted) growth in v4 that did NOT happen in v4-land.... >The community should be able to come up with a better definition of who >should be allowed to get a /32 and who is condemned to go to an upstream >provider. This should be more objective than the current rule and not >result in the problems that we see now for RIR's and IXP's and smaller >NREN's and ISP's, . Welcome to the show. I hope you would be around to help when we have to re-work the thing to adapt it to the evolving Internet :-) Just one comment on the use of "smaller" here: we couldn't come up with a good set of criteria to define a "smaller" "whatever". What are the criteria? Real estate? Gigabit/sec? Terabit storage? number of contracts? number of web pages? annual turnover? annual profit (or loss :-)? The tier-1 ISP of yesterday is the chapter 11 case of today and a department of another ISP tomorrow. As I said during the discussion, (given the IETF recommendation) a SOHO customer of a "commercial" ISP s/would qualify for a site .eq. a /48. Probably a handful of physical subnets would be used. And it is easy to have a few hundred of those, eventually (probably). A university, or a regional edu-network could be structured alongside a single /48 as well. Such a "site" could happen to serve some 5000..10000 ..50000 users in quite some hundred physical subnets (LAN, ISDN, ADSL, wire-less). Which of those network would be the "smaller" one?? Is it really "cheating" if we start to treat a primary and secondary school as a site with their own /48? Or the other way 'round, why is the "commercial ISP" not treated as a site with *1* /48? I am stretching things here just a little bit, on purpose... >I think we can evade a global routing slump if we allow the RIR's to >continue the excellent work they have done in the last couple of years. >They have conserved adresses well. In one of the doc.s there is that famous statement that conservation and routing aggregation can, or tend to, be conflicting goals. >But we should provide them with adequate >rules to work with, so that they can aggregate well in the IPv6 future too. > >>The problem is the lack of arguments for an RIR on what is the right thing >>to do. >> >>Joao > >Let us provide them with the right arguments to do the right thing. Fair enough, but - >Maybe we should take that discussion back to the global v6 list. wouldn't it be prudent to try to *implement* the new policy, learn by doing so, and *then* go back to the drafting table?! I do not believe anybody claiming that we/he/she can find out *now* what the best solution is in a few year's time. The 'net is constantly evolving.... >Greetings, > >Rudolf van der Berg >Dutch German Internet Exchange >http://www.ndix.net OK, I think I'll leave it at that for this discussion :-) Thanks for your good questions and observations! Cheers, Wilfried. _________________________________:_____________________________________ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5 4

Re: draft agenda (v2) RIPE43
by Wilfried Woeber, UniVie/ACOnet 10 Sep '02

10 Sep '02

>> Isnt this proposed topic of the kind: >> "See? no traffic, we should shut down IPv6!!! Nobody is using it!!!" >> or >> "Bahhhh, i was right... IPv6 is worthless..." Those who support that point of view would do so anyway, either backed by real data or by data made up on the fly :-) >no. it is wanting baseline measurement. e.g. apnic is tracking >hits on ip6.int service. > >five years from now, we will wish we have such data. > >randy Randy, I agree. Nevertheless a brief summary on projects (looking at quality instead of sheer "volume") would still be interesting, I guess. Wilfried. PS: David, I can bring a few minutes' worth of snap-shot info for our sandbox.

6 6

draft agenda (v2) RIPE43
by David Kessens 30 Aug '02

30 Aug '02

Hi, Below follows the second version of the draft agenda (v2) for the ipv6 wg. The proposed agenda for the ipv6 working group still has quite some room for other topics/presentations. I would very much welcome your input on other interesting topics that you might want to volunteer yourself or somebody else for. There are a couple of items that ask for 'input of the audience' or 'need a volunteer'. Please don't hesitate to contact me if you are willing to help out, even if you can only talk for just a few minutes. Also, you are all invited to the ipv6 tutorial which has been scheduled on monday. See my previous mail for more details. Thanks, David K. --- Draft agenda (v2) for the IPv6 Working Group Meeting RIPE43 September 11, 2002, 14:00 - 17:30, Rhodes, Greece 1st slot A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. 6Bone Address Allocation and Registration Transition (Ray Plzak) D. IPv6 version of TTM (5-10m) (Henk Uijterwaal) E. Action point 42.1: Investigate the CNAME and other solutions for v6-reverse delegation (RIPE NCC) F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? (We are looking for a speaker from the RIPE NCC) G. Action point 42.2: Give an overview of 6-to-4 reverse delegation issues at RIPE 43 (RIPE NCC) Coffee break 15:30 - 16:00 H. Global IPv6 routing table status (Gert Doering) I. Report about *actual* v6 traffic volume as compared to v4? what's *real* out there, not what's on powerpoint? (Proposed by Randy Bush, we are looking for a volunteer(s)) J. DNS and IPv6 - issues and current BCP: draft-ietf-dnsext-ipv6-addresses-01.txt (I am looking for a volunteer who is willing to cover this topic) K. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) Z. AOB ---

6 6

FW: Proposal for Transfer of 6bone Address Management Responsibilities to RIRs
by leo vegoda 26 Aug '02

26 Aug '02

Dear Colleagues, It has been proposed that the management of the 6bone 3FFE::/16 address space be transferred to the Regional Internet Registries (RIRs). More information about the 6bone can be obtained at: <http://www.6bone.net/> At a recent 6bone meeting, Bob Fink made a proposal for this management transfer. A copy of the presentation slides are available at: <http://www.6bone.net/ngtrans/minutes/default.htm> or at: <http://www.apnic.net/meetings/14/sigs/policy/index.html> These presentation slides were based on the text, "Policies for transfer of 6bone address management responsibilities to RIRs," provided below. Please send your comments about this proposal to the LIR WG mailing list <lir-wg(a)ripe.net>. The 6bone and other RIRs will be conducting similar reviews within their communities and the RIPE NCC will summarise the collective responses, issues, and concerns, made in regard to this proposal. This review process will end on December 31, 2002. Regards, -- leo vegoda RIPE NCC Registration Services ----- Forwarded message ----- ******************* Policies for transfer of 6bone address management responsibilities to RIR Version: 20 August 2002 1. Introduction 6bone was established in 1996 as a continuing IPv6 test bed with the original purpose of testing of standards and implementations, and the more current focus on testing of transition and operational procedures, as well as application conversion. It provides an opportunity for those wanting early experience and/or needing to experiment with IPv6, with a minimum of startup complexity, particularly in terms of address management policies, and at minimal cost. It also provides an open peer process for information, hookup help, and support, with strong ties to the IETF process as well as to the operational community. To date, 6bone address space has been allocated and registered in an informal process quite separate from the existing Regional Internet Registry system. The purpose of this proposal is to establish a long term model that provides for a more "official" home for 6bone address space management within the established Internet administrative structures. At the same time, the proposal recognizes that 6bone's most important functions as an accessible and informal test bed network must be maintained. This document proposes the transfer of responsibility for administration of 6bone address space (3ffe::/16) to the Regional Internet Address Registries (RIRs). It describes a set of policies and procedures for this transfer, and for the ongoing administration of 6bone address space within the RIR framework. It should be noted that the ongoing operation of the 6bone, and policies related to it, are still the purview of the 6bone community itself. For example, 6bone network compliance with the 6bone routing guidelines is a matter for the community itself to resolve, typically by mail lists. It is also important to continue the strongly volunteer efforts of the 6bone, both to make it as easy and friendly as possible for individuals, sites and networks to experiment and learn about IPv6, but also to keep the process streamlined and cost-effective. 2. Definitions a) "6bone" and "6bone community", as it appears in section 3 below, means 6bone organizations and individuals including the RIRs, "6bone members" (see below), and those participating in the 6bone mail list. b) 6bone members are defined as entities which are approved for address space allocation by the 6bone community in accordance with 6bone policies, and who agree to be bound by those policies and the policies stated below. c) 6bone allocations are allocations of 6bone address space which are held by 6bone members, or made to 6bone members in accordance with these policies. d) 6bone address space is defined as IPv6 address space within the 3ffe::/16 address block. 3. Policies 3.1 General a) In consultation with 6bone, RIRs will implement a common set of policies applying specifically to 6bone allocations. This will follow the current RFC2772, "6Bone Backbone Routing Guidelines" and/or successor documents resulting as an evolution of conversations in the 6bone community and the RIRs.; b) 6bone members will be served by respective RIR in their region, for "6bone Address Services" including 6bone address allocation, database registration and maintenance, and ip6.arpa registration (as described below); c) In order to receive 6bone address services from an RIR as described here, each 6bone member must "join" that RIR, that is, enter into the appropriate membership or services agreement with the RIR. d) RIR fees will be waived for 6bone address services provided by RIRs to 6bone members (but not for other services 6bone members may require), until 1 year after this agreement starts. After this time each RIR may charge an administration fee to cover each allocation made. This fee simply covers registration and maintenance, rather than the full allocation process for standard RIR members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment. e) Organizations may receive 6bone address services from the RIR only on approval by 6bone, and in accordance with these policies; f) 6bone members will have the option to receive other services from an RIR (including allocation of production IPv6 address space), by following the policy, process and procedures in place at the time of application for those services. g) Continuing compliance with 6bone policies, and with the policies defined here, will be verified by 6bone at least every 2 years; 3.2 6bone Address Services a) 6bone Address Services include allocation of 6bone address space, registration and maintenance of database records relating to that address space, and registration of ip6.arpa records; b) 6bone address space allocations will be made from 3ffe::/16 and only /32 prefixes will be allocated. There will be exceptions for unusual and new proposals per joint RIR and 6bone review and approval. A relevant example of this is one or more new strategies such as geographic or metro addressing; c) No additional 6-bone address space will be allocated to any 6bone member (therefore no provision will be made for aggregation of multiple allocations, reservations etc); d) 6bone address services will be provided strictly for experimental, non-commercial use; e) Allocations will be made on the clear and stated understanding that the prefix 3ffe::/16 has a limited lifetime. The dates for the termination of allocation from the prefix and the expiration of the prefix will be determined at a future date. The RIRs will not participate in these determinations. f) 6bone address space will be returned to the RIR when no longer in use, when reclaimed due to non-compliance with 6bone or RIR policies, or when 3ffe: space is finally withdrawn; g) Registration of 6bone address space within the ip6.int zone is not covered by this policy, and is at option of 6bone member; h) Registration of 6bone sites, maintainers, persons and address space within the existing consolidated 6bone registry is not covered by this policy, and is at option of 6bone and its current policies. 3.3 Transfer of existing 6bone members a) Responsibility for existing 6bone members in respect of services described here will be transferred from 6bone to the respective RIR, at the option of those members individually, on entering into the appropriate agreement with the RIR; b) On joining the RIR, 6bone address registration records for the member concerned will be transferred from 6bone registry to the respective RIR database; c) On joining the RIR, 6bone members may establish ip6.arpa delegation records in accordance with applicable RIR procedures; d) Legacy holders will use RIR administrative procedures for management of their records; e) There will be a sunset (2 years?) on existing 6bone members not transferring to RIR administrative procedures, after which their address allocation will be revoked. ----- End forwarded message -----

1 0

IPv6 Tutorial
by David Kessens 23 Aug '02

23 Aug '02

Please see below for more information on the IPv6 tutorial. Thanks, David K. --- ------------------------------------------------------------------------ IPv6 tutorial Monday 9/9/2002, 14:00 - 17:30, Rhodes, Greece The success of the Internet has lead to an increased usage and requirement of IP addresses. IPv6 is the new generation of the Internet Protocol. It was introduced to help overcome the limitations of the current version (IPv4). The tutorial will introduce IPv6 and the transition mechanisms that can be used to ease the migration towards IPv6. Apart from the address space extension (IPv6 address is 128 bit long compared to the 32 bit long addresses in IPv4), IPv6 makes equipment autoconfiguration possible. Moreover, thanks to the very large space of global IPv6 addresses, usage of palliatives such as NATs will decrease and end-to-end communication, which is one of the basic principles of IP, will become again possible. There will be no D day to migrate from IPv4 to IPv6. IPv6 deployment started years ago and several transition mechanisms have been proposed by the IETF ngtrans working group to help networkers choose the appropriate migration strategies. Among others, the tutorial will be presented by: Bernard Tuy, Renater - G6, France Mohsen Souissi, AFNIC - G6, France ------------------------------------------------------------------------

1 0

E-mail address masquerading for archived mail messages
by RIPE NCC WebMaster 16 Aug '02

16 Aug '02

Dear Colleagues, [Apologies for duplicate mails] Beginning today, 16 August, the RIPE NCC will implement "e-mail address masquerading" for messages displayed on the web site in the RIPE and the RIPE NCC mailing list archives. E-mail masquerading makes it more difficult for spammers to harvest e-mail addresses from the mailing list archives. When masquerading is applied, the e-mail address of the sender will be hidden in the mail archived messages. Those reading archived mail will see a return e-mail address that appears as "<somebody@localhost>". When clicking on this e-mail address, the address of the original sender will be loaded in your mail program, enabling you to send a message to the author. The RIPE NCC has chosen to implement this security measure as there have been various complaints from members of the RIPE community that e-mail addresses were being abused by spammers for Unsolicited Bulk E-mail (UBE). By implementing this security measure we anticipate there will be a sharp reduction to address harvesting of archived e-mail addresses. We will be checking for harvesters who manage to overcome this measure and will take further steps if necessary. E-mail masquerading will be applied to all mailing lists found in the following directories: http://www.ripe.net/ripencc/mail-archives/ http://www.ripe.net/ripe/mail-archives/ We appreciate your understanding on this matter. Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

Updating inet6num objects with a legacy status attribute
by leo vegoda 06 Aug '02

06 Aug '02

Dear Colleagues, The RIPE Database server, whois.ripe.net, has been updated to allow the new status attributes specified in the document: "New Values of the 'status:' Attribute for inet6num Objects" <http://www.ripe.net/docs/new-value-status.html> The status values of all inet6num objects maintained by the RIPE NCC have been updated as appropriate. We would be grateful if everyone maintaining inet6num objects would update them to use the new status attribute values. The RIPE NCC will use the "ASSIGNED" status value to determine the HD ratio when it receives a request for an additional IPv6 allocation. A request form for additional IPv6 allocations will be published in the near future. Best regards, -- leo vegoda RIPE NCC Registration Services

1 0

draft agenda (v1) RIPE43
by David Kessens 06 Aug '02

06 Aug '02

Hi, Below follows the draft agenda (v1) for the ipv6 wg. The proposed agenda for the ipv6 working group still has quite some room for other topics/presentations. I would very much welcome your input on other interesting topics that you might want to volunteer yourself or somebody else for. There are a couple of items that ask for 'input of the audience' or 'need a volunteer'. Please don't hesitate to contact me if you are willing to help out, even if you can only talk for just a few minutes. Also, you might have already noticed on the schedule, an ipv6 tutorial has been scheduled on monday. As suggested by schedule there will indeed be an ipv6 tutorial on that day. You will receive a formal invitation when the exact time (we might ask the NCC for a bit more time than is currently indicated on the schedule), content and speakers are set. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE43 September 11, 2002, 14:00 - 17:30, Rhodes, Greece 1st slot A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Action point 42.1: Investigate the CNAME and other solutions for v6-reverse delegation (RIPE NCC) D. Action point 42.2: Give an overview of 6-to-4 reverse delegation issues at RIPE 43 (RIPE NCC) E. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? (We are looking for a speaker from the RIPE NCC) F. Global IPv6 routing table status (Gert Doering) G. Report about *actual* v6 traffic volume as compared to v4? what's *real* out there, not what's on powerpoint? (Proposed by Randy Bush, we are looking for a volunteer(s)) H. DNS and IPv6 - issues and current BCP: draft-ietf-dnsext-ipv6-addresses-01.txt (I am looking for a volunteer who is willing to cover this topic) I. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) Z. AOB ---

1 0

Minutes IPv6 wg RIPE42
by David Kessens 06 Aug '02

06 Aug '02

Please see below for the minutes of the IPv6 wg at the 42nd RIPE meeting. I would like to thank the scribe for writing down the minutes and all the small corrections that I received after posting the minutes. Thanks, David K. --- 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 Roecker 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 Doering) 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 Kuehne, 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: http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ ripe42-ipv6-juniper.pdf Pim van Pelt (PVP): What about Filtering and OSPF6 ? JMU: OSPFv3 for Junos will come in the second half of 2002 Filtering will come in a couple of weeks. ?: 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. 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. ======================== B. IPv6 roadmaps of network equipment vendors b. Cisco ======================== Simon Pollard (SP) presented Ciscos Roadmap for IPv6. Gert Doering (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 Doerings 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. === COFFEE BREAK 10:35 - 10:50 === ?: 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-ipng/ 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 presentated an overview of the activities of ipv6 promotion council in Japan. More information about the council can be found at: 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-dns/ 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 and other solutions 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 Suissi: RIPE NCC did this in the past, at least for 2002:0660::/35 both delegations were made. DNS reverse delegation must not be done at the parent zone before making sure the children (master & slaves) are ready. DK: RIPE NCC, could you investigate the possibilities for automatic delegation? 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 RIPE43? 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 Kuehne 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-survey/ ======================== J. Euro6IX and layer 3 IX addressing ======================== Raffaele D'Albenzio's presentation is available at: http://www.euro6ix.org/ingles/Presentations/ 020430-TILAB-DalbenzioGuardini-RIPEPresentation.pdf - 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) Geza's presentation is available at: http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ ripe42-ipv6-tipster6/index.html ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond French NIC initiative regarding DNSv6 deployment ======================== Mohsen Suissi presentation is available at: http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ ripe42-ipv6-souissi.pdf Mohsen Suissi 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 and other solutions for v6-reverse delegation. 42.2 ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43 ------------------------------------------------------------------------

1 0

New Document available: RIPE-256
by RIPE NCC Document Announcement Service 05 Aug '02

05 Aug '02

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store: "IPv6 Address Space Policy for Internet Exchange Points" Short content description ------------------------- Internet Exchange Points (IXPs) are used to exchange Internet traffic between different Internet Service Providers (ISPs). Many Exchange Point operators require address space for the peering mesh that is independent from any of the address space in use by member networks. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW. "IPv6 Address Space Policy for Internet Exchange Points" is available at the following URL: http://www.ripe.net/docs/ripe-256.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-256.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-256.txt plain text version Kind Reagrds, Jeroen Bet Webmaster RIPE NCC

1 0