Subject: DHCPv6-PD is fine

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

DHCPv6-PD is fine - especially for mobiles - so, please stop spreading FUD.
In OMNI in particular, we have two modes of prefix registration for mobiles:
1) Static configuration, 2) DHCPv6-PD - with both methods being driven by
RS/RA. We have used both methods for many years for prefixes lengths
in the /56 to /64 range, and I see no reason to get dragged into arguments
about longer lengths which is a completely different discussion.

Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 Nov 2020 17:41:00 +0100

> about longer lengths which is a completely different discussion.

Fred, maybe people in the aviation can deploy their own ground networks 
to accomodate planes with OMNI interfaces.  At that point it is easy to 
say DHCPv6-PD is fine.

But in other places, automobiles for example, one must use the existing 
cellular networks.  DHCPv6-PD is not fine there.  It's not FUD.

This discussion has become so complicated that it seems to me impossibly 
complex to come up with something that satisfies even a minority.

OMNI and DHCPv6-PD, Ethernet P2P, Variable SLAAC, 464XLAT, Mobile IPv6 
with NEMO extensions, and others - are each a potential solution to some 
environment.

Alex

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

---

From: Simon Hobson <[email-masked]>
Date: Mon, 9 Nov 2020 17:15:28 +0000

Alexandre Petrescu <[email-masked]> wrote:

> But in other places, automobiles for example, one must use the existing cellular networks.  DHCPv6-PD is not fine there.  It's not FUD.

Just to clarify ...
From what I've been reading in this thread, in the mobile world the problem isn't DHCPv6-PD, but the cellular world having not adopted it, or even blocked it (ref discussion of mobile modems blocking DHCP packets).

For clarity, is there a problem with DHCPv6-PD, or is there a problem with the mobile world not supporting it for whatever reason ?

The reason I ask is that if it's the latter, then the response to "it doesn't work, we need to change something" is that you need to go to the mobile industry and tell them to fix their ****.

My 2d worth, Simon

---

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

Simon, if it would interest you please have a look at the DHCPv6-PD method
outlined in the OMNI draft. It is more accurately called "proxy-DHCPv6" in that
the mobile (aka Client) does not issue traditional DHCPv6 Solicit, etc. but rather
only issues RS. The access router that receives the RS then acts as a "proxy" to
speak to the DHCPv6 server on the Client's behalf, then returns prefix info in
a responsive RA message.

Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Simon Hobson
> Sent: Monday, November 09, 2020 9:15 AM
> To: 6man <[email-masked]>
> Subject: Re: DHCPv6-PD is fine
> 
> From what I've been reading in this thread, in the mobile world the problem isn't DHCPv6-PD, but the cellular world having not
> adopted it, or even blocked it (ref discussion of mobile modems blocking DHCP packets).
> 
> The reason I ask is that if it's the latter, then the response to "it doesn't work, we need to change something" is that you need to go to
> the mobile industry and tell them to fix their ****.
> 
> My 2d worth, Simon
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 9 Nov 2020 17:38:55 +0000

> From what I've been reading in this thread, in the mobile world the problem
> isn't DHCPv6-PD, but the cellular world having not adopted it, or even
> blocked it (ref discussion of mobile modems blocking DHCP packets).
> 
> For clarity, is there a problem with DHCPv6-PD, or is there a problem with the
> mobile world not supporting it for whatever reason ?
> 
> The reason I ask is that if it's the latter, then the response to "it doesn't work,
> we need to change something" is that you need to go to the mobile industry
> and tell them to fix their ****.
> 
> My 2d worth, Simon

Please don't take this personally, but, IMO, this is exactly the attitude that has
brought us to this point. The IETF participants think IETF is in a position to dictate 
and think they know better how to operate and deploy a network than the
operators. Availability of equipment that implements features, complexity
of legacy OSS/BSS systems, and complexity of deploying multiple methods
of configuration (to make everyone happy) are 100% irrelevant and operators
should simply spend whatever amount is needed to do exactly what IETF dictates.

