Re: [Mip4] draft-makela-mip4-nemo-haaro-05.txt

[jouni korhonen <jouni.nospam at gmail.com>]

Hi Kent,

Thanks a lot for the comments. We tried to get some answers and  
further questions below.


> From: "Kent Leung (kleung)" <kleung at cisco.com>
> Date: November 10, 2009 9:55:28 AM GMT+02:00
> To: <mip4 at ietf.org>
> Subject: [Mip4] draft-makela-mip4-nemo-haaro-05.txt
>
> A few comments on the draft:
>
> 1)  Support for other realms.  Does different realms imply different  
> IP address space?  This introduces the problem with overlapped IP  
> address for prefix and also MR HoA.

Multiple, separate (logical) HA's are not supported - otherwise a HA  
could not really be even assisting MRs during the RO process as the  
draft describes. Single HA serving multiple realms are supported. I'm  
not seeing the issue with overlapping IP address spaces. As stated in  
the draft, the realm information is optional and meant to assist in  
making policy decisions. In default case, realm info is not even  
included in replies, and HA would only distribute information on MRs  
belonging to same realm. However, if two realms wish to communicate  
directly, they can contact HA's administrator and ask the admin to  
enable this "extranet" functionality. In that case, you have all the  
normal issues with making address spaces non-overlapping of course,  
but that's not exactly problem with RO solution proposed in the draft.


>   Each network prefix can be associated to a realm, usually in the  
> form
>   'organization.example.com'.  Besides the routers in customer's own
>   organization, the prefix list may also include other Mobile Routers,
>   e.g.  Default prefix (0.0.0.0/0) pointing towards Internet gateway
>   for Internet connectivity, and possible extranets.  The realm
>   information can be used to make policy decisions on the Mobile
>   Router, such as preferring optimization within specific realm only.
>
> 2)  For the different realm case (CRs served by different HAs), how  
> does CR’s HA know?  This is just another issue with different HAs  
> support.  Currently, the draft does say this is out of scope.

The RO described in the draft works reliably only for MRs served by a  
pool of HAs under the same administration. That is a restriction in  
the current solution as it was never targeted to work in an  
environment where a MR would initiate a RO with another MR that is  
under different administration (e.g. different operator running its  
HA). Such deployment does not really fit to any existing deployment/ 
business model we wanted to apply MRs & RO in the first place.  One HA  
can serve multiple realms, though.

We probably need to think a bit more of a generalized form of RO,  
where MRs do not need to belong to the same administration, at least  
when the I-D is worked as a WG I-D. The RO signaling and data  
structures already in the draft support RO with any MR regardless of  
under which HA they are anchored as discussed to some extent in  
Sections 6.3 and 6.5. However, in that case the information of other  
MRs and subnets served by them has to be learned by some other means  
(..which are not described in the current draft obviously).


>   In a registration
>   request, the Mobile Router claims to represent an arbitrary IPv4
>   network.  If the CR has not yet received this information (HoA <->
>   Network prefix), it SHOULD perform a re-registration to Home Agent  
> to
>   verify the claim.
>
> 3)  When there are many MRs, the size of the RRP can be huge.  The  
> RO cache has to have all the MRs’ prefixes to work properly (i.e.  
> the last registered MR has the full table).  I would propose a more  
> scalable method.  Since the HA is aware of the RO-support mode of  
> the MRs for traffic between their networks, HA should notify the MR 
> (s) to trigger Return Routability.  In the case of NAT traversal on  
> one MR, HA would tell the right MR to initiate the signaling.  It’s  
> also possible that HA facilitate the keying.

That is a possible approach. However, that requires the HA to keep  
track of traffic exchanged between different MRs for a dynamically  
varying number of subnets, which probably becomes a burden to the HA  
at some point. Current approach makes the HA role in the RO rather  
lightweight, which was one of the goals of the original proposal.

I would be interested in learning what size of MR networks you have in  
mind and based on which deployment scenarios?


> 4)  Clarify the NAT case.  A diagram with more details would be  
> helpful.  How does RR work with CR’s private IPv4 HoA?  The CoTI  
> message cannot be routed directed from MR (using its CoA).  It does  
> matter which MR initiates the RR with the different cases of one  
> side of the MR is behind NAT, or both MRs are behind the same NAT.

We can clarify the NAT case for sure.. at least when the I-D is worked  
as a WG I-D.

I don't really see a real reason why the MR HoA should be private  
(unless the HA address is also private) other than "it can be done"  
with IPv4?


> 5)  Unfortunately this is likely a common scenario.  Just a  
> comment.  When HA detects this case, it may not trigger RO if the  
> new method #3 is used.

What do you refer with method #3 to? Anyway, cases where both MRs are  
behind a NAT are possible, agree. How likely they are is questionable.  
There is a limit where a protocol complexity to does not justify  
adding a feature anymore. In case of two MRs behind NATs talking  
directly to each other falls into that category. It could be possible  
to do hole punching and such but that again works only if there are no  
nested NATs. Besides, when this situation happens e.g. due a MR  
movement, the operation falls back to normal HA routed case, so no  
harm was done.


>   If both the Mobile Router and the Correspondent Router are behind
>   separate NATs, route optimization cannot be performed between them.
>   Possibilities to set up mutual tunneling when both routers are  
> behind
>   NAT, are outside the scope of this draft.
>
> 6)  Different realms may have overlapped HoA’s.

This is similar case as in 1) MRs under the administration of a same  
HA cannot have overlapping HoAs.


>   Due to the fact that the route optimization procedures may occur
>   concurrently at two Mobile Routers, each working as each other's
>   Correspondent Router, there may be a situation where two routers are
>   attempting to establish separate tunnels between them at the same
>   time.  If a router with a smaller Home Address (meaning a normal 32-
>   bit integer comparison treating IPv4 addresses as 32-bit unsigned
>   integers) receives a registration request (in CR role) while its own
>   registration request (sent in MR role) is still pending, the reply
>   must be deferred until the tunnel initiated by its registration
>   request is up.  This avoids the problem of two separate tunnels
>   forming concurrently between two Mobile Routers.
>
> 7)  What happens when both MR and CR moves at the same time?  Maybe  
> some text to cover this?

This can be clarified.. at least when the I-D is worked as a WG I-D.


> 8)   CR cannot initiate RR in this case.

What this comment refers to?


>   In the case where Mobile Router is behind NAT (or firewall) and
>   Correspondent Router is not, the Mobile Router will, when tunnel has
>   been established, send keepalive messages (ICMP echo requests)
>   through the tunnel.  Until a reply has been received, the tunnel
>   SHOULD NOT be considered active.  Once reply has been received, NAT
>   mapping is in place and traffic can be sent.
>
> 9)  HA does not know the same NAT unless the same CoA address (use  
> explicit language).  Different IP address does not mean it’s not the  
> same NAT.

Ok.


>   If Mobile Router and Correspondent Router are behind same NAT from
>   HA's point of view, it is possible to establish tunnel between them.

Right. However, how likely scenario this is? Just trying to scope  
whether it is worth adding extra features to detect/react to such case  
if it turns out to be a corner case and would need huge amount of work  
to get done properly.


> 10)Generic notification message could be used by HA to inform the  
> MRs of new MRs/prefixes.  Just a thought.

Well, it could be used. Though, we did not originally pick it up  
although the generic notification draft already existed when we  
published the first version..

Cheers,
	Jouni



> Kent