Re: [DMM] WGLC reminder - draft-ietf-dmm-hnprenum-02

Thank you for your comments, Alex, please find my inline responses.

2016-06-08 

Z.W. Yan 

发件人： Alexandre Petrescu 
发送时间： 2016-06-07  18:02:49 
收件人： Jouni.nosmap 
抄送： dmm 
主题： Re: [DMM] WGLC reminder - draft-ietf-dmm-hnprenum-02 

Hi,
This is comments about draft-ietf-dmm-hnprenum-02
https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-02
The draft is short, and reads very well.  I think it should be further 
pursued.
Here are some comments:
>    o  When the MN obtains the new HNP information, it deletes the old
>       HoA and configures a new HoA with the newly allocated HNP.
It would make sense to delete not only _the_ old HoA but all addresses 
configured within the old HNP.  Because recently the hosts may configure 
more than one address when receiving a Router Advertisement - they may 
also configure at least one 'privacy' address.  All of them should be 
deleted.

***This description will be revised as "When the MN obtains the new HNP information, 
it deletes all the addresses (e.g., HoA) configured with the old HNP and configures new addresses with the newly allocated HNP."

>    (1) UPN message
>
>    In the UPN message sent from the LMA to the MAG, the notification
>    reason is set to 2 (UPDATE-SESSION-PARAMETERS).  Besides, the HNP
>    option containing the new HNP and the Mobile Node Identifier option
>    carrying Identifier of MN are contained as Mobility Options of UPN.
Can we see a message format of this?  Is it an ICMP message?  A Mobility 
Header?

***We did not present the message format because the UPN message, as a mobility header message, 
is speficied in RFC7077, (and also the notification reason used in this draft). And HNP option and Mobile Node Identifier option are speficied in RFC5213.

Has this message been prototyped, is there a packet dump?

***The procedure used for HNP renumbering in this draft follows the RFC7077, we did not introduce new security risk and failure.

>    In the first Prefix Information option, the old HNP is carried but
>    both the related Valid Lifetime and Preferred Lifetime are set to 0.
>    In the second Prefix Information option, the new HNP is carried with
>    the Valid Lifetime and Preferred Lifetime set to larger than 0.
This reads smart: a unique message to tell the Host to delete the old 
prefix and use the new one.  I agree.

***Yep.

>    (3) DHCP Message
>
>    When the DHCP is used in PMIPv6 to configure the HoA for the MN, a
>    new IPv6 HoA is generated based on the new HNP.  Trigged by the UPN
>    message, the MAG will request the new HoA from the DHCP server first
>    and then the MAG updates the allocated HoA to the MN through the DHCP
>    server-initiated configuration exchange [RFC3315].
I think this is too specific.  It says MAG should request the new HoA 
(but what if MAG is Relay?).  Second it says that the MAG requests an 
address and then the server does server-initiated configuration - this 
is also very specific.
Maybe we can formulate in a different way, in which these specificities 
are just examples in the DHCP behaviour.  Because there are other ways 
in which DHCP can act to achieve the same - e.g. use Prefix Delegation, 
use Relays, and others.

***Agree, then the description will be revised as 
"When the DHCP is used in PMIPv6 to configure the addresses for the MN, 
new IPv6 addresses (e.g., HoA) will be generated based on the new HNP 
and the related DHCP procedure is also trigged by the reception of UPN message."

> 7.  Security considerations
>
>    This extension causes no further security problem.  The security
>    considerations in [RFC5213] and [RFC7077] are enough for the basic
>    operation of this draft.
Maybe we should be specific to say that the security of the UPN message 
is ensured by... (something from RFC5213 and/or 5077).

***Because we did not specify new signaling messages in this draft, 
the suggestions to protect UPN/UNA messages are illustrated in RFC7077, which also follow the security considerations in RFC5213. 
Then we describe this part as "This extension causes no further security problem. 
The protection of UPN and UNA messages follow [RFC5213] and [RFC7077]."

Alex
Le 23/05/2016 à 19:17, Jouni.nosmap a écrit :
> Folks,
>
> Friendly nudge to do reviews on drafts we got now in WGLC.
>
> Jouni
>
> Sent from a smart phone.. Mind the typos..
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm