About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01)

  • To: jordi.palet@localhost
  • From: "Wilfried Woeber, UniVie/ACOnet" Woeber@localhost
  • Date: Thu, 28 Sep 2006 14:20:04 +0000
  • Cc: "address-policy-wg@localhost" address-policy-wg@localhost
  • Organization: UniVie - ACOnet
  • Reply-to: Woeber@localhost

¡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.




 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community