Subject: [Mip4] AD review of mip4-dsmipv4

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Aug 2008 15:50:23 +0300

(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: [email-masked]
    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/

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 29 Aug 2008 10:30:57 +0100

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:
> 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 <[email-masked]> wrote:
>> (e.g., site- local and organization-local [RFC4291
>> <http://tools.ietf.org/html/rfc4291>], to which the
>>   purpose of this specification is that all MLD [RFC2710
>> <http://tools.ietf.org/html/rfc2710>] or MLDv2
>>   As defined in the security considerations section of RFC3344
>> <http://tools.ietf.org/html/rfc3344>, ingress

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 29 Aug 2008 09:02:48 -0700 (PDT)

> Prefixes in this specification?

Agree with this. It will be lot simpler to just support prefixes, no
additional complexity on the HA, other than adding a prefix route
and prefix key in the registration entry. Else, MIP4 Home Agent
requires signficant part of MIP6 Home Agent function, not sure if all
vendors will adopt such big change. Also, I dont see this is as
loss of functionality.

Sri

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 29 Aug 2008 19:15:33 +0200

> Prefixes in this specification?

Works well for me.

	Henrik (no hat)