Subject: [nemo] review of draft-ietf-nemo-home-network-models-04.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Sep 2005 18:08:17 +0300

I was asked to review this document.

Overall, I found this document to be quite useful. The complexity
of the network scenarios can be surprising, and its good to have IETF
produce guidance on the use of its mechanisms. The content
of the draft is mostly OK. Some questions and issues were noted
below, however.

What troubled me perhaps most was that the
document suggests a mechanism to emulate returning
home when a virtual home link implementation is
being used at the home agent. I'm not convinced that this
is necessary, and if it is, this is probably something that should
be done for Mobile IPv6 and not just nemo. Getting rid of this
part of the document would also remove one normative behaviour
requirement (which currently does not feel appropriate in
an informational document such as this one).

Technical:

>    In implicit mode, the Home Agent has the necessary information to
>    continue routing to the MNPs in the absence of registration, and the
>    participation of the Mobile Router to the Home IGP is not required.

This may be a lack of understanding of RFC 3963 on my part, but
how does this actually work? Is the traffic to the MR routed through
home agent in all cases even when there's no registration?

>    When connecting to the Home Link, the Mobile Router also need to
>    autoconfigure an address on the egress interface as opposed to
>    assigning its Home Address to the interface.

And how does this work wrt. routing of the actual data packets?
Does this mean that the MR needs perform a registration to its
home agent, even if its on the home link?

> 5.5  Applicability
>    ...
>
>    Also, when the Home Address is derived from the prefix on the Home
>    Link, the Home Agent behavior on the link trivially extends that of
>    MIP and the support should for that configuration should be available
>    with all implementations.

But Section 5 appeared to be talking also about the case
when the MR's home address is not derived from the home
link prefix.

>    Alternatively, the Mobile Router might perform ND proxying for all
>    addresses in its MNPs, between the egress and the related ingress
>    interface.  Since the prefixes on the egress and ingress interfaces
>    are overlapping, routing is disallowed.

Reference to the ND proxy spec is appropriate here. But that
is experimental (and under discussion) -- is ND proxying what
we really want to do here?

>    Alternatives based on a routing protocol or ICMP redirect may apply
>    in some cases.

It would be interesting know what cases these are.

>                     /48                       eg: A:B:C::/48
>                     HA
>                     | /64                         A:C:C:E::/64
>          --+-----+--+- . -+- . -+--
>            |     |        |     |
>            MR1   MR2      MRi   MRN
>            /64   /64      /64   /64            A:B:C:i::/64  0 < i <= N
>
>
>
>                       Figure 5: Virtual Home Network

Is A:C:C:E::/64 correct? I would have assumed A:B:C:0::/64...

>    In order for a Mobile Router to emulate returning Home, it can
>    connect to one or more access link(s) configured for that purpose on
>    the Home Agent. ...
>    However, the Mobile Router must register its binding as if it was
>    accessing a foreign link.

I suspect this is the same as saying "in order to emulate returning
home link, the MR can connect to some other link and behave as
if it was accessing a foreign link" :-) Or am I missing something?

Suggest deleting or reformulating paragraph. Its clear that we can set up
networks and links close to the home agent, but in a virtual
network you don't return home, even if home might be just one
router hop away.

I would also suggest deleting appendix A.

>       There can be only one Home Agent since Mobile IPv6 relies on
>       Neighbor Discovery on the Home Link for other Home Agent discovery
>       and for Duplicate Address Detection.

As I have understood the Mobile IPv6 base requirements, there's
no mandate that you have to do home agent discovery only that way -
you could also configure things. And in theory you could construct
virtual links even across multiple home agents (such as via private
tunnels) but this would void the primary benefits of the virtual
approach i.e. ability to ignore what other nodes on the link are
doing. Suggested reformulation:

  As there is no physical link, this also implies that there can
  only be a single home agent per home prefix; multiple home
  agents would not be able to communicate with each other.

> 7.2  Applicability
>
>    At some point in the future, NEMO basic support may be extended to
>    operate fully at L3 for instance if the HAHA protocol [11] gets
>    standardized and deployed.  Until then, NEMO operations still inherit
>    from mobile IPv6 [7] for the Home Agent to Home Agent communication,
>    which is basically based on Neighbor Discovery extensions over the
>    Home Link.  Making that link virtual bars the deployment of multiple
>    Home Agents, which may be desirable for reasons of load balancing.
>    Please refer to the NEMO multihoming issues [12] draft for more on
>    this.

