Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated

From: [email-masked]
Date: Thu, 18 Jul 2002 03:13:38 +0300

Hi Mike,

> Vijay Devarapalli writes:
>  > RO is a SHOULD, it is not a MUST in the current draft. we were 
>  > not talking about route optimization. we were talking about 
>  > processing a HAO. in the current spec HAO MUST be processed but 
>  > not accepted if it cant be verified. verification can be in the 
>  > form of checking for a valid BCE (created securely), IPsec 
>  > protected data session, same trusted domain (where you dont 
>  > expect people to do reflection attacks), the tagging proposal 
>  > from Rajeev and Charlie, smart ingress filtering from Francis 
>  > Dupont, etc...
> 
>    Oh, OK. Sorry about that. Still if the code
>    isn't in the CN, the MN should still be able
>    to operate correctly, right? That still seems
>    to me to be a SHOULD rather than a MUST for the
>    same reasons in my reply to John.
> 
>    I guess the long and short of this is that I'm
>    somewhat skeptical of putting general node
>    requirements in the MIP draft since it's
>    probably not the first place one would be
>    looking to figure out if they were an IPv6
>    compliant node. If it's really, really vital
>    for the health of the net, yadda, yadda, it
>    would be better to put it in a general v6 node
>    requirements RFC, don't you think?

Just as an FYI, I replied to the earlier mail because I am
trying to sort this out for the node requirements.  I think 
that in MIPv6, it is OK that MIPv6 makes this recommendation (given 
working group consensus, IESG approval, etc.) but the Node Requirements
document is the final word on the issue (assuming WG consensus, 
IESG approval, etc.).

John

---

From: "Pascal Thubert" <[email-masked]>
Date: Thu, 18 Jul 2002 11:41:35 +0200

