[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MEXT] Comments on draft-ietf-mext-nemo-pd-02.txt

Hello,
I have a few minor comments. Sorry for not sending these comments during the WG last call. 

In section 3.5


   Therefore, when querying an HA to determine if the HA provides
   DHCPv6PD service, the MR MUST discontinue sending Solicit messages to
   the HA after sending 6 Solicit messages, and conclude that the HA
   will not provide DHCPv6PD service.


Why '6' attempts? Why not '3'? Just curious. Six attempts seems like a lot.


   The MR may choose to probe the HAs for DHCPv6PD service sequentially
   or in parallel.
Shouldn't this be done sequentially? If done in parallel, you could end up in a scenario where the DHCPv6 Delegating Router receives two requests through two different home agents acting as relay agents from the same mobile router. 


   Use of the DHCPv6 relay agent function with DHCPv6PD requires that
   there be some mechanism through which routing information for the
   delegated prefixes can be added to the appropriate routing
   infrastructure.  If the HA is acting as a DHCPv6 relay agent, the HA
   SHOULD add a route to the delegated prefix and advertise that route
   after receiving a binding update for the prefix from the RR
   [RFC3963].
The above paragraph kind of modifies the mobile router behavior described in RFC 3963. The mobile router first sends a Binding Update to setup the bi-directional tunnel, then runs DHCPv6 prefix delegation to obtain the mobile network prefix and then sends another Binding Update with the mobile network prefix. The second Binding Update is what sets up forwarding the mobile network prefix and causes the home agent to start advertising the mobile network prefix. Perhaps this should pointed out explicitly in the draft. The above paragraph is the first piece of text where you realize you need to send two binding updates. 

I have another question. Section 3.1 says


   If the MR has one or more active delegated prefixes, the MR initiates
   a DHCPv6 message exchange with a DHCPv6 Rebind message as described
   in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633.
In this case, can the mobile router include the mobile network prefix in the first Binding Update itself? Or does it have to first setup the bidirectional tunnel with the home agent, perform a DHCPv6 message exchange with a DHCPv6 Rebind message and then send a Binding Update again for setting up forwarding for the mobile network prefix? 


                      Discussion: If NEMO may be deployed with the HA
                                  and the DHCPv6 server in different
                                  administrative domains, this text
                                  should be extended to include the use
                                  of IKE with public keys.


Can this ever happen? IMO, it shouldn't....

Vijay

marcelo bagnulo braun wrote:

Hi,

This draft went over WGLC and received some comments.
The authors have produced this new version addressing the comments received. We would like to ask people that provided commnets to check if they have been addressed before the april 1st. 
We will ship the document to the IESG by then.

Regards, marcelo


-------- Mensaje original --------
Asunto:     [MEXT] I-D Action:draft-ietf-mext-nemo-pd-02.txt
Fecha:     Fri, 6 Mar 2009 12:00:01 -0800 (PST)
De:     Internet-Drafts at ietf.org
Para:     i-d-announce at ietf.org
CC:     mext at ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. 


    Title           : DHCPv6 Prefix Delegation for NEMO
    Author(s)       : R. Droms, et al.
    Filename        : draft-ietf-mext-nemo-pd-02.txt
    Pages           : 12
    Date            : 2009-03-06

One aspect of network mobility support is the assignment of a prefix
or prefixes to a Mobile Router (MR) for use on the links in the
Mobile Network.  DHCPv6 prefix delegation can be used for this
configuration task.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



------------------------------------------------------------------------

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext