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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hello Chan-Wah,

	Please see comments inline...

El mié, 07-09-2005 a las 16:22 +0800, Chan-Wah Ng escribió:
> 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.

	No problem :-)

> 
> On Tue, 2005-09-06 at 15:27 +0200, Carlos Jesús Bernardos Cano wrote:
> > 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.
> > 
> 
> 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.

	OK

> 
> > 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).
> 
> 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.
> 
> > 
> > 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).
> > 
> 
> 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".
> 
> > 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.
> 
> 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."

> 
> > 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).
> 
> Yes, I would like that (the providing text part).  But I am not so sure
> about removing the "Transparent Proxy" part.

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

> 
> > 
> > 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.
> > 
> 
> Yes, now I get the picture.  Thanks for your clarification.

	Thanks.

	Kind Regards,

	Carlos J.

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