Hi, On Thu, May 06, 2004 at 12:00:36PM +0200, Pim van Pelt wrote:

I would have expected the IPv6 IRT usage to be much higher, because SixXS uses IRT in our software (and we are accountable for 3000 or so of the inet6num objects in the RIPE database). We only appear to use them in the allocated (/40) blocks, rather than in the assigned space to endusers. I've ammended the code so you can expect some 2800 or so objects to contain an IRT reference after the next iteration of our cronscript (once daily).

Hopefully this sets an example for other IPv6 users.

Ummm, isn't the whole point of the mnt-irt: that it works "downstream", so you don't *have* to put it on all 2800 inet6num entries, but just on the /32 or /40 allocations? But even so: compared to the total number of IPv6 addresses covered by the /32s allocated right now, your mnt-irt:s on a handful of /40s are a good start but won't make a big numerical impact... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

Hi, Thanks for pointing this out. I was not familiar enough with the matter. Apparently Jeroen Massar is, as he headed the implementation of IRT in SixXS. I seem to have messed it up somewhat :-) | Hmm, this is nice, but not really necessary, because with the -c flag in | the whois-query you should get tho the allocated /40 anyway. | | i.e. your change should increase the # of objects, bur not the Footprint | of the IRT .. which was pointed out to me by other individuals as well. While we're on it (and I'm embarraed as it is), should I revert that software change and NOT set mnt-irt in the more specifics, or should I leave it as is. Opinions ? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

Hi *

*** More than *HALVE* of the inet6num's are 'protected' by IRT ***

Ok, Statistics Revisited: 1. Thanx Marco, i now have a database Dump from January as well. 2. added the irt (-c) line denoting all the objects protected by an IRT (either itself _or_ in a less specific) 3. in IPv4 the total count of ip addresses might have changed, because I had to tweak around the code that finds inetnums to ommit in the count (i.e. the iana /8s), because there was no org: in Jan. Comments welcome. IPV4 Statistics Jan 2004 +----------+------------------------------------+-------------------+---------+ | TYPE | Number of IPs | Number of Objects | Handles | +----------+------------------------------------+-------------------+---------+ | inetnum | 369130828 (100.0%) [/3.5 ] | 973621 (100.0%) | 0 | +----------+------------------------------------+-------------------+---------+ | irt | 25503202 ( 6.9%) [/7.4 ] | 1247 ( 0.1%) | 15 | | irt (-c) | 25503202 ( 6.9%) [/7.4 ] | 3774 ( 0.4%) | 15 | +----------+------------------------------------+-------------------+---------+ | abuse | 63048890 ( 17.1%) [/6.1 ] | 137154 ( 14.1%) | 0 | | abuse@ | 55513025 ( 15.0%) [/6.3 ] | 102355 ( 10.5%) | 916 | +----------+------------------------------------+-------------------+---------+ IPv4 Statistics 2004-05-06 +----------+------------------------------------+-------------------+---------+ | TYPE | Number of IPs | Number of Objects | Handles | +----------+------------------------------------+-------------------+---------+ | inetnum | 368768605 (100.0%) [/3.5 ] | 1048213 (100.0%) | 0 | +----------+------------------------------------+-------------------+---------+ | irt | 25957517 ( 7.0%) [/7.4 ] | 2243 ( 0.2%) | 20 | | irt (-c) | 25957517 ( 7.0%) [/7.4 ] | 6057 ( 0.6%) | 20 | +----------+------------------------------------+-------------------+---------+ | abuse | 70783778 ( 19.2%) [/5.9 ] | 150727 ( 14.4%) | 0 | | abuse@ | 61045047 ( 16.6%) [/6.1 ] | 113360 ( 10.8%) | 1050 | +----------+------------------------------------+-------------------+---------+ IPV6 Statistics Jan 2004 +----------+------------------------------------+-------------------+---------+ | TYPE | Number of IPs | Number of Objects | Handles | +----------+------------------------------------+-------------------+---------+ | inetnum | 2.473904089e+31 (100.0%) [/23.7 ] | 3658 (100.0%) | 0 | +----------+------------------------------------+-------------------+---------+ | irt | 1.590039684e+29 ( 0.6%) [/31.0 ] | 79 ( 2.2%) | 5 | | irt (-c) | 1.590039684e+29 ( 0.6%) [/31.0 ] | 96 ( 2.6%) | 5 | +----------+------------------------------------+-------------------+---------+ | abuse | 2.448884817e+29 ( 1.0%) [/30.4 ] | 1686 ( 46.1%) | 0 | | abuse@ | 2.446926357e+29 ( 1.0%) [/30.4 ] | 1537 ( 42.0%) | 85 | +----------+------------------------------------+-------------------+---------+ IPV6 Statistics 2004-05-06 +----------+------------------------------------+-------------------+---------+ | TYPE | Number of IPs | Number of Objects | Handles | +----------+------------------------------------+-------------------+---------+ | inetnum | 2.845286343e+31 (100.0%) [/23.5 ] | 5357 (100.0%) | 0 | +----------+------------------------------------+-------------------+---------+ | irt | 3.992163199e+29 ( 1.4%) [/29.7 ] | 135 ( 2.5%) | 12 | | irt (-c) | 3.992163199e+29 ( 1.4%) [/29.7 ] | 2816 ( 52.6%) | 12 | +----------+------------------------------------+-------------------+---------+ | abuse | 4.445365368e+29 ( 1.6%) [/29.5 ] | 3213 ( 60.0%) | 0 | | abuse@ | 4.443286016e+29 ( 1.6%) [/29.5 ] | 3054 ( 57.0%) | 91 | +----------+------------------------------------+-------------------+---------+ lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140

Hi,

So you need to be really careful which percent values you're discussing over... :-)

That and also this difference I tried to show hith my statistics. The address-space Footprint is very low in v6. But when the guys receiving the big allocations from the NCC would use irt, it would be around 99% ;-) lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network - Security - ACOnet-CERT Universitaetsstrasse 7, 1010 Wien, AT eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 PGP Key-ID: 0xA8D764D8 Fax: (+43 1) 4277 / 9140

Hi, On Thu, May 06, 2004 at 05:12:29PM +0200, Jeroen Massar wrote:

But a good question: "Why isn't there a mnt-irt (yet)"

Due to concerns on the mandatoryness of the "encryption:" attribute. Our current abuse workflow doesn't permit PGP crypted mails, so I am a bit unwilling to setup an infrastructure that might result in half of the abuse mails going to me personally due to being PGP crypted... (But I mentioned that already in this list) Ulrich Kiermayr (sp?) pointed out today that he has never seen a complaint actually *using* PGP encryption, so I might well reconsider this :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

On Sat, 8 May 2004, leo vegoda wrote:

The point was that while all /48 assignments must be registered, they don't all need to be registered in Whois. I think the expectation is that the vast majority of address space users will have their address space registered in the LIR's private, internal database and not the public, Whois database. The drafters of the policy text had only intended to require registration in Whois when a single organisation received more than a /48.

I would urge you to reconsider. With IPv6 it is expected that almost all assignments to customers will actually be /48 as very very few customers actually need anything more then that (even large companies that currently might have /19 can be fine with /48 ip6). As such that basicly means the rir ip whois will no longer be of any use to do things research on geographical and other data on ip space, research on customers due to abuse or copyright complaints, confirmation and research on proper use of ip space by company (RIR are not the only entities that should be able to verify their claims - what if they claim something for their marketing and you know its not true, etc). Additionally considering how some (many) companies keep their internal "ip assignments" database I have this bad feeling that if you do not actually provide standard way to enter the information and requirement to keep it updated, that much of the data will never be entered and will not be kept updated which again might result in number of problems when you urgently need to find whose ip space it really is (and ISP helpdesks would be completely useless when its immediate problem and they themselve cant even identify who it is...). The correct way I think is to have clearly identified privacy policies (based on EU laws if its EU country I would suspect) what kind of information should the ISPs be required to provide in the whois and require that all /48 reassignments (but not /64s) be registered in whois but that information provided about the user (i.e. is address included or not) be based on that privacy policy. - William Leibzon Elan Networks william@elan.net

On Sun, 9 May 2004, Ulrich Kiermayr wrote:

...

I would urge you to reconsider. With IPv6 it is expected that almost all assignments to customers will actually be /48 as very very few customers actually need anything more then that (even large companies that currently might have /19 can be fine with /48 ip6).

The problem is that IPSc could (and regarding what I hear would) give out /48s to ther end users [if there is a chance they need more than one subnet]. In our case you would probably end up with ~30000 /48 assigned that way - and as a university we do not have that many DSL end-users.

In your case there is no need to actually provide whois reassignments because the ips are still in use at the university (ok by its students) and it is the same with IPv4. Nor is there reason why large company would provide reassignments on each /48 for each of their employers. Deligations and reassignments to organizations different then the one that received the ip block (from upstream or directly from RIR) or for personal use by end-users (in that case meaning not for use to do business or other similar activity as part of the organization that received ip space) are the only ones I meant as those that are usefull to have in the whois database. Their number would be in the same range of numbers as what is currently entered in whois for IPv4.

But what about the really big ISPs? At the moment the Ripe DB contains slightly over 1.000.000 Objects. if those ISPs register every /48 they assign, you end up with orders of magnitude more objects - and a consderable higher update-rate.

I do not believe we have any reason to worry that number would be too high that RIRs would not be able to handle it as it would be the same type of use as is currently entered in whois for IPv4 that are likely to receive majority of assigned /48s (i.e. reassignments to bussiness with multiple computer networks or to "well networked" homes). Also technology capabilities are still increasing and current databases (as seen based on millions of domains in .com) are quite capable of handling large number of records. Additionally the RIR policies are not meant to be a fixed thing, if you do ever find out that load on whois database due to new records being entered in is growing at the rate too great that it might indanger stability of such database, then obvious reaction on part of RIR and its members would be to modify policies to eliminate this threat (i.e. remove those /48 records from public site then and remove need to enter any more of them).

