Re: [dhcwg] DHCPv6 and IPv6ND

[Alexandre Petrescu <[e-mail]>]

Le 15/11/2017 à 22:02, Ted Lemon a écrit :
> On Nov 15, 2017, at 9:36 PM, Alexandru Petrescu 
> <[e-mail] <mailto:[e-mail]>> 
> 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.

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