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

RE: Getting addresses
by Michel Py 10 May '02

10 May '02

David, >> Michel Py wrote: >> There is no such thing as a default-free zone for IPv6 anyway. Not in >> the v4 sense, and there is no definition for IPv6 DFZ. I presented this >> at the 6bone meeting in Minneapolis, might want to have a look at it. >> http://arneill-py.sacramento.ca.us/ipv6mh/ietf53.ppt > David Kessens Wrote: > You can present whatever you want, but I don't have a 'default > route' that points to any of my ipv6 peers. Me neither, but it does not make me nor you part of the DFZ. This is called a defaultless setup. Unless there is a document that gives a definition of "DFZ" specific to IPv6 (I am not aware of it, please point me to it) this is the way it works in v4: - The DFZ and the DFZ's routing table are two different things. The DFZ's routing table expands outside the DFZ itself. - There is no relation in running a defaultless setup and being part of the DFZ. A defaultless setup does get the DFZ's routing table, though. - There is no relation in having a global prefix and being part of the DFZ either. What is the DFZ: It is where tier-1s peer together. In other words, in order to be part of a DFZ, you need to be a tier-1, which means you do not get transit from anybody. If you are a multihomed tier-2, you might run defaultless but you can always dump the traffic on one of your tier-1 transit providers (after all that's why you are paying them); a floating static default route might be useful for tier-2s in case of routing snafus. One of the requirements of the DFZ is that all tier-1s must be fully meshed. Since they do not have transit, they need to know all the routes, and since they announce only their own routes to other tier-1 peers, they get only the connected peer's own routes as well, which means they need to be fully meshed. As of today, the situation we have in IPv6 is that everyone peers nicely together without much filtering, resulting in people actually providing transit to their peers, which exists very little in v4. In v4, the only routes you advertise to your peers are your own, not in v6 today. So, it can be one of three things: 1. There is a specification of "DFZ" specific to IPv6 (I am not aware of it, please send link). 2. The Big Eight have actually completed their full v6 mesh (I am not aware of this, did I miss something?). 3. There is not such thing as an IPv6 DFZ. Michel.

1 0

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

10 May '02

Arien, > Arien Vijn wrote: > This is how I understand your proposed setup: > - Connect this DNS server directly to the L2 IXP infrastructure > via an 802.1q NIC. > - Configure n VLANs on it - one for each peer. > - In each VLAN, the server answers DNS queries on a different > /64 address. > - Each of these /64 belongs to the aggregate of the respective peers. > Is this an accurate description? You got it. I think that behind a router or firewall instead of directly on the L2 fabric would be better, though. >> Where is your problem? > Well, *if* my understanding is correct. Then I do see a number of issues. A number of them, indeed. And half of them, to be resolved, might require major annoyances including but not limited to: extra hardware, tedious or dirty configuration, hacks, and longs evenings swearing at debugging the darn thing. But none that can't be solved, AFAIK; can you be more specific please? I am not saying this a good configuration as there is none today. I'm not even saying this is the best (or the less worst) that would solve your problem short term. The points I am trying to make are: 1. You want to do multihoming without a multihoming protocol. - It can't be a free lunch. - If you want to do it today anyway, what you have is described above and some other methods equally un-satisfactory. 2. Whatever you do over PA is unlikely to be mergeable with any future multihoming solution including short-term ones. Do not build a multihomed infrastructure on PA, it is not going anywhere. In other words: I'm afraid that whatever you can do today is quick and dirty. Try to make it easier on the community and yourself to clean up later. Local messes are easier to clean than global messes. There is no way nobody has found yet that you will get the multihoming solution both RIPE-NCC and AMS-IX need without an allocation. A PA allocation is not a long-term solution. Every multihoming solution that I have seen requires a clean PA space. Every shot someone takes at PA aggregation diminishes the viability of a good multihoming solution. Don't play with that too much or the only multihoming solution you might ever get is a PI swamp. I short: PA is not what you need in the long run. If you don't want to end up in the PI swamp, don't make my job impossible in delivering the local /48 allocation you need. Michel.

2 1

Re: Getting addresses
by Wilfried Woeber, UniVie/ACOnet 10 May '02

