- ipv6-wg - mailman.ripe.net

Re: Regarding IPv6 prefix filtering
by Gert Doering 04 May '02

04 May '02

Hi, On Sat, May 04, 2002 at 08:55:17PM +0200, Sebastian Willing wrote: > Gert Doering wrote: > > > Why couldn't the RIPE (or better, IANA) claim a /32 or something like this > > > to be used only for PI /48 networks? This way, we could filter out everything > > > more-specific then /48 in this network and everything more-specific then /?? > > > everywhere else. > > > > What would be the benefit of this? > > > > The drawbacks are: > > > > - it creates instant legacy objects (those will be around forever - there > > is no way they can disappear) > > > > - if someone filters out /48s, those networks are instantly dead. When > > using /48s out of aggregateable space, if someone filters them, the > > networks can still be reached via the aggregate block. > > You (as an upstream) could announce the whole claimed block as a kind of > gateway-of-last-resort - route to your downstreams. This is why people use /48s out of PA blocks. Because it's automatic, and the block-route is already pointing into the right direction and does not have to be generate by every single "upstream" ISP out there. > > The only "advantage" of PI is that it's "independent" and you can carry > > it around when changing ISPs. But everbody else has to pay for that. > > > > PI is *bad*. > > Okay, change it's name or reserve it for organasations like RIPE, DeNic, Switch, > Nic.at, DeCix and so on. No. None of them are more special than everybody else. (For the IXes, the *peering mesh* LAN is. The services network is not) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45077 (47584) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

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