I've suggested engaging and collaborating with other SDOs where operators
prefer to do their work. But that suggestion clearly has no support here.
Barbara

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Nov 2020 19:54:18 +0100

> Please don't take this personally, but, IMO, this is exactly the
> attitude that has brought us to this point. The IETF participants
> think IETF is in a position to dictate and think they know better
> how to operate and deploy a network than the operators. 

To turn this around. There is at the moment no draft from the mobile world
on how they are going to provide mobile devices with prefixes that are 
shorter than 64 bits.

Instead, the expectation in this discussion is every vendor of every device in
the world has to change the device to accommodate the failure of the
mobile world to provide suitable prefixes. This also means that every 
installed device has to get an upgrade or become obsolete.

This is how operators run a substandard network and push to cost to everybody
else.

Of course, lots of operators like to run a network on the cheap. But few are
in a position to let the rest of the world pay the cost.

---

From: "tony.whyman" <[email-masked]>
Date: Mon, 09 Nov 2020 19:16:39 +0000

Fred,We should clarify that while OMNI may include DHCPv6 PD, that is for general use. Civil Aviation is using static MNP assignment and is only interested in MNP confirmation using the LLA convention.TonySent from my Samsung Galaxy smartphone.
-------- Original message --------From: Alexandre Petrescu <[email-masked]> Date: 09/11/2020  16:41  (GMT+00:00) To: [email-masked] Subject: Re: DHCPv6-PD is fine Le 09/11/2020 à 17:32, Templin (US), Fred L a écrit :> DHCPv6-PD is fine - especially for mobiles - so, please stop spreading FUD.> In OMNI in particular, we have two modes of prefix registration for mobiles:> 1) Static configuration, 2) DHCPv6-PD - with both methods being driven by> RS/RA. We have used both methods for many years for prefixes lengths> in the /56 to /64 range, and I see no reason to get dragged into arguments> about longer lengths which is a completely different discussion.Fred, maybe people in the aviation can deploy their own ground networks to accomodate planes with OMNI interfaces.  At that point it is easy to say DHCPv6-PD is fine.But in other places, automobiles for example, one must use the existing cellular networks.  DHCPv6-PD is not fine there.  It's not FUD.This discussion has become so complicated that it seems to me impossibly complex to come up with something that satisfies even a minority.OMNI and DHCPv6-PD, Ethernet P2P, Variable SLAAC, 464XLAT, Mobile IPv6 with NEMO extensions, and others - are each a potential solution to some environment.Alex> > Fred> --------------------------------------------------------------------> IETF IPv6 working group mailing list> [email-masked]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6> --------------------------------------------------------------------> --------------------------------------------------------------------IETF IPv6 working group mailing [email-masked] Requests: https://www.ietf.org/mailman/listinfo/ipv6--------------------------------------------------------------------

---

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

Tony,

>We should clarify that while OMNI may include DHCPv6 PD, that is for general use.
>Civil Aviation is using static MNP assignment and is only interested in MNP confirmation
>using the LLA convention.

Yes, that is a very good point and I tried to highlight that in my initial message
when I said: “In OMNI in particular, we have two modes of prefix registration
for mobiles:  1) Static configuration, 2) DHCPv6-PD”. What you are saying above
fits with option 1) Static configuration, and for Civil Aviation where the aircraft
has a uniquely-assigned MNP you are right that this will be the method used.
However, for non-aircraft users that do not have a pre-assigned MNP option
2) DHCPv6-PD may be the only option.

So, you are correct in what you are saying, yes – but I believe a complete
solution needs to support both options.

Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of tony.whyman
Sent: Monday, November 09, 2020 11:17 AM
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: DHCPv6-PD is fine

Fred,

We should clarify that while OMNI may include DHCPv6 PD, that is for general use. Civil Aviation is using static MNP assignment and is only interested in MNP confirmation using the LLA convention.

Tony

Sent from my Samsung Galaxy smartphone.

-------- Original message --------
From: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Date: 09/11/2020 16:41 (GMT+00:00)
To: [email-masked]<mailto:[email-masked]>
Subject: Re: DHCPv6-PD is fine

Alex

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

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

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 09 Nov 2020 22:00:35 +0100 (CET)

>> From what I've been reading in this thread, in the mobile
>> world the problem isn't DHCPv6-PD, but the cellular world
>> having not adopted it, or even blocked it (ref discussion of
>> mobile modems blocking DHCP packets).

Is this lack of flexibility for all intents and purposes
imprinted into silicon?  That would ... be an extremely effective
road-block for practical deployment if one wanted to make a
change where DHCP should additionally be used.

>> For clarity, is there a problem with DHCPv6-PD, or is there a
>> problem with the mobile world not supporting it for whatever
>> reason ?
>>
>> The reason I ask is that if it's the latter, then the response
>> to "it doesn't work, we need to change something" is that you
>> need to go to the mobile industry and tell them to fix their
>> ****.
>
> Please don't take this personally, but, IMO, this is exactly
> the attitude that has brought us to this point. The IETF
> participants think IETF is in a position to dictate and think
> they know better how to operate and deploy a network than the
> operators.

An alternative perspective could be that the mobile industry
collectively refused to cooperate for "whatever reason", and now
come back at the IETF without in detail explaining why DHCPv6-PD
"didn't work out", but instead want new protocol development to
essentially solve the same problem in another manner, using a
different protocol?  We all here know how enthusiastic the IETF
is in solving the same problem with multiple protocols, ref. the
long-standing controversy over address configuration in IPv6.

Also, I don't think it's entirely unreasonable to claim that the
IETF controls the development and standardization of Internet
protocols done through the IETF?

> Availability of equipment that implements features, complexity
> of legacy OSS/BSS systems, and complexity of deploying multiple
> methods of configuration (to make everyone happy) are 100%
> irrelevant and operators should simply spend whatever amount is
> needed to do exactly what IETF dictates.