* Just as an FYI, I replied to the earlier mail because I am
> document is the final word on the issue (assuming WG consensus,

This issue seems to delay MIPv6 till the node requirement is out; so could we
not just recommend that the Mobile Node SHOULD use the reverse tunnel till some
part of the RR test is complete? If we do so, then a potential CN that fails to
respond to the CoT test would be considered as a legacy device and we would not
perform RO at all.  My initial proposal is to negotiate the RO the following
way:

Cot Fails : The MN MUST use the reverse tunnel for all traffic
Cot works, Hot Fails : The CN accepts the HaO but is not willing to manage a
Bind Cache -> triangular routing (E.g. a clustered web server)
Both work: The CN is willing to receive bind updates.

What do you think?

Pascal

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Thursday, July 18, 2002 2:14 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated

Hi Mike,

John

---

From: "Pascal Thubert" <[email-masked]>
Date: Thu, 18 Jul 2002 11:42:41 +0200

What do you think?

Pascal

-----Original Message-----

Hi Mike,

John

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 06:05:14 +0300

> perform RO at all.  My initial proposal is to negotiate the RO the following

This is what the spec has been saying for some time.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 07:49:40 +0300

I'm trying to summarize the discussion on the HAO and BE
processing.

Here's a few things that came up in the discussion:

* MUSTs should be used only if interoperability is
   at danger, or if the health of the internet is
   in question even if protocols would operate
   correctly.

* There will be existing IPv6 nodes that do not
   yet have MIPv6 support, and not all of them can
   be changed overnight when a new IPv6 RFC comes out.

* The current MIPv6 protocol works technically even
   with non-MIPv6 nodes. The MNs will not normally
   attempt to use HAO without establishing a binding.
   If the CN does not support MIPv6 RR, it sends back
   an ICMPv6 parameter problem. And even if the MN
   went ahead and used HAO (as in with IPsec, for instance),
   the CN would also respond with a parameter problem.

   This is in the current draft*.

* There are two potential node requirements from the
   MIPv6 functionality:
     - Route optimization, the main benefit (section 8.2)
     - Basic HAO supported, a subset of the above and
       used for HAO under IPsec with triangular routing
       (8.1). Includes also BEs.

* The current draft does not state what the keyword
   is for the RO functionality (so far left for the node
   requirements team to decide, yet we intend to recommend
   something). The draft does say MUST for basic
   HAO support, however.

* The IETF is free to decide what kind of requirement to
   place on nodes for these functions, since there are
   no interoperability concerns.

* IPv6 WG has in the past accepted the HAO as a mandatory
   feature for all IPv6 nodes. Arguments have been made,
   however, that the processing of the HAO has been changed
   and the situation may now be different.

* Arguments have been raised that the basic HAO support does
   not fullfil conditions to be a MUST.

* Earlier discussions have looked upon what is the right
   level of support for RO. Proposals ranging from MAY to
   MUST were then mentioned, and arguments about congestion-like
   effects of non-optimal routing were used among others.

Jari

* A last call comment requested more text for the HAO-without-RO case.

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 18 Jul 2002 14:18:50 +0900 (JST)

Let me add one thing.

From: Jari Arkko <[email-masked]>

>    and the situation may now be different.

In addition, the current draft requires not only HAO but also BE.
This means all IPv6 nodes must implement a new extention header
(mobility header).

I never say that such a mechanism is bad at all.  It is good of
course.  But from the view of the fast deployment of both IPv6 and
Mobile IPv6, I personally think it better not to require additional
requirements...  This is not the view of the protocol designer,
though.

I'm probablly a bad designer and a bad scientist.  I just want a real
IPv6 and a Mobile IPv6...

Best Regards,

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 09:43:26 +0300

> This means all IPv6 nodes must implement a new extention header

Correct.

Jari

---

From: "Pascal Thubert" <[email-masked]>
Date: Thu, 18 Jul 2002 18:00:05 +0200

I think I've been a little cryptic:

Some devices such as a fridge may be happy to have a minimum set of requirements
for IPv6. Other devices such as clustered servers may not be able to maintain a
BCE at all because the cluster IP address is shared among all the members of the
cluster -- unless they perform a new protocol to distribute the BCEs-.
Furthermore, if the cluster uses a dispatcher that is not on the return path,
then the dispatcher cannot provide the MIP termination, either. However, if that
same dispatcher terminates an IPSEC tunnel, or by other means to be defined
later such as piggy backing, it could be possible to trust a Home address option
and perform triangular routing.

Using a Binding Cache as opposed to piggy backing the BU with each packet
assumes that memory scales better than CPU. This seems a reasonable approach, so
does delaying the support of piggybacking. But still, we must allow for the case
where this trade-off does not apply. Say the dispatcher I just mentioned has a
hardware accelerated crypto engine; say it can cache some recent computations in
a LRU fashion; say it has limited memory capabilities to keep many BCEs long
term; and say it needs to serve requests for a huge amount of unrelated users;
in that case, the trade-off is the wrong choice, and triangular may be the best
can do, unless the client sources its requests with its CoA, which leads to more
open issues. MUSTing a Binding Cache in IPv6 outlaws this configuration de
facto.

If we agree that there can be several levels of support by the CN for RO, then
we could define what the behaviour is for each level and how to negotiate that
between the CN and the MN. My suggestion was to do that negotiation at RR test
time so that no bind support would be necessary unless both parties agree upon
bi-directional route optimization.

A way to perform that negotiation is to give a meaning to the response to HoTi
and CoTi. This may be achieved by adding negative Return Code to Hot Cot, and
mostly by accepting an ICMP error as a 'no' response.

So 'No' to Both HoTi and CoTi means no bind updates, and usage of the bidir
MN-HA tunnel, which ensures compatibility with minimum and legacy stacks, as per
the draft
'Yes' to both HoTi and CoTi means let's go with the bind update, as per the
draft
'Yes' to CoTi only means support for Home Address option but not for Bind Cache
'Yes' to HoTi only does not make sense to me at the moment ???

This is not exactly the way the draft presents things, mostly for the triangular
part. Also, the draft is heavily biased (e.g. 8.1) in such a way as to let the
reader believe that MIP could not work without support of the Home Address
option by all nodes, "since otherwise communications may be impossible". I
believe that this is misleading, and that we should rather explain the different
scenarios and pro/cons of each level of support by the CN. I believe we
ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1.

Does that make sense?

Pascal

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Keiichi SHIMA / "?Oc^e
Sent: Thursday, July 18, 2002 7:19 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [mobile-ip] Re: summary of HAO, BE processing discussion

Let me add one thing.

Best Regards,

---
Keiichi SHIMA

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 14:23:43 +0300

> mostly by accepting an ICMP error as a 'no' response.

I've thought about this in the context non-RR RO security schemes. We can
already do this, by adding a new mobility option to be carried by hoti and
then returned by hot if the peer supports it.

> 'Yes' to both HoTi and CoTi means let's go with the bind update, as per the

Good.

> 'Yes' to HoTi only does not make sense to me at the moment ???

Do we really need this kind of negotiation just to figure out whether the receiver
can support HAO or not? If yes, I think it would be much better to have the
RO and HAO support together. That is, the peer supports HAO if and only if
it supports RO and RR.

> option by all nodes, "since otherwise communications may be impossible". I

Uh... that's not right.

> scenarios and pro/cons of each level of support by the CN. I believe we

Yes.

> ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1.

Yes.

Jari

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Thu, 18 Jul 2002 14:18:50 +0900 (JST)

Let me add one thing.

Best Regards,

---
Keiichi SHIMA