Hiya Randy, All, On Tue, 4 Sep 2001, Randy Bush wrote: -> ->an ix has a perfectly normal way to get infrastructure space now. the ->exchanges you mention have such (v4) space now. i am not aware of anyone ->suggesting to remove those policies. -> ->what we're trying to do here is to let those ixs who are now throwing up ->v6 peering meshes get the address space for those meshes. we are not ->trying to change the world, annoint ixs over isps, web hosters, ... -> ->life can be simple if we let it. -> ->randy This is not true and/or irrelevant, at least in Europe. We are also talking about non-peering-mesh infrastructure. In order to presently get IPv6 TLA space during the bootstrap phase, an applicant must meet RIPE-196's 4.2.2c or 4.2.2d (40 customers/6 months Mbone) criteria which presently are not met by IXPs. This is I believe why IXPs applications have been rejected/frozen. After the bootstrap phase things might get worst, since according to 4.2.1a ALL applicants must have 3 IPv6 peerings - which is practically impossible as they have not yet got the addresses with which to peer ( chicken and egg :-) Confusing the issue by comparing IXPs with small ISPs does not help at all and could initiate all sorts of complex side discussions such as IXPs issuing addresses to customers. ***The purpose of this discussion is to fix this and loosen up the allocation policy for ISPs. We need a quick perhaps temporary policy to fix this now. As a comment, it might save work for the RIPE NCC if the IXPs were to receive a standard sub-TLA. A separate discussion (apparently secret and certainly going on behind closed doors) might permanently improve the allocation policy for the rest of us. Cheers Dave ps. In IPv4 until very recently just about anyone could get an allocation by joining RIPE. IPv6 is *much* stricter - a reason for sticking with IPv4 ?

On Tue, 4 Sep 2001, Jim Dixon wrote:

On Tue, 4 Sep 2001, Dave Pratt wrote:

...

ps. In IPv4 until very recently just about anyone could get an allocation by joining RIPE. IPv6 is *much* stricter - a reason for sticking with IPv4 ?

It's very odd indeed, given that there is so much IPv6 address space and correspondingly little justification for tight management of that address space.

Please keep in mind that I for one don't want Joe Random's Own Little ISP, for example, get a sTLA. The whole point of tightly aggregated DFZ is pointless if that would be the case. Getting IPv6 address space, subTLA-level address space, should be way more difficult than getting an IPv4 /29 delegation. Let's not lose the meaning of sTLA; it's not (in my book at least) meant for small ISP's. Another question entirely is whether IXP's are "significant enough" in this sense, and would this encourage small ISP's, which wouldn't normally be allowed anywhere near a subTLA, found an _"_IXP_"_. So.. Don't be stingy with address space with those that actually do peering (other than tunnels!), but otherwise... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords

While the technical discussion is very important, please also do not loose site

... my apologies for my appalling spelling and grammar at the end of that line. I have no excuse as a native English speaker. Please blame the lack of coffee and the lack of a working network this morning. Peter

On Tue, 4 Sep 2001, Randy Bush wrote:

...

While the technical discussion is very important, please also do not loose site of the fact that it is not RIPEs role to act as a regulator. You cannot restrict a companies (or individuals) ability to carry out normal business because you think they are 'too small'.

what are you people smoking?

what is proposed is a NEW way of getting space in a specific case, not a restriction, but a very specific liberalization.

IMO, it should be noted more clearly in the draft (as pointed out before) what the target group is. If there is no prior policy, people will automatically consider something new as _the_ policy, and start to forget that there might be other options.. That is, so that 2 years down the road if you as an IX have address space needs that can't be met with the proposed solution, won't (necessarily/always) be met with "Sorry, this is how we allocate addresses to IX's. Have a good day." because people forgot it was only supposed to be _a_ way. I'm not saying that that would happen, but opinions on what the policy was all about might change in 6, 12, 18 or whatever months unless some kind of "applicability statement" is added. The last RIPE IPv6 allocation policy is from 1999. Who thought it would last this long? Who knows how long the interim policy would be active? It's better not to take chances. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords

Randy, On Tue, Sep 04, 2001 at 10:35:41AM -0700, Randy Bush wrote:

yup, we need a new v6 lir allocation policy. yup, we saw proposals for a new global v6 allocation policy at apnic. there may be a gap between the apnic view and others, they prefer a /29 starting allocation, which even steve deering thinks is too large. imiho, a /35 or a /36 is more in scale and sellable in the west. but i may be full of it. we'll be discussing the issues in prague and miami next month. in the meantime, check out

<http://www.apnic.net/meetings/12/sigs/joint_ipv6.html>

Judging the mails and proposals regarding ipv6 allocation policies that I have seen so far, and the discussions we have had at previous RIPE meetings, it seems that the gap between the apnic view and ripe community view on this matter is minimal. David K. ---

It's very odd indeed, given that there is so much IPv6 address space and correspondingly little justification for tight management of that address space.

Apart from the feeling of power it grants those who are responsible for allocating it. That's my cynicism kicking in - again. Peter

I don't see any huge conflict between what Randy and Dave are arguing here: Dave Pratt wrote:

->an ix has a perfectly normal way to get infrastructure space now. the ->exchanges you mention have such (v4) space now. i am not aware of anyone ->suggesting to remove those policies.

This is not true and/or irrelevant, at least in Europe. We are also talking about non-peering-mesh infrastructure.

So long as the same policies for "PI" IPv6 space remain open to IXPs to use for their non-peering-mesh requirements in the same way some use their own LIR IPv4 space, then I am satisfied the proposed policy is a reasonable approach. Since our multi-IXP plans mean we will need to apply for our own sub-TLA in due course, that's what we'll do (and giving IXPs who meet the existing criteria is not going to break the bank anyway, as there are maybe two orders of magnitude less IXPs than ISPs). But we can only do this if we have some way of achieving the criteria for this, and that requires ISP-neutral IPv6 space for our peering mesh so we do the peerings needed to meet these criteria. And that is the hurdle we have been struggling to overcome for about 8 months now:

->what we're trying to do here is to let those ixs who are now throwing up ->v6 peering meshes get the address space for those meshes. we are not

In order to presently get IPv6 TLA space during the bootstrap phase, an applicant must meet RIPE-196's 4.2.2c or 4.2.2d (40 customers/6 months Mbone) criteria which presently are not met by IXPs. This is I believe why IXPs applications have been rejected/frozen.

Correct. And the proposal put forward by the RIPE NCC a couple of weeks ago solves this. It IMHO has the dual merits of not solving any other problems, and not creating any other problems, as the limited scope does not generate exceptional precedents that can be exploited by non-IXPs wanting special allocations.

After the bootstrap phase things might get worst, since according to 4.2.1a ALL applicants must have 3 IPv6 peerings - which is practically impossible as they have not yet got the addresses with which to peer ( chicken and egg :-)

***The purpose of this discussion is to fix this and loosen up the allocation policy for ISPs. We need a quick perhaps temporary policy to fix this now.

So please can we go with the existing proposals, which provide a way around this, ASAP, so we have as much time as possible to prepare for the end of the bootstrap phase.

it might save work for the RIPE NCC if the IXPs were to receive a standard sub-TLA.

Not really, as the RIPE NCC have already done most of this work, on the basis of several months' of the silent appearance of consensus from previous discussion of this issue. I have not yet seen anyone in this most recent discussion raise any major reasons not to go with the proposal as it stands that have not been addressed in previous incantations of the debate. We do have a need for this address space for our business now, and my patience is getting pretty stretched. Please can we proceed with at least interim allocations under the proposed policy now. Frustrated of Pimlico, Keith Mitchell CTO, XchangePoint http://www.xchangepoint.net/contact/keith/

