Subject: Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 10 Nov 2020 14:43:17 +0000

Alex,

> -----Original Message-----
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Tuesday, November 10, 2020 2:58 AM
> To: Mark Andrews <[email-masked]>; Templin (US), Fred L <[email-masked]>
> Cc: Gyan Mishra <[email-masked]>; IPv6 IPv6 List <[email-masked]>; [email-masked]; Dusan
> Mudric <[email-masked]>; Dmytro Shytyi <[email-masked]>
> 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 <[email-masked]> 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:[email-masked]]
> >>> Sent: Monday, November 09, 2020 3:20 PM
> >>> To: Templin (US), Fred L <[email-masked]>
> >>> Cc: Gyan Mishra <[email-masked]>; IPv6 IPv6 List <[email-masked]>; [email-masked];
> Alexandre
> >>> Petrescu <[email-masked]>; Dusan Mudric <[email-masked]>; Dmytro Shytyi <[email-masked]>
> >>> 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 <[email-masked]> 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:[email-masked]]
> >>>> Sent: Monday, November 09, 2020 2:53 PM
> >>>> To: Templin (US), Fred L <[email-masked]>
> >>>> Cc: Alexandre Petrescu <[email-masked]>; Brian E Carpenter <[email-masked]>; Dmytro Shytyi
> >>> <[email-masked]>; Dusan Mudric <[email-masked]>; IPv6 IPv6 List <[email-masked]>; draft-mishra-6man-variable-
> >>> [email-masked]
> >>>> Subject: Re: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
> >>>>
> >>>>
> >>>> On Mon, Nov 9, 2020 at 5:14 PM Templin (US), Fred L <[email-masked]> wrote:
> >>>> Brian, brief comment/question below:
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> >>>>> Sent: Monday, November 09, 2020 1:58 PM
> >>>>> To: Gyan Mishra <[email-masked]>
> >>>>> Cc: IPv6 IPv6 List <[email-masked]>; [email-masked]; Alexandre Petrescu
> >>> <[email-masked]>;
> >>>>> Dusan Mudric <[email-masked]>; Dmytro Shytyi <[email-masked]>
> >>>>> 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 <[email-masked]<mailto:[email-masked]>>
> 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
> >>>>> [email-masked]
> >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> --------------------------------------------------------------------
> >>>> --
> >>>>
> >>>> Gyan Mishra
> >>>> Network Solutions Architect
> >>>> M 301 502-1347
> >>>> 13101 Columbia Pike
> >>>> Silver Spring, MD
> >>>>
> >>>> --------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list
> >>>> [email-masked]
> >>>> 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: [email-masked]
> >>
> >