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

[Gyan Mishra <[e-mail]>]

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