Re: draft-bourbaki-6man-classless-ipv6-00

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

I just don’t see the need for that.

3G/LTE operators providing broadband services to CPEs, have ways (dedicated provisioning or DHCPv6-PD), to receive a /48. I’ve used that.

So why not using the same for a cellular phone that may require instead of /64 a /56?

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6 <[e-mail]> en nombre de "Manfredi, Albert E" <[e-mail]>
Responder a: <[e-mail]>
Fecha: miércoles, 14 de junio de 2017, 19:36
Para: "[e-mail]" <[e-mail]>
CC: 6man WG <[e-mail]>
Asunto: RE: draft-bourbaki-6man-classless-ipv6-00

    -----Original Message-----
    From: ipv6 [mailto:[e-mail]] On Behalf Of [e-mail]
    
    > What _problem_ does changing the 64 bit boundary solve for _you_?
    
    A category of problems, such as creating hotspots with smartphones that have been allocated a single /64. A real-world situation, in which there's no conceivable reason to have to go hat in hand to service provider, asking for more /64s. And in fact, from an operator's point of view, would not a user asking for more /64s be a bigger pain than a user subnetting his own /64, with no consequence at all to the operator?
    
    I do acknowledge the "race to the bottom" potential. Then again, being overly stingy with /64s amounts to the same thing. Operators can make things bad, no matter what solution you adopt. Allowing the boundary to move gives users and app designers more flexibility and independence. For some players, that's a good thing.
    
    Plus, I oppose the idea of artificially declaring that a fixed IID length is associated with each link type. This is a legacy notion, driven by rationales no longer valid. It's an unnecessary constraint. Or if stated, add a historical note as to why you have stated it.
    
    If part of what makes IPv6 wonderful is SLAAC, then I don't think it's wise to cripple non-/64 solutions by artificially mandating that SLAAC be only possible with /64s. The smartphone hotspot example is one in which a non-/64 SLAAC would work great. And there's simply no reason to state that SLAAC can only work with /64s. It's not true!
    
    Using RECOMMENDED for /64s? IMO, that RECOMMENDED would only apply to operators. It should be RECOMMENDED that ISPs not hand out /128s, or other overly long prefixes. I would almost rather use the word "typical." The "typical" prefix at the "operator to user boundary" may be /64 (or /56 perhaps). But app designers and users? No, there should be no such recommendations.
    
    Bert
    
    
    --------------------------------------------------------------------
    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.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.