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

RE: Getting addresses
by Michel Py 13 May '02

13 May '02

Tim, > Tim Chown wrote: > but yes a university may feel it wants to offer connectivity to > past students This is a grey area for sure. I don't think that providing access to currently enrolled students can reasonably be considered bad use of public money, for the good reason that a simple accounting trick will assign that to tuition fees students do pay. Besides, access to the university's computer resources is mandatory for studying, and a university provided dial pool does have some operational advantages in terms of security. However, providing access to past students could definitely be seen as using public money to compete with businesses. > staff. I do not think staff is a problem. They get a paycheck that contains public money, why can't they use a dial-up that is paid by public money? > In terms of the get-outs, I expect that commercial spin-offs or > products from the universities (e.g. a university selling > intelligent widgets) may be hosted from a university with such a > spin-off. Most of these will get grants that include cash from the university, there is nothing fundamentally wrong in making connectivity part of the grant. > the really fuzzy area is universities who use their academic > connectivity to give students access from halls of residence, which > if done with open ADSL-like rules may well let students run > commercial services. This is not that bad. Students have 10 meg connectivity in dorms. And yes, we know they'll use it not only for studying but also to surf porn and download pirated .mp3s. From time to time, an idiot will run a warez ftp server and will get busted. Frankly, I'd look the other way if I see a student that runs a website for his on-campus pizza delivery service that helps pay his/her tuition. I think it all comes down to this: fast and reliable Internet access is something that students need. Money and side jobs are also something lotsof them need. They are students for 4 years, after that they get a real job and pay for their own. Michel.

1 0

Re: Getting addresses
by James Aldridge 13 May '02

13 May '02

Pekka Savola wrote: > > I can imagine DSL operators offering /64 (single subnet) and /128 (single > > host) assignments to some customers (in the same way that single IPv4 > > addresses are often assigned now), in which case these 1,000,000 customers > > could be handled with an allocation of between a /39 and a /103 while > > maintaining an HD ration of 0.8 within that allocation - i.e. one /32 would be > > more than enough! > > IAB/IESG recommendation state /48 should be used in scenarios like this. Personally, I don't agree with the "/48 for all" policy but it's there so I suppose we have to live with it... Note, however, that rfc3177 is just the IAB/IESG *recommendations* in the form of a "best current practices" RFC. James

1 0

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

13 May '02

Sorry, Francis, >=> one detail which is never called to mind here is an university which >gives internet access to its students *outside* the university (i.e. >in a context where students can need a /48) should be sued by all >commercial ISPs for illegal competition using public money... but this statement is simply ridiculous.... and completely off-topic as well. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

RE: Getting addresses
by Michel Py 13 May '02

13 May '02

