IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-18

[Ballot discuss]
rev -16 of this doc is much improved.  Although I have not cleared all
of my DISCUSS issues, I think the doc is close to publication.  BTW, a
couple of the remaining DISCUSS issues are the result of the wording
of my previous DISCUSSes, and I'm sorry for the confusion...

My first DISCUSS was, on reflection, really two different issues.  The
second (which I won't repeat here) has been resolved.  The first is
still issue still exists in -16.

The document is not clear about whether assigning the IPv4 address
used by the MN as its default router MUST or MAY be assigned to the
MAG interface facing the MN.

Section 3.4:

  o  The DHCP server or the DHCP relay agent configured on the mobile
      access gateway is required to have an IPv4 address for exchanging
      the DHCP messages with the mobile node.  This address is the
      mobile node's default router address provided by the local
      mobility anchor.  Optionally, all the DHCP servers co-located with
      the mobile access gateways in the Proxy Mobile IPv6 domain can be
      configured with a fixed IPv4 address.  This fixed address can be
      potentially an IPv4 private address [RFC-1918] that can be used
      for the DHCP protocol communication on any of the access links.
      This address will be used as the server identifier in the DHCP
      messages.

Is this configuration of addresses a protocol requirement that needs
some normative language, and that needs to be reflected elsewhere in
the document?  And, to be picky, a DHCP server or relay agent isn't
configured with an IPv4 address, per se.  I know what is meant - DHCP
uses IPv4 addresses as identifiers; e.g., as a "Server identifier" and
in the 'giaddr' field - so the idea is to ensure that the same
identifier is used throughout the domain to provide a consistent
environement for the host.  For example, in section 3.4.1:

  o  If a fixed address such as the IPv4 default router address of the
      mobile node is used as the DHCP server Id on any of the links in
      that Proxy Mobile IPv6 domain...

Either the fixed address is required, as specified in the earlier
bullet from section 3.4, or, if it's not required, and the "If" clause
in this text is false, how does DHCP work?
---
I understand, now, that the use of point-to-point links obviate the
need for explicit assignment of an IPv4 address to the MAG interface
on the link with the MN.  The point-to-point links are also used to
allow for conditional implementation of ARP and proxy ARP; e.g., from
the third bullet on page 21:

      The mobile access gateway SHOULD
      configure this address on its interface and respond to any ARP
      requests sent by the mobile node for resolving the hardware
      address of the default router.

and the last bullet in section 3.2.4:

  o  The mobile access gateway SHOULD use proxy ARP [RFC-925] to reply
      to ARP Requests that it receives from the mobile node seeking
      address resolutions for the destinations on the mobile node's home
      subnet. [...]
      However, if the link between the
      mobile node and the mobile access gateway is a point-to-point
      link, then the mobile access gateway is not required to support
      proxy ARP.  The mobile node can be configured to use the point-to-
      point link for sending all IP packets.

Is it the case that a MN MUST be configured to forward all IP traffic
on the point-to-point link without using ARP?  Or, is it possible that
an MN using a point-to-point link might still use ARP?  Unless there
is a guarantee that no MN will ever send ARP I think there will be
interoperability issues with "SHOULD [...] respond to any ARP
requests" and "SHOULD use proxy ARP".
---
My suggestions for corrections to the text describing the use of the
DHCP "client identifier" were unclear.  So, let me see if I can get it
right here:

  o  A DHCP server identifies a DHCP interface from the contents of
      the DHCP "Client-identifier" option [RFC-2132], if present, or
      from the client hardware address (chaddr), as specified in
      [RFC-2131].  Note that the name "Client-identifier" is a
      misnomer as it actually identifies an interface and not the
      client.  The DHCP server uses this identity to identify the
      interface for which the address is assigned.  A mobile node in a
      Proxy Mobile IPv6 domain, can attach to the network through
      multiple interfaces and can obtain address configuration for
      each of its interfaces.  Additionally, it may perform handoffs
      between its interfaces.  Following are the related
      considerations with respect to the identification presented to
      the DHCP server.

      *  If the mobile node attaches to the Proxy Mobile IPv6 domain
        through multiple physical interfaces, the DHCP server will
        uniquely identify each of those interfaces and will perform
        address assignment.  The DHCP server will identify the
        interface as specified in RFC 2131.  The mobile node SHOULD
        generate and use the "Client-identifier" for each physical
        interface according to [RFC-4361].  Any time the mobile node
        performs an handoff of a physical interface to a different
        mobile access gateway, using the same interface, the DHCP
        server will always be able to identify the binding using the
        presented identifier.  The presented identifier (either the
        "Client-identifier" or the hardware address) will remain as
        the primary key for each binding, just as how they are unique
        in a Binding Cache entry.

      *  If the mobile node is capable of performing handoff between
        interfaces, as per [RFC-5213], a "Client-identifier" value
        MUST be used for the attachment point that is not tied to any
        of the physical interfaces.  The identifier MUST be generated
        according to RFC 4361, which guarantees that the identifier
        is stable and unique across all "Client-identifier" values in
        use in the Proxy Mobile IPv6 domain.

Note that I've specified the use of RFC 4361 for generation of
"Client-identifier" values.  This style of "Client-identifier" will
produce stable identifiers for the virtual interfaces with vanishingly
small probability of identifier clashes.

[Ballot comment]
Updated for rev -15.

In figure 1, doesn't either MAG1 need a Proxy-CoA address or LMA2 need
an IPv4-LMAA, so that MAG1 and LMA2 have a shared version of IP over
which they can communicate?
---
In section 2.2:

  Mobile Node's IPv4 Home Address (IPv4-MN-HoA)

      The IPv4 home address assigned to the mobile node's attached
      interface.  This address is topologically anchored at the local
      mobility anchor.

Which local mobility anchor is the address anchored at?
---
In section 3:

  The IPv4 home address mobility support essentially enables a mobile
  node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
  configuration for its attached interface and be able to retain that
  address configuration even after changing its point of attachment in
  that Proxy Mobile IPv6 domain.  This section describes the protocol
  operation and the required extensions to Proxy Mobile IPv6 protocol
  for extending IPv4 home address mobility support.

This paragraph talks about the MN as having a single IPv4 interface
and associated address configuration, while the last paragraph
describes operation if there are multiple interfaces.  I think it
would be more consistent to talk about interfaces and allow for a MN
to have multiple interfaces.
---
In section 3.1.2.1, there is discussion of a policy profile in which
the MN may or may not be authorized for IPv6 service.  Is there a
similar authorization for IPv4 service in that profile?
---
Also in section 3.1.2.1, do the considerations for re-registration and
de-registration need to be extended to consider the MN's
IPv4-Proxy-CoA?

  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.  If the
      request is a re-registration request, considerations from Section
      3.1.2.3 MUST be applied and if it is a de-registration request,
      considerations from Section 3.1.2.4 MUST be applied.

And, in the previous paragraph, are the section numbers correct?

---
In section 3.2.3.1, are the two sub-bullets under "The IPv4 Home
Address Request option MUST be present in the Proxy Binding Update
message" mutually exclusive alternatives?
---
The first two bullets in the list in section 3.2.3.2 seem to be
contradictory, in that they specify different behaviors in the MAG in
response to receipt of the same Proxy Binding Ack message from the
LMA.
---
Is there some difference in the predicate conditions in the last two
bullets on page 20?  In more detail, is it possible for the Proxy
Binding Ack message to have status Accepted while the IPv4 Home
Address option has a failure status?
---
These two bullets in section 3.2.4 may be contradictory; the first
seems to allow local routing while the second requires traffic to be
forwarded to the LMA:

  o  Considerations from Section 6.10.3 of [RFC-5213] MUST be applied
      with respect the local routing and on the use of
      EnableMAGLocalRouting flag.

  o  On receiving a packet from a mobile node connected to its access
      link, the packet MUST be forwarded to the local mobility anchor
      through the bi-directional tunnel established with the local
      mobility anchor.

[Ballot discuss]
I've updated my DISCUSS based on rev -15 of the doc.

I'm still left with a fundamental question about the deployment requirements for IPv4 address assignment in MAGs. 

From Section 3.4:

  o  The DHCP server or the DHCP relay agent configured on the mobile
      access gateway is required to have an IPv4 address for exchanging
      the DHCP messages with the mobile node.  This address is the
      mobile node's default router address provided by the local
      mobility anchor.  Optionally, all the DHCP servers co-located with
      the mobile access gateways in the Proxy Mobile IPv6 domain can be
      configured with a fixed IPv4 address.  This fixed address can be
      potentially an IPv4 private address [RFC-1918] that can be used
      for the DHCP protocol communication on any of the access links.
      This address will be used as the server identifier in the DHCP
      messages.

If I understand this paragraph correctly, in the case:

  o  DHCP relay agent co-located with the mobile access gateway.

the relay agent uses the MN's default router address, and in this
case:

  o  DHCP server co-located in the mobile access gateway.

the server uses either the MN's default router address or an IPv4
address that is fixed across all MNs and MAGs.  In the latter case,
each MAG knows to forward IPv4 traffic to that single fixed address to
the DHCP server in the MAG.

Is this configuration of addresses a protocol requirement that needs
some normative language, and that needs to be reflected elsewhere in
the document?  For example, in section 3.4.1:

  o  If a fixed address such as the IPv4 default router address of the
      mobile node is used as the DHCP server Id on any of the links in
      that Proxy Mobile IPv6 domain...

Either the fixed address is required, as specified in the earlier
bullet from section 3.4, or, if it's not required, and the "If" clause
in this text is false, how does DHCP work?

Expanding on this question, this text in section 3.2.3.2 uses "MAY":

  o  The default router address MUST be obtained from the IPv4 Default-
      Router Address option present in the received Proxy Binding
      Acknowledgement message.  The mobile access gateway MAY configure
      this address on its interface and respond to any ARP requests sent
      by the mobile node for resolving the hardware address of the
      default router.  It MAY also use this address as the source
      address for any datagrams sent to the mobile node and originated
      by the mobile access gateway itself.  It MAY also use this address
      in the DHCP Router option [RFC-2132] in the DHCP messages.

I guess if I read the last sentence carefully, the MAY could be
correct because the MAG will use the address in the DHCP Router option
only if the MAG is not acting as a DHCP server and using a single common
IPv4 address for all MNs.  However, consistent with
the requirements in section 3.4, shouldn't the use of the default
router address be a MUST requirement?
---
This sentence from section 3.1.2.7 is not parseable:

  However, when there are no Home Network Prefix options with a
  NON_ZERO value present in the request a single Home Network Prefix
  option with NON_ZERO value present in the request, but if there an
  IPv4 Home Address option with a NON_ZERO value present in the
  request, the following considerations MUST be applied.
---
In section 3.2.4, under what circumstances would the MAG not implement
proxy ARP for the MN's home subnet and what are the consequences:

  o  The mobile access gateway MAY use proxy ARP [RFC-925] to reply to
      ARP Requests that it receives from the mobile node seeking address
      resolutions for the destinations on the mobile node's home subnet.
      When receiving an ARP Request, the local mobility anchor can
      examine the target IP address of the Request, and if this IP
      address matches the mobile node's IPv4 home subnet, it MAY
      transmit a Proxy ARP Reply.

---
From section 3.4, this text needs to be more careful about
describing the "client identifier" (which is admittedly misnamed, as
it is actually a fixed "interface identifier") identifies an interface
(but not a host) to a DHCP server.  My apologies to the authors, as I
had previously agreed to this text, which I now see needs a little
tweaking.

  o  A DHCP server identifies a DHCP client from the client identifier,

s/client/interface/

      if present, or from the client hardware address (chaddr), as
      specified in [RFC-2131].  It uses this identity for identifying
      the client and its interface for which the address is assigned.  A

s/client and its interface/the interface/

      mobile node in a Proxy Mobile IPv6 domain, can attach to the
      network through multiple interfaces and can obtain address
      configuration for each of its interfaces.  Additionally, it may
      perform handoffs between its interfaces.  Following are the
      related considerations with respect to the identification
      presented to the DHCP server.

      *  If the mobile node attaches to the Proxy Mobile IPv6 domain
        through multiple interfaces, the DHCP server will uniquely
        identify each of those interfaces and will perform address
        assignment.  The DHCP server will identify the client as

s/client/interface/

        specified in [RFC-2131].  If the client identifier is present,
        that will be used for identifying the mobile node, otherwise

s/mobile node/mobile node interface/

        the client hardware address will be used.  Anytime the mobile
        node changes its point of attachment in the network and

What is "point of attachment"?

        performs an handoff to a different mobile access gateway, using
        the same interface, the DHCP server will always be able to
        identify the binding using the presented identifier, the client
        identifier or the hardware address.  The client identifier or
        the hardware address will remain as the primary key for each
        binding, just as how they are unique in a Binding Cache entry.

When the mobile node performs a handoff and moves an interface to a
different MAG, the interface MUST continue to use the same identifier
(either client identifier or hardware address) so that the DHCP server
will associate the interface with the existing DHCP address binding.

Does "just as how they [client identifier or hardware address] are
unique in a Binding Cache entry" imply that the DHCP identifier is in
the Binding Cache?  Does it need to be?

      *  However, if the mobile node is capable of performing handoff
        between interfaces, as per [RFC-5213], the client identifier in
        such scenarios needs to be an identifier that is not tied to
        any of those interfaces.  The identifier must be a stable
        identifier which remains the same through out the mobile node's
        attachment in that Proxy Mobile IPv6 domain.  This identifier
        must remain fixed for a given binding

... so that the DHCP server will identify the session with the
existing DHCP address binding for that session and maintian the same
IPv4 address for the session.

                                                  This identifier in some
        implementations can be the identifier associated to a virtual
        interface, that is abstracting the physical interfaces.
---
Section 3.4:

  o  Any time the mobile node goes into the DHCP RENEWING state [RFC-
      2131], it simply unicasts the DHCPREQUEST message including the
      assigned IPv4 home address in the 'requested IP address' option.
      The DHCPREQUEST is sent to the address specified in 'server
      identifier' field of the previously received DHCPOFFER and DHCPACK

s/'server identifier' field/Server Identifier option/

      messages.

[Ballot comment]
The base Proxy Mobile IPv6 spec (RFC 5213) uses IPsec in a very simple
way: it requires no Mobile IP specific changes to IPsec, and it's even
possible to use a "bump-in-the-wire" implementation, such as a
separate IPsec gateway sitting next to the MAG and LMA.

The IPv4 transport support introduced in this document completely
changes the situation by requiring Mobile IP specific changes to
IPsec, and preventing the use of separate gateway/"bump-in-the-wire"
implementation. With these changes, I do not think IPsec is anymore a
reasonable solution for securing PMIP. However, it is not realistic to
ask this draft to fix the situation; thus, I am balloting "abstain".

[Ballot comment]
Updated for rev -14.

Is there any impact of lease lengths on the use of DHCP address
assignment?  If so, guidance would be helpful; if not, explicitly
mentioning that lease length doesn't matter would be helpful.

[Ballot discuss]
I've updated my DISCUSS based on rev -14 of the doc.  Some, but not
all, of my issues have been addressed.  I've added comments explaining
my responses to the changes in the doc.  In addition, I have some new
issues with text added to section 3.4.3.

> From conversations with the authors, a "handoff" is a change of
> network attachment that is not reported to layer 3 as a loss of link
> connection.  The differentiation between handoff and a change of
> network attachment that is reported to L3 is important in section 3.4,
> as a DHCP message exchange is triggered by network reconnection
> reported to L3.
>
> The use of 'client identifier' and 'chaddr' in this text from section
> 3.4 differs from the use of those fields in DHCP servers.
>
>    o  A DHCP server identifies the DHCP client and its interface for
>      which the address is assigned from the client identifier and the
>      client hardware address (chaddr) [RFC-2131] fields respectively.
>      A mobile node in a Proxy Mobile IPv6 domain, can attach to the
>      network through multiple interfaces and additionally may perform
>      handoffs between its interfaces.  Following are the related
>      considerations:
>
> The first issue is that DHCPv4 does not have any concept of multiple
> interfaces attached to a single host computer.  Each address
> assignment - called a 'binding' (this term should be cited as defined
> in RFC 2131, to clarify and make distinct from other bindings in this
> document) - is regarded as independent, even if the addresses are
> assigned to interfaces on the same host.

The referenced text has been revised in -13 and is now OK.

> The second issue is that the DHCP server uses the client identifier
> (if it's available) or the chaddr to identify the entity to which an
> address is assigned.  Therefore, it's not possible to assign addresses
> as suggested in the following text:
>
>      *  If the mobile node attaches to the Proxy Mobile IPv6 domain
>          through multiple interfaces, the DHCP server will uniquely
>          identify each of those interfaces from the client hardware
>          address and will perform address assignment.  As the mobile
>          node changes its point of attachment in the network and
>          performs an handoff to a different mobile access gateway, using
>          the same interface, the DHCP server will always be able to
>          identify the binding using the presented client hardware
>          address.  The client hardware address and client identifier
>          will remain as the primary keys for each binding, just as how
>          they are unique in a Binding Cache entry.
>
> Specifically, the client identifier is the identifier for a binding,
> so there is no concept of using both the client identifier and
> hardware address as primary keys.
>
> So, I think I understand what's going on in this first sub-bullet
> (although the first sentence seems out of place).

The preceding bullet appears to be unchanged in -14, and my earlier
comments still apply.  This text needs to be fixed by specifying that the DHCPv4 identifier - client identifier, if supplied, or hardware address - is used by the DHCPv4 server to identify the interface.

> The second sub-bullet, if I understand it correctly, is also easy to
> fix:
>
>      *  However, if the mobile node is capable of performing handoff
>          between interfaces, as per [RFC-5213], the client hardware
>          address in such scenarios needs to be an identifier that is not
>          tied to any of those interfaces.  The identifier must be a
>          stable identifier which remains the same through out the mobile
>          node's attachment in that Proxy Mobile IPv6 domain.  This
>          identifier must remain fixed for a given binding.  This
>          identifier in some implementations can be the identifier
>          associated to a virtual interface, that is abstracting the
>          physical interfaces.
>
> I'm guessing that the idea here is to move the IPv4 address from
> interface A to interface B when the handoff happens.  If I've got that
> right, then the client needs to use the same client identifier for any
> subsequent DHCP message exchanges on interface B.
>
> I'm still not clear about how the use of multiple simultaneous
> interfaces fits into the model.

The preceding bullet also appears to be unchanged in -14, and my
earlier comments still apply. Here, too, what is needed is to replace "hardware address" with some way of describing the DHCP identifier.

> Section 3.4.1 needs some additional detail to describe what happens
> when the steps 2-4 in Figure 5 occur before step 1.  When the DHCP
> server receives the DHCPDISCOVER message, it needs to check to see if
> the tunnel is already set up.
>
> If the tunnel setup is not complete before the DHCP client retransmits
> the DHCPDISCOVER, the DHCP server needs to ignore the subsequent
> DHCPDISCOVER messages and wait for the tunnel to be set up.

This issue is resolved in -13.

> Does the DHCP server also get a subnet mask from the LMA?  I suggest
> also adding text to the second bullet after Figure 5 that the default
> router option in the DHCPOFFER sent to the mobile node be set to the
> default router from the mobile node's Binding Cache entry.

I don't think the subnet mask issue is resolved in the -14 rev.
Text about the default router option was added in the -13 rev, resolving
that issue.

rev -14 still does not resolve the issue in section 3.4.1 in
which the DHCP server should set the Server Identifier option, not
siaddr, to the default router address. 

OLD:

      The DHCPOFFER
      message will have the server address field (siaddr) and the
      default router option set to the mobile node's default router
      address.

NEW:

      The DHCP server includes a DHCP Server Id option (option code
      54) containing the address of the MN's default router, and
      a Router option (option code 3) containing the address of
      the MN's default router in a DHCPOFFER message sent to the MN.

> Still in section 3.4.1, in the subsection that starts at:
>
>    IPv4 Home Address Renewal with a different DHCP server (After
>    Handoff):
>
> How is the mobile node's default router handled during a handoff?
> This paragraph implies that the new MAG may have a different address
> from the old MAG.  But, if the new MAG isn't using the mobile node's
> default router address, how are packets forwarded from the mobile
> node?

I'm still confused by this question in rev -14. 
Does the MN use the same default IPv4 router
throughout the Proxy Mobile IPv6 domain, or is DHCP used to update the
default router information?  This text in section 3.2.3.2 is relevant:

  o  The default router address MUST be obtained from the IPv4 Default-
      Router Address option present in the received Proxy Binding
      Acknowledgement message.  The mobile access gateway MAY configure
      this address on its interface and respond to any ARP requests sent
      by the mobile node for resolving the hardware address of the
      default router.  It MAY also use this address as the source
      address for any datagrams sent to the mobile node and originated
      by the mobile access gateway itself.  It MAY also use this address
      in the DHCP Router option [RFC-2132] in the DHCP messages.

But, why is the configuration of the MAG interface a MAY?  Under what
circumstance would the MAG not add the MN's default router address to
the MAG interface, etc.?  If the MAG does not add the MN's default
router address to the MAG interface, how does IPv4 routing work?

The specific text in the unnumbered section "IPv4 Home Address Renewal with the DHCP server (After Handoff):" seems to be a mix of requirements and recommendations.  It seems to recommend the use of the same IPv4 address on all MAGs, but doesn't explain how DHCP will functions if MAGs use different IPv4 addresses.

> A better way to handle the case in which nMAG has a different address
> than oMAG would be for the nMAG DHCP server to ignore the unicast
> RENEWING DHCPREQUEST messages and respond to the broadcast REBINDING
> DHCPREQUEST message, which is normal DHCP client behavior for changing
> DHCP servers.
>
> I think the error case in which the nMAG "is unable to complete the
> Proxy Mobile IPv6 signaling or is unable to acquire the same IPv4
> address as requested by the mobile node" applies to either case in
> this subsection.

These issues don't appear to be addressed in -14.

> In Section 3.4.2, "Initial IPv4 Home Address Assignment:" should the
> MAG check for an assigned IPv4 home address or the existence of the
> MAG-LMA tunnel?  Or, are those checks equivalent?  Is there a reason
> that the note "the mobile node needs to be identified by the
> MN-Identifier" appears in this step and not the corresponding step in
> the process described in section 3.4.1?

This issue is addressed in -13.

> More generally, I think the corresponding first steps, in which the
> MAG receives a DHCPDISCOVER from the mobile node, in sections 3.4.1
> and 3.4.2 are pretty much the same, except for the location of the
> DHCP server and relay agents.  Yet, the text in the two is much
> different; e.g., 3.4.1 defines "the mobile access gateway MUST NOT
> enable IPv4 support for the mobile node on that access link" while
> 3.4.2 defines "the mobile access gateway will discard the DHCPDISCOVER
> messages from the mobile node" as the behaviors in response to failure
> to set up the tunnel to the LMA.

This issue is addressed in -13.

> Still in section 3.4.2, subsection "IPv4 Home Address Renewal to the
> same DHCP server: (No Handover)", in the third bullet, why would the
> test on the negotiated IPv4 address ever fail and why would the relay
> agent drop the DHCPREQUEST message?

While this issue is not addressed in -13, I suspect it is a simple
belt-and-suspenders check and I consider it closed.

> I think section 3.4.3 applies in the situation where the mobile node
> stack L3 has received an indication that network reattachment has
> happened.  It would be clearer to call this event something other than
> "handoff", which is used in the previous two sections to indicate that
> L3 was not notified of the change in attachment.

There is new text (added in rev -13) in section 3.4.3:

o When a mobile node sends a DHCPDISCOVER message [RFC-2131], the
  DHCP server or the relay agent co-located with the mobile access
  gateway will trigger the mobile access gateway to complete the
  Proxy Mobile IPv6 signaling. This is the required interaction
  between these two protocols. The mobile access gateway on
  receiving this trigger will check if there is already an assigned
  IPv4 home address for the mobile node, from the local mobility
  anchor. If there is no assigned IPv4 home address assigned for
  that mobile node, the mobile access gateway will complete the
  Proxy Mobile IPv6 signaling with the local mobility anchor by
  sending a Proxy Binding Update message.

I think this text is somewhat confusing in conjunction with the
assumption earlier in this draft and in RFC 5213 that the MAG gets a
direct indication of MN attachment.  Figure 5 indicates that the
PBU/PBA message exchange can take place either before or after the
DHCPDISCOVER message is received by the MAG.  The text in question remains unchanged in rev -14,

More new text in rev -13:

o The mobile access gateway will drop all the DHCPDISCOVER messages
  till it completes the Proxy Mobile IPv6 signaling.  If the mobile
  access gateway is unable to complete the Proxy Mobile IPv6
  signaling, or, if the local mobility anchor does not assign an
  IPv4 address for the mobile node, the mobile access gateway MUST
  NOT enable IPv4 home address mobility support for the mobile node
  on that access link.

I think this text is in conflict with Figure 5, which indicates that
the MAG responds immediately to the previously received DHCPDISCOVER
when the PBU/PBA message has completed rather than waiting for the
next DHCPDISCOVER.  Figure 7 is ambiguous on this point as it shows
the initial DHCPDISCOVER arriving at the MAG after the PBU/PBA
messages.  In rev -14, the relevant figures are 7 and 9, but the text in question is unchanged.

More new text from rev -13, unchanged in rev -14:

o Any time the mobile node detects a link change event due to
  handoff, or due to other reasons such as re-establishment of the
  link-layer, the following are the mobile node's considerations
  with respect to the DHCP protocol.

  *  If the mobile node is DNAv4 [RFC-4436] capable and if it
      performs DNAv4 procedures after receiving a link change event,
      it would always detect the same default router on any of the
      access links in that Proxy Mobile IPv6 domain, as the mobile
      access gateway configures a fixed link-layer address on all the
      access links, as per the base Proxy Mobile IPv6 specification
      [RFC-5213].  The mobile node will not perform any DHCP
      operation specifically due to this event.

I think this sub-bullet assumes that the MAG has assigned the MN's
default router address to the MAG's interface.  With that assumption
and the assumption that all MAGs use the same link-layer address, the
MN using the default router as its test node will not detect a change
of network attachment.  But, the earlier text does not require that all MAGs use the same IPv4 address.  What happens in the case where the MN
does detect link change through DNA?

  *  If the mobile node is not DNAv4 [RFC-4436] capable, after
      receiving the link change event it will enter INIT-REBOOT state
      [RFC-2131] and will send a DHCPREQUEST message as specified in
      Section 3.7 of [RFC-2131].  The mobile node will obtain the
      same address configuration as before, as the link change will
      not be transparent to the mobile node in that Proxy Mobile IPv6
      domain.

While the MN may obtain the same address configuration as before (and
the details should be spelled out), I don't see how the second half of
the last sentence follows from the first half.

[Ballot discuss]
I've updated my discuss based on version -14 of the draft. Many of my
concerns have been resolved in this version, but the following need
some discussion and/or changes:

3) Section 3.4.3 now mentions the Interface MTU DHCP option, but
there's nothing about processing of user data packets at MAG/LMA.  I
expect some existing RFCs already have the details (DF bit, ICMP Too
Big, etc. when doing IPv4-over-IPv6 and IPv6-over-IPv4), so possibly
pointers to those RFCs (making clear what the MAG and LMA have to
implement here) could be enough.

6) Section 4.3 is a big improvement over the earlier versions, and the
new figures are really good. However, both of them address only the
"incoming packet" part -- there should be similar figure for outgoing
packets (when LMA sends PBA, or MAG sends PBU). Also, the text
currently covers only PBU/PBA processing, but not the optional payload
protection (for MN's data traffic).

[Ballot discuss]
I've updated my discuss based on version -14 of the draft. Many of my
concerns have been resolved in this version, but the following need
some discussion and/or changes:

2) What does the MAG do with the IPv4 subnet mask it receives from the
LMA? (Or in other words: what parts of MAG functionality actually use
this value for something?)

