Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

Alex,

> -----Original Message-----
> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
> Sent: Tuesday, November 10, 2020 2:58 AM
> To: Mark Andrews <marka@isc.org>; 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; Dusan
> Mudric <dusan.mudric@gmail.com>; Dmytro Shytyi <dmytro@shytyi.net>
> Subject: Re: SLAAC, Static & DHCPv6 day 1 interoperability issue> 
> 
> There is something strange in calling a mobile a site.
> 
> To me, a site is very much a fixed location.

IMHO, "fixed location" is a very 20th century viewpoint. Internetworking
has gone mobile in the 21st century, and each mobile is a site unto itself.

Fred

> Alex
> 
> Le 10/11/2020 à 01:09, Mark Andrews a écrit :
> > I’ve got no problem with a airplane being a site nor a car being a site.
> > That said, my car is a node on whichever mobile phone the driver has currently, but
> > that may well change in the future.
> >
> > Things can change role in this space.  A cell phone may be router or just a node.
> > A car may be a router or just a node.
> >
> > Mark
> >
> >> On 10 Nov 2020, at 10:37, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >>
> >> 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
> >>
> >