David, > 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. This is by choice and not by necessity, because you could have one if you wanted to. Here are a few definitions I glanced in what we are currently working on: 1. At the top level, the `default-free zone', it's not possible to define a default route. BGP speakers in the default-free zone really do need to have a route for every possible Internet destination. 2. The core of the Internet is also called the default-free zone (DFZ) because backbone service providers must maintain a complete map of all globally visible network prefixes reachable throughout the Internet: no default routes are allowed. 3. The Default-Free Zone (DFZ) of the Public Internet is where routers MUST maintain routing entries for all reachable destinations. In short: A router in the DFZ can NOT have a default route. These are tier-1 transit providers. Opposed to tier-2, where you CAN configure a default route to one or more of your transit providers; it actually is common practice for tier-2 to have a floating static default route as backup in case of BGP snafus. As of today, I have not seen a single IPv6 router where you could not configure a default route, as filtering (or the lack thereof) makes almost every peer a transit provider. The ipv6mh mailing list had this discussion a while ago and here is the definition we currently use: DFZ: the subset of routers that do not have a default route and do not receive a full routing table from a single peer. Michel.

1 0

RE: Getting addresses
by Michel Py 12 May '02

12 May '02

> This is very I advocate separate, "earmarked" blocks for > dialup/DSL/whatever, if it is done in such a big scale that /48 > for organization or /32 for an ISP would not be enough. > If you just give out an /32 which should be used for everything, > I think the problem is more serious. One can not know beforehand > how big a block of that /32 must be reserved to dialup/DSL/whatever. > And after it is reserved, what if there is a need to expand? These > things do happen within a time span of 2-3 years. This is where HD > ratio is useful. I have not seen many universities growing their number of students that fast, but any there is a word to address this: PLANNING. If one evaluates that they would need more than a /32 in three years and don't have the 7,100 sites now, there is legitimate reason to ask why they think they need more a /32. I don't have a problem with that figure of 7,100 except that I would have placed the bar a little higher. As far as having multiple blocks, I personally prefer having only one. Michel.

1 0

RE: Getting addresses
by Michel Py 12 May '02

12 May '02

> Gert Doering wrote: As a side note: nothing prevents you from > making better usage of a /32 - 7100 users is the minimum value > you have to document to get a bigger block. > Depending on the way the internal network hierarchy works (if > it has few levels, and all entities at one level are similarily > sized) it is perfectly allowed to utilize 20.000 /48s or more :-) > - it all depends on your network structure. Pekka, I don't know how you came with these figures but Gert is absolutely right. The HD of a dial pool or tunnel pool depends on two things: 1. The HD of the hardware itself, as there are some strong operational incentives to allocate a block per device, such as allocating a block of 256 sites to an access server that has only 192 modems. 2. The network structure. For a dial pool that size, there is absolutely no need for more than one level of aggregation (that would be the pop level). The device with the worst HD I have used is Cisco AS5400, it has 648 modems and it is temping to allocate a block of 1,024 sites to it. That device itself has a HD of 0.934. Then you have the pop aggregate. In a single pop, the worst you can have is 33 of these boxes. This is 21384 sites on a /32, which is a HD of 0.899. On a 3-pop setup, the worst you would have 9 boxes per pop, which still is 17,496 sites and a HD of 0.881. This is the absolute worst case scenario. The bottom line is that a typically organized /32 dial pool has up to 40k sites. Michel.

2 1

Getting addresses
by Peter B . Juul 11 May '02

11 May '02

Hi! The danish research network is part of the native IPv6 project 6net. We've tried for some months to get some IPv6 addresses assigned for this, 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. I gathered that changes were a-coming and RIPE-42 might be a turning point in this. However, I was unable to attend, so I'd like to hear if any consensus was achieved in this? Peter B. Juul, Uniï¿½C (PBJ255-RIPE)

10 28

RE: Multi homed IPv6 (was: Re: Regarding IPv6 prefix filtering)
by Michel Py 11 May '02

11 May '02

> Arien Vijn wrote: > Sorry for the late reply. No need to apologize. > Layer 2/switch software issues kept my attention all week. You mean you had to _work_ ? That's terrible. > All right. But what about these VLANs then? Do you mean that VLANs have > to be defined on both sites of this router/firewall? That's the way I would do it. > Why do you think we need VLANs anyway? Why not just configure n > addresses in the same VLAN? For security issues. Having 90 different prefixes on the same VLAN does not sound good to me anyway. > - VLANs must be defined an must not conflict with those of other > members. Many members do have switches them selves in-between the > IX infrastructure and their border routers. This is not mandatory. In the study case, RIPE-NCC needs to connect to each AMS-IX participant. Let's say that RIPE-NCC has a router in front of the DNS server, that router connects to AMS-IX fabric via a trunk (Cisco's term would be routing on a stick). That router, on the RIPE side, connects to RIPE's switch fabric. - Vlan 277 on one side of the RIPE router can be vlan 377 on the other side. In that kind of setup, you have strict policy routing between the router subinterfaces anyway, so there can be a conversion matrix. - The connection between AMS-IX' fabric and a participant does not need to be a trunk. If the port is an ordinary one that belongs to only one vlan, there is nothing wrong in having two different VLAN numbers. > - VLANs must be configured correctly in multiple places by > multiple parties. You do use something like VTP domains, don't you? > - Administer all these subnets and then hoping peers will route > it correctly. The peers' issue, not AMS-IX. > Suppose we can deal with this. Then it *might* work for UDP but what > about TCP sessions? Failover is a MH requirement too. Failover is a requirement of _real_ multihoming, which is available next year not today. > Is this worth the manpower? > In other words it is too much of a hassle for a solution which, might > be working (but not all the time). Your decision, not mine. > Advertising /48 is unsatisfactory from an aggregation point of view. > But it is the only working MH "solution" at the moment. I actually have less of a problem with the new policy that basically gives an allocation to anyone that wants one. It is a collective hypocrisy that is nothing less than recreating the pre-CIDR swamp. Nevertheless from a design standpoint it is preferable than punching holes in PA. > Our neutrality at least makes us reluctant to use provider space anyway. Find a reason to allocate 200x /48s to foreign entities and get a /32 by the new policy. The only problem with that is that you would appear as the fireman that puts gas on the fire. > I would very much like to see a working and scalable solution. It > would solve one of the main IPv6 issues for neutral, in-depended > entities, which just do not fit the customer-ISP-upstream model. You are encouraged to comment on what we have in the pipe. Michel.

1 0

RE: Getting addresses
by Michel Py 11 May '02

11 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