Re: [Mip4] AD review of mip4-dsmipv4

["George Tsirtsis" <tsirtsis at googlemail.com>]

Jari et,al.,

Thanks for the comments and sorry for the long delay in dealing with this.
I think I have dealt with all the issues you raised, including the
removal of IPv6 addresses (now we only support prefixes).
I also removed the MIPv4 way of allocating IPv6 prefixes and instead
point to DHCPv6-PD for this purpose as an example mechanism.
In the process I corrected a number of minor errors throughout the document.

I submitted v07 with all the changes.
You can also see some comments inline...

Thanks again
George

On Fri, Aug 22, 2008 at 1:50 PM, Jari Arkko <jari.arkko at piuha.net> wrote:
> (I was asked to resend. Does this make it to the mailing list?)
>
> I have reviewed this specification. It is in relatively good shape, but
> there are a number of  issues that we should correct before moving
> forward. The biggest issues relate to:
>
> - completeness of the rules relating to address overlap
> - authorization rules for address allocation
> - use of proxy ND on both addresses and prefixes
> - interface ID construction rules
>
> In addition, I  question the design decision to support addresses as
> well as prefixes. If your  protocol supported only prefixes, it would
> be  significantly simpler.
>
> Please find a number of issues and questions below. First the technical
> ones:
>
>>   Prefix Length
>>
>> ...
>>
>>      Indicates the prefix length of the prefix included in the Mobile
>>      IPv6 Network Prefix field
>>
>> ...
>>
>>   Mobile IPv6 Network Prefix
>>
>>      A sixteen-byte field containing the Mobile IPv6 Network Prefix
>>
>>   The following values are defined for use as a Code value in the above
>>   extension
>>
>>      ...
>>
>>      11 registration rejected, Duplicate Address Detection failed
>>     If the IPv6 home address included in an IPv6 Prefix Request extension
>>   is not an on-link IPv6 address with respect to the home agent's
>>   current Prefix List or a prefix it is configured to serve, ...
>
> Having read the document this far, the request extension has a prefix,
> not an address. It is only later that you explain the prefix can
> actually be /128 as well.
>
>>   When the IPv6 Prefix Request extension contains a /128 IPv6 address
>>
>
> This can certainly be done, but I wonder about the need for this. If you
> did not have
> address support, you would:
>
> - get rid of DAD rules
> - get rid of ND proxying
> - avoid having to say something about SEND in security considerations
> section
> - simplify authorization and overlap rules
> - not have any multilink subnet-style issues
> - not introduce something that could easily be done by DHCP over a prefix
> - ...
>
> What is the rationale for including support for addresses? You will not be
> compatible with Mobile IPv6, so there is no need to attempt to match it.
> You are building a new extension to Mobile IPv4, and there is no fundamental
> reason to replicate its behaviour either. You do not intend to build a
> competitor
> for Mobile IPv6, so you do not need a long list of features.
>

GT> Based on feedback from the group I am removing support for
addresses from the document as you suggest.


>>   Note that for IPv6 prefixes (rather than addresses), the home agent
>>   does not have to perform Duplicate Address Detection but it MUST
>>   check that allocated prefixes are not overlapping so that all
>>   addresses under each allocated prefix are allocated only to a single
>>   mobile node at any one time.
>>
>
> Are other nodes allowed to take addresses from the prefixes allocated to
> mobile nodes? E.g., another mobile node requesting a /128, or if the
> prefix is on-link at the HA, some fixed node? I hope not.
>
> I would suggest a reformulation. For instance:
>
>  Note that for IPv6 prefixes (rather than addresses), the home agent
>  does not have to perform Duplicate Address Detection but it MUST
>  make use a separate pool of prefixes that are only used for this
>  purpose. These prefixes MUST NOT appear as on-link to any other
>  node (e.g., via Router Advertisements). The home agent MUST
>  check that allocated prefixes are not overlapping so that all
>  addresses under each allocated prefix are allocated only to a single
>  mobile node at any one time. In particular, a mobile node must not
>  be able to request a /128 from a prefix allocated to another mobile
>  node.
>

GT> A slightly modified version of this will be included in the document.

>
>>   Dual stack home agents MUST use Proxy Neighbor Discovery [RFC4861
>> <http://tools.ietf.org/html/rfc4861>] on
>>   behalf of the nodes they serve.
>
> This seems wrong. You only need to proxy ND if the mobile nodes get just
> an address, not a prefix.
>

GT> Removed

>>   Packets addressed to the mobile node's IPv6 link-local address MUST
>>   NOT be tunneled to the mobile node.  Instead, these packets MUST be
>>   discarded and the home agent SHOULD return an ICMPv6 Destination
>>   Unreachable, Code 3, message to the packet's Source Address (unless
>>   this Source Address is a multicast address).
>
> How does the home agent know what the mobile node's IPv6 link-local
> address is?
>

