Re: Getting addresses
Hi Rudolf!
I am new to these discussions on the list, so if I am saying something stupid, please tell me so.
Not at all! The worst thing that is happening here is that we re-iterate things. So what....
I don't have a point of view. A lot of people are telling me they will choose the /48 road. Without a detailed definition of site, almost everyone's view will have to be accepted. That's what I am seeing in all these discussions.
That is what has been bothering me the most in the whole discussion about who gets a /32 assignment and who doesn't.
This is one thing that is so surprising for me in these discussions: There seems to be an implicit assumption that we SHOULD come up with all sorts of criteria to BLOCK distributing IPv6 addresses, rather than getting the technology rolled out :-(). As an aside, I still see IPv6 address space as a *global resource*, not something which a (roughly) self-defined group of entities partitions amongst them (tier-X ISPs). Becoming an LIR is possible for (almost) every type and shape and size of organisations (at least in the RIPE region) - but it is not for free. There are quite some good reasons for distributing globally unique IPv6 addresses to entities which would not fit the "classical" ISP (or even tier-X ISP) definition. And those amongst us who worry about end-to-restoration, making things simple(r), looking into the future, should recognize that there is no "rfc1918" space in v6-land. (Yes, I know about the site-local address concept. But why should we plant time-bombs ticking when there are plenty of those magic bit combinations around?).
Both the number of /48 assignments as well as the determination of what an end-site is, are completely arbitrary
I agree. It's the same level of "arbitray-ness" that is wired into "200 sites", trying to define an ISP, and the like. It's better than nothing at all (i.e. no consensus) - at least for now.
and therefore in the long run unworkable.
We'll see. We havent tried yet. And by the way, we have tried to define "ISP" in v4-land for years, and we failed.
Almost everyone that is an LIR now, is able through one trick or another to justify an allocation of a /32
Actually, this was the point of view that had emerged in the RIPE region during the Jan'02 meeting. "Every LIR should get an allocation" if they can document the need for 1 address. The "tricking" started to come into the game when we again tried to impose (artificial) criteria/ limits/ restrictions/... Btw, I still do remember the days (around '93) when a LIR was allowed to give away a /23 to every "site", no questions asked. And it didn't *break* the Internet, it made it *succeed*! In the end every policy is a compromise. Some of us don't like the version we do have on the table right now because we think it is too restrictive. Some of us dislike the thing because we perceive it as too liberal. Such is life.
and as Joao points out, the RIR's won't be able to do anything against it.
The RIRs should not act *against* "something"! They are supposed to execute a consensus, written down in a document and agreed by the community! It took a loong time, and many discussions, to arrive at the doc we do have on the table right now. And there are things in it which are "fuzzy". That was done deliberately, after trying (and failing) to come to more precise (and sometimes restrictive) definitions that would still be acceptable to all the 3(4) regions. On the other hand quite a few things were straightend out (like the exclusive reference to a /48 holder), and I'd really urge all of you to *completely read* the final doc.
And then I wonder if in the long run we won't see a global routing mess, because many more organisations will be able to register as LIR and justify a /32 in the same way. This is exactly what the requirement for 200 potential sites tries to achieve, but fails to do.
Well, again one of those "assumptions" that this is bad :-) I still think that we can accommodate a *lot* of IPv6 routing with the slack from the (predicted) growth in v4 that did NOT happen in v4-land....
The community should be able to come up with a better definition of who should be allowed to get a /32 and who is condemned to go to an upstream provider. This should be more objective than the current rule and not result in the problems that we see now for RIR's and IXP's and smaller NREN's and ISP's, .
Welcome to the show. I hope you would be around to help when we have to re-work the thing to adapt it to the evolving Internet :-) Just one comment on the use of "smaller" here: we couldn't come up with a good set of criteria to define a "smaller" "whatever". What are the criteria? Real estate? Gigabit/sec? Terabit storage? number of contracts? number of web pages? annual turnover? annual profit (or loss :-)? The tier-1 ISP of yesterday is the chapter 11 case of today and a department of another ISP tomorrow. As I said during the discussion, (given the IETF recommendation) a SOHO customer of a "commercial" ISP s/would qualify for a site .eq. a /48. Probably a handful of physical subnets would be used. And it is easy to have a few hundred of those, eventually (probably). A university, or a regional edu-network could be structured alongside a single /48 as well. Such a "site" could happen to serve some 5000..10000 ..50000 users in quite some hundred physical subnets (LAN, ISDN, ADSL, wire-less). Which of those network would be the "smaller" one?? Is it really "cheating" if we start to treat a primary and secondary school as a site with their own /48? Or the other way 'round, why is the "commercial ISP" not treated as a site with *1* /48? I am stretching things here just a little bit, on purpose...
I think we can evade a global routing slump if we allow the RIR's to continue the excellent work they have done in the last couple of years. They have conserved adresses well.
In one of the doc.s there is that famous statement that conservation and routing aggregation can, or tend to, be conflicting goals.
But we should provide them with adequate rules to work with, so that they can aggregate well in the IPv6 future too.
The problem is the lack of arguments for an RIR on what is the right thing to do.
Joao
Let us provide them with the right arguments to do the right thing.
Fair enough, but -
Maybe we should take that discussion back to the global v6 list.
wouldn't it be prudent to try to *implement* the new policy, learn by doing so, and *then* go back to the drafting table?! I do not believe anybody claiming that we/he/she can find out *now* what the best solution is in a few year's time. The 'net is constantly evolving....
Greetings,
Rudolf van der Berg Dutch German Internet Exchange http://www.ndix.net
OK, I think I'll leave it at that for this discussion :-) Thanks for your good questions and observations! Cheers, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi all, I'm Miguel Angel from RedIRIS. We are configuring our IPv6/IPv4 production servers, with Bind 9.2.1 In the docs related with DNS config, it sais that with .ip6.arpa we should use bitstrings labels to configure DNS servers. And Bind is configured to understand .arpa with bitstring labels. You can check that if you ask for 2001:720:418:cafe::159 Bind try to find \[x200107200418CAFE0000000000000159/128].ip6.arpa and not 1.5.9.0.0.0.0.0.0.0.0.0.0.0.0.0.E.F.A.C.8.1.4.0.0.2.7.0.1.0.0.2.ip6.arpa (really, the nibble fotmat should be used with the deprecated .ip6.int) The problem is that RIPE only makes the delegation using nibble + .ip6.arpa and I think it is not correct. And that's is how they configure it in its nameservers:
0.2.7.0.1.0.0.2.ip6.arpa Server: ns-v6.ripe.net Address: 193.0.0.193#53
Non-authoritative answer: 0.2.7.0.1.0.0.2.ip6.arpa nameserver = tais.rediris.es. 0.2.7.0.1.0.0.2.ip6.arpa nameserver = chico.rediris.es. 0.2.7.0.1.0.0.2.ip6.arpa nameserver = ns-v6.ripe.net. Authoritative answers can be found from: 0.2.7.0.1.0.0.2.ip6.arpa nameserver = tais.rediris.es. 0.2.7.0.1.0.0.2.ip6.arpa nameserver = chico.rediris.es. 0.2.7.0.1.0.0.2.ip6.arpa nameserver = ns-v6.ripe.net. ns-v6.ripe.net internet address = 193.0.0.193 It works, but not:
\[x20010720/32].ip6.arpa Server: ns-v6.ripe.net Address: 193.0.0.193#53
** server can't find \[x20010720/32].ip6.arpa.: NXDOMAIN I think, then, that the reverse delegation is never going to work, because Bind will try to find \[x200107200418CAFE0000000000000159/128].ip6.arpa and not 1.5.9.0.0.0.0.0.0.0.0.0.0.0.0.0.E.F.A.C.8.1.4.0.0.2.7.0.1.0.0.2.ip6.arpa Should RIPE starts to delegate IPv6 prefixes under .arpa using bitstring format? Or maybe I'm wrong? Is someone having the same problem? I've done some tests and as I have said, using nibble with ip6.arpa it doesn't work. Thanks for all, Miguel.
Hi Miguel, Nice to see you are deploying IPv6 at your entity. Simply put: bitlabels and A6/DNAME have proven to be less than ideal for the Internet, and have therefor been put back into experimental status and deprecated for normal use. We are using nibble format under the .arpa and .int trees today. Mind you, e.f.f.3.ip6.arpa has not yet been delegated, and several resolvers still use the ip6.arpa tree to resolve. You're better off for now, not implementing bitlabels in your bind 9 based setup. Stick to nibble stuff in stead! Good luck, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------
hi, On Thu, Oct 24, 2002 at 05:59:41PM +0200, Pim van Pelt wrote:
you, e.f.f.3.ip6.arpa has not yet been delegated, and several resolvers still use the ip6.arpa tree to resolve.
Having read the LIR-WG minutes from R43 today that explicitely ask the RIPE NCC to *solve that* (and a "sort-of" promise from Axel to do so), I wonder whether anything has happened, and if not, why not. David, do you have any idea? This *has* to be solved *quickly*. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert, On Thu, Oct 24, 2002 at 08:34:21PM +0200, ext Gert Doering wrote:
On Thu, Oct 24, 2002 at 05:59:41PM +0200, Pim van Pelt wrote:
you, e.f.f.3.ip6.arpa has not yet been delegated, and several resolvers still use the ip6.arpa tree to resolve.
Having read the LIR-WG minutes from R43 today that explicitely ask the RIPE NCC to *solve that* (and a "sort-of" promise from Axel to do so), I wonder whether anything has happened, and if not, why not.
David, do you have any idea?
This *has* to be solved *quickly*.
I think you were reading my mind :-). I sent mail today to the NCC and asked them to report back on the mailing list on what the status is and whether there are any holdups. I hope this helps, David K. ---
participants (5)
-
David Kessens -
Gert Doering -
Miguel Angel Sotos -
Pim van Pelt -
Wilfried Woeber, UniVie/ACOnet