Re: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt

[Lorenzo Colitti <[e-mail]>]

On Thu, Oct 18, 2012 at 9:32 PM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

> This draft proposes new DHCPv6 options to be added by the DHCPv6 relay
> agent when it generates a Relay-Forwarded message to influence the DHCPv6
> server's response that modify the host's address policy table
> [I-D.ietf-6man-addr-select-opt] based on observed network characteristics.
> These options can also be used to conditionally disable IPv6 temporary
> addresses in a managed network for selective hosts without authentication
> supplicant.
>
> Comments and suggestions are welcome.
>

A few general points:

1. The draft deals with two DHCPv6 options, with different use cases. Why
are you combine the options? I believe things would be much clearer if each
option had its own draft with its own use case.

2. Why is this draft in MIF? The address selection option has nothing to do
with multiple interfaces, and is already being discussed in 6man. The
relay-supplied prefix option also has nothing to do with multiple
interfaces.

3. The introduction does not provide a problem statement that matches the
solutions. The introduction says that "DHCPv6 allows relatively static
information to be configured in hosts, which is somewhat limiting", but
then states that the problem can be fixed by introducing DHCPv6 options. I
don't see how this is possible. DHCPv6 options cannot make things more
dynamic, since in DHCPv6, options are only handed out at request/response
time, and DHCPv6 options cannot change how often requests are made. Since
the options being proposed as solutions do not solve the problem, the draft
needs another problem statement.

4. The draft confuses RFC4941 privacy addresses with IA_TA options.
Ignoring IA_TA options will not disable RFC4941 privacy addresses, because
they are only used by SLAAC. The references to RFC 4941 should be removed.

As regards the address selection option specifically:

1. The option itself is still work in progress in 6man. So the
modifications should happen in 6man, not here. Otherwise we will have two
working groups working on the same option which is likely to have bad
results.
3. I don't understand the use case (Section 3.1). If the DHCPv6 relay is in
the mobile access gateway, then it's in the mobile operator's network. If
it's in the mobile operator's network, then how can it "influence the
DHCPv6 Server in the home network"? In general, the DHCPv6 server in the
home network has no way of talking to the mobile operator's network.