Subject: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 02:43:54 -0500

How do we propose to solve this problem if operators don’t support PD even
though the  3GPP standard has supported PD for over 10 years.

Another twist to this puzzle is Android has 90% of the mobile handset
marketplace worldwide and adamantly states they will NOT support DHCPv6 or
PD.

I researched Apple which has 10% of the market and they also do not support
PD.

Whats the solution now?
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 23 Nov 2020 13:24:43 +0100 (CET)

> I researched Apple which has 10% of the market and they also do not support

The obvious use-case for PD is the "LTE router" fixed-wireless use-case. 
There the problem of getting a DHCPv6-PD client into the UE isn't the same 
as on handsets. A lot of those platforms already support DHCPv6-PD for 
their wired versions (some have both LTE and wired WAN).

So this brings us back to the mobile core. Why doesn't this today, 8 years 
after DHCPv6-PD was introduced in 3GPP standards, still not support PD?

I don't know but I know staff at operators who claim to have tried (more 
than 5 years ago). I do not know why their efforts failed. Perhaps the 
mobile core vendors successfully managed to divide the customer base so 
there was no critical mass. I can only speculate. I just find it weird 
that there are now demands to change *everything* downstream from the 3GPP 
bearer to handle smaller subnets instead of enabling PD in mobile core.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 12:05:39 -0500

> their wired versions (some have both LTE and wired WAN).

    Gyan>Agreed the obvious PD use case is for wired LTE but this
particular use case brought up in slaac problem statement draft is for
handsets.

> bearer to handle smaller subnets instead of enabling PD in mobile core.

    Gyan> I have to research technical reasons why

-- 

*Gyan Mishra*

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 23 Nov 2020 19:12:31 +0100

Le 23/11/2020 à 13:24, Mikael Abrahamsson a écrit :
>> How do we propose to solve this problem if operators don’t support 
>> PD even though the  3GPP standard has supported PD for over 10 
>> years.
>> 
>> Another twist to this puzzle is Android has 90% of the mobile 
>> handset marketplace worldwide and adamantly states they will NOT 
>> support DHCPv6 or PD.
>> 
>> I researched Apple which has 10% of the market and they also do
>> not support PD.
>> 
>> Whats the solution now?
> 
> The obvious use-case for PD is the "LTE router" fixed-wireless 
> use-case. There the problem of getting a DHCPv6-PD client into the
> UE isn't the same as on handsets. A lot of those platforms already 
> support DHCPv6-PD for their wired versions (some have both LTE and 
> wired WAN).
> 
> So this brings us back to the mobile core. Why doesn't this today, 8 
> years after DHCPv6-PD was introduced in 3GPP standards, still not 
> support PD?
> 
> I don't know but I know staff at operators who claim to have tried 
> (more than 5 years ago). I do not know why their efforts failed. 
> Perhaps the mobile core vendors successfully managed to divide the 
> customer base so there was no critical mass. I can only speculate.

> I just find it weird that there are now demands to change 
> *everything* downstream from the 3GPP bearer to handle smaller 
> subnets instead of enabling PD in mobile core.

It is an interesting note.  Put that way indeed it looks weird.

Indeed a variable length plen in SLAAC with a non 64bit IID would be
changes downstream rather than upstream.  I can say however that such a
change could also accommodate the upstream; if the RA from PGW ('P'
Gateway in 3GPP network) contained a /56, and if we didnt want to create
a new option in RA, then it would be necessary to use an IID of length
72.  At which point operators might complain about a 'race to the up' if
I can say so.

It might be that after many efforts, discussion, software written,
trials, some people tend to conclude that changes in the 3GPP iface to
mobile are hardly feasible with respect to that /64.  Weird it is, I agree.

Alex

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 23 Nov 2020 22:18:20 +0000

From: ipv6 <[email-masked]> On Behalf Of Gyan Mishra

> How do we propose to solve this problem if operators don’t support PD even though the  3GPP standard has supported PD for over 10 years.

Maybe I've missed this detail in the thread. Are you saying that Android would be happy to tether downstream devices will a longer prefix, and support SLAAC with different length IIDs, but not happy to accept shorter prefixes from upstream? Or is this your suggestion, which assumes that Android will forever oppose receiving anything other than /64s?

Seems to me that accepting /56 or /48s should be an easier upgrade, and create a lot less commotion in the IETF, at this time.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Nov 2020 10:26:02 +0900

I don't think anyone ever said Android will not support DHCPv6 PD. That
said, implementing DHCPv6 PD on cellular is difficult for technical
reasons, including:

   - There is no DHCPv6 PD implementation in Android, so one would need to
   be written.
   - The natural place for such an implementation is in the IpClient code,
   which does not (yet?) run on cellular networks.

