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

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 9 Nov 2009 23:55:28 -0800

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

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.

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.

   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.

   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?

8)   CR cannot initiate RR in this case.  

   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.

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

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

Kent

---

From: jouni korhonen <[email-masked]>
Date: Wed, 11 Nov 2009 15:39:28 +0200

Hi Kent,

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

> From: "Kent Leung (kleung)" <[email-masked]>
> Date: November 10, 2009 9:55:28 AM GMT+02:00
> To: <[email-masked]>
> Subject: [Mip4] draft-makela-mip4-nemo-haaro-05.txt
>
> 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.

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

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

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

> 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?

> explicit language).  Different IP address does not mean it’s not the  
> same NAT.

Ok.

>   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