- ipv6-wg - mailman.ripe.net

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

04 May '02

> Gert Doering wrote: > We're trying to get a proper DNS chain going - it's not too useful > to build this on top of v4, if the goal is to do away with v4 > dependency for fairly unimportant things like "the DNS chain". You are putting the car before the horse, IMHO. You want a solution for *now*. Besides multihomed 6to4 (that will likely still be available in 15 years, which leaves you time to redesign), what you have *now* is your DNS servers having multiple PA IPv6 addresses without the need to leak /48s in the DFZ and without filtering problems. It appears to me that if you want to design a multihomed DNS chain, there could be some value in knowing what multihoming is actually going to be; and it's not going to be leaking PA prefixes in the DFZ in any scenario considered today. > and people in the RIPE region are starting to > do serious work on this. I'm happy they are. As of myself, I began a long time ago. And, BTW, I'm from the RIPE region. The kind of partial redundancy you would get by leaking prefixes has been solved a year ago. What we are currently discussing are specific cases of catastrophic multiple-ISP failures. Whining about the lack of a v6 multihoming solution is not going to bring it to you faster. I am not the one that stalled the process. Have you considered participating in its development? Michel.

2 1

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

03 May '02

> Among those that do not filter you, you have ideal and > perfect connectivity. And give them a real good opportunity to squeeze all the money they want out of you the day you _really_ need them not to filter. > If I've overlooked a flaw, and there is a better way *today* that > does not instantly create non-removeable legacy problems, please > point this out 6to4 addresses off a multihomed IPv4 address. The 6to4 address is portable, the v4 connectivity today is typically better than native v6 is, and if you are building a v6 only mission-critical system, you are building a skyscraper on sand. You don't like tunnels? I have news for you: *today*, v6 is _mostly_ tunnels. Michel.

2 1

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