[ipv6-wg] IPv6 prefix delegation BCOP document - draft v.2 for review.

Hi Mikael,

Responses below, in-line.

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6-wg <ipv6-wg-bounces at ripe.net> en nombre de Mikael Abrahamsson <swmike at swm.pp.se>
Organización: People's Front Against WWW
Responder a: <swmike at swm.pp.se>
Fecha: jueves, 11 de mayo de 2017, 6:57
Para: Jan Zorz - Go6 <jan at go6.si>
CC: "ipv6-wg at ripe.net" <ipv6-wg at ripe.net>
Asunto: Re: [ipv6-wg] IPv6 prefix delegation BCOP document - draft v.2 for review.

    On Thu, 11 May 2017, Jan Zorz - Go6 wrote:
    
    > Dear RIPE IPv6 WG,
    >
    > As promised at BCOP TF meeting on Monday, the co-authors present at the
    > RIPE74 meeting gathered on Tuesday afternoon and did some editorial
    > work, addressing majority of the comments and suggestions we got from
    > the community based on first version of the draft.
    >
    > Draft version 2 is now available for reading at
    > https://sinog.si/docs/draft-IPv6pd-BCOP-v2.pdf
    >
    > We'll have a short "lightning talk" in Thursday IPv6 WG session, please
    > go and read the document (those that have enough time and energy), so we
    > get more feedback and input for further improvements (if needed).
    >
    > See you all in couple of hours!
    
    Reading this and writing as I read it through:
    
    "IPv6 is not the same as IPv4. In IPv6 you assign a number of “n” /64 
    prefixes to each end-customer site, so they are able to have as many 
    subnets as they wish. "
    
    I think this immediately leads the reader wrong. This should be about 
    sites getting a larger prefix, and THEN out of this, they use /64s. So 
    while above is technically true, from a viewpoint of making the reader 
    understand better the hierarchy, I propose above sentence to be:
    
    "IPv6 is not the same as IPv4. In IPv6 you assign a large prefix to each 
    end-customer site, so they are able to have as many subnets (/64s) as they 
    need."

[Jordi] Fully agree, thanks!
    
    The /64 for cellular phones should not be in the executive summary.

[Jordi] Not sure about this one, it is a short sentence and we want to make sure to capture all the they key things in the first page, as know that unfortunately, most people will not read the rest …
    
    4. In IPv4, it's not only perception of scarcity, there *is* scarcity.
    
    4. I think I did the calculation and if you have 8B /48s, you still have 
    only consumed around 1/10000th of the IPv6 space. I would use this instead 
    of "480 years". 2^33 is ~8B. 48-33 is 15. So /48 for 8B people uses a /15. 
    Take that down to one of the /3s we have, and it's a /12. 2^12 is 4096. So 
    One /48 per person on earth uses 1/4000th of the currently used /3. So 
    even with inefficient addressing this is not a problem.

[Jordi] We will think about this
    
    4.1.2. Windows PCs CAN do DHCPv6-PD, if they have Internet connection 
    sharing turned on. This worked already in Windows Vista, 10 years ago. 
    However, I understand that this is not the point you're trying to make.

[Jordi] We can say something anyway to make the text more accurate.
    
    4.2.3. Can't we use the "STRONGLY DISCOURAGED" to use less than /56 ?

[Jordi] I think we should do that.
    
    5.x I have heard of online gamers being ddos:ed so that someone else gains 
    competitive advantage. It might be good to mention this drawback of 
    persistent prefixes.

[Jordi] However, it seems to me that if this happens during a “gamming” session, it is the same for non-persistent prefixes, right? I don’t think you change your prefix while you’re playing, or I’m missing your point?

    Good document, I'll refer to it a lot because I keep having discussions 
    with people in different forums about customer prefix size. Thanks!
    
    -- 
    Mikael Abrahamsson    email: swmike at swm.pp.se



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.