Re: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

On 10-Nov-20 12:10, Templin (US), Fred L 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. 

Exactly right. Maybe we need RFC9177 for only that reason, and a
corresponding liaison message to 3GPP to follow up.

The fact that BCP157 (aka RFC6177) isn't full of MUSTs and SHOULDs
doesn't matter, I believe. The message is perfectly clear.

   Brian

> 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<mailto:Fred.L.Templin@boeing.com>> wrote:
> Brian, brief comment/question below:
> 
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-bounces@ietf.org<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<mailto:hayabusagsm@gmail.com>>
>> Cc: IPv6 IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>; draft-mishra-6man-variable-slaac@ietf.org<mailto:draft-mishra-6man-variable-slaac@ietf.org>; Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>>;
>> Dusan Mudric <dusan.mudric@gmail.com<mailto:dusan.mudric@gmail.com>>; Dmytro Shytyi <dmytro@shytyi.net<mailto: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> <mailto: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<mailto:ipv6@ietf.org>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> --
> 
> [Image removed by sender.]<http://www.verizon.com/>
> 
> Gyan Mishra
> 
> Network Solutions Architect
> 
> M 301 502-1347
> 13101 Columbia Pike
> Silver Spring, MD
> 