IPv6 PI allocation

[Ruri Hiromi]

I still wonder what is the conclusion of this PI issues.
There are a lot of problem(_might_be) raised in this thread, but no  
technical opinions to solve them, I suppose. Or is there no need for  
consideration on things what PI addresses will be caused?

> We just recently become a LIR to get our own IPv4 address space  
> that we
> control. PI space wasn´t an option as far as I know. I think we  
> gain more
> from being LIR than if we just requested address space. And for  
> those that
> want PI, become a LIR. It might cost more but you gain more in the  
> long
> run.

"Becoming a LIR and get a space" means got a PA, right?
I think companies who want to have their own address space to  
advertise it to the outside their network, they have better to  
consider to become a LIR in the beginning like above company.

Anyway, here is my questions in mind after reading the first mail for  
PI allocation.

1. Is there also a possibility of routing table explosion with IPv6  
due to PI? And do we have to solve the problem with a technical aspect?

2. The word ”routing registry" is dead? Is there no rule for 2 or  
more prefixes from one AS? Or is there a demand for a good solution  
for transit providers, in stead of "one prefix from one AS"?

3. Do we need other sophisticated auto aggregation technology for PI  
in routing protocols?

4. Do we have to be against the size of /48 as PI?

Regards,

On 2007/05/20, at 8:00, Roger Jørgensen wrote:

> On lør, mai 19, 2007 23:41, Gert Doering wrote:
>> On Sat, May 19, 2007 at 03:56:38PM +0200, Roger Jorgensen wrote:
>>> in short, the only real option we have is IPv6.
>>
>> Do you have already started to plan this, and if yes, are you  
>> permitted
>> to talk about it?
>
> I got the attention from everyone at work after I presented the  
> numbers
> for when we´re out of IPv4 addresses and also told them the obvious
> solution, IPv6. All feedback, including CEO and other managers was
> positive so we´ve got a "go ahead" order to work more with IPv6.  
> Hope to
> have some real rought plans ready for presentation internaly within  
> a few
> months just to kick of some more official projects for moving along  
> with
> IPv6. It´s obvious for everyone as far as I know that we have to  
> prepare
> for IPv6, and also that we can gain alot from moving to IPv6.
>
>
>> I'm mainly curious about the addresses you plan to use (ULA-local,
>> ULA-central [which don't exist yet], RIR /32s, PI, ...) - and how  
>> well
>> your corporate application vendors handle it.
>
> That´s the real big problem. I´ve had several discussion with one  
> of the
> people that build the current network at work and we agree on one  
> thing,
> we need to learn from the mistakes done and make the next  
> generation of
> the network better. How is still an   unanswered question.
>
> But for the  structure we´ve so far considered two models
> a) We can go for ULA local/central combined with RIR space
> b) or only RIR space
>
> We just recently become a LIR to get our own IPv4 address space  
> that we
> control. PI space wasn´t an option as far as I know. I think we  
> gain more
> from being LIR than if we just requested address space. And for  
> those that
> want PI, become a LIR. It might cost more but you gain more in the  
> long
> run.
>
> Anyway, the options,  a) save us some troubles but ULA-central part  
> worry
> me. We really need _global_ unique netblocks for all our usage. We  
> just
> don´t want to get into the troubles with have today with collision  
> and NAT
> both ways to get things working. Without ULA-central we will  
> atleast have
> a need for one single authority handing out all ULA addresses for  
> all the
> organization we interconnect with. Not sure that´s possible...
>
> Options b) probably wont work either, we can easily satisfy the  
> requirment
> for a /32 after todays and any changes I´ve seen suggested so far.  
> Optimal
> we would love to have atleast two /32, that mean a /31 or bigger  
> but that
> required more documentation, not sure it´s worth the time really.   
> A /32
> would work just fine if we go for option a) but that has it´s own  
> problems
> as mention...
>
>
> About the vendor part... don´t know much about the network since I 
> ´m on
> the system group and work with servers. But most of the network  
> equipment
> I know about are bought within the last 5 years so think most of it
> support IPv6, how well is another question.
> On the system side we mostly run Linux, *BSD and other flavours of  
> *NIXes,
> even a few odd windows boxes and they all support IPv6 more or  
> less. Same
> for the application/services we have, we just haven´t actived it  
> anywhere.
>
> Anyway, the problem is not on the network or the system side, its  
> on the
> end-user side. Most of the application they use and need are  
> written for
> some very specific tasks and I really doubt alot, if any support  
> IPv6 at
> all on that side...
>
>
>
> -- 
>
> ------------------------------
> Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
> roger at jorgensen.no           | - IPv6 is The Key!
> -------------------------------------------------------
>
>

-------------------------------
Ruri Hiromi
hiromi at inetcore.com