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

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

RIPE-690 was for all kind of operators and it was clear on that:

 
4.2.4. Considerations for Cellular Operators
There is a clear exception to the rule described above when assigning prefixes in a cellular network. In this case, a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers, i.e. in the case of broadband by means of cellular access, it will still be necessary to choose a /48 or /56 in accordance with the aforementioned considerations.

 

We understood at that time that the default deployment model was /64 per PDP for a smartphone, but note that it was clear that a cellular router (or a device acting as a cellular router, it can still be a smartphone), should get /48 or /56.

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/11/20 7:35, "ipv6 en nombre de Gyan Mishra" <[e-mail] en nombre de [e-mail]> escribió:

 

 

 

On Fri, Nov 6, 2020 at 3:09 PM Brian E Carpenter <[e-mail]> wrote:

On 07-Nov-20 03:30, Mudric, Dusan wrote:
> Would it help if the problem statemen clarifies that:
> 
> - There is no race to the bottom. We are not trying to solve ISP problem by allowing longer than 64bit prefixes,

Unfortunately, once you push code allowing >64 subnet prefixes for SLAAC into the wild, you do automatically give ISPs a path to to allocating longer prefixes to customers, and all history tells us that some of them will follow that path.

Once that code is out there, the race to the bottom is enabled.

Even draft-bourbaki-6man-classless-ipv6 doesn't recommend changing the /64 default for SLAAC. (If it did, my name would not be on that draft.

 

   Gyan> I am not sure I understand the comment of pushing >64 subnet prefixes out into the wild as if by doing so we are breaking IPv6.  Also can you enlighten me on the history of another instance where a similar apples for apples comparison where something similar was done by ISPs?

 

So once the code is there it is only in theory that the race to the bottom will be used by providers once enabled.  We have a BCOP RIPE-690 which would still apply to broadband carriers recommendation of /56 or larger and with 3GPP mobile handset a /64.

 

If we have expect that operators to not follow BCOP why have a BCOP.     

 

Could we not have an IPv6 allocation guideline for mobile operators to support a minimum allocation of /64 similar to RFC 3177 or RFC 6177.  What good is an IETF protocol specification if it is not followed by operators.  

 

Bourbaki draft states that free BSD ships with SLAAC of any length.  That is a good point duly noted by the draft.

 

So in theory if router manufacturers decided they could ship code now that supports any prefix length and Free BSD and their maybe other OSs out there that may work.

 

Bourbaki draft is actually referenced in both of our drafts and Bourbaki draft clearly recommends any IID length.  

 

Introduction:

 

   Over the history of IPv6, various classful address models have been
   proposed, none of which has withstood the test of time.  The last
   remnant of IPv6 classful addressing is a rigid network interface
   identifier boundary at /64.  This document removes the fixed position
   of that boundary for interface addressing.
 

5.  Recommendations
 
Note that OpenBSD ships with SLAAC for lengths longer than /64.
 
   Nonetheless, there is no reason in theory why an IPv6 node should not
   operate with different interface identifier lengths on different
   physical interfaces.  Thus, a correct implementation of SLAAC must in
   fact allow for any prefix length, with the value being a parameter
   per interface.  For instance, the Interface Identifier length in the
   recommended (see [RFC8064]) algorithm for selecting stable interface
   identifiers [RFC7217] is a parameter, rather than a hard-coded value.
 
 
 



   Brian

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

-- 

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

 

-------------------------------------------------------------------- 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.