[Mip4] AD review of mip4-dsmipv4
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mip4] AD review of mip4-dsmipv4
(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/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
