Subject: [nemo] Comments on draft-ietf-nemo-ro-space-analysis-00.txt and MIRON

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 06 Sep 2005 15:27:27 +0200

Hi draft authors and all,

I've read the draft and I have some comments regarding MIRON (an
specific solution I'm co-author of). I prefer to send them in a
different e-mail, to keep them separated from the general ones I've
already sent.

In the section 3.2.1, MIRON is cited for the first time, as a mechanism
that decreases the number of Home Agents in the path in a nested
scenario. This is not completely true, since MIRON, as it's currently
specified in draft-bernardos-nemo-miron-00.txt, does not deal with
nested mobile networks. The main aim of MIRON is to provide a RO
mechanisms for LFNs of a NEMO, when they are communicating with CNs,
avoiding the MRHA tunnel with the MR's HA. This is done, by the MR
performing the MIPv6 RO tasks on behalf of the LFNs of its NEMO.

However, nothing prevents this solution to be applied also in a nested
NEMO, avoiding the last tunnel, or even all the tunnels if the MR is
provided somehow with a topologically valid IPv6 address that is
reachable without traversing any HA. This can be done, for example, by
providing to every MR in the nested topology with an IPv6 address that
belongs to the foreign network that the root-MR is visiting (for
example, by using DHCPv6), and enabling (with routing among the MRs and
proxy ND) these address to be directly reachable anywhere in the
Internet (without needing any special node, such a HA, to be deployed in
the infrastructure).

In the section 5.5.1, as far as I've understood, MIRON is classified as
a NEMO RO solution in which the "Mobile Router acts as a Transparent
Proxy". Firstly, for me it is not clear the distinction between "Mobile
Router as a Proxy" and "Mobile Router as a Transparent Proxy", since it
is said that - in the "Mobile Router as a Proxy" - the Mobile Router
uses standard Mobile IPv6 Route Optimisation procedure to bind the
address of a Mobile Network Node to the MR's CoA, and that's exactly
which MIRON does. Nevertheless, this "proxy" functionality requires the
MR to generate also the Return Routability signalling on behalf of the
LFNs, not only the Binding Updates messages. Besides, the packets
sent/received by the LFNs have to be modified, since they would be sent
by the CN addressed to the MR's CoA (carrying a type 2 RH), and the
packets sent by the LFN have to have the MR's CoA as their source
address (carrying a Home Address Destination Option).

OTOH, it is said that the "Mobile Router as a Transparent Proxy" works
by modifying MIPv6 RO packets sent to VMNs. This is not possible (at
least easily), since the HoTI and HoT messages sent by the VMNs have to
be sent using IPsec ESP, so the MR cannot modify these packets to set
its CoA as the VMN's CoA.

I'd suggest to remove the "Mobile Router as a Transparent Proxy" section
and rewrite the "Mobile Router as a Proxy" section (I can provide some
text for discussion if you want).

The main aim and advantage of MIRON is providing a NEMO RO mechanism
suited for LFNs (that is, IPv6 nodes that do not have/use any mobility
support), by using the Mobile IPv6 RO already defined mechanism and,
therefore, not requiring any change on the operation of LFNs and CNs.

Thanks a lot.

Kind Regards,

Carlos J.

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 07 Sep 2005 16:22:36 +0800

Hello Carlos,

I think we make the mistake of confusing the MIRON approach with an
approach that IIRC was mentioned in the ML by Erik on MR changing the RR
packets sent by MNN on the fly.

I like to apologise for that, and will made the necessary rectification.

> performing the MIPv6 RO tasks on behalf of the LFNs of its NEMO.

True.  Any case, if we decided to defer all reference to proposed
solution from Sect 3 to Sect 5, this wouldn't be a problem.

> Internet (without needing any special node, such a HA, to be deployed in

Okay.  As I see it, to handle nested case, MIRON would most likely
require the following:
(1) combining with an approach that flatten the nested NEMO, such as
using MANET routing, ND-Proxy, or PD from access network; or
(2) changes to CA: requiring CA to do recursive look up at its BCE.

> address (carrying a Home Address Destination Option).

OK.  I stand corrected: the MIRON approach should be correctly referred
to as "Mobile Router as a Proxy" approach, as opposed to "Mobile Router
as a Transparent Proxy".

> its CoA as the VMN's CoA.

Is it a must to ESP the communications between MN and HA?

> text for discussion if you want).

Yes, I would like that (the providing text part).  But I am not so sure
about removing the "Transparent Proxy" part.

> therefore, not requiring any change on the operation of LFNs and CNs.

Yes, now I get the picture.  Thanks for your clarification.

/rgds
/cwng

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 07 Sep 2005 10:45:25 +0200

Hello Chan-Wah,

	Please see comments inline...

> I like to apologise for that, and will made the necessary rectification.

	No problem :-)

> solution from Sect 3 to Sect 5, this wouldn't be a problem.

	OK

> Is it a must to ESP the communications between MN and HA?

	I think so. RFC 3775 says:

"10.4.6.  Protecting Return Routability Packets

   The return routability procedure, described in Section 5.2.5, assumes
   that the confidentiality of the Home Test Init and Home Test messages
   is protected as they are tunneled between the home agent and the
   mobile node.  Therefore, the home agent MUST support tunnel mode
   IPsec ESP for the protection of packets belonging to the return
   routability procedure.  Support for a non-null encryption transform
   and authentication algorithm MUST be available."

> about removing the "Transparent Proxy" part.

	OK, but I'm not sure if it is possible to have such a transparent proxy
solution.

> Yes, now I get the picture.  Thanks for your clarification.

	Thanks.

	Kind Regards,

	Carlos J.