Subject: [Mip4] AD review of draft-ietf-mip4-nemo-haaro (part 1)

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Sep 2011 00:31:14 +0300

I am reviewing this draft. So far I have progressed to the end of Section 3.3.3, and I have no major complaints. A couple of comments, however:

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.

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)

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

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

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Sep 2011 14:24:31 +0300

Continuing my review.

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

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

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

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

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

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.

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

Jari