Hi Z. W. Yan,
Le 08/06/2016 à 07:26, Z.W. Yan a écrit :
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."
I agree, thanks.
(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.
I think there are multiple things here. I think the following:
The Mobile Node Id option is defined in RFC4283, not RFC5213. The draft
hpnrenum should relate to it. Further, there is work ongoing to update
the MNId definition with more cases. The draft is
draft-perkins-mext-4283mnids-01.txt. It is not yet a WG item, but anyways.
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.
I am asking whether it has been prototyped (implemented), not whether it
introduces new risks. I wanted to see a packet dump of wireshark.
For example, one can take the scapy open source tool and simply generate
a UPN message for the HNP-renum draft. This can be very straightforward.
I am asking because you are saying that there are two HNPs in the RA,
but only one HNP in the UPN. Maybe this is normal.
I am asking also because I wonder whether the order of appearance of
MNID and HNP is important in the UPN message. Maybe the order is not
important.
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."
triggered... yes, I agree.
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]."
Sounds good.
But now that you mention UNA: the UNA message does not appear in the
section 5 "Message format".
So I digged further and I discover that "Update Notification Ack" is
defined in RFC7077 and it's actually abbreviated "UPA", not "UNA" -
which name is right?
I am not am implementor tester of this, but I think, since this is a
specific operation (delete routing info based on old HNP, add new
routing INFO based on new HNP), I think it could make sense to define a
new "Status Code" in UNA/UPA to reflect specific error to that specific
operation.
For example, the value could be decimal 127, and the meaning could be
"FAILED-TO-RENUMBER-HNP".
Of course, if the implementer does not find value or no reason in this
new Status Code, then I will not insist.
Yours,
Alexandre Petrescu
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
[email protected] https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list
[email protected] https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
