Document: draft-ietf-netlmm-pmip6-ipv4-support-12 Reviewer: Spencer Dawkins Review Date: 2009-05-18 IETF LC End Date: 2009-05-18 IESG Telechat date: 2009-05-21 Summary: This draft is almost ready for publication as a Proposed Standard. There are a small number of minor comments listed below, most of which are either about text clarity or 2119 language. I have also included a small number of nits, for the convenience of the editor. These nits are not part of the Gen-ART review. 1.1. Stated Assumptions The following are the configuration requirements from the mobility entities in the Proxy Mobile IPv6 domain for supporting the extensions defined in this document. o The local mobility anchor and the mobile access gateway are both IPv4 and IPv6 enabled. Irrespective of the type of transport Spencer (nit): is this saying "BOTH the local mobility and the mobile access gateway are enabled for BOTH IPv4 and IPv6"? If so, this might be said more clearly... network (IPv4 or IPv6) separating these two entities, the mobility signaling is always based on Proxy Mobile IPv6 [RFC-5213]. 2.2. Terminology Selective De-registration It is a procedure for partial de-registration of all the addresses Spencer (nit): s/It is a/A/ (just reads oddly to me in a technical specification) that belong to one address family, i.e., de-registration of either IPv4 home address, or all of the IPv6 home network prefixes. 3.1.2.1. Processing Proxy Binding Updates The processing rules specified in Section 5.3 of [RFC-5213] are applied for processing the received Proxy Binding Update message. However, if the received Proxy Binding Update message has an IPv4 Home Address option [ID-DSMIP6], the following considerations MUST be applied additionally. o If there is an IPv4 Home Address option [ID-DSMIP6] present in the received Proxy Binding Update message, but if there is no Home Network Prefix option [RFC-5213] present in the request, the local mobility anchor MUST NOT reject the request as specified in Section 5.3.1 of [RFC-5213]. At least one instance of any of these two options MUST be present. If there is not a single Spencer (minor): I'm confused by "these two options" - this MUST (and the next MUST) are already in text that's conditional on an IPv4 Home Address option being present, and the only other option that's named is Home Network Prefix option. I'm not sure which "two options" are being discussed. Should this text appear somewhere else (like, outside the "If there is an IPv4 Home Address option present")? If it's in the right place, s/any of these two options/either the IPv4 Home Address option or the Home Network Prefix option/ would be clearer - but I'm not sure if I'm understanding the intent here. instance of any of these two options present in the request, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home network prefix option) [RFC-5213]. o If the prefix request(P) flag in the IPv4 Home Address option is set to a value of 1, then the local mobility anchor MUST reject Spencer (nit): it would help readers if you also included an expansion of "value of 1" in parentheses, as you do for other "magic numbers" elsewhere in this draft. I don't see "prefix request flag" elsewhere in this document - if that's true, it would also be lovely if you provided a reference to the document where it is defined, but that's less important if you provide the expansion. the request and send a Proxy Binding Acknowledgement message with the Status field set to IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4 prefix assignment not supported). o If there exists a Binding Cache entry that can be associated with the request, the local mobility anchor MUST apply considerations from Section 5.3.1 of [RFC-5213], (point 13), to determine if the request is re-registration or a de-registration request and the respective considerations from the below sections MUST be applied. Spencer (nit): it would help readers if you could point to specific sections below (because there are a lot to choose from!), as you do in similar text elsewhere in the document. o If there exists a Binding Cache entry that can be associated with the request and if it is determined that the request is a re- registration request and with the request to extend IPv4 home address mobility support to the existing IPv6-only mobility session, considerations from Section 3.1.2.2 MUST be applied with respect to IPv4 support. 3.1.3. Routing Considerations for the Local Mobility Anchor Intercepting Packets Sent to the Mobile Node's IPv4 home address: o When the local mobility anchor is serving a mobile node, it MUST be able to receive packets that are sent to the mobile node's IPv4 home address. In order for it to receive those packets, it MUST advertise a connected route in to the Routing Infrastructure for the mobile node's IPv4 home address or for its home subnet. This Spencer (minor): The first MUST doesn't seem to be a 2119 MUST - I think it's stating a goal that the second MUST achieves. Perhaps "When the local mobility anchor is serving a mobile node, it MUST advertise a connected route in to the Routing Infrastructure for the mobile node's IPv4 home address or for its home subnet, in order to receive packets that are sent to the mobile node's IPv4 home address."? essentially enables IPv4 routers in that network to detect the local mobility anchor as the last-hop router for that subnet. 3.2.3.2. Receiving Proxy Binding Acknowledgement All the considerations from section 6.9.1.2 of [RFC-5213] MUST be applied with the following exceptions. Spencer (minor): not sure why the next two bullets are SHOULD NOTs - we usually provide at least one example of why an implementation would choose not to perform SHOULD NOTs, for background. o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The mobile node is not authorized for IPv4 home address), the mobile access gateway SHOULD NOT send a Proxy Binding Update message including the IPv4 Home Address option [ID-DSMIP6] till an administrative action is taken. o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The mobile node is not authorized for the requesting IPv4 home address), the mobile access gateway SHOULD NOT request for the same address again, but MAY request the local mobility anchor to do the assignment of address by including exactly one instance of IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address and the prefix length fields in the option set to ALL_ZERO value. ... o If there is an IPv4 DHCP Support Mode option present in the received Proxy Binding Acknowledgement message and if the (S) flag in the option is set to a value of 1, then the mobile access Spencer (nit): again, I'd suggest providing an expansion in paretheses wherever you have a "value of (magic number)" in the text, just to help the reader. Most of the time, you already provide these. gateway MUST function as a DHCP server for the mobile node. If either the (S) flag in the option is set to a value of 0, or if the option is not present in the request, then the mobile access gateway MUST function as a DHCP Relay for the mobile node. 3.3.1. IPv4 Default-Router Address Option A new option, IPv4 Default-Router Address Option is defined for using it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the local mobility anchor to the mobile access gateway. This option can be used for sending the mobile node's IPv4 default-router address. The IPv4 Default-Router Address option has an alignment requirement of 4n. Its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved (R) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Default-Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv4 Default-Router Address Option Reserved (R) This 8-bit field is unused for now. The value MUST be Spencer (minor): in the figure, it's a 16-bit field, isn't it? initialized to 0 by the sender and MUST be ignored by the receiver. 3.4.1. DHCP Server co-located with the Mobile Access Gateway This section explains the operational sequence of home address assignment operation when the DHCP server is co-located with the mobile access gateway. MN MAG(DHCP-S) LMA |------>| | 1. DHCPDISCOVER | |------->| 2. Proxy Binding Update | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) | |========| 4. Tunnel/Route Setup |<------| | 5. DHCPOFFER (IPv4 HoA) |------>| | 6. DHCPREQUEST (IPv4 HoA) |<------| | 7. DHCPACK | | | * DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling * (Step-2 to Step-4) may happen in parallel and in no specific order Spencer (minor): Isn't this "Step-2 AND Step-4"? The text says you can get the ACK (Step-3) before you send the Proxy Binding Update (Step-2) ... :-) Similar text appears in other ladder diagrams below. * Tunnel/Route setup(Step-4) and the subsequent steps will happen in * in the specified order. Figure 5: Overview of DHCP Server located at Mobile Access Gateway 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway o Any time the mobile access gateway detects that the mobile node has released its IPv4 address, it can send a Proxy Binding Update to the local mobility anchor and de-register the IPv4 mobility session. Spencer (nit): in the next section, similar text about releasing its IPv4 address includes this phrase: "by sending the DHCPRELEASE message [RFC-2131]", and explains how the mobile access gateway detects the release. Is it worth having the same phrase here? 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message o If the mobile access gateway and the local mobility anchor are using globally routable IPv4 addresses and if there is a security association that is based of IPv4 addresses, then the encapsulated Spencer (nit): s/based of/based on/ IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) MUST be protected using IPsec ESP [RFC-4301] mode. There is no need to apply IPsec ESP header to the IPv6 packet. In all other cases, the Proxy Binding Acknowledgement message MUST be protected using IPsec prior to the IPv4 or IPv4-UDP encapsulation. * The encapsulation mode for the bi-directional tunnel MUST be set to IPv4. However, if the value of the configuration variable, UseIPv4UDPEncapForSignalingMessages, is set to 1, then the following considerations MUST be applied. Spencer (nit): would it be clearer to the reader if the previous paragraph was un-indented one level, so the following paragraphs are more clearly "following"? * If there is a NAT Detection option [ID-DSMIP6] in the received Proxy Binding Acknowledgement message and if the value of the configuration flag, UseIPv4UDPEncapForSignalingMessages, is set to value of 1, then the encapsulation mode for the tunnel MUST be set to IPv4-UDP. Otherwise the encapsulation mode MUST be set to IPv4. * If the (T) flag in the Proxy Binding Acknowledgement message is set to value of 1, then the encapsulation mode MUST be set to IPv4-UDP-TLV.