Prefix Delegation Support for Proxy Mobile IPv6
Note: This ballot was opened for revision 12 and is now closed.
(Brian Haberman) Yes
(Jari Arkko) No Objection
(Richard Barnes) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Spencer Dawkins) No Objection
(Adrian Farrel) No Objection
(Stephen Farrell) No Objection
Comment (2013-11-21 for -12)
I'd like to be able to use an MR that can do this, so thanks for working on this. I expected to see a security consideration to the effect that there could be DoS issues e.g. for the LMA caused by a large set of LFNs being behind an MR. Doesn't something like that warrant a mention?
(Joel Jaeggli) (was Discuss) No Objection
Comment (2013-12-12 for -13)
cleared my discuss having had it addressed. was: From the ops-dir review I don't see these as blockers but I'd like to seem some dicussion on them, thanks. ... However, the document doesn't provide much guidance in general in terms of logging/reporting. For e.g., in Section 5.1.2 Signaling Considerations - Is there a mechanism to inform the mobile router with some status in the event that the MAG receives a REQUESTED_DMNP_IN_USE or NOT_AUTHORIZED_FOR_DELEGATED_MNP message? ... Also, in some cases it is not clear if packets should be silently discarded (e.g. section 5.1.4 Packet Forwarding) or logged and discarded. I'd imagine that the latter might be beneficial from an operational point of view. Not sure if there was any discussion regarding this. ...
Barry Leiba No Objection
(Ted Lemon) (was Discuss) No Objection
Comment (2013-12-11 for -13)
In Section 1, paragraph 1, this isn't a complete sentence: In this context, the mobility management support that is enabled for an individual IP host, which is the mobile node. I don't know what was intended here, but please figure it out and fix it. :) The use of the term "mobile network" to mean the network that is moving around is _really_ confusing. I get why you chose this terminology, but every time I see "mobile network" I think of the upstream network, rather than the downstream network. In 3.2.1: The Advertise and Request messages are optional, and they are not used if a two message client-server exchange is used. This is a really vague way of saying something that is sort of true. The right way to say this is: If the requesting router includes a Rapid Commit option in its Solicit message, it is preferable that the MAG respond directly with a Reply rather than with an Advertise message, as described in RFC 3315, Section 17.2.3. In 3.2.2 paragraph 2, the relay agent behavior is described in RFC 3315, not RFC 3633. In 4.1, given that at least 8 of the sixteen bits of the DMNP are going to be zero, wouldn't it make sense to only include the bits that are included in the prefix length, and default the rest to zero? In 126.96.36.199: o In case the Proxy Binding Update signaling with the local mobility anchor is not completed successfully, for example because the local mobility anchor is not authorized for delegated mobile network prefix or the requested prefix is in use, the DHCPv6 Delegating Router will send a Reply message to the Requesting Router containing the IA_PD with the lifetimes of the prefixes in the IA_PD set to zero. This text only makes sense after the MR has successfully gotten a prefix delegation. Before that, there won't be any prefixes in the IA_PD. You would do better to just defer to RFC 3633: o In case the Proxy Binding Update signaling with the local mobility anchor is not completed successfully, for example because the local mobility anchor is not authorized for delegated mobile network prefix or the requested prefix is in use, the DHCPv6 Delegating Router will send a Reply message to the Requesting Router with no IA_PREFIX suboptions and with a Status Code option as described in RFC 3633, section 11.2. The same advice applies to the equivalent paragraph in 188.8.131.52. Next paragraph: The standard DHCPv6 considerations will be applied with respect to the interactions between the Delegating Router and the Requesting Router. The Delegating Router is provided with the delegated prefix(es), which can then be then advertised in the mobile network, and therefore used by the locally fixed nodes to auto configure IP addresses allowing to gain access to the Internet. The last sentence should probably start with "The Requesting Router," since it's the requesting router that's in the MR, not the delegating router. Former DISCUSS: DISCUSS item 1: In 3.2.2, paragraph 2, the text doesn't really describe what's happening in the diagram. Not only is this a usability issue for vision-challenged readers, you're glossing over some very weird behavior here. I would suggest the following change: OLD: Once the mobile access gateway gets the set of delegated prefixes from the delegating router function running on the local mobility anchor, it conveys it in a proxy binding update. This ensures that the local mobility anchor properly routes the traffic addressed to the delegated prefixes via the PMIPv6 tunnel established with the mobile access gateway, and that mobility is provided to these prefixes while the mobile router roams within the PMIPv6 domain. NEW: If the client did not request Rapid Commit, or the LMA doesn't support it, the relay agent on the MAG will behave normally in accordance with RFC 3315 in handling the Advertise message from the DR and the Request message from the RR. However, the MAG does not strictly follow RFC3315 in its handling of the Reply message. When the MAG receives the DHCPv6 Reply message from the LMA, it extracts the DMNP from the Reply message and sends a PBU to the LMA containing the DMNP from the Reply message. When the PBA comes back from the LMA containing the DMNP, the Reply message is forwarded to the client. I realize that the intention here was to gloss over this and leave it for the interworking stuff that isn't specified in this document, but what you are doing to the relay function in the MAG here is sufficiently weird that I think you need to call it out explicitly. You can resolve this DISCUSS item by making the change I've proposed above, or explaining why that's not the right thing to do. I am also concerned that you haven't accounted for any of the things that can go awry during this process, but I am reluctant to demand that you fully flesh out the interworking, and that is what you would have to do to address this problem. You do not need to address this point to clear the DISCUSS, but I'm mentioning it here because it concerns me and is related to the first DISCUSS item. DISCUSS item 2: I'm noticing in 184.108.40.206 that you are talking about IPv4 prefixes, but of course RFC3633 does not support IPv4 prefixes. What's the intention here? To resolve this DISCUSS item you need to explain what was intended here and possibly negotiate a fix. DISCUSS item 3: You never talk about how the identity of the MR that is presented over DHCPv6 will be correlated with the identity of the MR that is presented over PMIPv6. This seems like an important detail. Have you thought about it? Why isn't it described here? To resolve this DISCUSS item, you need to answer these questions and possibly add some text, with which I will be happy to help.