3) Section 3.4.3 now mentions the Interface MTU DHCP option, but
there's nothing about processing of user data packets at MAG/LMA.  I
expect some existing RFCs already have the details (DF bit, ICMP Too
Big, etc. when doing IPv4-over-IPv6 and IPv6-over-IPv4), so possibly
pointers to those RFCs (making clear what the MAG and LMA have to
implement here) could be enough.

6) Section 4.3 is a big improvement over the earlier versions, and the
new figures are really good. However, both of them address only the
"incoming packet" part -- there should be similar figure for outgoing
packets (when LMA sends PBA, or MAG sends PBU). Also, the text
currently covers only PBU/PBA processing, but not the optional payload
protection (for MN's data traffic).

[Ballot comment]
Is there any impact of lease lengths on the use of DHCP address
assignment?  If so, guidance would be helpful; if not, explicitly
mentioning that lease length doesn't matter would be helpful.

Nit: s/handover/handoff/ for consistency (I think there is just one
occurrence of "handover")

Nit: s/default-router/default router/ for consistency (both are used
in various places in the document)

In section 3.4.1, is there a sentence fragment or some other kind of
typo here:

    The use of fixed DHCP server address on all DHCP servers
    MN  oMAG(DHCP-S) nMAG(DHCP-S)
      |      :        |
    RENEW------------->|    1. DHCPREQUEST (IPv4 HoA)
    BOUND<-------------|    2. DHCPACK or DHCPNACK
      |      :        |

          Figure 6: Address renewal with a different DHCP server

In figure 7, deleted "(IPv4HoA)" in step 4.

[Ballot discuss]
I've updated my DISCUSS based on rev -13 of the doc.  Some, but not
all, of my issues have been addressed.  I've added comments explaining
my responses to the changes in the doc.  In addition, I have some new
issues with text added to section 3.4.3.

> From conversations with the authors, a "handoff" is a change of
> network attachment that is not reported to layer 3 as a loss of link
> connection.  The differentiation between handoff and a change of
> network attachment that is reported to L3 is important in section 3.4,
> as a DHCP message exchange is triggered by network reconnection
> reported to L3.
>
> The use of 'client identifier' and 'chaddr' in this text from section
> 3.4 differs from the use of those fields in DHCP servers.
>
>    o  A DHCP server identifies the DHCP client and its interface for
>      which the address is assigned from the client identifier and the
>      client hardware address (chaddr) [RFC-2131] fields respectively.
>      A mobile node in a Proxy Mobile IPv6 domain, can attach to the
>      network through multiple interfaces and additionally may perform
>      handoffs between its interfaces.  Following are the related
>      considerations:
>
> The first issue is that DHCPv4 does not have any concept of multiple
> interfaces attached to a single host computer.  Each address
> assignment - called a 'binding' (this term should be cited as defined
> in RFC 2131, to clarify and make distinct from other bindings in this
> document) - is regarded as independent, even if the addresses are
> assigned to interfaces on the same host.

The referenced text has been revised in -13 and is now OK.

> The second issue is that the DHCP server uses the client identifier
> (if it's available) or the chaddr to identify the entity to which an
> address is assigned.  Therefore, it's not possible to assign addresses
> as suggested in the following text:
>
>      *  If the mobile node attaches to the Proxy Mobile IPv6 domain
>          through multiple interfaces, the DHCP server will uniquely
>          identify each of those interfaces from the client hardware
>          address and will perform address assignment.  As the mobile
>          node changes its point of attachment in the network and
>          performs an handoff to a different mobile access gateway, using
>          the same interface, the DHCP server will always be able to
>          identify the binding using the presented client hardware
>          address.  The client hardware address and client identifier
>          will remain as the primary keys for each binding, just as how
>          they are unique in a Binding Cache entry.
>
> Specifically, the client identifier is the identifier for a binding,
> so there is no concept of using both the client identifier and
> hardware address as primary keys.
>
> So, I think I understand what's going on in this first sub-bullet
> (although the first sentence seems out of place).

The preceding bullet appears to be unchanged in -13, and my earlier
comments still apply.

> The second sub-bullet, if I understand it correctly, is also easy to
> fix:
>
>      *  However, if the mobile node is capable of performing handoff
>          between interfaces, as per [RFC-5213], the client hardware
>          address in such scenarios needs to be an identifier that is not
>          tied to any of those interfaces.  The identifier must be a
>          stable identifier which remains the same through out the mobile
>          node's attachment in that Proxy Mobile IPv6 domain.  This
>          identifier must remain fixed for a given binding.  This
>          identifier in some implementations can be the identifier
>          associated to a virtual interface, that is abstracting the
>          physical interfaces.
>
> I'm guessing that the idea here is to move the IPv4 address from
> interface A to interface B when the handoff happens.  If I've got that
> right, then the client needs to use the same client identifier for any
> subsequent DHCP message exchanges on interface B.
>
> I'm still not clear about how the use of multiple simultaneous
> interfaces fits into the model.

The preceding bullet also appears to be unchanged in -13, and my
earlier comments still apply.

> Section 3.4.1 needs some additional detail to describe what happens
> when the steps 2-4 in Figure 5 occur before step 1.  When the DHCP
> server receives the DHCPDISCOVER message, it needs to check to see if
> the tunnel is already set up.
>
> If the tunnel setup is not complete before the DHCP client retransmits
> the DHCPDISCOVER, the DHCP server needs to ignore the subsequent
> DHCPDISCOVER messages and wait for the tunnel to be set up.

This issue is resolved in -13.

> Does the DHCP server also get a subnet mask from the LMA?  I suggest
> also adding text to the second bullet after Figure 5 that the default
> router option in the DHCPOFFER sent to the mobile node be set to the
> default router from the mobile node's Binding Cache entry.

These questions still need to be addressed by adding text about where
the DHCP server gets the subnet mask for the MN, and that the
DHCPOFFER needs to supply the Subnet Mask option and the Default
Router option to the MN.

Also, on re-reading this section more carefully, I see that the DHCP
server should set the Server Identifier option, not siaddr, to the
default router address.

> Still in section 3.4.1, in the subsection that starts at:
>
>    IPv4 Home Address Renewal with a different DHCP server (After
>    Handoff):
>
> How is the mobile node's default router handled during a handoff?
> This paragraph implies that the new MAG may have a different address
> from the old MAG.  But, if the new MAG isn't using the mobile node's
> default router address, how are packets forwarded from the mobile
> node?

I'm still confused by this question, and in trying to understand the
mechanism, I realized I must be missing something in the underlying
addressing model.  Does the MN use the same default IPv4 router
throughout the Proxy Mobile IPv6 domain, or is DHCP used to update the
default router information?  This text in section 3.2.3.2 is relevant:

  o  The default router address MUST be obtained from the IPv4 Default-
      Router Address option present in the received Proxy Binding
      Acknowledgement message.  The mobile access gateway MAY configure
      this address on its interface and respond to any ARP requests sent
      by the mobile node for resolving the hardware address of the
      default router.  It MAY also use this address as the source
      address for any datagrams sent to the mobile node and originated
      by the mobile access gateway itself.  It MAY also use this address
      in the DHCP Router option [RFC-2132] in the DHCP messages.

But, why is the configuration of the MAG interface a MAY?  Under what
circumstance would the MAG not add the MN's default router address to
the MAG interface, etc.?  If the MAG does not add the MN's default
router address to the MAG interface, how does IPv4 routing work?

> A better way to handle the case in which nMAG has a different address
> than oMAG would be for the nMAG DHCP server to ignore the unicast
> RENEWING DHCPREQUEST messages and respond to the broadcast REBINDING
> DHCPREQUEST message, which is normal DHCP client behavior for changing
> DHCP servers.
>
> I think the error case in which the nMAG "is unable to complete the
> Proxy Mobile IPv6 signaling or is unable to acquire the same IPv4
> address as requested by the mobile node" applies to either case in
> this subsection.

These issues don't appear to be addressed in -13.

> In Section 3.4.2, "Initial IPv4 Home Address Assignment:" should the
> MAG check for an assigned IPv4 home address or the existence of the
> MAG-LMA tunnel?  Or, are those checks equivalent?  Is there a reason
> that the note "the mobile node needs to be identified by the
> MN-Identifier" appears in this step and not the corresponding step in
> the process described in section 3.4.1?

This issue is addressed in -13.

> More generally, I think the corresponding first steps, in which the
> MAG receives a DHCPDISCOVER from the mobile node, in sections 3.4.1
> and 3.4.2 are pretty much the same, except for the location of the
> DHCP server and relay agents.  Yet, the text in the two is much
> different; e.g., 3.4.1 defines "the mobile access gateway MUST NOT
> enable IPv4 support for the mobile node on that access link" while
> 3.4.2 defines "the mobile access gateway will discard the DHCPDISCOVER
> messages from the mobile node" as the behaviors in response to failure
> to set up the tunnel to the LMA.

This issue is addressed in -13.

> Still in section 3.4.2, subsection "IPv4 Home Address Renewal to the
> same DHCP server: (No Handover)", in the third bullet, why would the
> test on the negotiated IPv4 address ever fail and why would the relay
> agent drop the DHCPREQUEST message?

While this issue is not addressed in -13, I suspect it is a simple
belt-and-suspenders check and I consider it closed.

> I think section 3.4.3 applies in the situation where the mobile node
> stack L3 has received an indication that network reattachment has
> happened.  It would be clearer to call this event something other than
> "handoff", which is used in the previous two sections to indicate that
> L3 was not notified of the change in attachment.

There is new text in section 3.4.3:

o When a mobile node sends a DHCPDISCOVER message [RFC-2131], the
  DHCP server or the relay agent co-located with the mobile access
  gateway will trigger the mobile access gateway to complete the
  Proxy Mobile IPv6 signaling. This is the required interaction
  between these two protocols. The mobile access gateway on
  receiving this trigger will check if there is already an assigned
  IPv4 home address for the mobile node, from the local mobility
  anchor. If there is no assigned IPv4 home address assigned for
  that mobile node, the mobile access gateway will complete the
  Proxy Mobile IPv6 signaling with the local mobility anchor by
  sending a Proxy Binding Update message.

I think this text is somewhat confusing in conjunction with the
assumption earlier in this draft and in RFC 5213 that the MAG gets a
direct indication of MN attachment.  Figure 5 indicates that the
PBU/PBA message exchange can take place either before or after the
DHCPDISCOVER message is received by the MAG.

More new text:

o The mobile access gateway will drop all the DHCPDISCOVER messages
  till it completes the Proxy Mobile IPv6 signaling.  If the mobile
  access gateway is unable to complete the Proxy Mobile IPv6
  signaling, or, if the local mobility anchor does not assign an
  IPv4 address for the mobile node, the mobile access gateway MUST
  NOT enable IPv4 home address mobility support for the mobile node
  on that access link.

I think this text is in conflict with Figure 5, which indicates that
the MAG responds immediately to the previously received DHCPDISCOVER
when the PBU/PBA message has completed rather than waiting for the
next DHCPDISCOVER.  Figure 7 is ambiguous on this point as it shows
the initial DHCPDISCOVER arriving at the MAG after the PBU/PBA
messages.

More new text:

o Any time the mobile node detects a link change event due to
  handoff, or due to other reasons such as re-establishment of the
  link-layer, the following are the mobile node's considerations
  with respect to the DHCP protocol.

  *  If the mobile node is DNAv4 [RFC-4436] capable and if it
      performs DNAv4 procedures after receiving a link change event,
      it would always detect the same default router on any of the
      access links in that Proxy Mobile IPv6 domain, as the mobile
      access gateway configures a fixed link-layer address on all the
      access links, as per the base Proxy Mobile IPv6 specification
      [RFC-5213].  The mobile node will not perform any DHCP
      operation specifically due to this event.

I think this sub-bullet assumes that the MAG has assigned the MN's
default router address to the MAG's interface.  With that assumption
and the assumption that all MAGs use the same link-layer address, the
MN using the default router as its test node will not detect a change
of network attachment.

  *  If the mobile node is not DNAv4 [RFC-4436] capable, after
      receiving the link change event it will enter INIT-REBOOT state
      [RFC-2131] and will send a DHCPREQUEST message as specified in
      Section 3.7 of [RFC-2131].  The mobile node will obtain the
      same address configuration as before, as the link change will
      not be transparent to the mobile node in that Proxy Mobile IPv6
      domain.

While the MN may obtain the same address configuration as before (and
the details should be spelled out), I don't see how the second half of
the last sentence follows from the first half.

[Ballot discuss]
I have reviewed draft-ietf-netlmm-pmip6-ipv4-support-12, and have
couple of questions/concerns that I'd like to discuss before
recommending approval of the document:

1) When the MN attaches to an access link, how does the MAG determine
whether the MN is IPv4-only, IPv6-only, or dual-stack?

Figure 3.4.1 suggests the MAG would wait until it receives
DHCPDISCOVER before sending the PBU -- but if the MN host has
e.g. disabled IPv4, the DHCPDISCOVER will never come...?

While the policy profile might tell whether the user is authorized for
IPv4, IPv6, or both, that doesn't necessarily tell what the actual
hosts supports -- the user might have changed the configuration,
upgraded from XP to Vista, or something.

2) I had some difficulties in understanding what the text about
"subnet mask" means. It seems this specification doesn't support
allocating an IPv4 prefix to the MN, only a single address, right? In
this situation, draft-ietf-mext-nemo-v4-traversal says that the
Prefix-len field in IPv4 Home Address Option is set to 32.  But if the
MN gets only a single IPv4 (home) address, what does the MAG do with
subnet masks?

3) I was expecting to see some text about MTU and related issues (at
least pointers to other documents -- quite obviously, the text in base
PMIP6 doesn't work as is here), and perhaps something about the
Interface MTU DHCP option. But the draft never mentions MTU at all?

4) Section 3.4.1 says that when the MN needs to send a DHCP lease
renewal, but it has moved to a different MAG, "it is required that the
mobile node updates the DHCP server address and uses the address of
the DHCP server that is co-located with the new mobile access
gateway". How does this happen? Does this require PMIP-specific
modifications to the DHCP code?

5) Section 3.4.3 says DHCPRELEASE "should not release any IPv6 home
network prefix(es) assigned to the mobile node". Why isn't this
"MUST NOT release..."?

6) RFC 5213 uses IPsec in a very simple way (much simpler than client
Mobile IPv6), and doesn't really require anything Mobile IP specific
from the IPsec stack (beyond using MH type as traffic selector). The
text in Section 4 isn't very clear on how IPsec would be used
(e.g. what the SAD/SPD entries would be?) here, but it seems to assume
some unspecified modifications to the IPsec stack (perhaps similar to
DSMIPv6, but it's not clear).

This text needs to be significantly clearer on how the IPsec
processing would actually work, and what the SAs (negotiated by
e.g. IKEv2) would actually be. I would really prefer if we could
keep this simpler than DSMIPv6 (where the IPsec parts are absolutely
horrible).

7) Section 3.3.2: The IPv4 DHCP Support Mode option has number of bits
reserved for future use. Should there be an IANA registry?

8) IANA considerations doesn't mention the IPv4 DHCP Support Mode
Option?

[Ballot comment]
Paraphrased from Stephen Farrell's secdir review:

3.1.2.7 says: "when there is not a single Home Network Prefix
option with NON_ZERO value present in the request..." That's very
hard to interpret and possibly badly ambiguous. "Not a single" could
mean zero or >1.

Perhaps "when there are no Home Network Prefix options with a
NON_ZERO value present in the request ..." would be clearer.

3.1.3 says that the mobility anchor MUST advertise a connected
route but doesn't say how.  Perhaps a reference is in order here?

section 7: s/news/new/

[Ballot comment]
The OPSA-DIR review included a number of editorial comments. None of them is a show stopper, but incase the document goes though a revision for other reasons I suggest that they are considered.

[Ballot comment]
I have raised my issues as Comments as they are all editorial. But
the volume of issues brings them very close to being bundled together
as a Discuss.

===

I know that the RFC Editor can sort a lot of this out, and it is no
criticism of the authors, but the reviews would be smoother and more
likely to focus on technical details if in future you could get
someone to take a pass on the English of the document preferably
before WG last call.

Fixing some of the language has the potential to accidentally break
the meaning of the text, and you cannot rely on the RFC Editor to
understand all of the technical details.

===

Section 1
  It is also reasonable to expect the same
  mobility infrastructure in the Proxy Mobile IPv6 domain to provide
  mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode
  and when the network between the local mobility anchor and the mobile
  access gateway is an IPv4 or an IPv6 network.

I can't parse this sentence. I get lost around "and when". Any chance
of a rephrase?

===

Section 1 bullet 1
      The mobile node is not required to be
      allocated or assigned an IPv6 address for enabling IPv4 home
      address support.

I think you mean s/for enabling/to enable/  but this is a subtly
different meaning.

===

Figure 1

This figure is an orphan! I can't find any text that refers to it and
it really needs some explanation. It also uses some acronyms that aren't
explained until quite a bit later.

It *is* good to have a figure early in the I-D, but you can't just plonk
it in.

===

Section 1.1

The section title is clear, and the bullet points appear to match the
title, but the introduction paragraph:
  The following are the configuration requirements from the mobility
  entities in the Proxy Mobile IPv6 domain for supporting the
  extensions defined in this document.
talks of configuration requirements and is only relevant to some of
the assumptions. Separate assumptions from configuration requirements?

===

Figure 2 also uses some acronyms/identifiers that are not explained.

===

I don't find the use of "IPv4 default-router" and "IPv4 default-router
address" very clear.

In 1.1 there is
      The mobile access gateway is the IPv4 default-router for the
      mobile node on its access link.
which is clear.
But later (3.1.1 etc. and even in 3.3.1)
      The IPv4 default-router address assigned to the mobile node.
Can you make this clear throughout the document (search on default-
router) whether this is an address assigned to the mobile node (i.e.
and address of the mobile node) or the address of the default-router
that has been assigned to the mobile node (i.e. the address of the
default-router).

===

3.3.2

You might consider creating a registry for bits in the DHCP Support
Mode Option.

===

The IANA section seems to be deficient in detail and also missing the
IPv4 DHCP Support Mode Option. But I see that IANA has an open issue
to be addressed by the authors.

===

[Ballot discuss]
From conversations with the authors, a "handoff" is a change of
network attachment that is not reported to layer 3 as a loss of link
connection.  The differentiation between handoff and a change of
network attachment that is reported to L3 is important in section 3.4,
as a DHCP message exchange is triggered by network reconnection
reported to L3.

The use of 'client identifier' and 'chaddr' in this text from section
3.4 differs from the use of those fields in DHCP servers.

  o  A DHCP server identifies the DHCP client and its interface for
      which the address is assigned from the client identifier and the
      client hardware address (chaddr) [RFC-2131] fields respectively.
      A mobile node in a Proxy Mobile IPv6 domain, can attach to the
      network through multiple interfaces and additionally may perform
      handoffs between its interfaces.  Following are the related
      considerations:

