Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

[Ca By <[e-mail]>]

On Sun, Nov 8, 2020 at 3:58 PM Mark Andrews <[e-mail]> wrote:

>
>
> > On 5 Nov 2020, at 02:54, Gyan Mishra <[e-mail]> wrote:
> > On Wed, Nov 4, 2020 at 3:51 AM Lorenzo Colitti <[e-mail]>
> wrote:
> > On Tue, Nov 3, 2020 at 4:27 PM Gyan Mishra <[e-mail]>
> wrote:
> > It's hard to see why this draft is needed anyway. All that is needed
> > is to remove the "64 bit" statement from the addressing architecture,
> > which the WG has consistently failed to reach consensus about.
> >
> >     Gyan>  This topic has come up many times over the years in heated
> debate and this is another instance of that.  Agreed.  However, what makes
> this instance different is that we have a major problem to be solved with
> 4G  &  now as 5G is rolled out, segmentation is of utmost importance.  I
> think in the past we have not had a major problem to be solved and so this
> change being proposed did not gain traction,  but now as 5G becomes the
> "norm" as it will compete directly with broadband that customers will start
> using 5G in SOHO as well as other environments.   This is a major issue
> that has come up with the ramp up for 5G IPv6 only deployments.
> >
> > There is already a solution to this: use DHCPv6 PD on 5G networks. It's
> been supported since 3GPP release 10 several years ago.
> >
> >    Agreed.  Fixed 5G broadband agreed would use the current wired
> broadband DHCPv6 PD and would follow the BSOP RIPE-690 and I think would
> use the recommended shorter prefix like a /56.  As fixed 5G would take
> advantage of the value added at a premium network slicing capabilities for
> the front haul and backhaul I can see Broadband 5G getting even a /48.  The
> issue mentioned in the draft is related to 4G as well as 5G “mobile
> handsets” and getting a /64 allocation which has been the standard which
> cannot be segmented by the Subscriber customer end.
>
> This is a failure of imagination, not a technical impossibility. There is
> nothing preventing cell phones from being a router that hands out /64s to
> other routers than people with lack of imagination.  Cell phones have more
> than enough capacity to do this.  It’s not like the cell phone are
> incapable of handling /56 or /48 responses these days.  10 years ago there
> where some that fell over but given the attrition rate of cell phones and
> that there are newer images that do correctly handle shorter than /64
> should have reconciled this to history.
>
> Even in Africa the cost of a /56 per customer per year is well under
> 0.01USD as is the initial allocation fee.
>
>                 Allocation fee Membership
> Small   /32     $2,500         $2,500
> Large   >/32    $20,000        $20,000
>
> $2500/(2^(56-32))
> .00014
> $20000/(2^(56-31))
> .00059
> $20000/(2^(56-28))
> .00007
>
> I think most of this comes down to can I save $18000 per year over a
> customer base of > 16 million.  Penny pinching at its extreme.



Yet another person missing the point and harkening back to the idea that
anyone is trying to conserve  ipv6 addresses.

Please stop.


>
> > I don’t see the mobile handset /64 prefix being going any shorter even
> for 5G.  For 5G the business driver for larger allocation is for the value
> added network slicing capabilities and the is relevant only for fixed
> broadband 5G which will replace wired broadband.  Mobile handset 5G will
> not get network slicing capabilities as it would use the front hall handset
> to tower backhaul tower to core Normal RAN Radio VPN.  Compared to Fixed 5G
> broadband which would have capabilities of being provisioned for high
> priority network slice Enhanced VPN with resource isolation and dedicated
> resource characteristics.
>
> > --
> >
> >
> > 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
> > --------------------------------------------------------------------
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>