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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Please see inline [Tiru]

From: Lorenzo Colitti [mailto:[e-mail]]
Sent: Wednesday, October 24, 2012 8:24 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [e-mail]
Subject: Re: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt


On Thu, Oct 18, 2012 at 9:32 PM, Tirumaleswar Reddy (tireddy) <[e-mail]<mailto:[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.
[Tiru] Sure, we will create two different drafts. After we split the draft into two [1] we will post Absolute Precedence Option with relevant use cases in 6man [2] Relay-supplied prefix option in DHCP WG.

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.
[Tiru] Yes. Only Absolute Precedence Option deals with MIF scenario where Mobile Node is assigned prefixes from both Local Access Network and Home Network. We had other multi-homing use cases in 01 version which are removed in 02.

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.
[Tiru] Agreed the problem statement needs to be fixed in this version.

But we are evaluating other scenarios for the next version  For e.g. In IPv6 multi-homing, dual stack scenarios - where Relay agent dynamically influences the host policy table If IPv6 connectivity is detected to be broken (Section 10.3.1 of RFC 6724). This can be achieved by Relay Agent sending RECONFIGURE-REQUEST (http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-01) to the DHCPv6 server providing the updated policy table in Absolute Precedence Option. DHCPv6 server will in turn initiate reconfigure message with the client, resulting in the client to initiate Renew/Reply or information-request/Reply transaction with the server to receive updated Policy Table OR

Do you think we can send the dynamic policy table in RA itself and solve the problem (but then it brings in complexity on the host if it is receiving policy table from two different sources)

Please let us know your opinion before we proceed on this path .


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.
[Tiru] Yes, will remove this part.

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.
[Tiru] Agreed

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.

[Tiru] This use case is specific to Proxy Mobile IPv6 (RFC 5213). Where there is tie-up b/w the Local Access Network and Mobile Network. Mobile. MAG in the Local Access Network establishes tunnel with LMA in the Home network. MAG can act as a DHCP relay agent and can communicate with the DHCP server in the home network.


  MN   MAG(DHCP-R) LMA   DHCP-S

   |       |------->|      | 1. Proxy Binding Update *

   |       |<-------|      | 2. Proxy Binding Acknowledgement

   |       |========|      | 3. Tunnel/Route Setup*

   |------>|-------------->| 4. Solicit via DHCP-R

   |<------|<--------------| 5. Advertise via DHCP-R

   |------>|-------------->| 6. Request via DHCP-R

   |<------|<--------------| 7. Reply via DHCP-R

   |       |               |
We will add more details to explain these details in next version.

--Tiru.