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/[email protected]/
[address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
- Previous message (by thread): [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
- Next message (by thread): Keeping in reserve, was: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
Woeber at CC.UniVie.ac.at
Thu Sep 28 16:20:04 CEST 2006
¡Hola Jordi! JORDI PALET MARTINEZ wrote: > Hi Wilfried, > > Thanks again for your inputs. > > I fully understand your point, but you need to balance it with being > temporary. We are not allocating this space for ever. It is a noble mindset to assume just a transient issue, but in reality nothing tends to last longer than a quick hack :-) > Also it is not clear > to me that a few hundreds of extras /32 will make a difference in terms of > lifetime, No, I agree. But whay are we having the discussion on /48, /56, /?? then and the impact of different values of HD_ratio on the lifetime of IPv6? It won't fly to propose reducing /48 to say a /56 for the "masses" of *PA* space users and in parallel give away a /32 for a *PI* Site at the same time. > specially having in a few years alternative technical solutions > (again we are doing a temporary thing). Right now I am not holding my breath. Not because I don't belive in a solution being theoretically possible, but rather looking at the fact that nobody cares, really. Still readin the CIDR Report, anyone ;-) > On the other way around, what operators do to filter or not, is not our > problem (as RIPE community), Exactly, but my conclusion is different :-) > and we can't do nothing against that, so, do > you really think it make sense to arrange a policy that may work only in > some networks ? Let's be realistic ! I can't see why "this" address space is sooo different. We always have to deal with ISPs that don't track real life developments. And there may be ISPs which - for whaterever "good" reason - may want to block those address ranges. Playing silly games with the *size* won't make a big difference. What *will* make a difference is full integration into the regular set of proactive provisions trying to minimize those *accidental* problems. Like announcing a test prefix from the range, alerting people that assignemnts from a different block of addresses will commence soon, and the like. This is business as usal already in our Service Region. The rest is an issue for a trouble ticket and for obtaining support from your upstream(s) you are paying money to, in particular for providing *end-to-end* connectivity :-) > One possibility will be to allocate /48 but keep reserved the remaining /32. > If the applicant justify that the /48 is getting filtered, then he may opt > to justify to obtain the /32. Is this a possible compromise solution ? Come on, what's in a "justify" to get a free upgrade to "business class"? Your ISP(s) would be more than happy to "prove" that. Their product development folks might even offer that as a commercial service :-) I'm convinced that the NCC will be doing "The Right Thing[TM]" to make sure there's room to grow, and maybe even to upgrade such an End-Site PI block to a regular LIR PA block. Actually that might be conflicting goals, and may involve re-numbering :-( > Regards, > Jordi Saludos, Wilfried.
- Previous message (by thread): [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
- Next message (by thread): Keeping in reserve, was: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]