Now, now...  Imagine for a moment that a new protocol or protocol
variant was developed and standardized through the IETF for
handing out larger address blocks to customers.  How would
deploying that imagined new protocol be any easier with respect
to the above mentioned complexities or obstacles than doing the
same with an already standardized protocol?  (However, if DHCP is
in essence "blocked by hardware", that makes that avenue for all
intents and purposes unusable in that particular use case.  Not
sure I'd blame the IETF for that one, though.)

Or .. I may not understand what you are saying here. Are you
implicitly saying that "This isn't a problem worth solving" or
"This problem costs too much to solve now"?  I think I'm
confused.

> I've suggested engaging and collaborating with other SDOs where
> operators prefer to do their work. But that suggestion clearly
> has no support here.

Building organizational-level collaboration and the needed mutual
respect, and overcoming the obvious cultural impedance mismatch
is decidedly a two-way street.  I'm not sure it's fair to put all
the blame on the IETF here.

Regards,

- Håvard

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Nov 2020 16:23:04 -0500

> change where DHCP should additionally be used.

I’m having trouble envisioning how this would even be possible. Is there an IP stack on the chip that has a firewall in it that blocks DHCP? This woud be surprising. Why would they go to that effort?

---

From: Havard Eidnes <[email-masked]>
Date: Mon, 09 Nov 2020 22:30:47 +0100 (CET)

> I'm having trouble envisioning how this would even be possible.
> Is there an IP stack on the chip that has a firewall in it that
> blocks DHCP? This woud be surprising. Why would they go to that
> effort?

I can't claim first-hand knowledge on that point; someone who has
should speak up.  If I recall correctly the claim made was that it had
to do with the "mobile modem" implementations in common use.

Regards,

- Håvard

---

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

Barbara,

> prefer to do their work. But that suggestion clearly has no support here.

The problem there is what it's always been: the underlying motivations of
SDOs with paid-up membership models are different from the IETF's. The IETF
literally doesn't care about the profit margins of operators; it's perhaps
unintentionally slightly oriented towards the profit margins of vendors.
But "make the Internet work better" and "The Internet is for End Users"
are not in the least oriented towards operators' profit margins.

That really does make for a tussle rather than collaboration. It would be
great to achieve collaboration but I'm not sure how it can be done.

If we can show convincingly that /48 to the end user is good for
the operators' profit margins, that would help.

   Brian

---

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

This is a personal point of view, I am not employed at manufacturer or
operator.

Le 09/11/2020 à 22:23, Ted Lemon a écrit :
> On Nov 9, 2020, at 4:00 PM, Havard Eidnes 
> <he=[email-masked] 
> <mailto:he=[email-masked]>> wrote:
>> Is this lack of flexibility for all intents and purposes imprinted 
>> into silicon?  That would ... be an extremely effective road-block 
>> for practical deployment if one wanted to make a change where DHCP 
>> should additionally be used.
> 
> I’m having trouble envisioning how this would even be possible. Is 
> there an IP stack on the chip that has a firewall in it that blocks 
> DHCP?

Yes.

> This woud be surprising.

YEs to me too it was surprising to see how many things these modems do.

I was surprised first when my laptop sent a DHCP request, received an
answer, but the operator told me they did not receive such a request and
they did not generate an answer either.  It's because there was a DHCP
proxy in between that I could not see.  It's on the modem.

There is a whole operating system running in modern modems of
smartphones.  They have their own IP addresses inside.  Some times they
even run DHCP servers inside.

Looking at the open source efforts to make an OS for these modems it is
possible to get a hint of how advanced they are.  IIRC one is called
Hexagon MiniVM.

> Why would they go to that effort?

In order to protect (some humans at some computers at some) operator.

The legislation requests that the owner of a smartphone has access to
that smartphone, i.e. to log in and install whatever s/he wishes; as a
side note this is different than CPEs where the legislation only
requests the GPLed source codes of CPE to be made available upon request.

On these smartphones, a malicious user might install malicious software
that could attack the (~) operator.  Other than outright vicious attacks
some programmers might want to play with a home made DHCP client on the
ARM part of the smartphone (not the modem).  That client would disrupt
functioning of the already exisitng DHCP server running in the modem.  I
suspect that is why smartphone manufacturer, under guidance of modem
manufacturer and in agreement with (~) operator, effectively block UDP
port numbers of DHCPv6.  They block other people's DHCP and let only
their own non-documented variant of DHCP proxy through.

That is my supposition, or rather a speculation.  It means that I might 
be wrong.  But that does not improve the situation of absence of 
DHCPv6-PD in smartphones.

Alex

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 10 Nov 2020 12:16:40 +0000

The less tethering - the more additional SIMs and Modems to sell.
Blocking DHCP PD is the revenue generating technology.
Is it by coincidence?

If you would split /64 on /66 - would it resolve the root cause?
Are you trying to undermine additional revenue stream?
Ed/
> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: 10 ноября 2020 г. 13:21
> To: [email-masked]
> This is a personal point of view, I am not employed at manufacturer or operator.
> 
> >>>> From what I've been reading in this thread, in the mobile world the
> >>>> problem isn't DHCPv6-PD, but the cellular world having not adopted
> >>>> it, or even blocked it (ref discussion of mobile modems blocking
> >>>> DHCP packets).
> >>
> I was surprised first when my laptop sent a DHCP request, received an answer,
> but the operator told me they did not receive such a request and they did not
> generate an answer either.  It's because there was a DHCP proxy in between
> that I could not see.  It's on the modem.
> 
> There is a whole operating system running in modern modems of smartphones.
> They have their own IP addresses inside.  Some times they even run DHCP
> servers inside.
> 
> possible to get a hint of how advanced they are.  IIRC one is called Hexagon
> MiniVM.
> 
> The legislation requests that the owner of a smartphone has access to that
> smartphone, i.e. to log in and install whatever s/he wishes; as a side note this is
> different than CPEs where the legislation only requests the GPLed source codes
> of CPE to be made available upon request.
> 
> On these smartphones, a malicious user might install malicious software that
> could attack the (~) operator.  Other than outright vicious attacks some
> programmers might want to play with a home made DHCP client on the ARM
> part of the smartphone (not the modem).  That client would disrupt functioning
> of the already exisitng DHCP server running in the modem.  I suspect that is why
> smartphone manufacturer, under guidance of modem manufacturer and in
> agreement with (~) operator, effectively block UDP port numbers of DHCPv6.
> They block other people's DHCP and let only their own non-documented variant
> of DHCP proxy through.
> 
> That is my supposition, or rather a speculation.  It means that I might be wrong.
> But that does not improve the situation of absence of DHCPv6-PD in
> smartphones.
> 
> Alex
> 
> >

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 17:27:42 +0100

Le 10/11/2020 à 13:16, Vasilenko Eduard a écrit :
> Blocking DHCP PD is the revenue generating technology. Is it by 
> coincidence?

One might be tempted to think along these lines yes.  But.

> If you would split /64 on /66 - would it resolve the root cause? Are
>  you trying to undermine additional revenue stream?

I am not sure the question is asked rhetorically?

Anyways, there are many new ways in which to generate new revenue
streams for cellular networks.  6G is one if I had to mention but one.

The mobile WiFi hotspots sold by cellular operators are other examples:
that single SIM accomodating multiple WiFi devices is generating
additional revenue streams from selling a device which is an additional
SIM card for an owner who already owns a SIM card in a personal smartphone.

The Tesla cars whose cellular plans are pre-paid entirely to mobile
operators all over the world are another example of new revenue streams
which still use one SIM card per a group of devices in the car.
Moreover, many drivers plug their SIM-enabled smartphones on these new
car's dashboards, effectively bringing in multiple SIM cards and
computers in the car.

Overall, I dont think there is any reduction in revenue stream provoked
by extending the network. The value of the network might grow with its
size, is said, and I agree.

Alex

> Ed/
>> -----Original Message----- From: ipv6 
>> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu 
>> Sent: 10 ноября 2020 г. 13:21 To: [email-masked] Subject: Re: 
>> DHCPv6-PD is fine
>> 
>>>>>> having not adopted it, or even blocked it (ref discussion 
>>>>>> of mobile modems blocking DHCP packets).
>>>> 
>>>> imprinted into silicon?  That would ... be an extremely 
>>>> effective road-block for practical deployment if one wanted to
>>>>  make a change where DHCP should additionally be used.
>>> 
>>> I’m having trouble envisioning how this would even be possible. 
>>> blocks DHCP?
>> I was surprised first when my laptop sent a DHCP request, received
>>  an answer, but the operator told me they did not receive such a 
>> request and they did not generate an answer either.  It's because 
>> there was a DHCP proxy in between that I could not see.  It's on 
>> the modem.
>> 
>> smartphones. They have their own IP addresses inside.  Some times 
>> they even run DHCP servers inside.
>> 
>> Looking at the open source efforts to make an OS for these modems 
>> it is possible to get a hint of how advanced they are.  IIRC one is
>> called Hexagon MiniVM.
>> 
>> The legislation requests that the owner of a smartphone has access
>>  to that smartphone, i.e. to log in and install whatever s/he 
>> wishes; as a side note this is different than CPEs where the 
>> legislation only requests the GPLed source codes of CPE to be made
>>  available upon request.
>> 
>> On these smartphones, a malicious user might install malicious 
>> software that could attack the (~) operator.  Other than outright 
>> vicious attacks some programmers might want to play with a home 
>> made DHCP client on the ARM part of the smartphone (not the modem).
>> That client would disrupt functioning of the already exisitng DHCP
>> server running in the modem.  I suspect that is why smartphone
>> manufacturer, under guidance of modem manufacturer and in agreement
>> with (~) operator, effectively block UDP port numbers of DHCPv6.
>> They block other people's DHCP and let only their own 
>> non-documented variant of DHCP proxy through.
>> 
>> That is my supposition, or rather a speculation.  It means that I 
>> might be wrong. But that does not improve the situation of absence
>>  of DHCPv6-PD in smartphones.
>> 
>> Alex
>> 
>>>