Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purpose
>From the discussions so far, it seems that a couple of suggestions made
to encode into smaller prefix will not allow 6rd deployment without
losing its benefit.
Just wondering - could we take a different approach, and focus on making
sure that allocated blocks will actually be returned?
I know returning space is generally hard but one idea is to define a
specific block for this purpose and set a time limit of use.
Any thoughts about this approach/method?
Izumi/JPNIC
(Tomohiro -INSTALLER- Fujisaki/) wrote:
> Hi Sanjaya,
>
> Thank you so much for your information!
>
> If we assume these address blocks are used as customer assignment
> blocks, many organizations have to create multiple 6rd domains to
> encode less than 32 bits of address.
>
> I personally think having multiple 6rd domains makes operations
> complex, and technically, it will disable direct communication between
> 6rd users in different domains.
>
> Yours Sincerely,
> --
> Tomohiro Fujisaki
>
>
> From: Sanjaya <sanjaya at apnic dot net>
> Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
> Date: Thu, 19 Aug 2010 15:59:40 +1000
>
> | Dear Fujisaki-san and all,
> |
> | APNIC has 6,811 distinct entities in IPv4 delegated stats, of which:
> |
> | - 4,947 have only one entry (no subsequent allocation)
> | - 1,864 have more than one entry
> |
> | Of the 1,864 multiple entry cases:
> |
> | - 547 have resources under only one /8
> | - 1,317 have more than one parent /8
> |
> | Of the 1,317 multiple parent /8 entities:
> |
> | - 709 have 2 different parent /8
> | - 255 have 3 different parent /8
> | - 148 have 4 different parent /8
> | - 73 have 5 different parent /8
> | - 51 have 6 different parent /8
> | - 30 have 7 different parent /8
> | - 11 have 8 different parent /8
> | - 8 have 9 different parent /8
> | - 12 have 10 different parent /8
> | - 7 have 11 different parent /8
> | - 2 have 12 different parent /8
> | - 1 have 13 different parent /8
> | - 2 have 14 different parent /8
> | - 1 have 15 different parent /8
> | - 1 have 16 different parent /8
> | - 1 have 17 different parent /8
> | - 1 have 19 different parent /8
> | - 1 have 21 different parent /8
> | - 1 have 22 different parent /8
> | - 1 have 33 different parent /8
> | - 1 have 37 different parent /8
> |
> | Hope this will help this policy proposal's discussion. Please let me
> | know if you need more information.
> |
> | Regards,
> | ________________________________________________________________________
> | Sanjaya email: sanjaya at apnic dot net
> | Services Director, APNIC sip: sanjaya at voip dot apnic dot net
> | http://www.apnic.net phone: +61 7 3858 3100
> | ________________________________________________________________________
> | * Sent by email to save paper. Print only if necessary.
> |
> | On 17/08/2010 11:54 AM, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) wrote:
> | >
> | > One request to APNIC Secretariat, could you show the allocation
> | > statistics that how many IPv4 address holders obtain addinional
> | > address blocks, and if possible, how may multiple IPv4 address block
> | > holders above got same IPv4 address prefixes? (e.g. initial address is
> | > 1.0.0.0/22 and additonal address is also under 1.0.0.0/8)
> | >
> | >
> | > Yours Sincerely,
> | > --
> | > Tomohiro Fujisaki
> | > * sig-policy: APNIC SIG on resource management policy *
> | > _______________________________________________
> | > sig-policy mailing list
> | > sig-policy at lists dot apnic dot net
> | > http://mailman.apnic.net/mailman/listinfo/sig-policy
> | * sig-policy: APNIC SIG on resource management policy *
> | _______________________________________________
> | sig-policy mailing list
> | sig-policy at lists dot apnic dot net
> | http://mailman.apnic.net/mailman/listinfo/sig-policy
> |
> |
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy