Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

[Mark Andrews <[e-mail]>]

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 <[e-mail]> 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:[e-mail]]
>> Sent: Monday, November 09, 2020 3:20 PM
>> To: Templin (US), Fred L <[e-mail]>
>> Cc: Gyan Mishra <[e-mail]>; IPv6 IPv6 List <[e-mail]>; [e-mail]; Alexandre
>> Petrescu <[e-mail]>; Dusan Mudric <[e-mail]>; Dmytro Shytyi <[e-mail]>
>> 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 <[e-mail]> 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:[e-mail]]
>>> Sent: Monday, November 09, 2020 2:53 PM
>>> To: Templin (US), Fred L <[e-mail]>
>>> Cc: Alexandre Petrescu <[e-mail]>; Brian E Carpenter <[e-mail]>; Dmytro Shytyi
>> <[e-mail]>; Dusan Mudric <[e-mail]>; IPv6 IPv6 List <[e-mail]>; draft-mishra-6man-variable-
>> [e-mail]
>>> Subject: Re: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
>>> 
>>> 
>>> On Mon, Nov 9, 2020 at 5:14 PM Templin (US), Fred L <[e-mail]> wrote:
>>> Brian, brief comment/question below:
>>> 
>>>> -----Original Message-----
>>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
>>>> Sent: Monday, November 09, 2020 1:58 PM
>>>> To: Gyan Mishra <[e-mail]>
>>>> Cc: IPv6 IPv6 List <[e-mail]>; [e-mail]; Alexandre Petrescu
>> <[e-mail]>;
>>>> Dusan Mudric <[e-mail]>; Dmytro Shytyi <[e-mail]>
>>>> 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 <[e-mail]<mailto:[e-mail]>> 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
>>>> [e-mail]
>>>> 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
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: [phone]              INTERNET: [e-mail]
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]