[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sig-ipv6]Let's restart discussion about RIPE-261
Dear all,
This is Yong Wan Ju, one of co-chairs on Address Policy SIG.
As you may know, I remember we discussed "IPv6-sparse allocation"
(Refer to http://www.ripe.net/ripe/docs/ipv6-sparse.html) in previous
APNIC OPM but we didn't come to any conclusion.
This subject was raised in RIPE-45 meeting recently and the discussion
result can be seen in
http://www.ripe.net/ripe/meetings/ripe-45/webcast-archive.html
(see lir-2)
And Gert Doering's initiative comments of ipv6-wg@ripe.net are as below;
> I have the following comments:
> - The /23 allocations ICANN -> RIRs are bad, because they lead to
> address space fragmentation, and the blocks are too small to do useful
> allocation towards the LIRs. Something NEEDS to be changed here.
> - Nevertheless, I do NOT like the idea of a "common address pool". People
> want to be able to see the "region" that a prefix is coming from by
> looking at the address. This is working fine now in v4 (except for
> the swamp and part of ERX) and in the so-far IPv6 allocations (except
> that due to the /23s it's getting messy), but would be broken by
> the CAP.
> - As a technical reason: people want to be able to filter IPv6
> prefixes by region, like "I only have one uplink that provides me
> with US connectivity, so there's no need to carry any US prefixes
> in my routing table, I just point a summary down that line".
> This is not yet done, but I am convinced that we shouldn't break
> routing hierarchy without good need.
> - If people *really* go into "multiple /48s per site" multihoming,
> source address selection works by doing a longest-match check, and
> this will work better if same-region addresses have something like
> a common prefix, instead of "everythins smeared everywhere".
> So my personal recommendation would be:
> - change the /23 allocation boundary ICANN -> RIR to something more
> useful, like a /12 or so (a /12 means "512 of them are available,
> so we're not yet burning bridges - but a /8 would work as well. A
> /16 is already somewhat tight).
> - every RIR still gets its own allocation from where RIR->LIR allocations
> are taken
> - inside that RIR allocation, use the binary chop algorithm described
> in RIPE-261 for the RIR->LIR distribution.
Maybe I think above comment & idea will be helpful for us to start the discussion
As we know, though this issue is the matter between RIRs and ICANN,
because this issue will affect all of us(NIRs, LIRs, ISP etc) deeply,
we need further discussion within these groups to get any consensus.
I expect good ideas and comments in the aspect of policy and technique
on this issue.
Personally, I will also circulate my opinion after deep consideration.
Sincerely yours,
Yong Wan Ju
=============================================================
IP Address Management Team in Korea Network Information Center
Manager Yong Wan Ju / Tel : +82-2-2186-4536 Mail : ywju@nic.or.kr
=============================================================
