- ipv6-wg - mailman.ripe.net

RE: Regarding IPv6 prefix filtering
by Michel Py 03 May '02

03 May '02

>> Michel Py wrote: >> Nevertheless, no matter how good the reasons, even tacitly allowing >> /48s in the routing table does create a terrible precedent. > Gert Doering wrote: > Maybe. But I'm not so sure whether this is so terrible - if you do > not want to see /48s, filter them out, and live with potentially > non-perfect routing (to the aggregate and find the more-specific > there). I'm sorry, but what do you achieve in terms of multihoming doing this? If you filter PA specific routes, the only aggregate you see in the DFZ is that provider's block, effectively making the site singlehomed. Michel.

2 1

RE: Regarding IPv6 prefix filtering
by Michel Py 03 May '02

03 May '02

Gert, > Gert Doering wrote: > Currently there is no other working and implemented way to get > v6 multihoming. Multiple /48s obviously do not work (think > failover of established TCP sessions and routing policy > decisions), regional addressing isn't here (and I'm unsure how > that is supposed to work concerning non-rationality of upstream > networks), so what else do we have? There is no current v6 multihoming solution, and we know it. It will not be ready for months at best and we also know that. I repeatedly voiced loudly my dissatisfaction about the lack of progress towards a v6 multihoming solutions. We are actively working on it. Nevertheless, no matter how good the reasons, even tacitly allowing /48s in the routing table does create a terrible precedent. Michel.

2 1

RE: Regarding IPv6 prefix filtering
by Michel Py 02 May '02

02 May '02

> Your list is already very strict. As we have discussed yesterday, > it might be desireable (until there is a better solution for > multihoming) to explicitely permit prefixes up to a /48. This > could be done "for your own region only", or "for all regions", I am personally opposed to allow /48 PA prefixes in the routing table. This would become a de-facto the end of aggregation and lead us quickly to an un-manageable routing table again that would take huge efforts to clean. Although I have sometimes disagreed with Pim, the filters he posted are the responsible thing to do. We have reached this situation of people requesting 6bone pTLAs or subTLAs for the sole purpose of being multihomed because too many people have put their head in the sand for too long. Please don't encourage this anymore. /48s in the routing table are not a solution. There are two different IPv6 multihoming solutions currently discussed on the ipv6mh list that deal with geographic addresses (with a finer graining than a region) that could be aggregated. Michel.

2 1

Regarding IPv6 prefix filtering
by Pim van Pelt 02 May '02

02 May '02

