Hi Jordi, On 21 Jun 2007, at 7:38am, JORDI PALET MARTINEZ wrote:

We are talking about two different things/cases.

Both proposals may seem as related, but actually they are not.

In fact, we can't relate both policy proposals also, because it is not clear that 2006-01 will go further (at least not with the actual text), as I didn't got inputs to my last replies to previous inputs :-( So it is difficult for me to keep going w/o community review.

2006-01 seems to have had a couple of dozen comments on it over the last month, actually. Are you referring to something else?

2006-02 is intended for entities that have their own network with multiple sites.

I think the intention makes sense but the phrasing of the policy text needs some work. It looks like you want an end site to qualify for a /32 IPv6 allocation if it needs to make *any* size of assignment to multiple internal sites. But the text doesn't actually define what one of these internal sites is. That creates a problem for anyone that wants one of these /32 allocations because they can't work out if they qualify for it or ought to try and get a /47 (or whatever) under the IPv6 PI policy. If the policy text is confusing it's going to create lots of extra work for the requesters and the RIPE NCC.

Those sites behave as end-sites to the "internal" ISP. This is for example the case of Universities, or NATO (just to mention a clear case) that already have indicated in the list their need. I don't see those as PI cases, because they are by their own real ISPs, even if for the same entity, they have their own NOC, staff, etc. to manage the network.

Instead 2006-01 is looking for PI cases, for example a data center.

So I don't see the need to stop 2006-02, and what it is really needed is to get more input on 2006-01 !

I think the issue still remains: 2006-01 and 2006-02 need to work together closely. Presumably, a network that does not qualify for a / 47 should not qualify to receive a /32. Or should it? If it should not then how does this policy text ensure that? Because as far as I can tell there isn't a good definition of what one of these 'final' sites is, so anyone can claim that every /64 in their internal network is a site and get a /32 allocation. Regards, -- Leo Vegoda IANA Numbers Liaison

Hi Jordi, On 25 Jun 2007, at 4:34pm, JORDI PALET MARTINEZ wrote: [...]

...

It looks like you want an end site to qualify for a /32 IPv6 allocation if it needs to make *any* size of assignment to multiple internal sites. But the text doesn't actually define what one of these internal sites is. That creates a problem for anyone that wants one of these /32 allocations because they can't work out if they qualify for it or ought to try and get a /47 (or whatever) under the IPv6 PI policy.

We can't base this policy proposal in the existence of the IPv6 PI one, because it is not the case.

We can't base one on the other but if both proposals make it through the PDP and become policies it would be a shame if they didn't work well together. [...]

...

If the policy text is confusing it's going to create lots of extra work for the requesters and the RIPE NCC.

I don't really think it is the case. It will be the same right now for anyone, requesting space because "plan for 200 sites" is basically a lie. We have removed this in other regions, I don't see why we are still willing to set a new barrier, which may become artificial again.

I see lots of extra work because I find the proposed policy text confusing. The definitions are vague and that makes it difficult to work out how to apply the conditions. Each requester needs to understand the policy so that they can decide if they qualify and then send in a request. If they find the policy text confusing the RIPE NCC needs to produce an explanation in training material, in e- mail or over the telephone. But wouldn't it be better if the policy text didn't need explanation? I agree that the current policy is flawed but is this proposal an improvement? It seems to maintain the form of the current policy while removing its context. If the intention is to ensure that all LIRs can have a /32 then why not just say that RIPE NCC membership qualifies an LIR for a /32? If RIPE NCC membership alone if not enough then I think you need to work on the definition of a site because I find the recursive nature of your proposed text difficult to understand. [...]

...

If it should not then how does this policy text ensure that? Because as far as I can tell there isn't a good definition of what one of these 'final' sites is, so anyone can claim that every /64 in their internal network is a site and get a /32 allocation.

Same as today. I still believe we should move ahead, and if required improve it in following cycles, not be stuck forever.

I'm not opposed to making IPv6 address space available to all the networks that need it. I just think basing the policy for doing so on a concept that is so slippery we can't really define it is fatally flawed. If the net effect of your proposal would be that more than 95% of members would qualify for a /32 allocation it is probably simpler to just make the qualifying criterion being a RIPE NCC member. That way we can get rid of impossible to define concepts like "End Site" and near-but-not-quite restrictions, like the requirement for a plan to make more than one assignment to an end site within two years. [slightly reordered]

...

...

I think the issue still remains: 2006-01 and 2006-02 need to work together closely. Presumably, a network that does not qualify for a / 47 should not qualify to receive a /32. Or should it?

It is not a matter of the size of the prefix. It is a matter of understanding if we are talking about an ISP or something different. An ISP, even if it is an ISP for a specific organization (one that has several sites and consequently need to assign space to them), requires PA. The other cases requires PI.

So if an organisation planned to connect eight internal sites through a single external connection they should receive a /32 and not a /45 or /44? Regards, -- Leo Vegoda IANA Numbers Liaison

...

flawed. If the net effect of your proposal would be that more than 95% of members would qualify for a /32 allocation it is probably simpler to just make the qualifying criterion being a RIPE NCC member.

Well. Let's do a straw poll...

"who is in favour of doing so?"

Me. I've expressed this opinion lots of times, although Leo's justification for it is characteristically succinct. Messing around with restrictive policies which are just going to end up making LIRs lie about their requirements is both silly and counter- productive. If a LIR applies for IPv6 address space, they are presumably going to use it. If they don't want it, they are not going to apply for it. What's the big issue here? I would like to see something along the lines of: "A LIR is automatically entitled to an initial IPv6 /32 allocation. If the LIR requires a larger initial allocation or subsequently requires further allocations, justification must be provided." Everyone's been tying themselves up in knots about this policy proposal since May last year, and we've really got no-where since Jordi's original document. Meanwhile, LIRs are still lying, and RIPE is still turning a blind eye to this. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie

Seconded.... Good to see a refreshing 'short and to the point' suggestion. After all that has been said over the past months, I guess we need something that will work, rather than be worked-around ! Mark

-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Jeroen Massar Sent: 26 June 2007 20:01 To: Gert Doering Cc: Leo Vegoda; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2006-02 Last Call for Comments (IPv6 Address Allocation and Assignment Policy)

...

I think it would make sense, to have "full-weight" LIRs

Gert Doering wrote: [..] that automatically

...

get a /32-or-bigger allocation, and possibly "light-weight" RIPE "customers" (to get the contractual stuff that is desired) that get a /48-or-so PI.

Just as a rough outline - details to be worked out.

The outline sounds good to me, you have my support (though of course show details first ;).

And it is *MUCH* better than the current proposals which are simply going to waste address space.

It is then also very simple "become member, pay fees, justify space requirement, get it, done presto"

Also that avoids any need for ULA-C as everybody is covered. Now if only the rest of the RIR community was able to understand that point.

Greets, Jeroen

Nick Hilliard wrote:

Jeroen Massar wrote:

...

It is then also very simple "become member, pay fees, justify space requirement, get it, done presto"

The whole point is that it's even simpler: "become member, pay fees, get space, done presto"

And which prefix size does the organization get then? There are enough end-site organizations that can easily justify a /42 worth of address space, 64 /48's isn't that much if you give every separate building where you have an office a /48 and those offices can definitely be considered sites. Easy is great, but there should be a possibility for sites to request a bit more. When the size becomes smaller than a /40 (eg /32) I do suggest that these prefixes are considered to be PA though and that they cough up the normal LIR fees, at that size one is hopefully running a nice internal ISP anyway who has LIR functions already.

Incidentally, this is irrelevant to ULA-C, which is primarily intended for end-users.

ULA-C should never come in existence in the first place. But why would an end-user not be able to request a /48 when they are willing to pay the fees? (And fill in the paper work, justification, come up with gear, connectivity, pay for all that etc). I am pretty happy that we are running SixXS, as it allows me to simply get the same /48 everywhere I go, the tunnel just moves along with me. Same goes for quite some other users who move from city to city or from country to country (this is my 3rd country for instance :) and I keep the same prefix where-ever I go. Same goes of course when you have PA space and work for an ISP and simply tunnel your own /48 to where-ever you go. As long as you are happy friends with them you can take it along with you. As for folks "but that takes up a routing slot": we now got ~800 routes in the IPv6 DFZ(*), that is a far cry from the 200k in IPv4. Before we even reach 100k most likely (and hopefully) the smart folks have come up with a nice id/loc mechanism. Then at that point the "Tier Wars" can begin, if you are cool enough, and thus have a PA prefix, you can remain in the DFZ, if you are not, thus with a /48 or so, you have to start using id/loc. As the non-PA prefixes are being allocated from well known blocks and they are non-/32 in size, filtering on the can become very easy. Also to mitigate that an ISP has a /20 PA and simply announces /32's one can of course easily handle that by having per-prefix filters. Greets, Jeroen * = before Randy jumps in, lets just define "IPv6 DFZ" as the prefixes that are seen by RIPE's RIS and GRH, those systems are public and are fed by a rather large amount of ISP's around the globe, when they have the prefixes (especially when it is >20% in GRH for instance) then it certainly can be said IMHO that the prefix is "on the Internet")

On 26 Jun 2007, at 19:00, Jeroen Massar wrote:

Also that avoids any need for ULA-C as everybody is covered.

Non sequitur. Your conclusion may be true; unless you choose to expose your logic, it is unproven, and may even be just wishful thinking. I'ld really like to see a conclusion (for or against, I don't care) about ULA-C which didn't involve religious convictions. That probably belongs in another thread. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