The first issue is that DHCPv4 does not have any concept of multiple
interfaces attached to a single host computer.  Each address
assignment - called a 'binding' (this term should be cited as defined
in RFC 2131, to clarify and make distinct from other bindings in this
document) - is regarded as independent, even if the addresses are
assigned to interfaces on the same host.

The second issue is that the DHCP server uses the client identifier
(if it's available) or the chaddr to identify the entity to which an
address is assigned.  Therefore, it's not possible to assign addresses
as suggested in the following text:

      *  If the mobile node attaches to the Proxy Mobile IPv6 domain
        through multiple interfaces, the DHCP server will uniquely
        identify each of those interfaces from the client hardware
        address and will perform address assignment.  As the mobile
        node changes its point of attachment in the network and
        performs an handoff to a different mobile access gateway, using
        the same interface, the DHCP server will always be able to
        identify the binding using the presented client hardware
        address.  The client hardware address and client identifier
        will remain as the primary keys for each binding, just as how
        they are unique in a Binding Cache entry.

Specifically, the client identifier is the identifier for a binding,
so there is no concept of using both the client identifier and
hardware address as primary keys.

So, I think I understand what's going on in this first sub-bullet
(although the first sentence seems out of place).

The second sub-bullet, if I undertstand it correctly, is also easy to
fix:

      *  However, if the mobile node is capable of performing handoff
        between interfaces, as per [RFC-5213], the client hardware
        address in such scenarios needs to be an identifier that is not
        tied to any of those interfaces.  The identifier must be a
        stable identifier which remains the same through out the mobile
        node's attachment in that Proxy Mobile IPv6 domain.  This
        identifier must remain fixed for a given binding.  This
        identifier in some implementations can be the identifier
        associated to a virtual interface, that is abstracting the
        physical interfaces.

I'm guessing that the idea here is to move the IPv4 address from
interface A to interface B when the handoff happens.  If I've got that
right, then the client needs to use the same client identifier for any
subsequent DHCP message exchanges on interface B.

I'm still not clear about how the use of multiple simultaneous
interfaces fits into the model.

Section 3.4.1 needs some additional detail to describe what happens
when the steps 2-4 in Figure 5 occur before step 1.  When the DHCP
server receives the DHCPDISCOVER message, it needs to check to see if
the tunnel is already set up.

If the tunnel setup is not complete before the DHCP client retransmits
the DHCPDISCOVER, the DHCP server needs to ignore the subsequent
DHCPDISCOVER messages and wait for the tunnel to be set up.

Does the DHCP server also get a subnet mask from the LMA?  I suggest
also adding text to the second bullet after Figure 5 that the default
router option in the DHCPOFFER sent to the mobile node be set to the
default router from the mobile node's Binding Cache entry.

Still in section 3.4.1, in the subsection that starts at:

  IPv4 Home Address Renewal with a different DHCP server (After
  Handoff):

How is the mobile node's default router handled during a handoff?
This paragraph implies that the new MAG may have a different address
from the old MAG.  But, if the new MAG isn't using the mobile node's
default router address, how are packets forwarded from the mobile
node?

A better way to handle the case in which nMAG has a different address
than oMAG would be for the nMAG DHCP server to ignore the unicast
RENEWING DHCPREQUEST messages and respond to the broadcast REBINDING
DHCPREQUEST message, which is normal DHCP client behavior for changing
DHCP servers.

I think the error case in which the nMAG "is unable to complete the
Proxy Mobile IPv6 signaling or is unable to acquire the same IPv4
address as requested by the mobile node" applies to either case in
this subsection.

In Section 3.4.2, "Initial IPv4 Home Address Assignment:" should the
MAG check for an assigned IPv4 home address or the existence of the
MAG-LMA tunnel?  Or, are those checks equivalent?  Is there a reason
that the note "the mobile node needs to be identified by the
MN-Identifier" appears in this step and not the corresponding step in
the process described in section 3.4.1?

More generally, I think the corresponding first steps, in which the
MAG receives a DHCPDISCOVER from the mobile node, in sections 3.4.1
and 3.4.2 are pretty much the same, except for the location of the
DHCP server and relay agents.  Yet, the text in the two is much
different; e.g., 3.4.1 defines "the mobile access gateway MUST NOT
enable IPv4 support for the mobile node on that access link" while
3.4.2 defines "the mobile access gateway will discard the DHCPDISCOVER
messages from the mobile node" as the behaviors in response to failure
to set up the tunnel to the LMA.

Still in section 3.4.2, subsection "IPv4 Home Address Renewal to the
same DHCP server: (No Handover)", in the third bullet, why would the
test on the negotiated IPv4 address ever fail and why would the relay
agent drop the DHCPREQUEST message?

I think section 3.4.3 applies in the situation where the mobile node
stack L3 has received an indication that network reattachment has
happened.  It would be clearer to call this event something other than
"handoff", which is used in the previous two sections to indicate that
L3 was not notified of the change in attachment.

[Ballot comment]
Is there any impact of lease lengths on the use of DHCP address
assignment?  If so, guidance would be helpful; if not, explicitly
mentioning that lease length doesn't matter would be helpful.

Nit: s/handover/handoff/ for consistency (I think there is just one
occurrence of "handover")

Nit: s/default-router/default router/ for consistency (both are used
in various places in the document)

In section 3.4.1, is there a sentence fragment or some other kind of
typo here:

    The use of fixed DHCP server address on all DHCP servers
    MN  oMAG(DHCP-S) nMAG(DHCP-S)
      |      :        |
    RENEW------------->|    1. DHCPREQUEST (IPv4 HoA)
    BOUND<-------------|    2. DHCPACK or DHCPNACK
      |      :        |

          Figure 6: Address renewal with a different DHCP server

In figure 7, deleted "(IPv4HoA)" in step 4.

[Ballot discuss]
Spencer Dawkins posted an extensive Gen-ART Review.  See
  http://www.ietf.org/mail-archive/web/gen-art/current/msg04081.html

  The review has resulted in some additional discussion, which is also
  in the Gen-ART mail archive.  It is pretty clear to me that an update
  to the Internet-Draft is needed once the discussion converges.

IANA questions/comments:

- The IANA consideration section is not clear on what actions are
requested of IANA. In addition, there appear to be allocation
requests in sections not pointed to by the IANA Considerations.

- The IANA Considerations references section 3.3.2 for Action 2, but
the registrations are in section 3.3.3. You should copy the list by
value into the IANA Considerations Section.

- Section 3.3.2 defines a new Option (DHCP Support Mode) that is not
referenced in the IANA Considerrations Section. You should add this
registration to the IANA Considerations Section.


Action 1:

Upon approval of this document, IANA will make the following
assignment in the "Mobility Options" registry at
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Value Description Reference
----- ----------- ---------
tbd IPv4 Default Router Address [RFC-netlmm-pmip6-ipv4-support-12]


Action 2:

Upon approval of this document, IANA will make the following
assignments in the "Status Codes" registry at
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Value Description Reference
----- ----------- ---------
tbd NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS [RFC-netlmm-pmip6-ipv4-support-12]
tbd NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX [RFC-netlmm-pmip6-ipv4-support-12]
tbd MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED
[RFC-netlmm-pmip6-ipv4-support-12]
tbd IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED [RFC-netlmm-pmip6-ipv4-support-12]

# (1.a) Who is the Document Shepherd for this document? Has the Document # Shepherd personally reviewed this version of the document and, in particular, # does he or she believe this version is ready for forwarding to the IESG for # publication?

Document Shepherd is Vidya Narayanan. I have personally reviewed the document and I believe the document is ready for publication.


# (1.b) Has the document had adequate review both from key WG members and
from
# key non-WG members? Does the Document Shepherd have any concerns about the
# depth or breadth of the reviews that have been performed?

The document has had extensive reviews within the WG. I do not have any concerns about the depth or breadth of reviews received.


# (1.c) Does the Document Shepherd have concerns that the document needs
more
# review from a particular or broader perspective, e.g., security,
operational
# complexity, someone familiar with AAA, internationalization or XML?

I have no concerns about the reviews for this document.


# (1.d) Does the Document Shepherd have any specific concerns or issues with
# this document that the Responsible Area Director and/or the IESG should be
# aware of? For example, perhaps he or she is uncomfortable with certain
parts
# of the document, or has concerns whether there really is a need for it. In
# any event, if the WG has discussed those issues and has indicated that it
# still wishes to advance the document, detail those concerns here. Has an
# IPR disclosure related to this document been filed? If so, please include
a
# reference to the disclosure and summarize the WG discussion and conclusion
# on this issue.

I have no concerns on the document. There have been no IPR disclosures filed on this document.


# (1.e) How solid is the WG consensus behind this document? Does it
# represent the strong concurrence of a few individuals, with others
# being silent, or does the WG as a whole understand and agree with it?

There is a strong consensus behind the document.


# (1.f) Has anyone threatened an appeal or otherwise indicated extreme
# discontent? If so, please summarise the areas of conflict in separate
# email messages to the Responsible Area Director. (It should be in a
# separate email because this questionnaire is entered into the ID Tracker.)

Nobody has threatened to appeal and the document is a product of the WG as a whole.


# (1.g) Has the Document Shepherd personally verified that the document
# satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
# http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
# enough; this check needs to be thorough. Has the document met all formal
# review criteria it needs to, such as the MIB Doctor, media type and URI
# type reviews?

ID Nits produces a couple of warnings about non RFC3330 compliant IP addresses on section numbers that appears to be a bug in ID Nits. Otherwise, there are no ID nits errors or warnings on the document.


# (1.h) Has the document split its references into normative and
informative?
# Are there normative references to documents that are not ready for
# advancement or are otherwise in an unclear state? If such normative
# references exist, what is the strategy for their completion? Are there
# normative references that are downward references, as described in
# [RFC3967]? If so, list these downward references to support the Area
# Director in the Last Call procedure for them [RFC3967].

There is a split to normative and informative references. The document has draft-ietf-mext-nemo-v4traversal as a normative reference. This draft is already in IESG evaluation and is expected to be published soon. So, there is no concern on having normative references in an unclear state. There are no downward references in the document.

# (1.i) Has the Document Shepherd verified that the document IANA
# consideration section exists and is consistent with the body of the
# document? If the document specifies protocol extensions, are reservations
# requested in appropriate IANA registries? Are the IANA registries clearly
# identified? If the document creates a new registry, does it define the
# proposed initial contents of the registry and an allocation procedure for
# future registrations? Does it suggest a reasonable name for the new
# registry? See [RFC2434]. If the document describes an Expert Review
# process has Shepherd conferred with the Responsible Area Director so that
# the IESG can appoint the needed Expert during the IESG Evaluation?

Yes, IANA considerations section does exist and seems to be in line with the
rest of the document.


# (1.j) Has the Document Shepherd verified that sections of the document
that
# are written in a formal language, such as XML code, BNF rules, MIB
# definitions, etc., validate correctly in an automated checker?

No formal language segments exist.


# (1.k) The IESG approval announcement includes a Document Announcement
# Write-Up. Please provide such a Document Announcement Write-Up? Recent
# examples can be found in the "Action" announcements for approved
documents.
# The approval announcement contains the following sections:

Technical Summary
The Proxy Mobile IPv6 specification in RFC 5213 describes network based mobility management for IPv6 hosts across IPv6 network domains. This document describes the necessary extensions to RFC 5213 to support IPv4-only and dual stacked hosts. It also supports IPv4 network traversal between the Mobile Access Gateway (MAG) in the access network and the Local Mobility Anchor (LMA).

Working Group Summary
There is a consensus in the NETLMM WG for publication as a proposed standard.

Document Quality
The document has gone through various reviews and a successful WGLC.

Personnel
Responsible AD is Jari Arkko and the document shepherd is Vidya Narayanan.