So picking up on Keith's point: Here's where we seem to be at. The joint working group chairs have put forth a proposal making obtaining a /64 for a peering mesh doable for any bona fide exchange point operator. The chairs put forth this interim policy proposal to these lists hoping to garner consensus or judge that consensus does not exist. The ensuing discussion, while not unuseful, does not appear (to me) to be helping the chairs and the wg membership from gauging the extent to which there is consensus for this interim policy proposal. So I ask: In lieu of any other policy changes, are you, as a RIPE member and participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy proposal for IPv6 address assignment policy for internet exchange points? /david

In lieu of any other policy changes, are you, as a RIPE member and participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy proposal for IPv6 address assignment policy for internet exchange points?

yes

Hiya, On Tue, 4 Sep 2001, David R Huberman wrote: ->So I ask: -> ->In lieu of any other policy changes, are you, as a RIPE member and ->participant in the LIR, EIX, and IPv6 WGs, in favor of the interim policy ->proposal for IPv6 address assignment policy for internet exchange points? -> ->/david Sorry, I cannot agree with the proposed policy as it stands since: 1. The idea of issuing a single/multiple /64 is totally unnecessary. 2. As stated many times by many, the IXP need globally routed space, which they cannot get under present normal sTLA allocation rules. Allocate a /48 (or larger), and remove the comments about not being "globally routable" and I would be happy. Cheers Dave

Dave,

Dave Pratt wrote:

...

Sorry, I cannot agree with the proposed policy as it stands since:

1. The idea of issuing a single/multiple /64 is totally unnecessary. 2. As stated many times by many, the IXP need globally routed space,

which

...

they cannot get under present normal sTLA allocation rules.

Allocate a /48 (or larger), and remove the comments about not being "globally routable" and I would be happy.

While I understand you don`t agree with the policy as its stands, it is an *interim* proposal to facilitate v6 take-up within the ixp community.

The trouble with *interim* policies is once they are in place they never change or are very difficult to change.

No doubt if we shift the policy to fit your wishes, someone else will disagree. In the interests of pragmatic progression, lets debate these issues from the perspective of a working model and get this policy approved.

Regards, Steve.

Randy, On Wed, Sep 05, 2001 at 07:15:38AM -0700, Randy Bush wrote:

...

1. The idea of issuing a single/multiple /64 is totally unnecessary. 2. As stated many times by many, the IXP need globally routed space, which they cannot get under present normal sTLA allocation rules.

both above statements are patently false.

1. there are ixs who need/want it and are actively waiting for the /64 to open their mesh

2. the ix can get globally routable sTLA just like everybody else can.

As pointed out earlier, there are alternative ways of getting a /64 for an exchange point. Therefore, Dave's first statement is not in any way a 'patently false' statement as you claim. The ixs that you are talking about decided that those alternative solutions are not good enough for them - while for example Palo Alto Internet Exchange apparently decided that the alternative solution served their business needs just fine. And then there is yet-another-solution that doesn't even need a /64 but that results in ugly traceroutes. As for your second point, I don't think it is as easy as you claim it is. Yes, exchange point operators can ask for a sTLA, but at the same time, the requirements to get them according to the current allocation policy make it very hard to get one without bending the guidelines or without interpreting the guidelines in a way that only the us supreme court can understand. Luckily enough, the guidelines are up for revision so we will have a chance to fix that :-). David K. ---

Hi Dave At 10:24 am +0200 6/9/01, Dave Pratt wrote:

I wrote: ->> > 1. The idea of issuing a single/multiple /64 is totally unnecessary.

This point was poorly expressed and could be mis-interpreted. As hinted at later in the same email, allocating a /48 makes much more sense to me if we want to save work for the NCC and the IXPs.

The current proposed allocations are being made with /48 boundaries so that we can make the change following discussion in Prague if that is the consensus about the interim policy. We, as in the WG-Chairs and the NCC, have tried to make the interim policy extensible to allow it to be easily modified as we get more feedback on areas that were causing some people concern but that there was no consensus of what was the right way forward. f