Something like the new RA option proposed in the 64share v2 thread (+Cameron
Byrne <[email-masked]>) - assuming it gains consensus - would be much
easier to implement.

As an alternative: it's possible to extend the Android telephony HAL to
allow the baseband to return a delegated prefix as well as the
directly-connected route. That way, if a modem vendor (e.g., Qualcomm,
Mediatek, ...) implements DHCPv6 PD in baseband-dependent code (which is
not part of the Android OS), it can simply pass up the prefix through the
HAL and the OS can use it.

As we know, DHCPv6 PD has been mentioned in 3GPP standards for several
releases. Are there any 3GPP specs on how prefix delegation should be used?
Are there any requirements that might simplify the implementation? For
example, a requirement that the delegated prefix may not change for the
lifetime of the session, and that its lifetime is infinite, would be
consistent with the 3GPP requirements around RAs, and would substantially
simplify implementation.

On Mon, Nov 23, 2020 at 4:44 PM Gyan Mishra <[email-masked]> wrote:

> I researched Apple which has 10% of the market and they also do not
> support PD.
>
> Whats the solution now?
> --
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 23 Nov 2020 22:32:32 -0800

<no hats>

There have been, I think, 2-4 (more?) ND-based PD or PD-like
proposals.  The main argument against ND-PD, as I recall from PIO-X
days, has been "we have DHCPv6 PD, ND PD will have to replicate most
of the same semantics, why do we need two ways to do this?"

If, on the other hand, we are to understand that 3GPP operators are
just not deploying DHCPv6 PD (for whatever reason), then I think a
reasonable argument can be made that "we wouldn't have two, because we
currently have zero."

If the above is true, I, for one, would be interested to evaluate a
simple, clean draft that did things like:

    [1] define a PDIO, and its use in RAs and RSes (for requesting a
prefix length or refreshing/requesting a previously delegated prefix),

    [2] define the scope of applicability (i.e. in contexts where it
can be guaranteed that only one client will receive the RA),

    [3] did not make unnecessary reference to link technologies,
mobility architectures, or the like (just define the generic
deployment requirements, however they may be met),

    [4] did not try to make other unrelated changes (like redoing the
/64 SLAAC boundary; residential PD has been working fine for a while)
and

    [5] define the relationship to any PIOs present (i.e. a PDIO that
covers or equals a PIO with L=0 can inform the client that it's in an
RFC 8273-style environment whereas L=1 indicates an RFC 6603
situation).

I think it's possible to over-complicate the work, but if the
deployment requirements are well-scoped I think it could be fairly
clean and simple.

On Mon, Nov 23, 2020 at 5:27 PM Lorenzo Colitti
<lorenzo=[email-masked]> wrote:
>
> I don't think anyone ever said Android will not support DHCPv6 PD. That said, implementing DHCPv6 PD on cellular is difficult for technical reasons, including:
>
> There is no DHCPv6 PD implementation in Android, so one would need to be written.
> The natural place for such an implementation is in the IpClient code, which does not (yet?) run on cellular networks.
>
> Something like the new RA option proposed in the 64share v2 thread (+Cameron Byrne) - assuming it gains consensus - would be much easier to implement.
>
> As an alternative: it's possible to extend the Android telephony HAL to allow the baseband to return a delegated prefix as well as the directly-connected route. That way, if a modem vendor (e.g., Qualcomm, Mediatek, ...) implements DHCPv6 PD in baseband-dependent code (which is not part of the Android OS), it can simply pass up the prefix through the HAL and the OS can use it.
>
> As we know, DHCPv6 PD has been mentioned in 3GPP standards for several releases. Are there any 3GPP specs on how prefix delegation should be used? Are there any requirements that might simplify the implementation? For example, a requirement that the delegated prefix may not change for the lifetime of the session, and that its lifetime is infinite, would be consistent with the 3GPP requirements around RAs, and would substantially simplify implementation.
>
>> Another twist to this puzzle is Android has 90% of the mobile handset marketplace worldwide and adamantly states they will NOT support DHCPv6 or PD.
>>
>> I researched Apple which has 10% of the market and they also do not support PD.
>>
>> Whats the solution now?
>> --
>>
>>
>> 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
> --------------------------------------------------------------------

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 Nov 2020 12:56:25 +0100

> days, has been "we have DHCPv6 PD, ND PD will have to replicate
> most of the same semantics, why do we need two ways to do this?"
> 
> If, on the other hand, we are to understand that 3GPP operators
> are just not deploying DHCPv6 PD (for whatever reason), then I
> think a reasonable argument can be made that "we wouldn't have two,
> because we currently have zero."

We are creating 2 mechanisms, the fact that the mobile world doesn't use
it doesn't remove DHCP PD from the 3GPP standards.