Hi, Regarding filtering on incoming and outgoing BGP updates, kindly note my opinion on the matter (which differs somewhat from Gert's slides at the ripe42 meeting). He had pasted UUNet UK's rules, but following the current RFC and policies from RIR and 6BONE, this might be more approriate: ipv6 prefix-list strict seq 5 permit 3ffe::/17 ge 24 le 24 ipv6 prefix-list strict seq 10 permit 3ffe:8000::/17 ge 28 le 28 ipv6 prefix-list strict seq 15 permit 3ffe:4000::/18 ge 32 le 32 ipv6 prefix-list strict seq 20 permit 2000::/3 ge 16 le 16 ipv6 prefix-list strict seq 25 permit 2001::/16 ge 29 le 35 ipv6 prefix-list strict seq 27 permit 2002::/16 ipv6 prefix-list strict seq 30 deny 2000::/3 This might clean up some of the broken elements in the current global routing tables. Regarding the informational aspect, looking at the project I am forming and briefly presented at the ripe42 meeting, perhaps this project can contribute to some form in the RIPE region education of LIRs. Any participation from the ISP and operators level is kindly requested and more information about this project can be found in the presentation slides numbered 3 and up, and the presentation is at: http://www.sixxs.net/presentation/ipv6-ripe42.htm </spam> ;-) groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim(a)ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------

3 3

IPv6 assignments to DNS root servers in the RIPE region
by Joao Luis Silva Damas 29 Apr '02

29 Apr '02

Dear all, below find a proposal for a policy enabling the assignment of blocks of IPv6 addresses to Internet DNS root servers in the RIPE region. I would like to use the opportunity to request from the chairman of the LIR WG to include this point for discussion in the WG meeting next week. Of course, discussion in the mailing list is welcome. Best regards, Joao Damas RIPE NCC **************** This proposal requests the adoption of a special IPv6 assignment policy for Internet DNS root servers. It does not apply to any other infrastructure. Specifically, this is not a request for a generic "special infrastructure" IPv6 assignment policy. --- IPv6 address assignments to Internet DNS root servers in the RIPE region Internet DNS root servers are particularly critical elements of the Internet's infrastructure. They need to be operated in a neutral and professional manner which will not impose any artificial or unnecessary barriers for access to their designated services. DNS resolvers and resolving name servers need to be pre-configured with the network addresses of the root name servers. This makes these addresses special and not easy to change. Hence this special policy. Under this policy, each (current or future) Internet DNS root server (as listed in the root-servers.net zone) in the RIPE region will be assigned a block of IPv6 address space for purposes of root server operations. The size of the block shall be the same as the size of the minimum allocation to LIRs valid at the time of the root server assignment. The assigned prefix is only for root server operations and support functions related directly to the operations, such as monitoring, statistics, etc., and is bound to the root server service itself. It is not associated with the organization/s that operate the root server at a particular point in time and these organizations should not use the address space to provide any services not related to the root server. Should the operational responsibility for a DNS root server move to a new organization, the IPv6 address space associated with the server will also move to the new organization. The old and the new organizations must update the registration information with the RIPE NCC. If the new location of the root name server is outside the RIPE region, the address space must be returned to the RIPE NCC and a new assignment must be requested from the appropriate RIR. If a root server stops operating within the RIPE region, the address space will be returned to the RIPE NCC and marked as "reserved" for a suitably long period of time. *******************

11 29

Agenda for the IPv6 Working Group Meeting RIPE42
by David Kessens 26 Apr '02

26 Apr '02

Below follows the agenda for the ipv6 wg. After my request for topics on the list, I got quite some requests for topics to be covered and even some people who offered to do presentations. I am very glad that I received all these offers and I hope that we will be able to cover them all in the limited time that we have available. Due to time limitations I have dropped the 'Status of the 6bone' repport from the agenda, and due to lack of volunteers for a presentation I also dropped the 'DNS and IPv6 - issues and current BCP: draft-ietf-dnsext-ipv6-addresses-01.txt' topic. I hope to see you all at the meeting next week, David K. --- Agenda for the IPv6 Working Group Meeting RIPE42 Wednesday May 1st, 2002, 14:00 - 17:30, Amsterdam 1st slot A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. IPv6 roadmaps of network equipment vendors Juniper (Jean-Marc Uze, Elise Gerich) 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. IPv6 allocation survey (Mirjam Kuehne, RIPE NCC) I. Euro6IX and layer 3 IX addressing (Raffaele D'Albenzio) J. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) - French NIC initiative regarding DNSv6 deployment (Mohsen Souissi) Z. AOB ---

4 6

FWD: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by David Kessens 26 Apr '02

26 Apr '02

For your information: You might want to read the latest iteration of the 'IPv6 Address Allocation and Assignment Global Policy' draft before the actual discussion of the draft during the lir wg session at the RIPE meeting next week. David K. --- ----- Forwarded message from Thomas Narten <narten(a)us.ibm.com> ----- X-Delivered-For: <david(a)iprg.nokia.com> X-mProtect: <200204251156> Nokia Silicon Valley Messaging Protection X-Authentication-Warning: data.staff.apnic.net: majordom set sender to owner-global-v6(a)lists.apnic.net using -f To: global-v6(a)lists.apnic.net Subject: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy Date: Thu, 25 Apr 2002 06:54:02 -0400 From: Thomas Narten <narten(a)us.ibm.com> X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) A revised version of the IPv6 address document is now available. It incorporates feedback from the recent RIPE, APNIC and ARIN discussions, as well as many wording cleanups. It is believed that the document is consisent with the discussions held so far and the consensus calls of APNIC and ARIN. The document can be found at: IPv6 Address Allocation and Assignment Global Policy ftp://ftp.cs.duke.edu/pub/narten/ietf/global-ipv6-assign-2002-04-25.txt Thomas - - This list (global-v6) is handled by majordomo(a)lists.apnic.net ----- End forwarded message -----

3 2

Minutes of the IPv6 wg session at RIPE41
by David Kessens 26 Apr '02

26 Apr '02

Please see below for the minutes of the IPv6 wg session during RIPE41. The only changes that were made from the draft (v1) were some small corrections as requested by Mohsen Souissi on the list. Thanks, David K. --- ----------------------------- RIPE 41 Amsterdam Ipv6 Working Group Wednesday 16th January 2002 16:00 - 17:30 Chair - David Kessens 117 attendees present A Administrative Stuff Added agenda items: Status of ip6.int to ip6.arpa transition and the use of ipv6 capable nameservers for ip6.arpa B Status of the 6bone (David Kessens, http://www.kessens.com/~david/presentations/) Summary: There are now over 1000 ipv6 sites in 55 countries. Q: size definition, what is a site? A: an administrative entity that has an ipv6 network, can be very small, i.e. one machine, or a large ISP. Q: Is it necessarily the same as a site for a nla allocation? A: No! C Global IPv6 routing table status (Gert Doering, SpaceNet AG, http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations.html#ipv6) Q: Why can't you announce 2001::16? I do this because I want to have a default free announcement. A: This does not belong to you specifically so should not be announced. Q: What is preferable? A: It should not be announced in the default free zone, there is no problem with you announcing this internally. Q: Are there invalid AS numbers in some registries i.e. the 6bone registry? A: I didn't check there, most likely they are because the 6bone registry does not check to see if an AS number is valid or invalid. Q: Are we now in the right phase to filter based on registry databases? A: I don't think so! We don't have RPSL for Ipv6. Comment: For your info, in Japan the exchanges are not exchanging routes anymore, for example NTT are charging for transit. Q: Where do you connect to for these bgp tables? A: Mainly Germany, but also some US and European sites. Q: would it be worth having a discussion regarding filtering policies for our routers in the next meeting ? Q: can you volunteer for this ? A: yep! D Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience requested) Comment: French NIC has a secondary DNS IPv6-capable server which already hosts .fr zone and other TLD zones such as .re, .es, .br and .dz. We are looking forward to do some collaboration in DNSv6 field with other European TLDs. A: Can I volunteer you to discuss this at the next meeting? A: Yep! Q: Does this mean that you do accept quad A or A6 records because there are some parts that just have it as transport to ship a query to the server and to receive the result? A: The transit of DNS messages is they need them in Ipv6 dative mode only where they are supported in OUR zone file we don't object to the use of zone files containing AS's. Global Ipv6 Summit Madrid 13th - 14th March 2002 www.ipv6-es.com Jordi Palet gave slides to David to present Euro6IX Status. David presented the slides (http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations.html#ipv6) Q: 6link is a coordination of different v6 projects. Similar updates to Euro6IX! Z AOB Reverse Delegation in v6 I would like to talk about the slowdown of DNSv6 service deployment. There is a plan of migration from ip6.int to ip6.arpa for the IPv6 revese tree. RIRs have already asked for reverse delegation of their blocs and that has already been done. But no name server among the authoritative ones for ip6.arpa talks IPv6! In November we sent a mail to IANA hostmaster to tell them, we can also be a secondary for ip6.arpa. So far we have had no response! I am therefore concerned of willingness for deploying IPv6. Things are going well from a standardization point of view but from a practical point of view people are not encouraged! Q: We received a request from Bill reagrding the various ranges which we have passed on to the people running the ip6.arpa. Should this be in our operational area? Probably most people feel that yes it should! We are trying to do this as fast as we can.. Q: can we at ripe get independent v6 addresses A: no, not enough for everyone!!! Q: good question, where do the registries get it from? Q: Is ICANN considering using new records for the route zone? A: I don't make policy on the route zone, discussion has been made which has not yet been concluded. I will hand over to Bill.. A: testing regarding this is still ongoing, a preliminary set of recommendations still has to be tested. It is going very slow as people are being very careful. Q: does the registry process of RIPE NCC allow me to register name servers without having v4 address? A: yes Q: is there anything we can do as a community, i.e. make it clear to the ripe community that we want this? A: yes A: we can then approach Icann about this. You should be asking the RIPE NCC when we can use v6 in the name server. Conclusion Hopefully the agenda will be fuller next time, if you have any suggestions please let David know so that we can have more agenda points. It could be interesting to see a road map plan, I see we have Cisco and Juniper here so can you help me do this for next time? A: Yep! ------------------------------------------------------------------------ ------------------------------------------------------------------------ <<< Chronological Index >>> <<< Thread Index >>> ------------------------------------------------------------------------

1 0

RE: IPv6 assignments to DNS root servers in the RIPE region
by Guy Davies 24 Apr '02

24 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gert, I think what Joao was suggesting was that if the nameserver had been in NASA's v6 block, then rapid renumbering would have made it viable to demand the whole block back from NASA when the nameserver was shutdown. While this is nice in theory, I tend to agree with Randy that it is not very likely in reality for a huge organisation like NASA. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Wednesday, April 24, 2002 1:56 PM > To: Randy Bush > Cc: Joao Luis Silva Damas; lir-wg(a)ripe.net; ipv6-wg(a)ripe.net > Subject: Re: IPv6 assignments to DNS root servers in the RIPE > region > > > hi, > > On Wed, Apr 24, 2002 at 08:50:05AM -0400, Randy Bush wrote: > > > No, NASA should probably not return their IPv4 space. > With IPv6 you > > > can do it right, so why not do it right? > > > > oh, i forgot ipv6's rapid renumbering. i also forgot santa > claus and > > the tooth fairy. > > Huh? What does this have to do with anything? > > This proposal is about NOT changing IPv6 root name server > addresses, and > NOT about "easy renumbering". > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 44543 > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPMauCY3dwu/Ss2PCEQLfkwCg7upE2tAaEQ2GoHjIlRwwIEkLez8AoMjD X24zM7WSw2QARZm0DFdvnnCx =WbDK -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

4 3

RE: IPv6 assignments to DNS root servers in the RIPE region
by Guy Davies 24 Apr '02

24 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > In message > <C653AC166708D51195D600034723D865075BBB(a)cain.telindus.co.uk>, Guy > Da vies writes: > > >Hi Gert, > > > >I think what Joao was suggesting was that if the nameserver had > >been in NASA's v6 block, then rapid renumbering would have made it > >viable to demand the whole block back from NASA when the > >nameserver was shutdown. While this is nice in theory, I tend to > >agree with Randy that it is not very likely in reality for a huge > >organisation like NASA. > > As I read it, it means that the root-server will get its own > allocation, and that allocation follows the rootserver around. That's the original discussion point. However, there's a little throwaway comment in one of Joao's subsequent emails in which he says... "No, NASA should probably not return their IPv4 space. With IPv6 you can do it right, so why not do it right?". To me, that implies that you can force an organisation like NASA to return *all* their v6 space and renumber in this kind of situation. > Sounds surprisingly reasonable to me. For the initial discussion point, yes. For the subsequent point, above, absolutely not. Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPMavqo3dwu/Ss2PCEQJL/wCfRGx6hetMOJqPCh/+d/thPLA9dssAn0y3 1KYq6bIEy0YhVED7SbjmdxTV =0hrB -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

1 0