Re: [**EXTERNAL**] Re: the race to the bottom problem

[JORDI PALET MARTINEZ <[e-mail]>]

I don't think that's true, at least not in broadband.

It is only true in mobile. I never understood why they don't want to use DHCPv6-PD, at least as an option if the device needs more than /64, for example a "mobile router".

Regards,
Jordi
@jordipalet
 
 

El 8/11/20 20:57, "ipv6 en nombre de Joel M. Halpern" <[e-mail] en nombre de [e-mail]> escribió:

    Jorid, from what has been said, some ISPs do not use DHCPv6.  that's 
    fair.  We actually told them they did not have to.
    So I do not think it is fair or appropriate to claim that to solve the 
    delegation problem they must use DHCPv6.

         What is not clear to me is why solving the delegation problem 
    requires extending the allocation boundary past /64.  The draft on the 
    v6ops agenda simply asserts that it is necessary.

    Yours,
    Joel

    On 11/8/2020 2:46 PM, JORDI PALET MARTINEZ wrote:
    > There are many ISPs offering IPv6. I never hear of any that doesn't use DHCPv6-PD to allocate /48, /56, some do /60, very few do /64 and we shall train them to understand that this is incorrect.
    > 
    > There is no technical neither cost reason (in terms of RIRs cost for getting a bigger IPv6 block), to allocate smaller prefixes for customers. The only reason they some time to /56 instead of /48 is "marketing" to differentiate business from residential customers. Nothing else.
    > 
    > Many ISPs do persistent prefixes.
    > 
    > Again, see RIPE-690 and https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf (look for the survey slides at the 2nd part).
    > 
    > Regards,
    > Jordi
    > @jordipalet
    >   
    >   
    > 
    > El 7/11/20 4:24, "ipv6 en nombre de Michael Richardson" <[e-mail] en nombre de [e-mail]> escribió:
    > 
    > 
    >      Mark Smith <[e-mail]> wrote:
    >          >> Why are the isps not giving more than one 64 ?
    >          >>
    >          >> Is it because the ietf made it hard and dhcp-pd is unworkable ,
    > 
    >          > There are multiple production residential deployments of DHCPv6-PD.
    > 
    >          > I worked on one that was deployed in 2010. I then used it for the next
    >          > 8 years, and only moved away to another provider (and employer) where
    >          > it is in beta.
    > 
    >      That's much cool.
    >      It's very useful to hear of such successes!
    > 
    >      A question: was it easy to assign static subnets to the customers?
    > 
    >      My ISP initially statically routed my /56 to me, and then when they turned on
    >      PD, they now send me three subnets. One statically, and apparently two by
    >      DHCPv6-PD which they say they can't turn off/fix.  Very weird.
    >      Well.... they aren't present today.
    > 
    >          > Telstra here in Australia have also been deploying it for a number of
    >          > years in production.
    > 
    >          > Sky in the UK have deployed PD to 5 million subscribers.
    > 
    >          > PD is very workable, and a number of people have made it work.
    > 
    >      Maybe RIPE would do a survey to understand what has these things so
    >      successful so that others can repeat it!
    > 
    >      --
    >      Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
    >                 Sandelman Software Works Inc, Ottawa and Worldwide
    >      --------------------------------------------------------------------
    >      IETF IPv6 working group mailing list
    >      [e-mail]
    >      Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >      --------------------------------------------------------------------
    > 
    > 
    > 
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > The IPv6 Company
    > 
    > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    > 
    > 
    > 
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > [e-mail]
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
    > 

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [e-mail]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------



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

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.