Is there any guarantee that the mobile world will implement this new option
or will we be back here in a couple of years with the same discussion? I.e.,
if we do a new option when will it be part of 3GPP specs, when will routers
support it, when will telco's update routers and roll out this feature. When
will handset support it, etc.

That said, it seems to me that by and large DHCPv6 PD is the wrong model for
many of our current use cases. So if we can come up with something better,
then it is reasonable to have a newer mechanism that is better.

> If the above is true, I, for one, would be interested to evaluate
> a simple, clean draft that did things like:
> 
>     [1] define a PDIO, and its use in RAs and RSes (for requesting
>     a prefix length or refreshing/requesting a previously delegated
> prefix),

Yes

>     [2] define the scope of applicability (i.e. in contexts where
>     it can be guaranteed that only one client will receive the RA),

We may need to do the work in two steps. One is something that works only
links that are hardwired point-to-point such as ppp.

A second step would be to include point-to-point ethernet links.

> deployment requirements, however they may be met),

Indeed.

>     [4] did not try to make other unrelated changes (like redoing
>     the /64 SLAAC boundary; residential PD has been working fine
> for a while) and

Yes.

>     [5] define the relationship to any PIOs present (i.e. a PDIO
>     that covers or equals a PIO with L=0 can inform the client that
> it's in an RFC 8273-style environment whereas L=1 indicates an RFC
> 6603 situation).

I think we should be explicit. If part of the prefix is not avaiable then
there should be a field in the PDIO that says so. 

> deployment requirements are well-scoped I think it could be fairly

The hard part is coming up with a model such that we don't have to write
a series of drafts on how to deal with operational issues (such as
renumbering) as few years later.

I.e., the DHCPv6 PD model doesn't work for many cases, what model do we
agree on that does work.

---

From: [email-masked]
Date: Tue, 24 Nov 2020 13:17:24 +0100

Hi Erik, et al,

> deployment requirements are well-scoped I think it could be fairly

I come to realise something and I want to hear if others agree.

The 3GPP model is in may ways very similar to the model I described in P2P Ethernet.
It's not traditional address assignment happening on that link. The upstream router does not have a connected route and glean adjacency (address resolution required) towards the host.

When a RA with a /64 PIO is sent and the mobile terminal does tethering, it's much more like prefix delegation of that /64.

In a traditional RA+PIO with L=1, the router states:
 This prefix is directly connected between us and requires address resolution.
 If A=1 && plen == 64 you can generate an address from this prefix.

In the P2P Ethernet/3GPP case it says:
 This prefix is not used on the link between us.
 The prefix is dedicated to you, and I promise to install a route like:
  ipv6 route <prefix> p2p-interface | interface, NH pointing at you.
 You can if you like configure an address on the interface on the upstream link,
 as the router will forward traffic to anything in that prefix blindly.
 (you aren't strictly doing SLAAC at that point though.)

In the latter case the prefix-length can be <1-128>.

Now, if someone else could more succinctly express that difference...

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Nov 2020 22:01:16 +0900

> will handset support it, etc.

As for handset support: as I said, at least on Android such an option would
be easier to implement than DHCPv6 PD.

I don't know how easy it would be to get it into 3GPP implementations. +Cameron
Byrne <[email-masked]> +Gyan Mishra <[email-masked]>, do you
know? Is such a new RA option something that could happen via a feature
request to 3GPP equipment vendors, or would it require a year-long process
of revving the 3GPP specs and waiting for vendors to pick up the new 3GPP
release?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 24 Nov 2020 14:18:13 +0100 (CET)

> The 3GPP model is in may ways very similar to the model I described in P2P Ethernet.

The 3GPP model is almost identical to PPP, HDLC, ATM, IPIP or whatever 
that doesn't have an ethernet header and isn't a broadcast medium.

> Now, if someone else could more succinctly express that difference...

I don't think it should be inferred by the link type, I think similar to 
PIO-X it should be explicit. For broadcast media we put in some 
constraints, but there it gets more complicated. If we could start 
defining the "hey, I routed the entire PIO to you" somehow for P2P then we 
could continue with that for broadcast medium in a follow-up RFC.

For reference:

https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-02

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 Nov 2020 16:57:39 +0100

Le 24/11/2020 à 07:32, Erik Kline a écrit :
> reasonable argument can be made that "we wouldn't have two, because
> we currently have zero."
> 
> [2] define the scope of applicability (i.e. in contexts where it can
> be guaranteed that only one client will receive the RA),

[2.1] - the option should be implemented on as many as possible
platforms, before proceeding.  Android is a perfect candidate, but there
are more platforms different than Android that use same networks as
Android does - e.g. 'IoT routers' - who also need such option.

> [3] did not make unnecessary reference to link technologies, mobility
> architectures, or the like (just define the generic deployment
> requirements, however they may be met),
> 
> [4] did not try to make other unrelated changes (like redoing the /64
> SLAAC boundary; residential PD has been working fine for a while) 
> and
> 
> covers or equals a PIO with L=0 can inform the client that it's in
> an RFC 8273-style environment whereas L=1 indicates an RFC 6603 
> situation).