I'm not sure its useful to speculate about this. Also, this text
appears to be saying that Neighbor Discovery is not at L3.
Pointing to NEMO multihoming draft is good, though.

>    Alternatively, the
>    Home Agent may indicate that the Mobile Router has moved to the
>    virtual Home Access Links as a status code in the binding
>    acknowledgement.  The status code implies that Home Agent successsful
>    de-register the binding at the virtual Home Access Link. 

Which status code would this be? Neither RFC 3775 or 3963 appear to
define a code for this particular purpose.

Editorial:

>    acknowledgement.  The status code implies that Home Agent successsful

Typo.

>    of its own MNPs. .

Extra space.

>       physical maintenance or to hardware problems, so it is more
>       available than a physical link.  The high availability of the 
> Home Link is critical for the mobility service.     

... problems, so it has higher availability than a
physical link. This is critical ...

>    update with null lifetime sourced at the CareOf.  Alternatively, the

s/CareOf/care of address/

>    acknowledgement.  The status code implies that Home Agent successsful
>    de-register the binding at the virtual Home Access Link.  Detection

.. successfully de-registered ...

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 23 Sep 2005 16:44:51 -0700

> I was asked to review this document.

thanks for the review.

> an informational document such as this one).

there is a problem when there is a virtual home link and a
mobile router returns home. where does it connect to? does
it de-register? does it start sending routing protocol
updates in case it is capable of sending routing updates?
the last question especially is very important and is
specific only to NEMO.

the text we currently have is to address the above questions.
even for MIPv6, we need to address returning home in case
the home link is a virtual link, but the problem is not the
same. there are no routing updates from the mobile node that
could screw up route aggregation on the home network. also
for some reason the thinking was that in MIPv6 if the home
link is virtual the MN never goes home. the same may not be
true for mobile networks.

> home agent in all cases even when there's no registration?

for implicit mode, it is assumed the routes for MNPs exist
all the time. but the forwarding entry would point to a
virtual tunnel interface that wouldnt exist if the mobile
router does not have a valid binding cache entry at the HA.

in practice, the routes dont have to exist. there could be
some state on the HA which says, if the MR sends a binding
update in the implicit sate, create routes for these MNPs,
don't look for MNPs in the binding update. this is
implementation dependent.

> home agent, even if its on the home link?

this text is only specific to the case where the home address
of the MR is configured from the MNP. if the MR is capable of
sending routing protocol updates, it just sends an update for
the MNP. another option is to send an ICMP redirect for the MNP.
the MR shouldn't register with the home agent.

> when the MR's home address is not derived from the home

right. thats why we have the following text in section 5.3

    For all these reasons, this submode of extended is no more a trivial
    extension to the MIPv6 Home Model, and it might not be compatible
    with all implementations.

configuring a home address from the home prefix is the default
mechanism. configuring from the MNP may not work all the time.

> we really want to do here?

RFC 2461 allows a router to proxy for a host, right? that
should be sufficient. I dont think we are talking about the
ND proxying draft currently being discussed in the IPv6 WG.
Pascal, Ryuji, correct me if I am wrong.

> Is A:C:C:E::/64 correct? I would have assumed A:B:C:0::/64...

I think so...

> I would also suggest deleting appendix A.

well, we need to say something about returning home and virtual
home links. the alternative is to say, returning home for
virtual home links is not supported.

>  agents would not be able to communicate with each other.

ok.

> Pointing to NEMO multihoming draft is good, though.

you are right. should be re-written.

> define a code for this particular purpose.

looks like we need a new status code. :)

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Sep 2005 16:10:09 +0300

Hi Vijay,

> the last question especially is very important and is

I agree that the routing protocol update issue is
important. But its only important if you actually
do return home. NEMO works fine without ever
returning home, I suppose.

> implementation dependent.

Ok.

> the MR shouldn't register with the home agent.

Ok.

> mechanism. configuring from the MNP may not work all the time.

Right. I was asking whether this should be stated in 5.5, the
applicability section...

--Jari