Subject: [dhcwg] DHCPv6 and IPv6ND

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Nov 2017 03:46:28 +0000

Hi,

I have been using DHCPv6 PD for a long time to get delegated prefixes on
devices like Android handsets. But, I am troubled by the fact that I need to
also do RS/RA in order to get default router lifetimes and other information
specific to the link in addition to the DHCPv6 Solicit/Reply.

If my DHCPv6 server will always be on the same router that will serve as my
default router, is there any way to get DHCPv6 to also provide the information
normally conveyed in RAs? For example, define a new DHCPv6 option that
embeds an IPv6 ND RA?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 13:42:13 +0800

> normally conveyed in RAs? For example, define a new DHCPv6 option that

This would be something to bring up in 6man.   Because why not discuss it one more time...?   :]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Nov 2017 06:20:18 +0000

Hi Ted,

I don't want to perpetuate the endless debate going on over there, but I
think I have a fair question. How can we get the functionality of IPv6ND
RA and DHCPv6 PD in a single request/response message exchange?

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, November 13, 2017 9:42 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 and IPv6ND

On Nov 14, 2017, at 11:46 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
If my DHCPv6 server will always be on the same router that will serve as my
default router, is there any way to get DHCPv6 to also provide the information
normally conveyed in RAs? For example, define a new DHCPv6 option that
embeds an IPv6 ND RA?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 15:38:49 +0800

On Nov 14, 2017, at 2:20 PM, Templin, Fred L <[email-masked]> wrote:
> I

Right now, you can't.   The question is, why is this a problem?

We've been around on this a lot of times.   I don't see any reason to do it again.   But if you want to do it, you need to say why it's a problem that you have to do router discovery, why it's better to configure the DHCP server with router topology information, how you're going to get the right router link-local address to send, and why all of this complexity is somehow a better solution than router advertisements.

It's not good enough to just say "I'd really rather use DHCPv6 for this, can't we specify that?"

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Nov 2017 09:06:53 +0000

Hi Ted,

The sensitivity I have is for aeronautical data links that have bandwidths south of
1Mbps with some being as low as 32Kbps. I realize that these are marginal even
for running IPv6 in the first place. But, if we are to do IPv6 at all we need to keep
the number of control messages to an absolute minimum. I realize this may not
be as much of a concern for the majority of modern wired-line and wireless links
that we see in the Internet but with the airplanes we don't have that luxury.

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, November 13, 2017 11:39 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 and IPv6ND

On Nov 14, 2017, at 2:20 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I
think I have a fair question. How can we get the functionality of IPv6ND
RA and DHCPv6 PD in a single request/response message exchange?

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 14 Nov 2017 18:23:47 +0900

Templin, Fred L wrote:

> But, if we are to do IPv6 at all we need to keep
> that we see in the Internet

It is a concern for Wifi links.

http://standards.ieee.org/news/2017/ieee_802.11.html
IEEE 802.11ai addresses challenges where a large number of mobile users 
are continually entering and leaving an existing extended service set 
(ESS) coverage area. The amendment provides scalability for a high 
number of users simultaneously entering an ESS, minimizes time spent 
initializing a link, and provides secure authentication. In effect, IEEE 
802.11ai significantly improves user connectivity in high-density 
environments, such as arenas, stadiums, airports, shopping malls, etc., 
as well as for automotive systems, allowing for a more secure and 
reliable connection, and enabling more efficient spectrum use by 
optimizing the protocol overhead in high-density user environments.

					Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 18:44:04 +0800

Okay. How is this problem currently addressed on llns?

On Nov 14, 2017 17:07, "Templin, Fred L" <[email-masked]> wrote:

> that we see in the Internet but with the airplanes we don’t have that
> luxury.
>
>
>
> Thanks - Fred
>
>
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Monday, November 13, 2017 11:39 PM
> *To:* Templin, Fred L <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [dhcwg] DHCPv6 and IPv6ND
>
>
>
> We've been around on this a lot of times.   I don't see any reason to do
> it again.   But if you want to do it, you need to say why it's a problem
> that you have to do router discovery, why it's better to configure the DHCP
> server with router topology information, how you're going to get the right
> router link-local address to send, and why all of this complexity is
> somehow a better solution than router advertisements.
>
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 15:30:30 +0100

Le 14/11/2017 à 08:38, Ted Lemon a écrit :
> On Nov 14, 2017, at 2:20 PM, Templin, Fred L <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> I
> that you have to do router discovery, why it's better to configure the 
> DHCP server with router topology information, how you're going to get 
> the right router link-local address to send, and why all of this 
> complexity is somehow a better solution than router advertisements.

Ted,

The combined use of DHCPv6 and SLAAC is an unsolved problem in cellular 
networks.  Add to that the implications of the use of an undocumented 
link-layer setup protocol ("PDP") in the address formation.

A second aspect is that for full configuration one must use both 
DHCPv6-PD and SLAAC.

If we agree to those two points then it's easy to see the consequences 
which go along the lines that Fred proposes.

But if people dont agree DHCPv6 is needed, then it's a waste of time to 
explain.

One could as well go to 3GPP and tell them to offer not only address 
setup in PDP but also prefix delegation.  That may be less time to spend 
than do it at IETF.

Alex

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Nov 2017 22:53:21 +0800

Why is it an unsolved problem?

On Nov 14, 2017 22:30, "Alexandre Petrescu" <[email-masked]>
wrote:

> A second aspect is that for full configuration one must use both DHCPv6-PD
> and SLAAC.
>
> One could as well go to 3GPP and tell them to offer not only address setup
> in PDP but also prefix delegation.  That may be less time to spend than do
> it at IETF.
>
> Alex
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 03:26:07 +0100

Because of many reasons.  The most recent popped up in mail box this 
morning - again has to do with modem and lack of DHCPv6.

But at IETF, do you know whether there is a DHCPv6 Server up?  I would 
like to test Prefix Delegation on "ietf-v6ONLY".

The RA on "ietf-v6ONLY" has bit "Managed address configuration" not set; 
and I can not see any DHCPv6 traffic there.

Alex

Le 14/11/2017 à 15:53, Ted Lemon a écrit :
> On Nov 14, 2017 22:30, "Alexandre Petrescu" 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>         On Nov 14, 2017, at 2:20 PM, Templin, Fred L
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>             I
>         We've been around on this a lot of times.   I don't see any
>         reason to do it again.   But if you want to do it, you need to
>         say why it's a problem that you have to do router discovery, why
>         it's better to configure the DHCP server with router topology
>         information, how you're going to get the right router link-local
>         address to send, and why all of this complexity is somehow a
>         better solution than router advertisements.
> 
> 
>     Ted,
> 
>     The combined use of DHCPv6 and SLAAC is an unsolved problem in
>     cellular networks.  Add to that the implications of the use of an
>     undocumented link-layer setup protocol ("PDP") in the address formation.
> 
>     If we agree to those two points then it's easy to see the
>     consequences which go along the lines that Fred proposes.
> 
>     But if people dont agree DHCPv6 is needed, then it's a waste of time
>     to explain.
> 
>     setup in PDP but also prefix delegation.  That may be less time to
>     spend than do it at IETF.
> 
>     Alex
> 
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/dhcwg>
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dhcwg>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Nov 2017 10:27:57 +0800

On Nov 15, 2017, at 10:26 AM, Alexandre Petrescu <[email-masked]> wrote:
> Because of many reasons.

Can you list some of those reasons?

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 03:33:35 +0100

Le 15/11/2017 à 03:27, Ted Lemon a écrit :
> On Nov 15, 2017, at 10:26 AM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> Because of many reasons.
> 

The raw message from modem manufacturer is "clients at host side can not 
use DHCPv6 to get prefix from MDM [modem], they can use RS/RA to get 
prefix as DHCPv6 functionality is not supported in MDM".