On 27 Jun 2007, at 00:41, Jeroen Massar wrote:

See the various other discussions about ULA-C

I have, and I'm disappointed by what seems to me, on both (all?) sides to be a combination of hidden agendas, prejudice, grandstanding, and refusal to acknowledge that the opposing argument may even be made in good faith.

and the amount of questions that have been raised and remain unanswered and start tapping into that and answering them, then we can proceed with that part. Upto now those questions remain open and as such there actually is not even a real case at all why such space should exist, except for some people wanting to have "really cheap PI" space for vaguely defined examples.

And that case can be solved by what Gert proposed, thus then there really is no need any more for ULA-C.

Simply repeating your opinion isn't going to convince me that it has a real basis. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

Hi, On Wed, Jun 27, 2007 at 09:53:40AM +0100, Niall O'Reilly wrote:

Besides, this is probably not the right thread, or even list. A propos, if I do find time and energy, which would be the most appropriate list?

The ULA-C discussion is currently happening on the IETF lists, and as far as I understand, the "ipv6"-WG list is the right place. If the IETF says "ULA-C are a good thing" it will come back to the RIPE APWG list (and the other regions' policy fora). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

On 26 Jun 2007, at 10:19am, Gert Doering wrote:

On Mon, Jun 25, 2007 at 06:02:19PM -0400, Leo Vegoda wrote:

...

I'm not opposed to making IPv6 address space available to all the networks that need it. I just think basing the policy for doing so on a concept that is so slippery we can't really define it is fatally flawed. If the net effect of your proposal would be that more than 95% of members would qualify for a /32 allocation it is probably simpler to just make the qualifying criterion being a RIPE NCC member.

Well. Let's do a straw poll...

"who is in favour of doing so?"

However the IPv6 allocation policy is revised, it needs to work well with a PI assignment policy. If the only criterion for receiving a / 32 IPv6 allocation is that you become a RIPE NCC member then you create a situation where networks wanting PI space must demonstrate a need for anything more than a /48 but anyone willing to pay €3300 can get thousands of times as much space without needing to show any need. One of the goals for IPv6 address space management is: 3.6. Fairness All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor. I am not sure that this goal can be met if the only barrier to a block 65,636 times as large as a /48 PI assignment is an annual payment to the RIPE NCC. As such, I'd like to see work to update the policy in a way that would allow a quantifiable basis for evaluating requests for both PI and PA. I'm not sure that the current set of proposals allow that. Regards, -- Leo Vegoda IANA Numbers Liaison

Hi, On Tue, Jun 26, 2007 at 06:35:20PM -0400, Leo Vegoda wrote:

However the IPv6 allocation policy is revised, it needs to work well with a PI assignment policy. If the only criterion for receiving a / 32 IPv6 allocation is that you become a RIPE NCC member then you create a situation where networks wanting PI space must demonstrate a need for anything more than a /48 but anyone willing to pay ?3300 can get thousands of times as much space without needing to show any need.

Indeed. But given the past 7 years of history, we can't seem to come to a rule set that is more complex than "be LIR, ask for it" that people will agree upon. In IPv4 land, we had entry barriers for LIR allocations for a while, and that didn't work, so we're back to "be LIR, ask for it, get PA space" - and that model seems to work quite well.

One of the goals for IPv6 address space management is:

3.6. Fairness

All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size, or any other factor.

I am not sure that this goal can be met if the only barrier to a block 65,636 times as large as a /48 PI assignment is an annual payment to the RIPE NCC.

One of the differences is a different tag on the address block ("this is for me only" vs. "this is for me and my customers") - PI vs. PA. OTOH, I can't really understand this excitement about the size of the address block. A /48 is large enough for all but the biggest "end user" networks - and a /32 is still fairly small regarding the total amount of /32s in FP 001. If the numbers are so huge, people should really stop worrying about "this guy got a bigger one than I did!!!". Thus I'm not worrying very much about bit haggling (this is IPv6, not IPv4), but about - general availability of IPv6 (-> make PA space *easy* to get) - pressure on the routing system (-> *one* prefix per LIR, if at all possible, and some incentive to not use PI for "normal end sites") Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

michael.dillon@bt.com wrote: [...]

But, since an organization with a single external connection is not an ISP

How, why and when did you arrive at that conclusion? And for which definition of ISP? And for which definition of external?

they should not receive a /32. In general, /32s should be for organizations with steadily growing networks and also a few critical infrastructure types of organization which needs the operational characteristics of an ISP allocation.

--Michael Dillon

Wilfried