The deeper reason is that the way IPv6 addresses are handed out and the Space is devided, you can have end-users occupying the same IP space as big companies.

If these end-users have large enough network that they need /48 on public internet as does some large public company, then perhaps they should accept responsibility that comes with it. -- William Leibzon Elan Networks william@elan.net

The correct way I think is to have clearly identified privacy policies (based on EU laws if its EU country I would suspect) what kind of information should the ISPs be required to provide in the whois and require that all /48 reassignments (but not /64s) be registered in whois but that information provided about the user (i.e. is address included or not) be based on that privacy policy.

I disagree. IP space is a public resource, much like land. Just as who owns a piece of land is public information (everywhere I know of, at least), and this is not considered privacy-intrusive, I believe that being assigned a piece of IP space should require the owner information to be public. Nobody is required to hold any IP space, after all. If privacy laws in some jurisdiction make this illegal, then IP space simply must not be assigned to entities in that jurisdiction. Having IP space is not a right. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

...

IP space is a public resource, much like land. [...public ownership records...] This logic is problematic I think, because it might give a gouvernment an oppertunity tho get control over the IP-assignments under its juristiction.

It already has such control if it wants it, because the entities to whom the IP space is assigned are under its jurisdiction.

...

If privacy laws in some jurisdiction make this illegal, then IP space simply must not be assigned to entities in that jurisdiction. Having IP space is not a right. But getting one should not depend on local law.

I agree that it shouldn't. But lots of things that shouldn't be nevertheless are. I do not consider it acceptable for a jurisdiction to allow entities in it to evade the responsibility I believe they have to be accountable for public resource fragments assigned to them. The right answer to "this country doesn't permit me to make my contact info public" is "that's too bad, come back when you've got your laws fixed", not "well then I guess we'll let you duck the responsibility that inheres in the privilege we're granting you".

Just look how much of Internet and stuff is right now dependent on US Law - and we should avoid such implications wherever possible.

I agree that the IAB, IANA, and ICANN should be multinational entities (UN entities maybe, though I'm not entirely comfortable with that either), or perhaps set up in international waters, so as to not be under the thumb of any particular country. But this is a very different issue. In fact, I think your point supports my argument: I am arguing that the contactability and accountability requirements for having IP space should be designed for good operation of the net, rather than for conformance to any particular jurisdiction's restrictions. Countries with laws that conflict would then be faced with three choices: they can change their laws, or they can do without networking, or they can try setting up an alternative network with whatever characteristics they think good. Certainly the contactability and accountability mechanisms in place now aren't working. Whether this is an enforcement issue or a requirements issue is an open question - but _something_ needs to change. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

...

I do not consider it acceptable for a jurisdiction to allow entities in it to evade the responsibility I believe they have to be accountable for public resource fragments assigned to them. The LIR holding the address space *is* visible.

What good does that do? None of the LIRs do anything of use about broken contact information as far as I can see; the most I've seen anyone do is ARIN putting in a little note about "we know this contact information is broken, but we're going to let this address space go on being used by someone not even we can contact anyway". (I'm paraphrasing rather loosely, of course.)

So if one of their customers is doing bad things, you know whom to talk to - and if necessary, sends the feds to.

Actually, no, because the jurisdiction the LIR is in is not necessarily that of the end user. For example, I, in Canada, have address space whose LIR is ARIN, in the US. Or is this for values of "LIR" that include all entities who reassign their allocated address space?

If the LIR is "careless" - well, in that case mandatory end-user registrations aren't going to be very useful either.

Ultimately - if the IANA actually bothered to enforce them - they would get a sloppy LIR decommissioned, or at least its own assignemnts revoked, which amounts ot the same thing in practice. (Of course, this would be a last-resort action; presumably the IANA would take other measures first, but, ultimately, it's what would have to be done with a persistently uncooperative LIR....) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Now you seem to confuse LIR and RIR?

Urk. Yes, you are of course correct; I managed to get LIR and RIR switched around in my head when writing that, making most of it nonsense.

I agree that a LIR's contact data should always be up-to-date, and actually enabling people to contact "someone" who can "make things stop".

Well, "can" != "will", and therein lies a large part of the problem. Try to get anything done about the spammers hosted by Chinanet, for example.

Unfortunately, not even *this* is currently in place - and IMHO that's a much worse problem than "having end-user data in there or not".

Agreed, entirely agreed. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Tim Streater wrote:

I want to do something like the following:

import: from as<number> accept NONE except { from community.contains(val-a) action community.append(val-aa); accept any; from community.contains(val-b) action community.append(val-bb); accept any; }

That is to say, on my peering with as<number> I want to accept routes based on communities but add a new community based on the value of the existing one, and then accept the route. Is this a suitable syntax - except for the lack of a NONE keyword? Or can I fake this by using 0.0.0.0 instead of NONE? Or is there a better solution altogether?

"NOT ANY" = NONE Mark.