Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

Mark, what you are saying makes a lot of sense to me in terms of what we are seeing
in the real world today. I was thinking that our airplanes are another example of a
(multi-addressed) site

> -----Original Message-----
> From: Mark Andrews [mailto:marka@isc.org]
> Sent: Monday, November 09, 2020 3:20 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Gyan Mishra <hayabusagsm@gmail.com>; IPv6 IPv6 List <ipv6@ietf.org>; draft-mishra-6man-variable-slaac@ietf.org; Alexandre
> Petrescu <alexandre.petrescu@gmail.com>; Dusan Mudric <dusan.mudric@gmail.com>; Dmytro Shytyi <dmytro@shytyi.net>
> Subject: Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
> 
> Well people where thinking at the time that a person could be a site in terms
> of wearable networks.  They are now a common reality with cell phones providing
> a uplink.  /48 was chosen with that concept in mind.

What you are saying makes a lot of sense to me in terms of what we are seeing
in the real world today. In addition to people with their cellphones, I was thinking
that our commercial airplanes are another example of a site, and then so are
terrestrial vehicles and urban air mobility vehicles. All are sites; all are (mobile)
IoTs; all need multi-addressing.

Thanks - Fred

> Mark
> 
> > On 10 Nov 2020, at 10:10, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > I think the notion of what constitutes a “site” has advanced significantly since the
> > publication of RFC6177 – to the point that today even my cellphone could be seen
> > as a “site” in terms of the multi-addressing requirements its internal networks and
> > applications may require. Things that once were regarded as uni-addressed end
> > systems are now becoming (massively) multi-addressed IoTs. So an RFC6177-sized
> > IPv6 prefix for my cellphone could potentially be put to good use.
> >
> > Fred
> >
> > From: Gyan Mishra [mailto:hayabusagsm@gmail.com]
> > Sent: Monday, November 09, 2020 2:53 PM
> > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; Dmytro Shytyi
> <dmytro@shytyi.net>; Dusan Mudric <dusan.mudric@gmail.com>; IPv6 IPv6 List <ipv6@ietf.org>; draft-mishra-6man-variable-
> slaac@ietf.org
> > Subject: Re: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
> >
> >
> > On Mon, Nov 9, 2020 at 5:14 PM Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > Brian, brief comment/question below:
> >
> > > -----Original Message-----
> > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> > > Sent: Monday, November 09, 2020 1:58 PM
> > > To: Gyan Mishra <hayabusagsm@gmail.com>
> > > Cc: IPv6 IPv6 List <ipv6@ietf.org>; draft-mishra-6man-variable-slaac@ietf.org; Alexandre Petrescu
> <alexandre.petrescu@gmail.com>;
> > > Dusan Mudric <dusan.mudric@gmail.com>; Dmytro Shytyi <dmytro@shytyi.net>
> > > Subject: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
> > >
> > > This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> > > know that the content is safe.
> > >
> > >
> > > In line...
> > >
> > > On 10-Nov-20 04:35, Gyan Mishra wrote:
> > > > Brian
> > > >
> > > > In-line
> > > >
> > > > On Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
> > > >
> > > >     Gyan,
> > > >
> > > >     I don't think you were around for the original discussions, so there is an aspect that is missing from your logic below.
> > > >
> > > >     The inclusion of a separate interface identifier field in IP addresses was an entirely intentional feature of IPng. If all we had
> wanted
> > > to do was IPv4 with bigger addresses, that's what we would have done and the address length would have undoubtedly been 64
> bits.
> > > In fact there were various proposals to do exactly that, with a variety of associated transition and coexistence mechanisms.
> > > >
> > > >     But the rough consensus was to do more than that, and to allow *extra* space in the address for an interface identifier that
> was
> > > not part of the subnetting mechanism. Originally it was going to be 48 bits, so the longest subnet prefix would have been 80; on
> > > second thoughts it was set to 64, which gave *exactly* the same extension to the subnettable space as we would have got from
> IPv4
> > > with bigger addresses.
> > > >
> > > >     That isn't inconsistent with what we now call BCP198, which says that on links where an interface identifier & SLAAC isn't
> needed,
> > > subnetting can extend out to /127.
> > > >
> > > >     All that was despite the fact that we hadn't even realised the potential privacy benefits of a host-defined interface identifier at
> the
> > > time; that is much more recent.
> > > >
> > > >     As far "day 1" goes, please remember that DHCPv6 is a retro-fit:
> > > >
> > > >     RFC1971 IPv6 Stateless Address Autoconfiguration. August 1996
> > > >     RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). July 2003.
> > > >
> > > >
> > > >     Gyan> Makes sense then that as DHCPv6 was a retrofit “add on” to the base architecture that this issue came about
> afterwards.
> > > >
> > > >
> > > >
> > > >     (In fairness, draft-ietf-addrconf-ipv6-auto-00 was dated January 1995 and draft-ietf-dhc-dhcpv6-00 was dated February 1995,
> but
> > > it advanced very slowly compared to SLAAC.)
> > > >
> > > >
> > > >     Gyan> From a problem statement perspective do you agree with the title of this thread “Day 1 interoperability issue”?
> > >
> > > No. From the dates of the RFCs, it's a "Year 7 interoperability issue".
> > >
> > > > Do you agree that one way to solve is to allow SLAAC to support longer prefix lengths?
> > >
> > > That's one way, but it's the wrong way. The right way is for all operators, including mobile operators, to assign /48 or /56 to all end
> > > users.
> >
> > Isn't that exactly what RFC6177 (BCP157) tells us? Should we be working to
> > reaffirm that that BCP still applies today?
> >
> >
> >
> >    Gyan> RFC 6177 - Bottom of the intro it states that no formal recommendation is given.  It’s up to the operators to give what they
> feel is best.
> >
> >    This document does not make a formal recommendation on what the exact
> >    assignment size should be.  The exact choice of how much address
> >    space to assign end sites is an issue for the operational community.
> >    The IETF's role in this case is limited to providing guidance on IPv6
> >    architectural and operational considerations.  This document provides
> >    input into those discussions.  The focus of this document is to
> >    examine the architectural issues and some of the operational
> >    considerations relating to the size of the end site assignment.
> >
> >
> > Thanks - Fred
> >
> > > > Do you agree that this is a major operational issue that needs to be solved?
> > >
> > > Yes, but as Barbara says, that needs some collaboration with the SDOs and operator fora to get rid of /64 assignments.
> > >
> > >    Brian
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > --
> > <image001.jpg>
> >
> > Gyan Mishra
> > Network Solutions Architect
> > M 301 502-1347
> > 13101 Columbia Pike
> > Silver Spring, MD
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org