10 May '02

Dear Philip, thanks for circulating the URL! >The document containing the revised allocation and assignment policy: > > IPv6 Address Allocation and Assignment Global Policy > ftp://ftp.cs.duke.edu/pub/narten/ietf/global-ipv6-assign-2002-04-25.txt > >was discussed (in the LIR WG meeting) and consensus was achieved within the >RIPE community (joining consensus achieved in APNIC's and ARIN's >communities).... > >I suspect the doc will answer your question. > >philip >-- Dear Peter, may I suggest that we discuss your situation off-line? I definitely don't want to stop any discussion on a list, but I don't see a point in re-opening the discussion *right now* and *right here* for your situation. Unless my background is wrong (and you are actually trying to achieve something else) I'm pretty sure that we can find a *proper* way now with this new policy to supply you with IPv6 addresses (for 6NET). I would expect that either the Danish NREN and/or NORDUnet would be involved in one way or another. Regards, Wilfried.

1 0

RE: Getting addresses
by Michel Py 10 May '02

10 May '02

> Peter B. Juul wrote > but the active guidelines - specifically the demand for three peers > in the default-free zone, a demand that can't be met for political > and economical reasons - made this impossible. There is no such thing as a default-free zone for IPv6 anyway. Not in the v4 sense, and there is no definition for IPv6 DFZ. I presented this at the 6bone meeting in Minneapolis, might want to have a look at it. http://arneill-py.sacramento.ca.us/ipv6mh/ietf53.ppt > Francis Dupont wrote > => sub-TLAs are for ISPs, not for NRENs. The solution for a NREN > is either to disguise itself as an ISP, Which is really easy to do. When you look at the requirements, you can even meet the 200 /48s assigned to end-users quickly, just get all your local linux chapter buddies and some of your co-workers and students and voila, you have 200 users and now you are an ISP. As far as I know, there is no requirement for the links to be native v6, so tunnels would work fine. Gee, you don't have to be a NREN, you can even get that for your home. </sarcasm> > or to join the 6bone. Or both. There are some experiments that you could run over 6bone address space and don't want your "production" v6 network to be affected. Michel.

2 1

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

05 May '02

Sorry about the bad English; you should have read: I short: PA is not what you need in the long run. If you don't want to end up in the PI swamp, don't make my job impossible if you want me to deliver the local /48 allocation you need. Michel.

1 0

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

05 May '02

>>> neither are "use a /48 from each of the upstreams" >> Why not? All of the upstreams is probably overkill, but from three or >> four big ones? > For optimum routing, and neutrality, at least in the case of the > RIPE NCC (and maybe some of the IXes service networks), you want > all upstreams (90) to reach their network directly, not going over > other peers. So you either take 90 /48s, or take one, and announce > that to all the peers/ upstreams (which is mostly the same in these > situations). Note that we are not talking about 90 /48s here, but 90 /64s, one from each of the peers. So, you connect your DNS server with an 802.1Q compliant NIC, two-thirds of these 90 VLANS already exist in the exchange's L2 fabric. Where is your problem? > I can very well imagine a scenario where ISPs are willing to > accept more-specifics *in their own (RIR) region*, and filtering > out those from other regions. Except for global players (that > can't say "this is my region" because they're present everywhere) > this would result in near-perfect connectivity to all networks, > while not being forced to take all the crap. Gert, What you describe is a geographically based prefix filtering system. This does _not_ belong into PA space. It belongs to geographically aggregatable space, which like its name implies will be not only filtered based on geographical criteria but also aggregated. We have a project in ipv6mh called "geo for now" which is similar to what you describe and that we think is the short-term answer you and others are seeking. Aggregation of PA can _not_ be broke. Please allocate the resources of your brain into getting the solution out instead of futile attempts. Michel.

2 1

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

04 May '02

Hi, On Sat, May 04, 2002 at 10:25:55PM +0200, Sebastian Willing wrote: > Gert Doering wrote: > > (For the IXes, the *peering mesh* LAN is. The services network is not) > > ...and I don't see any reason for the peering LAN to be announced to others > than the IX-member-ASs. So, a /48 (or less) should be no problem. You may > even choose to not announce it within your structure. That's why we have a special policy for neutral-but-unrouteable prefixes (at least "possibly unrouteable") for IXes - for the peering mesh *only*. 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, > Gert Doering wrote: > Maybe I should be more precise on that. We're talking for > example about the address space to be used by the RIPE NCCs DNS > servers, doing reverse delegation for 6.0.1.0.0.2.ip6.{int,arpa}. > The NCC is multi-homed to about 90 ISPs today, many of which are > now starting to offer IPv6 services, natively delivered over the > AMS-IX exchange. > People want to see this service so that they can do v6-only > stuff, without the need to go to ns.ripe.net's IPv4 address. I understand this. > 6to4 is not an answer in this scenario, For the specific example of DNS roots, it is definitely not the best. Your original post did say anything about that. > neither are "use a /48 from each of the upstreams" Why not? All of the upstreams is probably overkill, but from three or four big ones? What you are looking at here, in terms of redundancy, compared to the prefix leak, is _some_ resolution failures when one of these "five nines" upstreams is down, opposed to a total failure if the one ISP you choose to leak the prefix has a major routing issue. Large operators will lose a pop from time to time, I can remember some tier-1 losing the entire North American frame relay for 24 hours, can happen to anyone. By using one PA address, you still are vulnerable to some forms of single ISP failure. > "get a globally unique prefix" (because that network is *not* > special enough to warrant an exception from "end sites do not > get an allocation") Agree. > Which leaves "leak more-specific", which would solve that > problem quite well. As of today, I think that "use a /48 from each of the upstreams" is a less risky option than "leak more-specific". This is debatable; I predict that you will have a hard time convincing people that "leak more-specific" brings enough short-term gains (especially given the fact that it still is having most of your eggs in the same basket) to justify the precedent of breaking the aggregation. At the risk of giving people bad ideas, let me tell you what will hear a lot should that happen: "You guys did leak your prefix in the DFZ to multihome your DNS. Your DNS is no more important than my business, and since you have shown the example I will cut a deal with my upstreams so they leak my prefix in the DFZ, too; if you're not happy about it you, though. You should not have started it in the first place". For the same reasons that apply to 'that network is *not* special enough to warrant an exception from "end sites do not get an allocation"', that network is not special enough to warrant an exception to filtering policies that will lead to a huge mess. > there are stronger arguments for "PA leaking" vs. "using PI and keep > that forever". I might be mistaken, but I do not think that either one is an open option at this time. Still the basic issue is unchanged - some people do not want to rely > on just one upstream, and for others (like the NCC) it doesn't make > sense to confine their service to just one upstream. > So what exactly are you talking about? I am talking about locally unique, provider-independent, aggregatable addresses. > Any implementations out there that I could look at? Go here http://arneill-py.sacramento.ca.us/ipv6mh/ and look at MHAP. There is no running code per say but simulations are under way. I suggest you refrain from posting "it does not work" before you read and understand it. > I'm doing my best to help developing policies and techniques that > follow the pragmatic approach of "make it work today and avoid > doing irrevocable damage in the progress". This is very close to our line of thinking. However, breaking aggregation of PA space _does_ irrevocable damage in the sense that people will begin to build multihomed setups based on it. The argument "We can do it, but not end-sites" will not hold. Save for ISPs that receive a global allocation, any kind of "multihomed" setup you create today, DNS related or not, will need to be scrapped when IPv6 multihoming is deployed [if you want to undo the damage]. >From a business standpoint, if I can get my business multihomed by cutting a deal with secondary ISPs to announce my primary's PA block, and if my business makes it to revenue-generating production, the only thing I want to do is continue paying my secondary ISPs to continue leaking my prefix in the DFZ. And they will do, because they want to keep me as a customer. Allowing people to leak specific prefixes in the DFZ is pretty darn close to giving them their own. ISPs will not filter because they don't want to risk losing revenue, end-sites will not allocate resources to clean what's not broken on their end (the DFZ's routing table). Exactly the same mess situation we have with v4. Once a /48 leaks into the DFZ and is used for revenue-generating production, would you explain us what are you going to do to take it away? Michel.

2 1

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