They dont understand that nobody asks them to implement DHCPv6 on the 
modem.  The DHCPv6 happens between ARM and the cellular operator.  Both 
sides are ready, yet the middle (the 'modem') blocks 547.

That's the problem.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Nov 2017 10:49:37 +0800

On Nov 15, 2017, at 10:33 AM, Alexandru Petrescu <[email-masked]> wrote:
> They dont understand that nobody asks them to implement DHCPv6 on the modem.  The DHCPv6 happens between ARM and the cellular operator.  Both sides are ready, yet the middle (the 'modem') blocks 547.
> 
> That's the problem.

I'm confused.   I thought you were saying that we can't do ND, but it sounds like what we can't do is DHCP.   And the reason we can't do it is a misconfigured middlebox, not a protocol issue.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 08:48:45 +0100

Le 15/11/2017 à 03:49, Ted Lemon a écrit :
> On Nov 15, 2017, at 10:33 AM, Alexandru Petrescu 
>> modem.  The DHCPv6 happens between ARM and the cellular operator. 
>>  Both sides are ready, yet the middle (the 'modem') blocks 547.
>>
>> That's the problem.
> 
> I'm confused.   I thought you were saying that we can't do ND, but it 
> sounds like what we can't do is DHCP.   And the reason we can't do it is 
> a misconfigured middlebox, not a protocol issue.

I was saying the DHCPv6+ND is unsolved in cellular.  It is not a 
protocol issue but a hardware problem.

There are protocol solutions to the hardware problems, like ability to 
vary port numbers.

Or we can further wait for hardware issues to be solved, if ever.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Nov 2017 17:07:12 +0800

How can it be a hardware problem?  Bits are bits. Don't you mean "a problem
with software that runs on a particular hardware platform?"

On Nov 15, 2017 15:48, "Alexandre Petrescu" <[email-masked]>
wrote:

>> On Nov 15, 2017, at 10:33 AM, Alexandru Petrescu <
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>> sounds like what we can't do is DHCP.   And the reason we can't do it is a
>> misconfigured middlebox, not a protocol issue.
>>
>
> I was saying the DHCPv6+ND is unsolved in cellular.  It is not a protocol
> issue but a hardware problem.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 10:56:56 +0100

YEs, a problem with software that runs on a particular hardware problem.

Another problem with that software too, is that it is closed source and 
a very high price to buy.  Moreover, it is almost forbidden to modify it 
by other company than the writer.

Very many people were tempted to fix that software but it looks very 
hard to access.

Alex

Le 15/11/2017 à 10:07, Ted Lemon a écrit :
> How can it be a hardware problem?  Bits are bits. Don't you mean "a 
> problem with software that runs on a particular hardware platform?"
> 
> On Nov 15, 2017 15:48, "Alexandre Petrescu" 
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>             They dont understand that nobody asks them to implement
>             DHCPv6 on the modem.  The DHCPv6 happens between ARM and the
>             cellular operator.  Both sides are ready, yet the middle
>             (the 'modem') blocks 547.
> 
>             That's the problem.
> 
> 
>         I'm confused.   I thought you were saying that we can't do ND,
>         but it sounds like what we can't do is DHCP.   And the reason we
>         can't do it is a misconfigured middlebox, not a protocol issue.
> 
> 
>     There are protocol solutions to the hardware problems, like ability
>     to vary port numbers.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Nov 2017 10:01:37 +0000

I don’t see how this is an IETF issue. Push pn the vendor to fix it; or don’t buy it.

- Bernie (from iPhone)

On Nov 15, 2017, at 5:57 PM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

Another problem with that software too, is that it is closed source and a very high price to buy.  Moreover, it is almost forbidden to modify it by other company than the writer.

Very many people were tempted to fix that software but it looks very hard to access.

Alex

How can it be a hardware problem?  Bits are bits. Don't you mean "a problem with software that runs on a particular hardware platform?"
On Nov 15, 2017 15:48, "Alexandre Petrescu" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
       <[email-masked]<mailto:[email-masked]>

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 14:36:02 +0100

I am afraid there is no 3GPP modem for smartphone that lets DHCPv6 through.

Qualcomm blocks multicast UDP 547 whereas Balong blocks multicast 
altogether.

I do need a modem to connect on 4G, LTE-V2X and pre-5G that does let 
DHCPv6 through.

But I would like to ask you: if no such modem exist on the market, why 
not modifying the DHCPv6 protocol to work on non-547 ports and on unicast?

Alex

Le 15/11/2017 à 11:01, Bernie Volz (volz) a écrit :
> On Nov 15, 2017, at 5:57 PM, Alexandre Petrescu 
>> Another problem with that software too, is that it is closed source 
>> and a very high price to buy.  Moreover, it is almost forbidden to 
>> modify it by other company than the writer.
>>
>>> <[email-masked] <mailto:[email-masked]> 
>>> <mailto:[email-masked]>> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Nov 2017 05:02:27 +0800

On Nov 15, 2017, at 9:36 PM, Alexandru Petrescu <[email-masked]> wrote:
> But I would like to ask you: if no such modem exist on the market, why not modifying the DHCPv6 protocol to work on non-547 ports and on unicast?

Hm, well, as a practical matter, you can already do that.   Updating the protocol spec to do that seems bogus, though.   What happens if you just use a different port number on the phone and on the server, and use unicast?

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 05:28:47 +0100

Le 15/11/2017 à 22:02, Ted Lemon a écrit :
> On Nov 15, 2017, at 9:36 PM, Alexandru Petrescu 
>> But I would like to ask you: if no such modem exist on the market, 
>> why not modifying the DHCPv6 protocol to work on non-547 ports and 
>> on unicast?
> 
> Hm, well, as a practical matter, you can already do that.

Yes, I already did that, between a Client and a Server that I can
program.  It works fine.

The problem is when I try my Client talk a Server on an operational
router at operator that router is not configurable with respect to the
DHCPv6 port numbers.  It only listens on 547 and only on multicast.
They have tried to modify the 547 to something else, but that has GUI
problems; the problems are reported to the manufacturer but this latter
has no willingness to fix, because it is not standard.

Momreover, when I say I want something different than 547 and multicast,
the operational router asks for business plan in order to implement
something that is non-standard.  I dont have a business plan, and I dont
want to make one.

> Updating the protocol spec to do that seems bogus, though.   What 
> happens if you just use a different port number on the phone and on 
> the server, and use unicast?

In that case, the full DHCP exchange worked fine.  But the delegated
prefix is literally "2001:db8::/56" - a fake prefix.  It is unknown at
the operator.   The operator does let through the DHCPv6 Advertise that
has that fake prefix inside, but does not set a route for it.

Even when I made my Server to put in DHCPv6 Advertise the prefix that
the operator is supposed to allocate (that prefix has been communicated
by an out-of-band means) the packets that use that prefix in src are not
routed to the Internet, because there is no route for them.

It is the DHCP Server in the operator's network that must put the prefix
in DHCPv6 Advertise; it has to be this way, in order to be able to set
the route accordingly.  It sets it depending on parameters that are
"GTP" parameters, that relate the smartphone to a tunnel.

The DHCP server at operator is there, ready to receive DHCPv6 Solicits,
ready to generate PD messages, ready to give a /56, ready to set routes. 
  But it does not receive my Solicit.

It does not receive my Solicit because a standard Solicit (multicast,
UDP 547) is blocked by modem in smartphone.

Modem in smartphone is produced by many manufactureres.  One of them
(widely used) says they dont want to add DHCPv6 in their modem.  They
dont understand nobody wants them to, and they dont understand they
block 547 and multicast.  My interface to them is through another party.
  I dont have a direct interface to them.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Nov 2017 13:29:38 +0800

