Re: [Mip4] AD review of draft-ietf-mip4-nemo-haaro

[Mäkelä Antti <[e-mail]>]

Hi,

  Consolidating both of your review e-mails into one. Comments inline. Overall we'll need more information in section 1 and some clarifications. We'll try to submit -06 soon.

>Section 1 should highlight that any route optimization between the MRs would only affect traffic between >them. That is, traffic to somewhere else in the Internet in the multihoming case of figure 1 would still go >through the virtual home agent operator, not directly.

  Actually, technically you could have a separate "MR" that would act as an Internet gateway, by advertising prefix 0.0.0.0/0. So HA would truly be relegated as nothing but a signaling anchor. But we'll add text to indicate this.

>Section 3.3.1 should highlight that if there is only one realm that can be communicated with one prefix, >this may not be sufficient to communicate many real-world situations (such as one prefix mapping to >multiple organizations, e.g., nomadiclab.com and ericsson.com)

  Our original approach was worrying about the situation where there's overlapping (private) address spaces, since that ericsson.com's 10.10.10.0/24 is not same beast as cisco.com's 10.10.10.0/24, so in fact you could send the same prefix out twice with different realms, and then it would be up to the policies set for the MR whether whether they allow connectivity between such two entities (and how do they do it - some sort of NAT would probably be needed). In same vein, such a policy could be set up that in case of nomadiclab and ericcson the prefix is in fact the same network.. 

  We'll add these considerations as well.

>The document should make it clear what types of NATs it can operate with. (And maybe it already does, >in some part that I have not yet read :-)

  This is covered later.

>>     If the check passes, the Correspondent Router MUST check whether the
>>     Mobile Router already exists in its Route Optimization Cache and is
>>     associated with the prefixes included in the request (Prefixes are
>>     present and Flag HA is true for each prefix).
>Can you make it clearer that checking whether an MR exists in the cache means checking whether an >MR with the given care-of address exists in the cache? (If you didn't check the care-of address, any >authorized router could claim any authorized prefix.)

  Ok.

>I think the document is in pretty good shape, but there were a few issues that I would like you to resolve >before moving forward. The biggest issues are that I think you could do a better job in the introduction >describing what kind of NAT scenarios this technology can work with, and adding a description of areas >of uncertainty/problems that would be worthwhile to get more experience on (since the doc is going to be >published as Experimental RFC).

 Ok - will add. We have already done some research on e.g. how to combine this with Sri's multiple tunnel support draft and load balancing issues (submission pending acceptance to a journal). Should such academic papers be cited as informational references?

>> When a Mobile Router wishes to join its home link, it SHOULD, in
>> addition to sending the registration request to the Home Agent with
>> lifetime set to zero, also send such a request to all known
>> Correspondent Routers.
>I think it would be useful to clarify that you send the request to the home address, not care-of address of >the CRs. Right? Otherwise they may have moved.

  Ok. Of course, all the signaling between MRs happens by using their Home Address, but can repeat that point here.

>>     In the case of a handover, the Correspondent Router simply needs to
>>     update the tunnel's destination to the Mobile Router's new Care-of
>>     Address.  Mobile Router SHOULD keep accepting packets from both old
>>     and new care-of Addresses for a short grace period, typically on the
>>     order of ten seconds.  In the case of UDP encapsulation, the port
>>     numbers SHOULD be reused if possible.
>Its not as simple as that when NATs and firewalls are involved. If the MR is behind a NAT now, it needs >to send a packet first. But will it send a packet to the care-of address or home address of the CR or both? >If care-of address, the CR may just have moved. If home address, there will be no pinhole opened in the >NAT.
>
>RR may open the pinholes (but is it running on top of the same UDP ports as tunnels? I'm not sure.)

  It is. However, the pinhole (and checking of it's validity!) is actually created by the first keepalive message.

  Basically, what happens is:

  MR behind NAT #1, CR sees MR with NAT #1's external addr
  MR moves to NAT #2, remains connected via NAT #1, re-registers to HA
  MR sends (RR and) registration request to CR (to CR's home address)
  CR sees MR's registration coming from the NAT #2's external addr, replies
  MR sends first keepalive to CR (directly), CR replies, now sees the UDP port used for actual end-user data. (This is covered in 6.1, 4th paragraph) - the registration signaling was conducted between MR's CoA to CR's HoA.
  => Tunnel open via the new path

  Now, if both MR and CR are behind (separate) NATs, then that's of course a whole different story, but this scenario is covered in 6.1 as "out-of-scope". 

  However, apparently this could also use some clarification...


>>       0               1               2               3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |     Type      |    Sub-type   |             Length            |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       1..n times the following information structure
>It was unclear to me what the relationship of "n" and "Length" are. Please clarify.

  The relationship is that "when you have read the information structure, if you have already reached Length octets, you have also reached n"...Will clarify.

>> In
>>     the case of one or both of the routers is known to be behind NAT or
>>     similarly impaired (not being able to accept incoming connections),
>>     the tunnel establishment procedure SHOULD take this into account.
>
>This is not an implementable requirement. What follows after this text is better, and that's the beef of what >implementations must actually do. I would change the above text with s/SHOULD/need to/.

  Ok.

>Since this specification is experimental, your Section 1 should describe the areas which are uncertain and >which would benefit from experience with implementations and deployment. For instance, Section 7 lists >scalability to a large number of prefixes as an area where further experience is needed.

  Ok.

>Section 3.3 an 8.3 seem to disagree. The former says Krm is invalidated if care-of address changes, yet >the 8.3 example does not appear to rerun RR (or the care-of address test part of RR).

  The diagram in 8.3 omits RR since it can be optional (with e.g. static keys). Will add that.

  Thanks.

--
- Antti Mäkelä | Researcher -
- Department of communications and networking -
- Aalto University -