GT> It does not any more. I will remove this.

>
>> Multicast packets addressed to a multicast
>> address with a scope larger than link-local, but smaller than global
>> (e.g., site- local and organization-local [RFC4291
>> <http://tools.ietf.org/html/rfc4291>], to which the
>> mobile node is subscribed, SHOULD NOT be tunneled to the mobile node.
>> Multicast packets addressed with a global scope, to which the mobile
>> node has successfully subscribed, MUST be tunneled to the mobile
>> node.
>
> I'm not sure I understand the rationale for making this distinction.
> I agree about not forwarding link-local traffic, but why the restriction
> on other scopes?
>

GT> I will remove the distinction

>> The only clarification required for the
>>   purpose of this specification is that all MLD [RFC2710
>> <http://tools.ietf.org/html/rfc2710>] or MLDv2
>>   [RFC3810 <http://tools.ietf.org/html/rfc3810>] messages between the
>> mobile node and the home agent MUST be
>>   tunneled between the mobile node and the home agent, bypassing the
>>   foreign agent.
>
> Does this change the home agent's decision to use a particular tunneling
> mode? Note that the home agent has no way to know if the mobile node will
> later send MLD messages.
>

GT> I do not think this affects the HA. The HA must always be prepared
to receive packets tunneled over the IPv4 HoA, so this is in parallel
to any other tunnel that might be used. I will include an appropriate
clarification.


>>   A mobile node MAY include one or more IPv6 Prefix Request extensions
>>   with the IPv6 Prefix field set to ::interface_identifier, where
>>   interface_identifier is the unique layer 2 address of the client.
>>   ...
>>
>>      - the IPv6 prefix field set to PREFIX::interface_identifier and
>>      the prefix length field set to 128.  In this case an individual
>>      IPv6 address is allocated to the mobile node.
>
> The use of a link layer address directly seems problematic. RFC 4291
> has specific rules about how to use EUI-64 addresses (setting specific
> flags on and so on). Also, what about interface identifiers != 64 bits
> long? If you intend to keep the address functionality in the spec, the
> above rules have to be made more specific.
>

GT> I am removing support for addresses so all this goes away.

>>   As defined in the security considerations section of RFC3344
>> <http://tools.ietf.org/html/rfc3344>, ingress
>>   filtering in the data path may prevent mobiles from using triangular
>>   routing for their IPv6 communications even if the foreign agent used
>>   supports the dual stack extensions defined in this specification.  In
>>   such cases reverse tunneling can be used to allow for effective
>>   ingress filtering in intermediate routers without blocking IPv6
>>   traffic to reach its destination.
>
> The document is unclear about what foreign agents do about the
> IPv6 traffic. This should be more clearly specified. However,
> I do not think we should introduce the Mobile IPv4 triangular
> routing behavior in IPv6. This will be cause problems for ingress
> filtering, and would be something that we would have to take into
> account in many other products and specifications later on.
>
>

GT> Agreed. This is explicitly ruled out in section 4.4
"...All IPv6 traffic MUST be reverse tunneled to the home agent by the
foreign agent irrespectively from the reverse tunneling setting
negotiated for IPv4 packets..." I actually think Section 4.4 is pretty
clear in what the FA must do.

>> Security Considerations
>
> This section should talk about the authorization model to use an
> address/prefix.
> This model can be FCFS if that's what you want, but you should document its
> limitations. E.g., if you succeed in blocking a mobile node from
> re-registering,
> you can take over its address?
>
> Editorial:
>
>> ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
>
> Correct the above.
>
>> When IPv6 prefix and/or IPv6 tunneling mode extensions are used by
>>   the mobile IP client, they MUST be placed after the registration
>>   request header and before the mobile - home authentication extension
>>   so they MUST be included in the computation of any authentication
>>   extension.
>>
>
> ... so that they will be included ...? I.e., their correct placement is
> the MUST
> and the rest just follows? Same issue in another paragraph a little further
> down in the same section.
>
>>   In addition to that, the home agent SHOULD check that the source
>>   address of the inner header is a register IPv4 or IPv6 home address
>>   for this mobile node.
>
> s/register/registered/?
>
> Jari
>
>
> --
> Mip4 mailing list: Mip4 at ietf.org
>   Web interface: https://www.ietf.org/mailman/listinfo/mip4
>    Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>
--
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/