I'm having trouble figuring out how changing the port would help.   You'd still have to make the same modifications.   You'd still have to define a business model.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Nov 2017 06:27:56 +0000

Yeah, this all sounds like missing functionality in a product and that isn’t something the IETF can fix or should work around.

- Bernie (from iPhone)

On Nov 16, 2017, at 1:29 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 07:38:15 +0100

Le 16/11/2017 à 06:29, Ted Lemon a écrit :
> I'm having trouble figuring out how changing the port would help.
> You'd still have to make the same modifications.   You'd still have
> to define a business model.

_If_ there is a standard that says port number is variable, and if 
hardware manufacturer implements it, then it will help.

If not, not.

If so, this entire issue about making DHCPv6 work on 3GPP networks 
should be forgotten.   It's impossible to make it work.

That puts the discussion of DHCPv6 and IPv6ND outside the 3GPP context 
altogether.

For the business model: I am not an economist.

Alex

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Nov 2017 14:40:32 +0800

On Nov 16, 2017, at 2:38 PM, Alexandru Petrescu <[email-masked]> wrote:
> If so, this entire issue about making DHCPv6 work on 3GPP networks should be forgotten.   It's impossible to make it work.

It is not impossible.   It is impossible for the IETF.

If you want to define a standard for 3GPP to do DHCP over a different port, that sounds fine.   But it's not an IETF thing—this is a specifically 3GPP problem, and it doesn't make any sense to write an IETF standard to work around it.   Suppose we did so: what advice would we give to implementors?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Nov 2017 06:50:23 +0000

See RFC 6459:

