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

[Gyan Mishra <[e-mail]>]

On Fri, Nov 6, 2020 at 6:42 AM Vasilenko Eduard <[e-mail]>
wrote:

> Address could not be flexible to infinity. It should have maximum. It is
> /64 now.
> If it would become bigger - some protocols would have the challenge.
> For example, temporary address generation (your rfc4941bis) would not have
> 64bits anymore for IID. We would need rfc4941_bis_bis


    As Fernando mentioned and others on this thread, it’s the IID
generation modified EUI64 is what is setting the boundaries at 64.

As Fernando mentioned with a random IID generation stable or not RFC 4941
or RFC 7217 you are now not bound to the 64 bit fixed IID.

I believe free BSD does not fix the boundary

We have tested with Linux kernel mods using random IID generation schema
RFC 4941 or RFC 7217 stable and you can create any length IID.


> Ed/
> > -----Original Message-----
> > From: Fernando Gont [mailto:[e-mail]]
> > Sent: 6 ноября 2020 г. 13:34
> > To: Vasilenko Eduard <[e-mail]>; Fernando Gont
> > <[e-mail]>; IPv6 List <[e-mail]>
> > Subject: Re: [EXTERNAL] Re: I-D Action:
> draft-mishra-6man-variable-slaac-01.txt
> >
> > On 6/11/20 07:18, Vasilenko Eduard wrote:
> > > Hi Fernando,
> > > I said that "address resolution is not needed". Some simplified
> protocol is
> > needed anyway.
> > > You have pointed to the manual address collision.
> >
> > No. I pointed out that unless the IID is mandated to embed the
> underlying MAC
> > address in all cases, you still need address resolution.
> >
> > (and *that* has never been mandated).
> >
> >
> >
> > > I could additionally say that the router should announce "seed" to
> obfuscate
> > MAC addresses on this link (the same MAC should look different on
> different
> > links).
> >
> > Why should it?
> >
> >
> >
> > > Additionally, RA is needed to centralized push of configuration
> information.
> > > But it is not "neighbor discovery", it is "link configuration".
> > > Well, it does not make sense to discuss - much smaller things has been
> > rejected on 6man. It is really the revolution that I do believe make
> sense to push.
> > >
> > > But yes, such revolution would need to keep subnet boundary at the
> exact
> > position (like /64).
> >
> > Sorry, I'm lost here.
> >
> > There's no *technical* reason for the subnet boundary to be required to
> be fixed
> > at /64.
> >
> > /64 was only needed if one wanted to support IID generation based on
> > embedding MAC addresses on link-layers with 64-bit MACs.
> >
> > Once we got rid of recommending that IIDs be generated by embeding the
> > underlying mac address (think RFC8064), the only reason for mandating a
> fixed
> > subnet boundary is electro-political, *not* technical.
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: [e-mail]
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
>
> --------------------------------------------------------------------
> 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