Subject: Re: [netlmm] A review of draft-ietf-netlmm-pmip6-ipv4-support-16

From: Sri Gundavelli <[email-masked]>
Date: Fri, 11 Sep 2009 08:47:23 -0700 (PDT)

Thanks Pekka for the final review/cross checking. We will address
these comments and respond, will fix any inconsistencies/nits.
Appreciate your time on this review.

Regards
Sri

On Fri, 11 Sep 2009, Pekka Savola wrote:

> Hello,
>
> I've done a quick review of draft-ietf-netlmm-pmip6-ipv4-support-16 at AD 
> request.  I have only vague understanding of PMIP6 so take this with a grain 
> of salt.
>
> The document is written in a manner that should be easy to implement, but a 
> bit challenging to verify from the spec point of view for correctness and 
> that all the corner cases are dealt with.  This is an OK documentation 
> decision.  The spec also contains a bit of unnecessary repetition, but this 
> is not harmful as long as the length doesn't grow much or introduce 
> inconsistencies.
>
> I wonder at the original PMIP6 design decision that MAGs establish tunnels to 
> LMAs dynamically.  Are there really so many potential LMAs for each MAG that 
> these could not be set permanently, as a separate specification or 
> independent of MNs' behaviour?  A lot of space and complexity in the spec is 
> introduced by verifying whether the MAG-LMA tunnel has been set up.  This 
> also creates delays and complexities (users' packets dropped until the tunnel 
> is up) when the tunnel does not exist yet, tearing down tunnels, etc.  A 
> simpler alternative could have been that the MAG establishes tunnels when its 
> MAG services are started and they will always remain up. But again, the horse 
> has already left the barn.
>
> The specification only supports unicast; this is not stated in the spec.
>
> The security considerations section is a bit weak, but I don't have the 
> energy to comment on it in detail.
>
> Below are some of the issues or unclear things I spotted.  Sorry for not 
> having time to write them up more nicely.
>
> substantial
> -----------
>
>    o  The local mobility anchor and the mobile access gateway MUST be
>       configured with IPv6 globally unique addresses, even when they are
>       in IPv4-only network.  These addresses can be of the type Unique
>       Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address
>       [RFC-3587] or IPv4-mapped IPv6 address [RFC-4291].
>
> .. "Local IPv6 unicast addresses" are not IPv6 globally unique addresses,
> otherwise the term would be an oxymoron, right?  Also, IPv4-mapped IPv6 are
> not necessarily globally unique.  Further, it is not clear why IPv4-mapped
> IPv6 address is not even allowed in the spec.  I'd remove it here
> completely.  Some other places in the spec also mention "IPv6 globally
> unique addresses" and I frown a bit when I see it.  Aren't you really just
> referring to non-link-local addresses, or addresses that must be unique
> within the PMIPv6 domain? (Hopefully, these should be global, of course, but
> that's a separate topic.)
>
> In S 1.1 Assumptions:
>
>    o  The mobile node can obtain an IPv4 address for its attached
>       interface.  Based on the type of link, it may be able to acquire
>       its IPv4 address configuration using standard IPv4 address
>       configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332],
>       IKEv2 [RFC-4306] or static address configuration.
>
> But in S 3.4:
>
>    Section 3.4 identifies these interactions for supporting DHCP based
>    address configuration.
>
> .. Either the assumptions should say that only DHCP is supported, or S 3.4
> and the rest of the spec should be clearer how other mechanisms would work,
> or that they are beyond the scope of this spec.
>
> In S 3.2.4:
>
> 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.
>
> Yet in S 3.2.3.2 (also 3.4.2):
>
> However, since the link between
>       the mobile access gateway and the mobile node is a point-to-point
>       link, implementations will be able receive any packets sent to the
>       default router address without having to explicitly configure the
>       default router address on its interface.
>
> ... the spec is internally inconsistent.  It appears that the requred
> assumption is that the link is point-to-point, but at least one place
> (3.2.4) is not firm about that design decision, and it should be.
>
> In S 3.2.4:
>
>              When receiving an ARP Request, the local mobility anchor
>       SHOULD examine the target IP address of the Request, and if this
>       IP address matches the mobile node's IPv4 home subnet, it SHOULD
>       transmit a Proxy ARP Reply.
>
> .. I suppose proxy ARP should reply for every address in the subnet?
> I suppose because proxy ARP behaviour is not specified here, RFC 925 needs
> to be a normative reference.
>
> In S 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.
>
> .. I'm not sure if I understand the last scenario.  The only way the address
> could always be the same would be either using anycast or that each MAG is
> behind a different NAT, isolated from each other.  Or am I missing
> something? (I suppose so...)
>
> In S 3.4
>
>       *  However, if the mobile node is capable of performing handoff
>          between interfaces, as per [RFC-5213], the interface 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.  This identifier in some
>          implementations can be the identifier associated to a virtual
>          interface, that is abstracting the physical interfaces.
>
> .. aren't you basically saying that the prior point about using hardware 
> address
> based identifier doesn't work?  Even though the higher-level bullet point 
> just
> describes these as "considerations", shouldn't you really be describing
> the requirements (it seems a stable identifier must be used, otherwise
> handoffs don't quite work; it might be worth describing how they will not 
> work,
> and how to mitigate that).
>
> Am I reading the spec correctly that the only reason why a stable Client 
> Identifier
> is not mandated by the spec is because implementations out there don't 
> generally
> support it and no changes to the v4 node are allowed?  If this reading 
> between
> the lines is true, is there a more complete solution possible or feasible?
>
> In 3.4.2:
>
>   o  Once the mobile access gateway intercepts the DHCP message from
>       the mobile node to the DHCP server, it can verify if the mobile
>       node is negotiating the same IPv4 address that the local mobility
>       anchor allocated for that mobile node.  If the address in the
>       DHCPREQUEST message does not match with the IPv4 address allocated
>       for the mobile node, then the mobile access gateway SHOULD
>       silently drop the DHCP message.
>
> ... But earlier was slightly different recommendation, is there a reason why
> these are different:
>
>    o  On receiving a DHCPOFFER message from the DHCP server, the mobile
>       access gateway will ensure the assigned address is currently
>       assigned by the local mobility anchor to that mobile node.  If
>       this address is different from what is assigned to the mobile
>       node, then the mobile access gateway will drop the DHCPOFFER
>       message and an administrative error message will be logged.
>
> 4.1.3.3. NAT Presence Detection
>
>    When the transport network between the local mobility anchor and the
>    mobile access gateway is an IPv4 network and if the received Proxy
>    Binding Update message was sent encapsulated in IPv4 UDP header, the
>    local mobility anchor performs the NAT Presence Detection as
>    specified below.
>
>    On receiving the Proxy Binding Update message encapsulated in an IPv4
>    UDP packet, the local mobility anchor, if it detects a NAT on the
>    path, will send the Proxy Binding Acknowledgment message with the NAT
>    Detection Option.  The presence of this option in the Proxy Binding
>    Acknowledgment is an indication to the mobile access gateway about
>    the presence of NAT in the path.  On detecting any NAT in the path,
>    both the local mobility anchor and the mobile access gateway will set
>    the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation.
>    The specific details around the NAT detection and the related logic
>    are described in DSMIPv6 specification [RFC-5555].
>
> .. this seems to be saying that if LMA receives an IPv4-UDP encapsulated
> PBU, only then it will do NAT detection, the result of which would be
> starting to use IPv4-UDP encapsulation.  What am I missing here, isn't this
> a circular definition?
>
> In S 4.3.2:
>
>            MAG SPD-S:
>              - IF interface = IPv6 tunnel to LMAA_1 &
>                   local_address != Proxy-CoA_1 &
>                   remote_address != LMAA_1 & proto=any
>                Then use SA ESP tunnel mode
>
> yet:
>
>   MAG's IPsec module
>   :
>   :      IPv6 header (src=Proxy-CoA, dst=LMAA)
>   :      ESP header in tunnel mode
>   :      IPv4/v6 header (src= MN-HoA, dst= CN)
>   :      Payload
>
> ... are Proxy-CoA_1 and LMAA_1 above different from Proxy-CoA and LMAA
> below?  How, I'm not following the designations here, the ones with _1
> weren't explained?  Do SPDs written here have the two conditions
> inverted?  The same for LMA SPD-S.
>
> Section 6
>    Approval of this flag values are to be made through IANA Expert
>    Review.
>
> .. note that RFC5226 says: "The required documentation and review
>             criteria for use by the Designated Expert should be provided
>             when defining the registry." -- such criteria are not defined.
>
> 10. References
>
> .. A number of Informative References are used in a manner in the spec that
> they should really be normative.  For example, proxy-ARP behaviour leans on
> RFC-925; RFC-2473 S 7 and 8 are pulled in in this spec; RFC 4213
> considerations on fragmentation are a MUST implement; some IPsec components
> as well.  The list of informative references needs to be reviewed and some
> of these moved to normative.
>
> editorial
> ---------
>
> 3.3.4. IPv4 DHCP Support Mode
>
>    A new option, IPv4 DHCP Support Mode Option is defined for using it
>    in the Proxy Binding Acknowledgment message sent by the local
>    mobility anchor to the mobile access gateway.  This option can be
>    used for notifying the mobile access gateway, if it should function
>    as a DHCP Server or a DHCP Relay for the attached mobile node.
>
> .. what if the option is not present?  should MAG function in any DHCP 
> capacity?
> (A bullet point in S 4.1.3.2 later describes that the default behaviour is
> relay.  Not sure if this needs clarifying at all, and if yes, where.)
>
> In 3.3.5 (also Section 6)
>
>   MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED
>
> ... add (": IANA" to the end, I suppose this will also require a number?
>
> In S 4:
>
>    o  The mobile access gateway can be potentially in a private IPv4
>       network behind a NAT [RFC-3022] device, with a private IPv4
>       address configured on its egress interface.  But, the local
>       mobility anchor must not be behind a NAT and must be using a
>       globally routable IPv4 address.  However, both the local mobility
>       anchor and the mobile access gateway can be in the same private
>       IPv4 routing domain, i.e., when both are configured with private
>       IPv4 addresses and with no need for NAT translation between them.
>
> ... the "However" makes the previous sentence invalid because clearly LMA is
> not required to have a globally routable IPv4 address. Rewording for
> precision and more succint representation would be good. What you're saying
> that LMA must be deployed so that none of MAGs that need to talk to it need
> to go through NAT.
>
>
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Sep 2009 18:35:35 +0300 (EEST)

Hello,

I've done a quick review of draft-ietf-netlmm-pmip6-ipv4-support-16 at 
AD request.  I have only vague understanding of PMIP6 so take this 
with a grain of salt.

The document is written in a manner that should be easy to implement, 
but a bit challenging to verify from the spec point of view for 
correctness and that all the corner cases are dealt with.  This is an 
OK documentation decision.  The spec also contains a bit of 
unnecessary repetition, but this is not harmful as long as the length 
doesn't grow much or introduce inconsistencies.

I wonder at the original PMIP6 design decision that MAGs establish 
tunnels to LMAs dynamically.  Are there really so many potential LMAs 
for each MAG that these could not be set permanently, as a separate 
specification or independent of MNs' behaviour?  A lot of space and 
complexity in the spec is introduced by verifying whether the MAG-LMA 
tunnel has been set up.  This also creates delays and complexities 
(users' packets dropped until the tunnel is up) when the tunnel does 
not exist yet, tearing down tunnels, etc.  A simpler alternative 
could have been that the MAG establishes tunnels when its MAG services 
are started and they will always remain up. But again, the horse has 
already left the barn.

The specification only supports unicast; this is not stated in the 
spec.

The security considerations section is a bit weak, but I don't have 
the energy to comment on it in detail.

Below are some of the issues or unclear things I spotted.  Sorry for 
not having time to write them up more nicely.

substantial
-----------

In S 1.1 Assumptions:

But in S 3.4:

In S 3.2.4:

In S 3.2.4:

In S 3.4:

In S 3.4

.. aren't you basically saying that the prior point about using hardware address
based identifier doesn't work?  Even though the higher-level bullet point just
describes these as "considerations", shouldn't you really be describing
the requirements (it seems a stable identifier must be used, otherwise
handoffs don't quite work; it might be worth describing how they will not work,
and how to mitigate that).

Am I reading the spec correctly that the only reason why a stable Client Identifier
is not mandated by the spec is because implementations out there don't generally
support it and no changes to the v4 node are allowed?  If this reading between
the lines is true, is there a more complete solution possible or feasible?

In 3.4.2:

In S 4.3.2:

            MAG SPD-S:

yet:

   MAG's IPsec module
    :

Section 6

10. References

editorial
---------

.. what if the option is not present?  should MAG function in any DHCP capacity?
(A bullet point in S 4.1.3.2 later describes that the default behaviour is
relay.  Not sure if this needs clarifying at all, and if yes, where.)

In S 4: