[Apwg-ipv6-papi] The Picture / Re: first draft?
Daniel Stolpe
stolpe at resilans.se
Tue Jul 30 15:54:56 CEST 2013
Same here. I guess we will see some more action again in a few weeks.
On Wed, 24 Jul 2013, Elvis Daniel Velea wrote:
> Hi Emilio, everyone,
>
> I haven't had any time in the past few day as I was attending my
> brother's wedding. I'll have a look at all the e-mails and the
> documents from Emilio next week.
>
> cheers,
> elvis
>
> Excuse the briefness of this mail, it was sent from a mobile device.
>
> On 24 jul. 2013, at 08:57, Emilio Madaio <emadaio at ripe.net> wrote:
>
>> Hi Elvis,
>> here in attachment the picture as requested in your comments on the
>> google doc.
>>
>> It could be retrieve also from the IPv6_old_new document I sent to our
>> mailing list some days ago.
>>
>>
>> Cheers
>> Emilio
>>
>>
>>
>>
>> On 7/18/13 10:13 AM, Emilio Madaio wrote:
>>> Hi all,
>>> I made some small comments in the document online.
>>>
>>> I also wanted to share something that can be helpful in the long term.
>>>
>>> I run the Cosmetic Surgery Project (CSP) to improve the readability of
>>> some policy documents and one of the deliverable was to redraft the
>>> merger of the 3 IPv6 documents:
>>>
>>> -ripe-589 "IPv6 Address Allocation and Assignment Policy"
>>> -ripe-451 "IPv6 Address Space Policy for Internet Exchange Points"
>>> -ripe-233 "IPv6 Addresses for Internet Root Servers in the RIPE Region"
>>>
>>> So, in all the cases where a rewording is due (i.e.: the new chart of
>>> RIR/LIRs, section 4.1 etc), I kindly ask you to have a look at the CSP
>>> draft in attachment.
>>>
>>> Looking forward to hearing from you
>>> Regards
>>> Emilio
>>>
>>>
>>>
>>>
>>>
>>> On 7/17/13 5:05 PM, Daniel Stolpe wrote:
>>>>
>>>> On Mon, 15 Jul 2013, Elvis Velea wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 7/15/13 8:38 PM, Gert Doering wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, Jul 15, 2013 at 05:32:24PM +0300, Elvis Daniel Velea wrote:
>>>>>>> Hope you had a great vacation Daniel.
>>>>>>>
>>>>>>> can't wait to see your input/comments.
>>>>>>>
>>>>>>> Basically, I'm still wondering if it's going to be ok (accepted by the
>>>>>>> community) to have a minimum allocation of a /32 either made by the
>>>>>>> RIPE NCC or by the LIR.
>>>>>>
>>>>>> Allocations are always made by the RIPE NCC :-) - I assume this is
>>>>>> sub-allocations?
>>>>>
>>>>> in the document, there are only allocations and assignments. Allocations can
>>>>> be made by the RIPE NCC to the LIR (not portable) or to the customer of the
>>>>> LIR (portable). (Sub-)Allocations can also be made by a customer (to it's
>>>>> downstream customer).
>>>>
>>>> I guess you would have to call it a sub-allocation if it is address space
>>>> that comes from a (bigger) allocation.
>>>>
>>>>>>> I would see a few problems:
>>>>>>> - if the LIR makes minimum /32 allocations.. they will run out of
>>>>>>> space in their allocations after 8 customers and will need an
>>>>>>> additional allocation. Should the /32 allocated to a customer (the
>>>>>>> sub-allocation) be considered fully used once it's made?
>>>>>>
>>>>>> When introducing sub-allocations to IPv4, I think I said "sub-allocations
>>>>>> are not considered used". So if a LIR is careless with sub-allocs, and
>>>>>> runs out of space, they need to ensure that the sub-allocs are properly
>>>>>> filled by the receipients.
>>>>>
>>>>> True, in IPv4 sub-allocations are not considered in use. However, in the
>>>>> model in my head, and as I understood from you, the big allocations would
>>>>> have been of a minimum /32.
>>>>> Either the allocations made by the RIPE NCC (portable) or the ones made by
>>>>> the LIR (sub-allocations, or non-portable allocations) would have been of a
>>>>> minimum /32.
>>>>>
>>>>> I might have misunderstood and I actually think that we should allow any
>>>>> allocations between a /48 and a /32 (or even larger). However, in this case,
>>>>> we may risk seeing ultra-conservative LIRs which would not give enough space
>>>>> to their customers and therefore force the customers to use /64s or smaller
>>>>> prefixes.
>>>>
>>>> There might be risks both ways. What if you make a big sub-allocation for
>>>> a customer who is then not using very much of it, and then you need more
>>>> space for yourself? Do you have to take back space from that customer?
>>>>
>>>>>> If this is properly documented, I think LIRs will not carelessly hand
>>>>>> out large swaths of space, but really consider what they are doing - some
>>>>>> might be fine with /32s (because they know that they are serving a
>>>>>> specific
>>>>>> constituency, and won't ever have more than 3 direkt customers...), others
>>>>>> might prefer to go for /40s or so.
>>>>>
>>>>> ok, so we will not make the smaller allocation size a /32.
>>>>
>>>> Not carelessly, no. But plans might change. See above.
>>>>
>>>>>>> -if the NCC will make minimum /32 portable allocations.. what will be
>>>>>>> the incentive for someone to become an LIR? should the cost for the
>>>>>>> portable allocations be different then the 50? paid for the /48
>>>>>>> (portable) assignment?
>>>>>>
>>>>>> That will be an interesting can of worms, as APWG cannot decide on the
>>>>>> cost of things...
>>>>>>
>>>>>> My initial idea was to make the "big allocation" slightly more expensive
>>>>>> than the "small allocation" (like, 200 EUR vs. 50 EUR), to avoid giving
>>>>>> the wrong signal - if we make "big allocations" too expensive, we signal
>>>>>> "hey, use a /48, and give all your dial-in customers just a /128 and
>>>>>> have them make NAT66!" - which we should not do.
>>>>>>
>>>>>> But in the end, this is something for the RIPE AGM to sort out.
>>>>>
>>>>> correct
>>>>
>>>> Yes. This could be interesting. :-)
>>>>
>>>>>> An incentive to become a RIPE member: "direct dealings with the RIPE NCC"
>>>>>> (some really want to be "that independent!"), plus "voting rights at the
>>>>>> AGM", and possibly other services that are members-only, like dnsmon,
>>>>>> Atlas, etc.
>>>>>
>>>>> ok :)
>>>>
>>>> Ha ha. You do now that some people are ready to go a long way in order to
>>>> *avoid* direct dealings with the RIPE NCC? :-)
>>>>
>>>> But that is of cource not really our business right now.
>>>>
>>>> I have made a couple of comments. More will probably come later.
>>>>
>>>> Cheers,
>>>>
>>>> Daniel
>>>>
>>>> _________________________________________________________________________________
>>>> Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se
>>>> Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/
>>>> Box 13 054 556741-1193
>>>> 103 02 Stockholm
>>>>
>>>>
>>>> _______________________________________________
>>>> Apwg-ipv6-papi mailing list
>>>> Apwg-ipv6-papi at ripe.net
>>>> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Apwg-ipv6-papi mailing list
>>>> Apwg-ipv6-papi at ripe.net
>>>> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>> <PIC-NewIPv6Policy.docx>
>
> _______________________________________________
> Apwg-ipv6-papi mailing list
> Apwg-ipv6-papi at ripe.net
> https://www.ripe.net/mailman/listinfo/apwg-ipv6-papi
>
>
mvh
Daniel Stolpe
_________________________________________________________________________________
Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se
Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/
Box 13 054 556741-1193
103 02 Stockholm
More information about the Apwg-ipv6-papi
mailing list