5.3<https://tools.ietf.org/html/rfc6459#section-5.3>.  Prefix Delegation

   IPv6 prefix delegation is a part of Release-10 and is not covered by
   any earlier releases.  However, the /64 prefix allocated for each
   default bearer (and to the UE) may be shared to the local area
   network by the UE implementing Neighbor Discovery proxy (ND proxy)
   [RFC4389<https://tools.ietf.org/html/rfc4389>] functionality.

   The Release-10 prefix delegation uses the DHCPv6-based prefix
   delegation [RFC3633<https://tools.ietf.org/html/rfc3633>].  The model defined for Release-10 requires
   aggregatable prefixes, which means the /64 prefix allocated for the
   default bearer (and to the UE) must be part of the shorter delegated
   prefix.  DHCPv6 prefix delegation has an explicit limitation,
   described in Section 12.1 of [RFC3633]<https://tools.ietf.org/html/rfc3633#section-12.1>, that a prefix delegated to a
   requesting router cannot be used by the delegating router (i.e., the
   PDN-GW in this case).  This implies that the shorter 'delegated
   prefix' cannot be given to the requesting router (i.e., the UE) as
   such but has to be delivered by the delegating router (i.e., the
   PDN-GW) in such a way that the /64 prefix allocated to the default
   bearer is not part of the 'delegated prefix'.  An option to exclude a
   prefix from delegation [PD-EXCLUDE<https://tools.ietf.org/html/rfc6459#ref-PD-EXCLUDE>] prevents this problem.

Perhaps you are on an early Release?

- Bernie (from iPhone)

On Nov 16, 2017, at 2:40 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 16, 2017, at 2:38 PM, Alexandru Petrescu <[email-masked]<mailto:[email-masked]>> wrote:
If so, this entire issue about making DHCPv6 work on 3GPP networks should be forgotten.   It's impossible to make it work.

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 10:08:27 +0000

Hi Alex, 

I disagree.

The problems you are describing are implementation ones. 

Cheers,
Med

> -----Message d'origine-----
> De : dhcwg [mailto:[email-masked]] De la part de Alexandru
> Petrescu
> Envoyé : jeudi 16 novembre 2017 07:38
> À : Ted Lemon
> Cc : dhcwg; Bernie Volz (volz)
> Objet : Re: [dhcwg] DHCPv6 and IPv6ND
> 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 12:05:08 +0100

Med,
Which part do you disagree with in my text?

I agree the problems are indeed implementation problems, but I need to 
understand which part do you disagree?

Do you disagree when I say that the entire issue about making DHCPv6 
work on 3GPP should be forgotten?  Or other part?

Alex

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 11:25:52 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Alexandru Petrescu [mailto:[email-masked]]
> Envoyé : jeudi 16 novembre 2017 12:05
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Ted Lemon; dhcwg; Bernie Volz (volz)
> I agree the problems are indeed implementation problems,

[Med] Cool. 

 but I need to
> understand which part do you disagree?

[Med] I disagree that the spec needs to say that the port number is variable. This should be left to implementers, if neede. BTW, configuring a distinct port number will require that the client is able to learn that alternate port. This will lead to more interoperability problems than it solves. 

> work on 3GPP should be forgotten?

[Med] Prefix delegation can work easily in cellular networks if all involved parties/implementers are following current specs. That is: 
- The client uses the defined multicast address + service port when issuing its solicit messages + supply prefix_exclude. 
- The server listens on the service port + does not make any assumption about the source IP address + treat DUIDs as opaque values that are only used to compare equality. 

I'm aware that some messages are "blocked" by some shipset vendors, but again this is an implementation issue. 
  
I do agree with you it is frustrating. 

  Or other part?

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 12:49:52 +0100

Med,

Thank you for the reply.  I agree with some parts, but not with others.

> - The server listens on the service port + does not make any assumption about the source IP address + treat DUIDs as opaque values that are only used to compare equality.

I think after all this time we can safely say that the specification 
written above has never been experimented successfully.

YEs, my ARM runs DHCPv6-PD with all the options that you required.  Yes, 
the operator DHCPv6 Server is running and configured to do PD a /56. 
But no, the two have never performed a successful exchange.

The problem is in the middle - the modem.

It's not only me who says this.  Lorenzo complained about modems and 
DHCPv6 several years ago.  Others on the v6ops WG agreed with him.

Yes, they made a wrong assertion saying the operator does not support 
DHCPv6: the operator _can_ do DHCPv6, and the assertion was wrong.

> I'm aware that some messages are "blocked" by some chipset vendors, but again this is an implementation issue.

I checked Qualcomm and Balong modems.  That represents quite a lot of 
the installed base.

I will be happy to check others like Intel modems, but I dont know how.

There is also a possibility that the specification that you write above, 
and where you refer to involved parties: maybe it's a matter between 
operator, implementers at router manufacturer and implementers at modem 
manufacturer.  I do not represent any: just implementer of open source.

A modem implementer has access to source code of the modem.

A router manufacturer implementer has access to source code of router.

Alex

> I do agree with you it is frustrating.

Yes.

Alex

---

From: <[email-masked]>
Date: Thu, 16 Nov 2017 11:57:46 +0000

Alex, 

Actually, it seems that we are in agreement in almost all points :)

The question is how this group can help fixing the modem issue (or any other blocking filters that may be in-between clients and servers). 

Cheers,
Med

> Envoyé : jeudi 16 novembre 2017 12:50
> > [Med] I disagree that the spec needs to say that the port number is
> variable. This should be left to implementers, if neede. BTW, configuring
> a distinct port number will require that the client is able to learn that
> alternate port. This will lead to more interoperability problems than it
> solves.
> >
> > [Med] Prefix delegation can work easily in cellular networks if all
> involved parties/implementers are following current specs. That is:
> > - The client uses the defined multicast address + service port when
> issuing its solicit messages + supply prefix_exclude.
> > - The server listens on the service port + does not make any assumption
> about the source IP address + treat DUIDs as opaque values that are only
> used to compare equality.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 13:15:36 +0100

Le 16/11/2017 à 12:57, [email-masked] a écrit :
> The question is how this group can help fixing the modem issue (or
> any other blocking filters that may be in-between clients and
> servers).

Maybe they can not.  But until that is fixed we can not talk about 
DHCPv6-and-IPv6ND on cellular networks.

And I dont see that fixing happening.

Alex

> 
> Cheers, Med
> 
>> -----Message d'origine----- De : Alexandru Petrescu
>> [mailto:[email-masked]] Envoyé : jeudi 16 novembre
>> 2017 12:50 À : BOUCADAIR Mohamed IMT/OLN Cc : Ted Lemon; dhcwg;
>> Bernie Volz (volz) Objet : Re: [dhcwg] DHCPv6 and IPv6ND
>> 
>> Med,
>> 
>>> Cheers, Med
>>>> -----Message d'origine----- De : Alexandru Petrescu
>>>> [mailto:[email-masked]] Envoyé : jeudi 16
>>>> novembre 2017 12:05 À : BOUCADAIR Mohamed IMT/OLN Cc : Ted
>>>> Lemon; dhcwg; Bernie Volz (volz) Objet : Re: [dhcwg] DHCPv6 and
>>>> IPv6ND
>>>> 
>>>> Med, Which part do you disagree with in my text?
>>>> 
>> variable. This should be left to implementers, if neede. BTW,
>> configuring a distinct port number will require that the client is
>> able to learn that alternate port. This will lead to more
>> interoperability problems than it solves.
>>> 
>>>> Do you disagree when I say that the entire issue about making
>>>> DHCPv6 work on 3GPP should be forgotten?
>>> 
>> about the source IP address + treat DUIDs as opaque values that are
>> only used to compare equality.
>> 
>> I think after all this time we can safely say that the
>> specification written above has never been experimented
>> successfully.
>> 
>> YEs, my ARM runs DHCPv6-PD with all the options that you required.
>> Yes, the operator DHCPv6 Server is running and configured to do PD
>> a /56. But no, the two have never performed a successful exchange.
>> 
>> It's not only me who says this.  Lorenzo complained about modems
>> and DHCPv6 several years ago.  Others on the v6ops WG agreed with
>> him.
>> 
>> Yes, they made a wrong assertion saying the operator does not
>> support DHCPv6: the operator _can_ do DHCPv6, and the assertion was
>> wrong.
>> 
>>> I'm aware that some messages are "blocked" by some chipset
>>> vendors, but
>> again this is an implementation issue.
>> 
>> I checked Qualcomm and Balong modems.  That represents quite a lot
>> of the installed base.
>> 
>> There is also a possibility that the specification that you write
>> above, and where you refer to involved parties: maybe it's a matter
>> between operator, implementers at router manufacturer and
>> implementers at modem manufacturer.  I do not represent any: just
>> implementer of open source.
>> 
>>>>> Cheers, Med
>>>>>> -----Message d'origine----- De : dhcwg
>>>>>> [mailto:[email-masked]] De la part de Alexandru 
>>>>>> Petrescu Envoyé : jeudi 16 novembre 2017 07:38 À : Ted
>>>>>> Lemon Cc : dhcwg; Bernie Volz (volz) Objet : Re: [dhcwg]
>>>>>> DHCPv6 and IPv6ND
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> I'm having trouble figuring out how changing the port
>>>>>>> would help. You'd still have to make the same
>>>>>>> modifications.   You'd still have to define a business
>>>>>>> model.
>>>>>> 
>>>>>> _If_ there is a standard that says port number is variable,
>>>>>> and if hardware manufacturer implements it, then it will
>>>>>> help.
>>>>>> 
>>>>>> If not, not.
>>>>>> 
>>>>>> If so, this entire issue about making DHCPv6 work on 3GPP
>>>>>> networks should be forgotten.   It's impossible to make it
>>>>>> work.
>>>>>> 
>>>>>> That puts the discussion of DHCPv6 and IPv6ND outside the
>>>>>> 3GPP
>> context
>>>>>> altogether.
>>>>>> 
>>>>>> _______________________________________________ dhcwg
>>>>>> mailing list [email-masked]