Subject: SLAAC, Static & DHCPv6 day 1 interoperability issue

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Nov 2020 01:34:39 -0500

A day 1 issue that has existed with SLAAC and another critical operational
reason as to why longer prefix should be supported by SLAAC.

Since SLAAC only supports /64 plen due to the fixed 64 bit IID, that issue
ends up shackling IPv6 from using longer  prefix length when other devices
using static or DHCPV6 are configured on the same subnet.

The major issue that exists is that their maybe devices that do not support
DHCPV6 or static and have to use SLAAC and you have a subnet configured on
the router with longer then /64 prefix length like a /96 for example.

So now with those devices running SLAAC you end up with interoperability
issue with remaining devices on the subnet that support longer prefix
length via static or DHCPV6.

The workaround has always been to not use longer prefix lengths for DHCPV6
and static and only use the /64 prefix length as that is only supported by
SLAAC.

So that hinders any and  all operators both enterprises and service
providers from using longer prefix lengths, so you are now back to being
stuck with the 64 bit IID boundary for all host subnets till the end of
time using any of the three IPv6 addressing schemes.

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Mark Smith <[email-masked]>
Date: Sun, 8 Nov 2020 18:23:27 +1100

> reason as to why longer prefix should be supported by SLAAC.

No it didn't.

> using static or DHCPV6 are configured on the same subnet.

DHCPv6 doesn't provide prefix lengths to hosts, only a 128 bit address or
addesses to use. See the IA-NA and IA-TA options in RFC 8415.

RA PIOs tell hosts which range of addresses are on-link. See RFC 5942.

> The major issue that exists is that their maybe devices that do not
> support DHCPV6 or static and have to use SLAAC and you have a subnet
> configured on the router with longer then /64 prefix length like a /96 for
> example.
>

/96 prefixes aren't supported for hosts discovering addresses. See RFC
4291, and all of its ancestors back to RFC 1884.

> time using any of the three IPv6 addressing schemes.

Have you read RFC 7421?

Why is that a problem when the IPv6 address space is 73 billion billion
times larger (2^96) than IPv4's address space?

IPv6 was originally going to have only 64 bit addresses, which were
considered enough to solve the problem for a useful enough time period. See
RFC 8507.

The additional 64 bits provided the simplicity of having a single large
default prefix size for all edge links until IPv6 becomes obsolete.

It's best to assume most problems with IPv6 have been discovered by now,
because IPv6 is older now than IPv4 was when RFC1883 was published.

If you think you've discovered a problem, it is best to check the relevant
RFCs first.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Philip Homburg <[email-masked]>
Date: Sun, 08 Nov 2020 09:04:01 +0100

>length via static or DHCPV6.

I don't understand the problem you are describing. If a router marks a 
/96 prefix as onlink then SLAAC-only hosts on the same subnet can communicate
with that prefix but obviously cannot generate a SLAAC address.

There could be implementation errors. But then those should be pointed out
and fixed.

I assume you realize that the onlink property is separate from
autonomous address configuration. The onlink property does not have an
implicit 64-bit boundary.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Nov 2020 10:44:36 -0500

On Sun, Nov 8, 2020 at 2:23 AM Mark Smith <[email-masked]> wrote:

>> A day 1 issue that has existed with SLAAC and another critical
>> operational reason as to why longer prefix should be supported by SLAAC.
>>
>
> No it didn't.
>
>
>> Since SLAAC only supports /64 plen due to the fixed 64 bit IID, that
>> issue ends up shackling IPv6 from using longer  prefix length when other
>> devices using static or DHCPV6 are configured on the same subnet.
>>
>
>

    Gyan> Understood that DHCPv6 M=1 managed address that when using
stateful SLAAC RFC 8415 that the DHCPV6 pool the stateful addresses in the
dhcpv6 offer can be of any mask longer or shorter than /64.

> 4291, and all of its ancestors back to RFC 1884.

    Gyan> Understood.  What I am trying to say is that you can have IPv6
hosts that are configured with static addresses that support any length
prefix and you can have DHCPv6 pool for hosts where the Managed 128 bit
address sent to the host can have a any prefix length as defined on the
router. Hi

>> The workaround has always been to not use longer prefix lengths for
>> DHCPV6 and static and only use the /64 prefix length as that is only
>> supported by SLAAC.
>>

    Gyan> This draft references RFC 7421. My point here is that both Static
and DHCPv6 stateful RFC 8415 both support any prefix length.  SLAAC due to
IID fixed 64 bit boundary does not support.  The 64 bit boundary was a
problem when IID generation was based on modified EUI64 mac based IID.
However now with random station ID generation privacy extension RFC 4941
and stable IID RFC 7217 you can generate an IID of any length.  So the
issue that existed that has shackled SLAAC to the 64 bit boundary  is no
more.  The reasons to be able to have longer prefix lengths with SLAAC
addressed on the other threads related to 3GPP /64 segmentation to
connected devices but in this thread the issue I am trying to bring up is
related to maintenance consistently and parity between the three assessing
schemes, static, DHCPv6 and SLAAC.  So it’s the interoperability issues
that can arise if you have a mix of address allocation schemes on the same
subnet and are using longer prefixes with static configured devices and
longer prefix for DHCPv6 pool managed address devices and you have SLAAC
devices that pop up on same subnet they will not work.

>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Nov 2020 11:05:14 -0500

On Sun, Nov 8, 2020 at 3:04 AM Philip Homburg <
[email-masked]> wrote:

> support

   Gyan>Understood.  The main point I am trying to make is that static
address configuration and DHCPV6 stateful RFC 8415, you can have any prefix
length prefix.   SLAAC with A flag set requires a  64 bit IID and that
stems from RFC 4291 modified EUI64 mac based IID generation.  However, now
with random IID generation schemes with RFC 4941 privacy extension and RFC
7217 stable IID you can generate any length IID.

The operational issue with SLAAC not supporting any prefix length in PIO
and requirement for the 64 bit boundary is that in a deployment scenario
where you would like to deploy longer prefix length subnets with a mix of
server hosts with static address and mix of client hosts with managed
address M=1 that get their 128 bit address from the DHCPv6 server pool, the
fear has always been that if a device came up on the subnet that only
supports SLAAC it would not work due to the SLAAC A flag set and 64 bit IID
requirement.  In that case the SLAAC host would not be able to communicate
with any of the devices with a longer prefix including the router.

So that fear of interoperability of SLAAC hosts not being able to support
longer prefix lengths has prevented operators from being able to deploy
subnets with longer prefix lengths, as it’s hard to predict that all hosts
will be able to support static or stateful and so you may end up in a
situation where a device type may only support SLAAC so then you are in
trouble deploying longer prefix lengths.

Due to the SLAAC 64 bit IID restrictions it has prevented operators from
deploying “host” subnets with >64 bit prefix lengths.

Gyan
-- 

*Gyan Mishra*

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Nov 2020 09:14:49 +1300

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.

(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.)

Regards
   Brian Carpenter

On 08-Nov-20 19:34, Gyan Mishra wrote:
> 
> A day 1 issue that has existed with SLAAC and another critical operational reason as to why longer prefix should be supported by SLAAC.
> 
> Since SLAAC only supports /64 plen due to the fixed 64 bit IID, that issue ends up shackling IPv6 from using longer  prefix length when other devices using static or DHCPV6 are configured on the same subnet.  
> 
> The major issue that exists is that their maybe devices that do not support DHCPV6 or static and have to use SLAAC and you have a subnet configured on the router with longer then /64 prefix length like a /96 for example.  
> 
> So now with those devices running SLAAC you end up with interoperability issue with remaining devices on the subnet that support longer prefix length via static or DHCPV6.
> 
> The workaround has always been to not use longer prefix lengths for DHCPV6 and static and only use the /64 prefix length as that is only supported by SLAAC.
> 
> So that hinders any and  all operators both enterprises and service providers from using longer prefix lengths, so you are now back to being stuck with the 64 bit IID boundary for all host subnets till the end of time using any of the three IPv6 addressing schemes.
> 
> Gyan
> 
> 
> 
> 
> 
> -- 
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike 
> /Silver Spring, MD
> 
> 
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Nov 2020 11:43:07 +0100

>    The operational issue with
>    SLAAC not supporting any prefix length in PIO and requirement
>    for the 64 bit boundary is that in a deployment scenario where
>    you would like to deploy longer prefix length subnets with a
>    mix of server hosts with static address and mix of client hosts
>    with managed address M=1 that get their 128 bit address from
>    the DHCPv6 server pool, the fear has always been that if a device
>    came up on the subnet that only supports SLAAC it would not work
>    due to the SLAAC A flag set and 64 bit IID requirement.  In that
>    case the SLAAC host would not be able to communicate with any
>    of the devices with a longer prefix including the router.  

In this scenario, the SLAAC host would not get a global address, but would
still have a link local address. Communication with routers happens
using link local addresses, so I don't see how that could be an issue.

If the host wants to send a packet to a global address and the host only has
a link local address, then host generates a packet with a link local address
as source address. If the destination global address is onlink, then the
host can directly use ND to find the L2 address of the target.

If the destination is not onlink, then the destination could still be on
the same subnet, so the host would send the packet to the default router.
The default router would then forward the packet to the destination on the
same link. Obviously, this last part is rarely used, so it would not 
surprise me if there are bugs.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 10:35:48 -0500

Brian

In-line

On Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter <
[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.
>

    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”?

Do you agree that one way to solve is to allow SLAAC to support longer
prefix lengths?

Do you agree that this is a major operational issue that needs to be solved?

*Gyan Mishra*

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2020 10:57:42 +1300

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,
> 
>     Gyan> Makes sense then that as DHCPv6 was a retrofit “add on” to the base architecture that this issue came about afterwards.
> 
> 
> 
>     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.

> 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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 9 Nov 2020 22:13:53 +0000

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...
> 
> >     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.
> >
> >     (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.)
> >
> >

Isn't that exactly what RFC6177 (BCP157) tells us? Should we be working to
reaffirm that that BCP still applies today?

Thanks - Fred

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 17:43:33 -0500

In-line

On Mon, Nov 9, 2020 at 4:57 PM Brian E Carpenter <
[email-masked]> wrote:

> [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
> >     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.
> >
> >     (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”?
>

    Gyan>  I think you meant to say 17 year interoperability issue as RFC
3315 is dated 2003.   This is a MAJOR issue that had shackled operators in
deployments of longer prefixes to host subnets.  That is a fact.

> 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.

    Gyan> If you go to the “root” of the problem the root is the original
IPv6 specification RFC 1884 dated 1995, RFC 2373 dated 1998, RFC 3513 dated
2003 and now the present RFC 4291 dated 2006.  As soon EUI64 mac based IID
become not recommendedR and obsolete the standard should have immediately
updated RFC 4291 as the dependency on fixed IID is no longer as now random
IID generation schema starting with RFC 4941 privacy extension dated 2007
soon became standard for all OS vendors and later RFC 7217 stable IID
became an alternative option to provide a “random” IID.

Once random IID became mainstream in all Host Operating Systems it was at
that moment that the standard should have changed to update RFC 4291 to
permanently remove in all RFCs any mention of 64 bit boundary.

So this change if I do the math is now 13 years past due.  Even if you gave
a few years for host operating systems to adopt the new standard which I
believe back then was fairly quickly the standard should have changed
eliminating the 64 bit boundary.

Think of all the problems “Day 17 years” this has caused and even now all
of these threads.

This is clearly an IETF standards issue and needs to be fixed.

We can’t pass the blame to operators to dole out shorter prefixes or
support PD.  The IETF really needs to take onus end fix the broken standard.

Not going to happen for PDP as their are technical issue related to the
Mobile Network Gateway to support PD.   I will try to dig up the exact
reason but the network element is very different then a BNG broadband
gateway which supports most all L3 features.

As far as 3GPP operators they are following the well documented RIPE-690
which only requires allocation of /64.  The main reason mobile operators
are not making shorter prefix a standard is that is overkill from their
perspective as you may have many mobile handsets in a household and there
 is no reason for everyone at a single location to have shorter prefixes
per PDP.  When you are at honme you use your wired broadband and when are
away from home on the road on 3GPP on PDP is when the segmentation comes
into play to subdivide the /64 prefix to downstream devices but in a
household is only needed to be provided by one of the devices.
Bottom line is from a 3GPP provider standpoint it does not make sense to
provide a shorter prefix and I don’t think that will ever change even with
5G PDP.

Fixed 5G broadband which is a wired broadband replacement will follow
RIPE-690 guidelines and will allocation much shorter prefixes as with
network slicing and other capabilities with 5G offers the requirements
exist for shorter prefixes.  Not so much for PDP.

https://www.ripe.net/publications/docs/ripe-690#4-2-4--considerations-for-cellular-operators

4.2.4. Considerations for Cellular Operators

There is a clear exception to the rule described above when assigning
prefixes in a cellular network. In this case, a /64 will need to be
provided for each PDP context for cellular phones, whereas for LTE
modems/routers, i.e. in the case of broadband by means of cellular access,
it will still be necessary to choose a /48 or /56 in accordance with the
aforementioned considerations.

> Yes, but as Barbara says, that needs some collaboration with the SDOs and
> operator fora to get rid of /64 assignments.
>
>    Brian
>
> --

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 17:52:41 -0500

On Mon, Nov 9, 2020 at 5:14 PM Templin (US), Fred L <
[email-masked]> wrote:

> > Cc: IPv6 IPv6 List <[email-masked]>;
> [email-masked]; Alexandre Petrescu <
> [email-masked]>;
> > This message was sent from outside of Boeing. Please do not click links
> or open attachments unless you recognize the sender and
> > >     I don't think you were around for the original discussions, so
> there is an aspect that is missing from your logic below.
> > >
> 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.
> > >
> *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.
> > >
> > >     Gyan> Makes sense then that as DHCPv6 was a retrofit “add on” to
> the base architecture that this issue came about afterwards.
> > >
> > >
> > >
> 1995 and draft-ietf-dhc-dhcpv6-00 was dated February 1995, but

   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.

> > Yes, but as Barbara says, that needs some collaboration with the SDOs
> and operator fora to get rid of /64 assignments.
> >
> >    Brian
> >
-- 

*Gyan Mishra*

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2020 10:04:47 +1100

> On 10 Nov 2020, at 09:43, Gyan Mishra <[email-masked]> wrote:
> 
> 
> In-line
> 
> On Mon, Nov 9, 2020 at 4:57 PM Brian E Carpenter <[email-masked]> wrote:
> In line...
> 
>     Gyan>  I think you meant to say 17 year interoperability issue as RFC 3315 is dated 2003.   This is a MAJOR issue that had shackled operators in deployments of longer prefixes to host subnets.  That is a fact.
> 
> 
>     Gyan> If you go to the “root” of the problem the root is the original IPv6 specification RFC 1884 dated 1995, RFC 2373 dated 1998, RFC 3513 dated 2003 and now the present RFC 4291 dated 2006.  As soon EUI64 mac based IID become not recommendedR and obsolete the standard should have immediately updated RFC 4291 as the dependency on fixed IID is no longer as now random IID generation schema starting with RFC 4941 privacy extension dated 2007 soon became standard for all OS vendors and later RFC 7217 stable IID became an alternative option to provide a “random” IID.  
> 
> Once random IID became mainstream in all Host Operating Systems it was at that moment that the standard should have changed to update RFC 4291 to permanently remove in all RFCs any mention of 64 bit boundary.  

No.  The point of having a “fixed” size is to make the lives of everyone on the planet easier.  How you fill in the last 64 bits is a orthogonal issue.  Having a fixed /48 for a site was made for the same reason.  To make everyone’s lives easier.

> So this change if I do the math is now 13 years past due.  Even if you gave a few years for host operating systems to adopt the new standard which I believe back then was fairly quickly the standard should have changed eliminating the 64 bit boundary.
> 
> Think of all the problems “Day 17 years” this has caused and even now all of these threads.
> 
> We can’t pass the blame to operators to dole out shorter prefixes or support PD.  The IETF really needs to take onus end fix the broken standard.
> 
> Not going to happen for PDP as their are technical issue related to the Mobile Network Gateway to support PD.   I will try to dig up the exact reason but the network element is very different then a BNG broadband gateway which supports most all L3 features.
> 
> As far as 3GPP operators they are following the well documented RIPE-690 which only requires allocation of /64.  The main reason mobile operators are not making shorter prefix a standard is that is overkill from their perspective as you may have many mobile handsets in a household and there  is no reason for everyone at a single location to have shorter prefixes per PDP.  When you are at honme you use your wired broadband and when are away from home on the road on 3GPP on PDP is when the segmentation comes into play to subdivide the /64 prefix to downstream devices but in a household is only needed to be provided by one of the devices.
> Bottom line is from a 3GPP provider standpoint it does not make sense to provide a shorter prefix and I don’t think that will ever change even with 5G PDP.
> 
> Fixed 5G broadband which is a wired broadband replacement will follow RIPE-690 guidelines and will allocation much shorter prefixes as with network slicing and other capabilities with 5G offers the requirements exist for shorter prefixes.  Not so much for PDP.  
> 
> 
> There is a clear exception to the rule described above when assigning prefixes in a cellular network. In this case, a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers, i.e. in the case of broadband by means of cellular access, it will still be necessary to choose a /48 or /56 in accordance with the aforementioned considerations.
> 
> 
> 
> 
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 9 Nov 2020 23:10:27 +0000

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]>; [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]<mailto:[email-masked]>> wrote:
Brian, brief comment/question below:

> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E Carpenter
> To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
> Cc: IPv6 IPv6 List <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>;
> Dusan Mudric <[email-masked]<mailto:[email-masked]>>; Dmytro Shytyi <[email-masked]<mailto:[email-masked]>>
> > On Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> >
> >     Gyan,
> >

   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.

Thanks - Fred

> [email-masked]<mailto:[email-masked]>
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 18:14:15 -0500

On Mon, Nov 9, 2020 at 6:04 PM Mark Andrews <[email-masked]> wrote:

> >     Gyan>  I think you meant to say 17 year interoperability issue as
> RFC 3315 is dated 2003.   This is a MAJOR issue that had shackled operators
> in deployments of longer prefixes to host subnets.  That is a fact.
> >
> >
> >     Gyan> If you go to the “root” of the problem the root is the
> original IPv6 specification RFC 1884 dated 1995, RFC 2373 dated 1998, RFC
> 3513 dated 2003 and now the present RFC 4291 dated 2006.  As soon EUI64 mac
> based IID become not recommendedR and obsolete the standard should have
> immediately updated RFC 4291 as the dependency on fixed IID is no longer as
> now random IID generation schema starting with RFC 4941 privacy extension
> dated 2007 soon became standard for all OS vendors and later RFC 7217
> stable IID became an alternative option to provide a “random” IID.
> >
> > Once random IID became mainstream in all Host Operating Systems it was
> at that moment that the standard should have changed to update RFC 4291 to
> No.  The point of having a “fixed” size is to make the lives of everyone
> on the planet easier.  How you fill in the last 64 bits is a orthogonal
> issue.  Having a fixed /48 for a site was made for the same reason.  To
> make everyone’s lives easier.

   Gyan> Well that is what is stated in RFC 3177 for a default /48
allocation which is obsoleted by 6177 which takes a step back and is now
not making any recommendations and is putting the onus on operators to
figure it out and do what they feel is best which would definitely not be
one size fits all approach.

Please read the summary section in RFC 6177 below

5 <https://tools.ietf.org/html/rfc6177#section-5>.  Summary

   The exact choice of how much address space to assign end sites is an
   issue for the operational community.  The recommendation in RFC
3177 <https://tools.ietf.org/html/rfc3177>
   [RFC3177 <https://tools.ietf.org/html/rfc3177>] to assign /48s as a
default is not a requirement of the
   IPv6 architecture; anything of length /64 or shorter works from a
   standards perspective.  However, there are important operational
   considerations as well, some of which are important if users are to
   share in the key benefit of IPv6: expanding the usable address space
   of the Internet.  The IETF recommends that any policy on IPv6 address
   assignment policy to end sites take into consideration the following:

>
> > So this change if I do the math is now 13 years past due.  Even if you
> gave a few years for host operating systems to adopt the new standard which
> I believe back then was fairly quickly the standard should have changed
> is no reason for everyone at a single location to have shorter prefixes per
> PDP.  When you are at honme you use your wired broadband and when are away
> from home on the road on 3GPP on PDP is when the segmentation comes into
> play to subdivide the /64 prefix to downstream devices but in a household
> is only needed to be provided by one of the devices.

*Gyan Mishra*

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2020 10:20:08 +1100

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.

Mark

> On 10 Nov 2020, at 10:10, Templin (US), Fred L <[email-masked]> wrote:
> 
> On Mon, Nov 9, 2020 at 5:14 PM Templin (US), Fred L <[email-masked]> wrote:
> > > On Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > >     Gyan,
> > >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2020 10:25:42 +1100

Just because there where lots of people with IPv4 think in the operator community that
pushed back because “We think we know best” doesn’t mean the original decision was wrong.

If you look at those communities more and more are coming to the understanding that /48
was a good decision.

Mark

> On 10 Nov 2020, at 10:14, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 
>    Gyan> Well that is what is stated in RFC 3177 for a default /48 allocation which is obsoleted by 6177 which takes a step back and is now not making any recommendations and is putting the onus on operators to figure it out and do what they feel is best which would definitely not be one size fits all approach.
> 
> 5.  Summary
>    issue for the operational community.  The recommendation in 
> RFC 3177
> 
>    [
> RFC3177
> ] to assign /48s as a default is not a requirement of the

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2020 13:28:34 +1300

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2020 13:42:06 +1300

> If you look at those communities more and more are coming to the understanding that /48

I think it took a surprisingly long time for people to understand that the 35 trillion /48s in 2000::/3 is a really big number.

    Brian

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 20:05:07 -0500

On Mon, Nov 9, 2020 at 7:42 PM Brian E Carpenter <
[email-masked]> wrote:

> I think it took a surprisingly long time for people to understand that the
> 35 trillion /48s in 2000::/3 is a really big number.

  I agree 35 trillion is hard to comprehend and on top of that all the IANA
unallocated ranges which includes a bunch of /3.  In theory that all sounds
great.  One factor that does play into that is the two layers of
allocations framework IANA to RIR and then RIR allocation to service
providers which is large but not as large as you would expect given the 35
trillion.  RIR is still stingy old school on its allocations.

*Gyan Mishra*

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2020 12:21:48 +1100

> On 10 Nov 2020, at 12:05, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 
> On Mon, Nov 9, 2020 at 7:42 PM Brian E Carpenter <[email-masked]> wrote:
>   I agree 35 trillion is hard to comprehend and on top of that all the IANA unallocated ranges which includes a bunch of /3.  In theory that all sounds great.  One factor that does play into that is the two layers of allocations framework IANA to RIR and then RIR allocation to service providers which is large but not as large as you would expect given the 35 trillion.  RIR is still stingy old school on its allocations.  

Please name a single ISP that is unable to get enough /48’s for all their customers from a RIR.

Having to do a little paperwork to justify the size of the allocation being requested is not being stingy.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Nov 2020 10:18:44 +0100

You should not insist on blaming the RIPE-690 (“As far as 3GPP operators they are following the well documented RIPE-690 which only requires allocation of /64”), which is false, because:
It is not a standard, it is a BCP.
It was following the existing practices for existing LTE deployments, not changing it.
As you already included the text from 4.2.4., it is easy to see that it was already accounting for a /64 per PDP for a cellular smartphone, but when the cellular smartphone is used as a router, or it is a cellular router device and not a cellular smartphone, then it should also follows the rest of the BCP and standards regarding the provision of /48 or /56.

I think there is not chance for a wrong interpretation of section 4.2.4 in the RIPE-690. I tried my best and consulted with many folks, to make sure that it was clear enough. Even more, because not being native english speaker, I wanted to make sure that we don’t say anything that can be missinterpreted. Nevertheless, if you think it can be wrongly interpreted, I’m happy to work with the rest of the co-authors and make a new version, add whatever is needed for 5G, etc., etc. Just provide inputs.

Regards,

Jordi

@jordipalet

El 9/11/20 23:44, "ipv6 en nombre de Gyan Mishra" <[email-masked] en nombre de [email-masked]> escribió:

In-line

In line...

 

 

   Brian

-- 

Gyan Mishra

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Nov 2020 10:39:32 +0100

This is not true.

I’ve been working in policy development process in all the RIR since around 2003 or so. I think I’ve submitted around 100 policy proposals among all the RIRs, no including number of versions (some of them have reached consensus with just 1-2 versions, others required up to 7-8). I never did the exact stats, but I think probably 95-96% reached consensus and only dropped a few ones or have them “in-hold” (sometimes a policy proposal need to come back at another time to be accepted, so more people see the need, etc.).

And I can tell you, based on real experience, that in all the RIRs where I’ve proposed to have more clear guidelines and policies, on IPv6 allocation (ISPs) and assignment (end-users), ensuring that there are no restrictions and the justification is simple, it has passed. In a couple of regions, new proposals were not needed because someone else already did that.

The fact is that RIRs follow the consensus from the community, and rules exist since several years ago, to easily justify your need and get the allocation/assignment you really need, and this is true in all the 5 RIRs and *working*.

If you think otherwise, I’m happy to help you to submit a policy proposal to change that, we just need to understand what case can’t be fulfilled with existing policy in a given RIR.

Regards,

Jordi

@jordipalet

El 10/11/20 2:05, "ipv6 en nombre de Gyan Mishra" <[email-masked] en nombre de [email-masked]> escribió:

    Brian

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 11:44:56 +0100

Le 09/11/2020 à 23:13, Templin (US), Fred L a écrit :
>> -----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]> 
>> 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 Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter
>>> <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>> 
>>> Gyan,
>>> 
>> 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.
>>> 
>> 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.
>>> 
>> 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?

FRed, let me say now what I said then too: that RFC is for sites, not
for mobiles.  Some explain it as being the same, but they are not the same.

An RFC for mobiles, like RFC6177, might be appropriate.  But I think one
cant make it at IETF because concerned (~) operator(s) would not let it
through.  One simply cant accept an RFC which practically outlaws that
many deployments.

The (~) operators who would accept /56 to mobiles would suddenly reject
so many other protocols and software they already installed, planned, etc.

Alex

>> Yes, but as Barbara says, that needs some collaboration with the
>> SDOs and operator fora to get rid of /64 assignments.
>> 
>> Brian
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 11:56:08 +0100

There is something strange in calling a person a 'site'.

Alex