Daniel, Valeriu, I don't really see why publishing an assignment size alone would allow people to run block lists. People will run those regardless, and if they don't know what size prefix a customer has, they will assume one, and error on the side of caution - i.e. always assume a /48. Misguided people won't stop being misguided because of a lack of information. I wish that was true. As for your first argument, I don't think the RIPE NCC can do a proper job with some public oversight without publishing the assignment size. For IPv4 the world is pretty straightforward, because everybody knows that the size of a customer prefix in a dynamic pool is a /32 or somewhere close to that. It's not a /16. In IPv6, it can be anything from a /64 to a /48 - pretty much at the discretion of the ISP. It should be a surprise to absolutely nobody that ISPs who hand out /48s will go through their allocations a lot quicker than others handing out /64s, and as a result will end up with more address space. A published assignment size for dynamic pools helps to explain to the rest of the world why that is. And it protects your customers from misguided people who like to make assumptions that are safe for them, not your customers. Remco
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Valeriu Vraciu Sent: donderdag 27 januari 2011 9:01 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] Re: 2010-06 is going to Last Call
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 1/26/11 9:36 PM, Daniel Roesen wrote:
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal".
The only one who needs the assignment size is RIPE NCC when evaluating new allocation requests or in audit. At that time, it's easy for the LIR to provide this info to NCC for HD ratio evaluation. Following the spirit of data protection, we shouldn't put (in a mandatory manner) more potentially sensitive data into public databases without a good justification for the need to have that data public.
As a second reason, it allows folks running block lists to again start blocking dynamic customer IP prefixes by automatically looking up the assignment-size. Of course that makes no sense (as the /xy prefix will belong to another customer next day), but as soon as those assignment-size attributes will pop up, misguided folks _will_ start using them for broken heuristics and cause colateral damage.
My opposition is solely about the assignment-size attribute being mandatory.
Best regards, Daniel
Hi, I agree with Daniel's arguments regarding the mandatory and visible status of the proposed new "assignment-size" attribute.
Regards, Valeriu.
================================= Valeriu VRACIU Network Engineer at RoEduNet tel: +40 (232) 201003 fax: +40 (232) 201200 GSM: +40 (744) 615251 e-mail: valeriu.vraciu@roedu.net ================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1BJj0ACgkQncI+CatY9492fwCgiELB3MnMtLYpI1R/INqTgzsZ /DEAninsMzBnbJGgTVA+qfzMg2OoOTYl =JnxM -----END PGP SIGNATURE-----
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.