Gabriel,
On the requirement for HAO in all IPv6 nodes... is
this actually necessary? That is, if I do not
implement a binding cache (which is not a
requirment), the only processing the node would
need to do is inform the mobile node that it can
not/will not process the HAO because it's not
legal to interpret it as a home address without a
binding entry. Likewise, a MN shouldn't be sending
a HAO until it establishes a binding, thus there
shouldn't be a possibility for missynchronization
there either.
What am I missing?
Mike
gabriel montenegro writes:
> This is an attempt to close issue 53 in the MIPv6 draft
> ("HAO keyword"):
>
> http://www.piuha.net/~jarkko/publications/mipv6/issues/issue53.txt
>
> We're cross-posting to both IPv6 and MobileIP as this concerns both lists.
> I'm sending this on behalf of Jari Arkko and the Mobile IP chairs. Please
> send any issues to the lists.
>
> tnx,
>
> -gabriel
> --------------------------------------------------------------
> In July we had a big discussion around the right keyword for the
> Home Address destination option support in IPv6 nodes. This e-mail
> reviews the issue and makes a recommendation.
>
> Unless otherwise specified, section numbers refer to rev 18
> of the draft:
>
> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt
>
> BACKGROUND
>
> In the new security design for Mobile IPv6 (adopted to the
> base specification over the course of the last year), we
> allow two modes of operation for communicating with the
> correspondent nodes:
>
> 1. Tunneling via the home agent (also called "reverse tunneling" in
> section 11.2.1).
> 2. Route Optimization (also called "direct delivery" in section 11.2.1):
> routing directly from the mobile node to the correspondent
> node (using a "home address option"), and from the
> correspondent node to the mobile node (using a "routing
> header - type 2").
>
> Note that tunneling happens in *both* directions and that optimal
> routing can *only* be performed if a binding cache entry has
> been established. The mobile node can't send a packet directly to
> the correspondent node until it has completed return routability
> procedure and sent a binding update. This is a change from previous
> versions of the protocol and was done in order to guard against
> certain reflection attacks. (But see below for a special case.)
>
> The return routability procedure and binding updates are carried
> by the Mobility Header protocol (a new IPv6 protocol). According
> to RFC 2463, any node that doesn't recognize a specific "next header"
> protocol value will return ICMP Parameter Problem, Code 1 to the
> sender. The MIPv6 specification requires that the reception of
> such a message is taken as an indication that the peer does not
> support Route Optimization.
>
> Furthermore, even nodes that support MIPv6 may decline requests
> for Route Optimization due to temporary lack of resources, for
> instance. This happens via an error response within the Mobility
> Header protocol itself.
>
> The new version of MIPv6 protocol is therefore capable of operating
> both with nodes that support this specification (regardless of any
> temporary inability to accept requests) and with nodes that do not
> support MIPv6 (such as nodes that have already been deployed).
>
> The current MIPv6 specification lists the benefits of route
> optimization (Section 8.2) but does not state whether it is
> mandatory or not for all IPv6 nodes. The plan is to leave that for
> the IPv6 node requirements document to decide.
>
> THE PROBLEM
>
> Even though it does not mandate route optimization itself, the
> current MIPv6 spec does mandate that two items MUST be implemented
> by *all* IPv6 nodes (section 8.1):
>
> 1. All IPv6 nodes MUST recognize the Home Address destination
> option and,
>
> 2. All IPv6 nodes MUST be able to return Mobility Header error
> messages.
>
> However, several people have complained that in the current
> state of IPv6 deployment, they do not wish to add new
> requirements for all nodes.
>
> As explained above, this isn't technically necessary as the ICMP
> Parameter Problems (or the lack of response) is adequate to keep
> the mobile node using tunneling. No payload packets will be sent to
> the wrong place, and no packets are lost.
>
> However, these two requirements relate to a special case
> we currently allow in the specification: direct delivery from the
> mobile node to the correspondent node (which uses a home address
> destination option) is allowed not just when a binding exists but
> also if the packets have been protected by IPsec. This constitutes
> "triangular routing": whereas the mobile node can directly deliver
> packets to the correspondent node by virtue of IPsec, the opposite
> is not true: the reverse direction cannot be optimized if the
> correspondent node does not have a binding for the mobile node.
> Although allowed, triangular routing is not adequately described
> in the current spec (more below).
>
> Note that in any case a correspondent node that doesn't support the
> Home Address destination option will send ICMP Parameter Problem,
> Code 2, so that the mobile node may learn the fact that this node
> is of an older variant that doesn't support this option, and
> continues using reverse tunneling.
>
> ALTERNATIVES
>
> The main question in the debate was to choose:
>
> 1. Remove the current requirements for all nodes.
> 2. Keep the current requirements for all nodes.
>
> However, we also have some additional questions
> to answer:
>
> - Should triangular routing (the IPsec-protected HAO) mode be a
> part of the Mobile IPv6 specification, even as optional?
>
> - What is the right keyword for Route Optimization
> support in correspondent nodes?
>
> - Should the MIPv6 specification state all these
> requirements for IPv6 nodes, or the IPv6 node
> requirements document?
>
> ANALYSIS
>
> - Mobile nodes that try to improve upon reverse tunneling
> by either route optimization or triangular routing can survive
> a situation where they connect to an older node with no MIPv6
> support at all. In this case they can fall back to reverse
> tunneling mode which does not require any support from the
> correspondent node.
>
> - We need to separate the technical requirements for
> mandating a specific protocol function (e.g. saying that "route
> optimization or some part of it is mandatory"), and more high
> level requirements (e.g. saying "security is mandatory").
>
> - It is likely that obtaining an IPsec security association
> between a mobile node and an arbitrary correspondent node
> continues to be difficult. Even if possible, it may not be
> justifiable for the mobile node to either (1) obtain such a
> security association (e.g. if the traffic pattern consists of
> access to public web sites), or (2) obtain it and stop without
> spending the negligible *additional* effort to create a binding
> entry. This implies that the main modes would be reverse
> tunneling and route optimization, whereas triangular routing
> via the IPsec-protected HAO would be perhaps less often used.
>
> - The IPsec-protected HAO mode is inadequately described
> in the current specification. Section 9.2.2 describes
> this possibility for the correspondent node, but not
> for the mobile node in 11.2.1. This can be easily fixed,
> however.
>
> - If we removed the IPsec-protected HAO mode from the
> specification along with the HAO requirement, the effect would
> be that even nodes that use IPsec would have to establish a
> binding before any optimization is possible. Establishing a
> binding requires 1.5 roundtrips every 7 minutes. Of course,
> such nodes can continue using reverse tunneling.
>
> Note that the establishment of the binding can take place in
> parallel with the security association establishment.
>
> - RFC 2119 states on the use of imperatives in RFC's: "MUST only
> be used where it is actually required for interoperation or
> to limit behavior which has potential for causing harm (e.g.,
> limiting retransmisssions) For example, they must not be used
> to try to impose a particular method on implementors where the
> method is not required for interoperability."
>
> In this respect, the "MUST" keywords on HAO processing &
> error message requirements do not seem necessary, as (1)
> interoperability is already achieved using other mechanisms
> (ICMP/lack of answer and reverse tunneling via the home agent),
> and (2) for the mode that could potentially benefit from this
> the difference is not catastrophic as explained in the previous
> bullet.
>
> RECOMMENDATION
>
> The requirements of RFC 2119 for a "MUST" are not fulfilled in
> this case: interoperability is achieved in any case. Furthermore,
> it is questionable that nodes that bother to set up an
> IPsec security association would not be able to afford
> a much smaller amount of memory for a binding cache
> entry, particularly when bidirectionally optimal routing
> can only be achieved with Route Optimization.
>
> Therefore, we recommend that the HAO processing and error message
> MUST requirements be removed for all nodes.
>
> Instead, we recommend that Route Optimization support
> for correspondent nodes be made a SHOULD in the IPv6 node
> requirements document. The ability of a correspondent node
> to participate in route optimization is good for the efficient
> operation of the IPv6 Internet, beneficial for robustness and
> reduction of jitter and latency, and is in some cases necessary
> to avoid congestion in the home network.
>
> We also recommend that triangular routing via the IPsec-protected
> HAO processing be described in the Mobile IPv6 base specification,
> and be made a SHOULD for mobile and correspondent nodes. This
> includes describing how nodes can survive the situation where
> the other side does not support this mode.
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
