Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

[Alexandre Petrescu <[e-mail]>]

There is something strange in calling a mobile a site.

To me, a site is very much a fixed location.

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 <[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]
>>
>