Proxy Mobile IPv6
draft-ietf-netlmm-proxymip6-18

Section 4., paragraph 2:
> The mobile access gateway and the local mobility anchor MUST
> implement IPsec for protecting the Proxy Mobile IPv6 signaling
> messages [RFC-4301].  That is, IPsec is mandatory to implement
> security mechanism.  However, additional documents may specify
> alternative mechanisms.

  Is there a mechanism by which the MAG and the LMA can detect if the
  other side is using one of the to-be-defined mechanisms, i.e., not
  IPsec? Or is this supposed to be up to configuration?


Section 5.3.6., paragraph 0:
> 5.3.6.  Constructing the Proxy Binding Acknowledgement Message

  This section has several "option X MUST be present, if..." constructs.
  Please say something about whether option X MAY or MUST NOT be present
  when the conditional is false.


Section 3., paragraph 0:
>     Alternatively, if there is mobile
>     node generated timestamp that is increasing at every attachment
>     to the access link and if that timestamp is available to the
>     mobile access gateway (Ex: The timestamp option in the SEND
>     messages that the mobile node sends), the mobile access gateway
>     can use this timestamp or sequence number in the Proxy Binding
>     Update messages and does not have to depend on any external clock
>     source.  However, the specific details on how this is achieved is
>     outside the scope of this document.

  The MN link-attach "timestamp" here might as well be a sequence
  number, so it's not quite accurate to characterize this a
  timestamps-based approach. The magic bits from the MN are carried
  inside the timestamp fields, but that's about as much as can be said.
  Essentially, this scheme is a third approach that depends on the side
  effects of certain link layer technologies implemented at the MN, and
  I'm not extremely thrilled to see this suggested in an IETF document.


Section 2., paragraph 0:
> 2.  An implementation MUST support Sequence Number based scheme, as
>     per [RFC-3775].

  It would be good to repeat the requirement from above that to use this
  scheme, a mechanisms that synchronizes the last sequence number sent
  across all MAGs is REQUIRED.


Section 10., paragraph 0:
> 10.  IANA Considerations

  Who are the proposed IANA Experts for the registries requiring expert
  review? (Question to the AD.)


Nits:

Section 4.1., paragraph 2:
>          and authorize CHILD_SA for remote address lma_addres_1

  Nit: s/lma_addres_1/lma_address_1/


Section 9., paragraph 12:
>    EnableMAGLocalrouting

  Nit: s/EnableMAGLocalrouting/EnableMAGLocalRouting/

Current specs about Mobile IPv6/IPsec interaction specify also
payload packet protection (which is optional to use). Section 4
about Proxy Mobile IPv6/IPsec interaction seems to ignore this
topic entirely.  At least a statement that no payload packet
protection is provided (possibly with short rationale why not)
should be there.

Section 5.3.2, step 3, is unclear about whether the LMA is allowed
to ignore the prefix "hint" or not. The text seems to say that if
the hint cannot be respected, the LMA must return an error -- but
then calling it "hint" is slightly misleading.

Section 4 would have been lot easier to understand if it had said
in the beginning that PBUs don't have the Home Address destination
option (and PBAs don't have the Type 2 RH with home address).

  The Gen-ART Review by Elwyn Davies raises two things that might
  deserve some attention.  He previously reviewed -10, and this
  is from his subsequent review of -11.  Elwyn said:

  An editorial update added to s3, para 4 (just after fig 1) to
  emphasize the pivotal role of the MN-Identity would be helpful.
  Something like:
    'The authenticated, stable identifier of the mobile node
     (MN-Identifier) uniquely identifies the mobile node to the
     LMA(s) as the node roams through the Proxy Mobile Domain.'

  Outstanding query: s6.1, bullet 2:  This bullet refers to '*the*
  interface identifier' and suggests that it might be retrieved
  from a Router Solicitation.  My original point was that the IID
  for IPv6 addresses is not necessarily common between the addresses
  configured on an interface.  My comment was a little glib and the
  authors glossed over the point in their reply.  I think this bullet
  may require clarification to indicate which of the IIDs would be
  implied here.  Particularly if SEND is in use, the IID used for the
  link local address (that would typically be found in the
  solicitation) will a.s. differ from the IID used with the address
  assigned out of the prefix allocated by Proxy MIP.  My original
  point was to ask the authors to clarify whether ProxyMIP actually
  cares which IID is used and, accordingly, state either that 'it
  doesn't matter' or specifically which IID should be transmitted.

The security considerations provide a nice description of how the Proxy Mobile IPv6 protocol
defends itself against most of the threats listed in RFC 4382, but does not address threats
from the Internet (Section 4 of RFC 4382).  For completeness, please note how the Proxy Mobile
IPv6 protocol does (or does not) defend against these threats.