Subject: [nemo] Michael's comments on NEMO spec

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Apr 2004 19:33:32 -0700

hi Michael and Harald,

thanks for your review and comments.

> Technical Problems
> ------------------
> 
> In at least two places they have a requirement that a mobile router
> that advertises it's network when at home must never advertise this
> prefix on a visited network.  This is a requirement which cannot, in
> practice, be met in all cases.  A periodic routing packet could be
> sent in the interval between when the connectivity changes and the
> router discovers that fact (think atmospheric effects on radio
> transmission, or an Ethernet switch having the VLAN allocations
> changed).

once the mobile router realizes it is no longer on the
Home Link, it should not advertise the Mobile Network
Prefix in the visited link. we dont want the mobile router
to disseminate wrong prefix information in the visited
network.

the mobile router recognizes that it is not longer on the
home link based on the prefix information in the router
advertisements advertised by the routers on the visited
link.

> 
> In section 6.6 under a certain condition (which is independent of
> whether implicit or explicit mode is in use) it describes sending error
> status code 140.  However, in the description of what a MR does with
> responses in explicit mode, error code 140 implies discard response.
> If the MR is going to discard it, why send it?  The MR needs to know
> there was a problem, so I think the fix is to make it process these.

you are right. this is a slip. Steve Bellovin also spotted
it. the MR should process 140 in both implicit and explicit
mode. this has been fixed now.

> Other problems with the document
> --------------------------------
> 
> Both sections 5.2 and 6.2 talk about only implicit and explicit modes
> of operation and ignore dynamic routing.  This case needs to be
> covered in these sections as well.

fixed this.

> 
> In some places it says a success is indicated by a status code of 0
> while in others it says any code from 0-127 is success.  It needs to
> get that right everywhere.

I couldnt find this. we do say that the success status
is 0. in the Mobile IPv6 specification, 0-127 does
indicate success, but anything other than 0 means the
binding update was processed succesfully, but the Mobile
Node has to do something in addition. this spec does not
introduce any new status values between 0 and 127. status
values greater than 127 indicate that the binding update
was not processed succesfully.

> 
> Section 5.4 has a lot of wording problems, not the least of which is
> the frequent use of the word "should" in lower case.  I'm not sure if
> they want them to be SHOULD, if not I advise use of a different word,
> and if so, fix it.

I rewrote section 5.4 a bit. the new text is at
http://people.nokia.net/vijayd/nemo/draft-ietf-nemo-basic-support-pre03.txt

> 
> In the second paragraph of 5.5 they talk about the single
> bi-directional tunnel and two simplex tunnels.  They need to get their
> terminology straight.

RFC 2473

    Bi-directional tunneling is achieved by merging two unidirectional
    mechanisms, that is, configuring two tunnels, each in opposite
    direction to the other - the entry-point node of one tunnel is the
    exit-point node of the other tunnel (see Fig.2).

we should probably just point to this text and not try to
rephrase it.

> 
> The second one of the ticked items in 6.2 (i.e. the second indented
> thing with a "-" in front) I just didn't get.  I read it several
> times, took a break, came back and read it several more times.  After
> that, it still wasn't clear to me what it was doing there.  My
> understanding of the words always resulted in either a tautology or a
> non-sequitur, neither of which could have been their intent.

in Mobile IPv6, the Home Agent rejects a binding update if
the home address in the binding update is not configured
from the prefix advertised on the home link. in NEMO, a
mobile router could configure a home address from the prefix
advertised in the Mobile Network. the prefix on the Mobile
Network is always different from the prefix advertised on
the home link. so we relaxing the MIPv6 requirement. the
home agent only has to make sure that the home address belongs
to the aggregated prefix that it is configured to serve. the
aggregated prefix here includes the home prefix and all
prefixes delegated to the all mobile routers that the home
agent is currently supporting.

> 
> In the third paragraph under section 5, the wording is quite strange.
> I'm not sure what they are doing without more research than I have
> time for, but my guess is that they are saying at the end that under a
> specific set of criteria, they are relaxing a MUST in another document
> to a MAY, but they need to be clearer on the intent.

yup. I will add some text clarifying this.

> 
> In section 8 they describe a requirement for confidentiality (and
> there may be confidentiality aspects to other parts of the operation),
> but there is no mention of confidentiality in the "Security
> Considerations".  I think there are other things that need to be in
> there, too, but leave more detailed critique to the Security Area.

good catch. added some text in the Security Considerations
section.

> 
> There are two sections titled "References", neither of which has a
> section number or appears in the TOC.  My first guess was that one was
> supposed to be normative and the other informative, but if that's so
> they have several references misfiled (5 is info not norm, 8&9 are
> norm).

moved 5 to informative. I dont think the two terminology
documents should be normative. I made sure that this spec is
self-contained with respect to terminilogy. you can get a
better idea of what Mobile Routers are by looking up the
terminology documents. that is why they are informative.

> In several places they talk about operation in the various modes, but
> never really say how a node decides which.  I realize that the intent
> is that it's locally configured in the MR, but I think it deserves
> being explicitly said somewhere.

this depends on local configuration on the mobile router. I
will add some text making this more explicit.

thanks again for the thorough review.

Vijay

ps: your comments are files as issue 35 at
http://people.nokia.net/vijayd/nemo/issues.html

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Apr 2004 23:44:28 -0700

Harald Tveit Alvestrand wrote:
> 
> Thanks for the update!
> 
> --On 14. april 2004 19:33 -0700 Vijay Devarapalli 
> <[email-masked]> wrote:
> 
>> hi Michael and Harald,
>>
> so the requirement is that "once the mobile router realizes it is no 
> longer on the home link, it MUST NOT advertise the Mobile Network Prefix"?

right, this was the intention.

Vijay

> 
> I think that's sensible, and certainly looks implementable to me. It was 
> the requirement to do it before realizing that the move had happened 
> that was iffy....
> 
>                     Harald
> 
> 
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 14 Apr 2004 23:44:28 -0700

Vijay

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 14 Apr 2004 22:50:12 -0700

Thanks for the update!

> advertisements advertised by the routers on the visited

so the requirement is that "once the mobile router realizes it is no longer 
on the home link, it MUST NOT advertise the Mobile Network Prefix"?

I think that's sensible, and certainly looks implementable to me. It was 
the requirement to do it before realizing that the move had happened that 
was iffy....

                     Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 14 Apr 2004 22:50:12 -0700

Thanks for the update!

                     Harald