This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ncc-services-wg@ripe.net/
[address-policy-wg] Re: [ncc-services-wg] IPv6 applications (was: Request Forms: updated and available on LIR Portal)
- Previous message (by thread): [address-policy-wg] Re: [ncc-services-wg] IPv6 applications (was: Request Forms: updated and available on LIR Portal)
- Next message (by thread): [ncc-services-wg] Proposal for easing keysigning at meetings
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sascha Lenz
slz at baycix.de
Tue Sep 2 07:56:42 CEST 2003
Hay, On Mon, Sep 01, 2003 at 04:33:06PM +0200, Gert Doering wrote: > Hi, > > On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote: > > You both made several points and I hope I can explain our thinking on them > > for you. We think these new forms represent a change in the way we provide > > services to LIRs so we've addressed this answer to the NCC Services WG list. > > We don't think they represent a change to the RIPE community's policy. > > Actually, I tend to disagree, at least for some parts. Which is why > I've put the APWG list back into the CC: (sorry for duplicates). > > Some of the criticism voiced is that the NCC is asking questions and > enforcing rules that are more strict than what the policy demands - and > this is certainly relating to policy. Yes, in the case of the requirement of a network topolocy map, it looks like it always was part of the request form for the initial IPv6 Allocation, but never part of the policy. Just that noone complained yet. > [..] > > You asked about the requirement for a network diagram to be supplied when > > requesting an IPv6 allocation. There are two reasons for this. Firstly, the > > RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 > > networks is limited and we need network operators to show us how they intend > > to use IPv6 address space in their networks. > > I agree with the assessment that "more experience for the NCC is a good > thing". > > On the other hand, many startup IPv6 deployments are extremely trivial > ("one access server with 1000 DSL circuits, serving /48s to DSL end > users" would certainly qualify for the policy requirements). > > So I don't think it's appropriate to enforce this "you send us an > interesting picture, otherwise you won't get an IPv6 allocation" > approach. Make it optional. Full-ACK. The main reason i came up with the idea that i can save some time and not paint a pointless map was, that it's just not in the policy. So i didn't consider it a nescessary requirement. We almost have have such a trivial setup as you mention. We're still using an IPv6 overlay network, no joint IPv4+IPv6 backbone yet due to vendor limitations, i.e. many tunnels. It's subject to change at any time anyways, there's absolutely no way to tell how the final network will look like until all vendors support IPv6 in mainline firmware releases. So where is the point in doing so? What benefit has the RIPE NCC from a map which doesn't need to be a fancy diagram and even can be a handwritten drawing as Dominic suggest? And no, "overlay network" doesn't mean it's a test setup not qualifying for production IPv6 space either. The reason for requesting a production IPv6 Allocation is, that one wants to start to actually assign /48s to endusers and make sub-allocations to downstream organisations. I also consider the "have a plan for making at least 200 /48 assignments to other organisations within two years." requirement quite dim. But since it's in the policy and i initially supported a slow-start mechanism, i have no problems with that. It's not that hard to fulfill for most early adoptors anyways, not even for my LIR :) ("Tunnels, free Tunnels, Tunnels for all! Take two - get one for free!") Though... see below. > > Secondly, the current IPv6 > > policy does not allow stockpiling of IPv6 address space. One way of > > distinguishing a genuine request from one that is intended for stockpiling > > reasons is to request a diagram showing how the address space will be used. > > It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn > > diagram instead of sending one by e-mail. When we have more experience with > > IPv6 I expect we will make the diagram optional. > > This is "conservationism striking again", and this is BAD. > > The idea behind the current policy is "make IPv6 address blocks available > to anybody who is asking for them" (and can reasonably claim 200 future > IPv6 customers). For that, you don't *need* a fancy network, so why > do you have to demonstrate it at all? > > What are you worrying about? Address wastage is really not a problem > right now. Obstacles on the way to IPv6 deployments are a problem, and > we don't want the NCC to be an obstacle. ´ Full-ACK, again. But, even more generally speaking: Look at the current IPv4 policy discussion. It shows that more and more LIRs are very small LIRs, probably using only IP-space for themselves and very few customers. Even the initial allocation size is subject to be reduced again. What do those LIRs do if they want to start deloying IPv6? They probably can't show 200 potential /48 customers. And don't have the manpower or any interest in painting topology maps. They are cut off from IPv6 then and need to get a suballocation from another LIR? Why do they pay the full RIPE fee then? I guess the whole policy currently is a bit outdated. In my eyes it prevents IPv6 deployment. Not to a degree like the hardware/software support situation, but it adds obstacles for some organisations and they rather just don't care about IPv6, "too complicated". The main reason i supported the slow-start mechanism was, that there was no experience in first place, and for example not even the initial IPv6 Allocation size was settled. And as we know, it changed in the meantime. Currently there's still the discussion about weather to make reservations and fragment the 2001::/16 space or not, but most of the policy is quite final i think, so i'm not very positive about the need for RIPE to continue with that slow-start thing for much longer. On the other hand, just look who currently alrady got some IPv6 Allocation and how many of them are just unused. I only looked for de.* LIRs on my search for some IPv6 uplink who probably can offer IPv6 natively, but already was amazed about the results. For starters, i was quite happy that our main uplink got an IPv6 Allocation for almost a year now, just to notice that their Prefix is not in the BGP tables shortly afterwards, and there are no assignments yet. Asking our tech contacts there, the first one at least knew what IPv6 is, but then i got a "no, we don't have any IPv6 at all, not even via tunnel". Sales Department then even told me "IPv6? No, we don't even have plans for that at the moment, sorry." So, hm. Someone can tell me how they got the Allocation? Because they are a big IPv4 LIR and someone gave RIPE a high-gloss Network map which their Marketing people produce all the time? RIPE, do you really WANT to be lied to? (DISCLAIMER: I'm not accusing anyone of lying here, that's just a question as stylistic device :) ) Of course i can just comply with that and make up thousands of dial-customers who all want to have IPv6, i know that they do! And of course we have a BIIIIG IPv6 network in 2years, see my nice map? So my point is, one really should start thinking about a change. There is the idea of "One IPv6 Allocation for every LIR on request." on some mailinglists for quite a while. I'd support this now for the future (not nescessarily imemdiately). > Now come and flame me :-) Certainly not :) -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz at baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================
- Previous message (by thread): [address-policy-wg] Re: [ncc-services-wg] IPv6 applications (was: Request Forms: updated and available on LIR Portal)
- Next message (by thread): [ncc-services-wg] Proposal for easing keysigning at meetings
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]