Re: [Mip4] AD review of mip4-dsmipv4

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

Hi All,

I reviewed Jari's comments and I think we need to decide on at least
one of these as a group before I can create a new version.

The current version of the draft supports both IPv6 Prefixes and IPv6
addresses. Jari questions why we need to support addresses and I do
not have a good answer for that at the moment. Jari, specifically
points out that a number of issues in the document would be simplified
if we dropped support for addresses i.e., we 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
> etc

Is the WG in agreement with Jari's proposal to only support IPv6
Prefixes in this specification?


Thanks
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.
>
>>   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.
>
>
>>   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.
>
>>   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?
>
>
>> 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?
>
>> 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.
>
>>   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.
>
>>   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.
>
>
>> 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/