I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
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.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf