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.
(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?
Has this message been prototyped, is there a packet dump?
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.
(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.
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).
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