[5.1] - define whether or not this option is used to form an address on
the receiving interface.  Define whether or not this option must
be accompanied by a regular PIO.  Consider the consideration of the
reduction of numbers of bytes on wireless links.  Consider whether or 
not the use of this option implies that more other messages must be sent 
on the link.

[5.2] - define the additional security implications of using the new option.

> deployment requirements are well-scoped I think it could be fairly 

It is a good goal.

Alex

.
>> I don't think anyone ever said Android will not support DHCPv6 PD.
>> That said, implementing DHCPv6 PD on cellular is difficult for
>> technical reasons, including:
>> 
>> There is no DHCPv6 PD implementation in Android, so one would need
>> to be written. The natural place for such an implementation is in
>> the IpClient code, which does not (yet?) run on cellular networks.
>> 
>> Something like the new RA option proposed in the 64share v2 thread
>> (+Cameron Byrne) - assuming it gains consensus - would be much
>> easier to implement.
>> 
>> As an alternative: it's possible to extend the Android telephony
>> HAL to allow the baseband to return a delegated prefix as well as
>> the directly-connected route. That way, if a modem vendor (e.g.,
>> Qualcomm, Mediatek, ...) implements DHCPv6 PD in baseband-dependent
>> code (which is not part of the Android OS), it can simply pass up
>> the prefix through the HAL and the OS can use it.
>> 
>> As we know, DHCPv6 PD has been mentioned in 3GPP standards for
>> several releases. Are there any 3GPP specs on how prefix delegation
>> should be used? Are there any requirements that might simplify the
>> implementation? For example, a requirement that the delegated
>> prefix may not change for the lifetime of the session, and that its
>> lifetime is infinite, would be consistent with the 3GPP
>> requirements around RAs, and would substantially simplify
>> implementation.
>> 
>>> How do we propose to solve this problem if operators don’t
>>> support PD even though the  3GPP standard has supported PD for
>>> over 10 years.
>>> 
>>> Whats the solution now? --
>>> 
>>> 
>>> Gyan Mishra
>>> 
>>> M 301 502-1347 13101 Columbia Pike Silver Spring, MD
>>> 
>>> 
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 24 Nov 2020 18:00:38 +0100

Le 24/11/2020 à 13:17, [email-masked] a écrit :
[...]
> I come to realise something and I want to hear if others agree.

Since publication I wondered whether P2P Ethernet is an L2TP 'in 
disguise'?  I mean, If I understand correctly, L2TP is used in 
residential networks much how the P2P Ethernet seems to be assumed to 
work on a cellular link: a ptp link whose interfaces are highly like 
Ethernet.

> It's not traditional address assignment happening on that link. The upstream router does not have a connected route
> and glean adjacency (address resolution required) towards the host.
> 

I cant express it more succinctly.

The difference between 'assigning a prefix to a link' and 'allocating a
prefix to a Host' depends on the nexthop presence and the kind of iface
in the routing table entry.

In the simplest linuces, three alternate forms of entries in the routing
table are possible:

(1) nexthop '*'        | kind of iface 'Ethernet'
(2) nexthop '*'        | kind of iface 'ptp'
(3) nexthop IP-of-Host | kind of iface 'Ethernet' or 'ptp'
(assume a prefix/plen in each entry)

In the first form, a Gateway 'assigns' that prefix on that link.  The
Host can form an address within that prefix, but packets whose dst is
some address within that prefix might not reach that Host, because other
Host might have it, and because ND would kick in and resolve to that
other Host's IP address; ND is used because there is no nexthop.  This
is the typical Ethernet.  This is called 'connected' route, I think, on
Cisco.

In the second form, a Gateway 'assigns' the prefix to that link, and
also 'delegates' the prefix to the Host.  Packets whose dst is any
address prefixed by that prefix will be transmitted to that Host,
because ND is not used on ptp links, because even if there is no
nexthop, the 'ptp' is exceptional; 'ptp' means no ND because there are
always two neighbors that know each other very well.

In the third form, a Gateway 'delegates' the prefix to the Host but does
not 'assign' it on the link.  The Host cant form an address out of that
prefix on the receiving interface.  That prefix is not assigned to that
link.  But packets addressed to any address prefixed by that prefix are
indeed forwarded to the Host, because ND is not used here because there
is a next-hop.

In summary:
       Assign to link     Delegate to Host
(1)         x
(2)         x                   x
(3)                             x

Alex