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

[Gyan Mishra <[e-mail]>]

With 5G network slicing will become a formidable part of the paradigm shift
from shared resources to network resource isolation at the radio and RAN
layers.  The use case for being able to provide critical segmentation for
network slices makes it an industry imperative to be able support variable
IID lengths with slaac as all 5G deployments worldwide will be IPv6 only
from the start.

On Tue, Nov 3, 2020 at 2:20 AM Gyan Mishra <[e-mail]> wrote:

>
> Brian
>
> Responses in-line
>
> Thanks
>
> Gyan
>
> On Mon, Nov 2, 2020 at 4:41 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> Hi authors,
>>
>> > 8.  Greater than 64 bit prefix usage by ISPs is strictly prohibited
>> >
>> >    The RA flag S bit setting proposed by this draft for greater or less
>> >    then /64 bit prefix feature is strictly for enterprises and broadband
>> >    subscriber customer use only.
>>
>> How do you propose to enforce this, to prevent a race to the bottom
>> between ISPs? Do you have a funding source for the new Protocol Police?
>>
>
>    Gyan> Understood that there is no way we can police.  Working as a Tier
> 1 ISP with Verizon, I can say that from a cost benefit analysis trade off
> that it would be cost prohibitive to manage vlsm to customers.
>
>>
>> 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.  The
> problem with increasing the size of the handset allocation from /64 is
> problematic as well just due to the massive mobile subscriber base as I
> believe the last count of mobile handsets worldwide is 15 Billion.  The
> segmentation as well for 4G & 5G use cases with IOT as well would be
> beneficial.  Also as 5G swallows up the broadband subscriber base this
> problem gets even worse with not having segmentation capability.
>
>>
>> >    o  1: Variable length interface identifier is enabled (ignored by
>> >       hosts not supporting)
>>
>> How does this work if the router expects hosts to use shorter IIDs but
>> hosts in fact use standard 64 bit IIDs? As far as I can see, SLAAC,
>> DAD and default address selection will only work correctly if all
>> nodes on a given link agree about the prefix and IID lengths. For
>> all existing devices, the baked-in code assumes that both are 64.
>>
>>     Gyan> Valid point. Any subnet would require all hosts to support the
> same vlsm mask just a we do today with IPv4.  The only way to get around
> that which is common is if you have multiple IPv6 addresses on a LAN subnet
> on a router and RA PIO sends all the prefixes down to the host and then the
> host via Default address selection picks the address to use.  The goal is
> to allow slaac to not have a fixed iid dependency as defined in RFC 4291
> from an addressing standpoint have parity with static and stateful so that
> you could have a greater than /64 prefix length with a mix of hosts static,
> dhcp & slaac all on the same subnet.  Existing IPv6 deployments have
> shackled static & dhcpv6 unfortunately due to the 64 bit iid boundary
> restriction so that slaac devices can be supported.  So even though static
> & dhcpv6 support vlsm, it is not commonly deployed due to the slaac fixed
> 64 bit iid issue and possible interop issues that could crop up if slaac
> devices came up on LAN with dhcpv6 or static vlsm masking.  This has been a
> day 1 operations issue that all operators have lived with unfortunately.
>
>
>> If a 64 bit node wants to send to a destination with the same
>> 64 bit prefix that is in fact off-link because the on-link prefix
>> is actually supposed to be /68, what happens?
>>
>
>     I don't think you could have mix of vlsm masked hosts on the same
> subnet as that would not work.  That is not at all what is being suggested
> in this draft.  What is being suggested is variable length prefix greater
> or less then .64 bit and for longer prefixes use of RFC 4941 or RFC 7217
> random iid that does not have modified EUI mac dependency.   In the
> variable mask scenario all hosts would have the same mask.
>
> A point that came up a year or so ago with the classless draft below was
> related as well to the race to the bottom which comes up every time but
> also the variable length sizing and I think there was some contention as to
> what size to support.  So with this draft as it supports any length prefix,
> it would be supported with any length random iid would be generated RFC
> 4941 or stable RFC 7217 style whichever is desired.  Greater than or less
> then /64 length prefixes and corresponding iid would be supported.
>
>
> https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05
>
>
>>
>> Regards
>>    Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD