Subject: Re: [Mip4] Comments on draft-ietf-mip4-nemo-haaro-02.txt

From: Antti Mäkelä <[email-masked]>
Date: Wed, 27 Oct 2010 19:35:46 +0300 (EEST)

Hi, thanks for comments. Especially the editorial ones :). I snipped 
them out and agree on almost all of them, but comments on the rest:

On Wed, 27 Oct 2010, Alexandru Petrescu wrote:

> My first comment is a question: is there a security problem of allowing
> MR to perform RR tests on behalf of an LFN, without LFN agreeing to this?

   In my opinion, no, as such - from perspective of LFN the MR is just a 
gateway router and shouldn't even care what tricks it has to do to get 
packets to their destination. If the LFN is setting it's (default) route 
to a mobile router, i.e. having it working as a gateway, it's implicitly 
agreeing to this.

   The current trust model assumes that HA has accurate information on 
network locations.

>> The basic premise is still the same; Mobile Routers, when
>> registering to the Home Agent, either inform the Home Agent of the
>> mobile network prefixes they are managing (explicit mode) or get
>> prefixes assigned by Home Agent (implicit mode).
> With respect to the implicit mode of rfc5177: I think the above text
> makes a wrong assumption: it reads as if the HA assigns a prefix to the
> MR upon registration.  This is not  happening so.  In implicit mode, the
> prefix is already assigned to the MR by non-MIP means, and configured in
> MR and in HA also by some non-MIP means.  HA does use a MIP-NEMO Prefix
> Table which uses that prefix, but it is in addition to the prefix being
> in its routing table.  In any case, that prefix is  not communicated by
> HA to MR.

   I think I disagree with you here on this one:

   Quoth RFC 5177, section 5, "Mobile Router Operation", on implicit mode:

In the latter case, the Home Agent obtains the Mobile Network Prefixes by 
other means than Mobile IP.  One example of obtaining the Mobile Network 
Prefix is through static configuration on the Home Agent.

   Also, 4.2, acknowledgement extension:

For Implicit Mode, the Mobile Network Acknowledgement informs the Mobile 
Router the prefixes for which the Home Agent sets up forwarding with 
respect to this Mobile Router.

   So to me this sound very much that HA informs MR what prefixes are 
assigned to it - of course the ultimate source for that assignment may be 
somewhere else than the HA.

> The prefixes are never assigned by the HA, by current state of affairs
> (no DHCPv4 Prefix Delegation for NEMOv4, expired daft-subnet-allocation,
> etc.)

   Is this just due to "current state of affairs" implementation wise? Why 
couldn't there be a HA that would be simply configured to divide e.g. a 
private address space (10.x.x.x) to /24-block and distribute it to MR's 
dynamically?

   Anyway, this can be corrected.

>> The schema requires a Mobile Router to be able to receive messages
>> from Home Agent and other Mobile Routers unsolicited - that is,
>> without first initiating a request.
>
> and soon below:
>
>> Note that the redistribution of network prefix information from the
>> Home Agent happens only during the registration signaling.  There are
>> no "routing updates" from Home Agent except during re-registrations
>> triggered by handovers, registration timeouts and specific
>> solicitation.
>
> It reads as this latter paragraph contradicts the former.  Reading the
> former paragraph I understand that the HA may send a message to MR
> without MR requesting it.  Yet the 2nd paragraph says there are no
> "updates" and that this information from HA happens as re-registration
> (a Reply from HA), timeouts (also initiated by MR) and specific
> solicitation (S bit set in RegReq).
>
> The comment: is it possible the HA sends a message to MR without MR
> requesting it first? (as rfc3543 RegRevocation message sent by HA to MR,
> without it being requested).  I hope not.

   No - the idea is that MR's may send registration messages to each other. 
It simply means that MR's must be able to receive signaling messages from 
other MRs (RR procedure and eventual Reg requests)

>> Upon receiving registration reply with a Route Optimization prefix
>> advertisement extension, the Mobile Router SHALL insert the Mobile
>> Router Home Addresses included in the extension as a host-prefixes
>> to the local Route Optimization Cache if they do not already exist.
> I read the "host-prefix" as a "host-based route", i.e. a 32-bit
> prefixlen route of the form: 192.0.1.1/32-192.0.1.2, where the .1 is the
> MR's HoA and .2 is the gateway.

   Yes, this is true. This is basically allowing for RO to take place 
between nodes.

>> The Route Optimization Cache contains mappings between potential
>> Correspondent Router HoA's, network(s) associated with each HoA,
>> network topology, and Return Routability procedure-related
>> information.
> In this list I think there should be the CoA too.

   Agreed.

> What is "network topology"?
>
>
> Later on in the draft when reading "The above information on network
> topology" makes think "network topology" is about NAT information and
> how NATted addresses hide private addresses, or so.  Is it this?  I
> think this is only a few aspects of what a network topology is.

   Yeah, that is correct. Maybe use "information on reachability" instead.

>> Two messages are sent to Correspondent Router's Home Address, one via
>> Home Agent using Mobile Router's Home Address, and the other directly
>> from the Mobile Router CoA, with two responses coming through same
>> routes.
> I think the two responses come through different IP paths, not same
> routes (although they can be forwarded according to same entries in
> routing tables - what is a "route"?).  And yes, they must end at the
> "same node".

   Agreed.

>> Each Mobile Router maintains a 'correspondent router key', Kcr, which
>> is MUST NOT be shared with any other entity.  Kcr is used for

   Also already received a comment on the "is MUST NOT" :)

>> authenticating peer Mobile Routers in the situation where mobile
>> router is acting as a CR.  This is analogous to node key, Kcn, in
>> Mobile IPv6.  Correspondent Router uses router key to verify that the
>> keygen tokens sent by Mobile Router in registration request are its
>> own.
> This last "its own"... CR's?  or MR's?

   CR's.

>> 3.3.1.  Triggering Route Optimization
>
> Is this section about triggering RO?  Or triggering starting RR?
>
> I think when MR receives other MR's prefix from HA we already have RO in
> place, although RR tests aren't performed yet... but I may be wrong.

   Basically the idea is (this is clarified in the examples a bit more) 
that if you have a small network of MR's, you can go ahead with route 
optimization right away and form a "full-mesh" of tunnels, but if you have 
more routers (hundreds), it might be beneficial to only initiate route 
optimization after you know there's going to be traffic to and from the 
target MR.

>> It is RECOMMENDED to start Route optimization only be started when
>> receiving a packet where destination address is in a locally managed
>> prefix (and the prefix is registered as route optimizable) and source
>> address exists in the network prefixes of Route Optimization Cache.
>
> Wrong twice use of "start", ok.
>
> The 2nd condition ("source adress exists in the network prefix") is
> ambiguous for implementation - how would an implementation make this
> check?   Is this longest-prefix match?  (remark longest-prefix match is
> specified and implemented for dst not src addresses).

   Idea is this that if you have network 192.168.1.0/24 as local, and you 
know that MR X manages network 192.168.2.0/24 (have it in your prefix 
table), and then you forward a packet from 192.168.2.5 to 1.5 (that came 
in via reverse tunnel), you can start RO with MR X - basically telling it 
"Hey, I own network 192.168.1.0/24, check if HA if you don't believe me, 
but you could send the stuff for this network directly to me".

>> In addition, host-routes to Correspondent Routers' Care-of addresses
>>  SHOULD be associated with the assigned to the physical interfaces
>> assigned with corresponding MR-CoA.
> However, I doubt there is necessity to specify the need of a host-based
> route towards the CoA - the default route should be sufficient, no?

   I think so. This is mostly implementation detail that can be left out 
from the spec. Initially we used routing (since basically MR had default 
route to reverse tunnel, and individual network routes to 
optimized-tunnels), the host-route to the CoA was there pointing to the 
physical interface so that the tunneled packets could get to their 
destination.
   Now we use socket option SO_BINDTODEVICE, instead, so no need to adjust 
routing tables for the tunnel.

>> optimized tunnel
> I am not sure what an optimized tunnel is.  It may be that is the tunnel
> interface on MR towards the other MR, for optimizing the path.  But that
> tunnel is not optimized ("optimized" with respect to what?).

   MR<->MR-tunnel.

>> When a Mobile Router wishes to leave network, 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.
> This reads as if the MR wishes to join the home link, right?  Not to
> leave network, right?

   Applies to both situations, of course.

>> This also indicates that the Mobile Router is capable of receiving
>> route optimization binding updates.
> I think that's rather RO-capable RegReq instead of RO BU.

   Eek, MIP6 term got left in.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Oct 2010 08:42:06 +0200

Le 27/10/2010 18:35, Antti Mäkelä a écrit :
>> My first comment is a question: is there a security problem of
>> allowing MR to perform RR tests on behalf of an LFN, without LFN
>> agreeing to this?
>
> In my opinion, no, as such - from perspective of LFN the MR is just
> a gateway router and shouldn't even care what tricks it has to do to
>  get packets to their destination. If the LFN is setting it's
> (default) route to a mobile router, i.e. having it working as a
> gateway, it's implicitly agreeing to this.

Hmmm, in a sense I agree with it, as you write it.

In another sense I think LFN should be more in charge about who does RO
for whom, because it is LFN the end.

This is obviously not black-and-white.

>>> registering to the Home Agent, either inform the Home Agent of
>>> the mobile network prefixes they are managing (explicit mode) or
>>> get prefixes assigned by Home Agent (implicit mode).
>> With respect to the implicit mode of rfc5177: I think the above
>> text makes a wrong assumption: it reads as if the HA assigns a
>> prefix to the MR upon registration. This is not happening so. In
>> implicit mode, the prefix is already assigned to the MR by non-MIP
>> means, and configured in MR and in HA also by some non-MIP means.
>> HA does use a MIP-NEMO Prefix Table which uses that prefix, but it
>> is in addition to the prefix being in its routing table. In any
>> case, that prefix is not communicated by HA to MR.
>
>> In the latter case, the Home Agent obtains the Mobile Network
>> Prefixes by other means than Mobile IP. One example of obtaining
>> the Mobile Network Prefix is through static configuration on the
>> Home Agent.

Yes, that means that the HA (not MR) obtains the MNP by being statically
configured with it.

>> For Implicit Mode, the Mobile Network Acknowledgement informs the
>> Mobile Router the prefixes for which the Home Agent sets up
>> forwarding with respect to this Mobile Router.

Yes, that is so for e.g. a human debugger to be able to look at
wireshark logs and understand what the HA did.  The spec does not say
that MR would retrieve MNP from RegRep and insert it in its (MR's)
routing table.

> assigned to it - of course the ultimate source for that assignment
> may be somewhere else than the HA.

Hmm, if this is how you read it then we may need to clarify it in the
spec; there was no intention to require the HA to communicate the MNP to
MR such that MR to insert that MNP in its routing table.  MR is supposed
to know its MNP prior to sending a RegReq to its HA, otherwise LFNs
under MR couldn't talk to each other when MR is disconnected from
infrastructure.

>> The prefixes are never assigned by the HA, by current state of
>> affairs (no DHCPv4 Prefix Delegation for NEMOv4, expired
>> daft-subnet-allocation, etc.)
>
> Is this just due to "current state of affairs" implementation wise?

Spec-wise.

> Why couldn't there be a HA that would be simply configured to divide
> e.g. a private address space (10.x.x.x) to /24-block and distribute
> it to MR's dynamically?

Oh no, no private space for a MIP node :-)

But yes, there could be designed a new mechanism to deliver MNP to MR
such that MR configures it in its routing table.  A sort of
bootstrapping MNP.  Kind of dhcpv4-prefix-delegation; or one that I just
discovered draft-ietf-dhc-subnet-alloc-11.txt.

I wouldn't like HA to assign a prefix to MR via RegRep, because
assigning prefixes should be a different operation than updating paths
to them (DHCP vs OSPF, RA vs MIP6, etc.).

>>> The schema requires a Mobile Router to be able to receive
>>> messages from Home Agent and other Mobile Routers unsolicited -
>>> that is, without first initiating a request.
>>
>> and soon below:
>>
>>> Note that the redistribution of network prefix information from
>>> the Home Agent happens only during the registration signaling.
>>> There are no "routing updates" from Home Agent except during
>>> re-registrations triggered by handovers, registration timeouts
>>> and specific solicitation.
>>
>> It reads as this latter paragraph contradicts the former. Reading
>> the former paragraph I understand that the HA may send a message
>> to MR without MR requesting it. Yet the 2nd paragraph says there
>> are no "updates" and that this information from HA happens as
>> re-registration (a Reply from HA), timeouts (also initiated by MR)
>> and specific solicitation (S bit set in RegReq).
>>
>> requesting it first? (as rfc3543 RegRevocation message sent by HA
>> to MR, without it being requested). I hope not.
>
> No - the idea is that MR's may send registration messages to each
> other. It simply means that MR's must be able to receive signaling
> messages from other MRs (RR procedure and eventual Reg requests)

Ok, so it doesn't mean that MR should receive unsolicited messages from
HA, as the Revocation works.  Yet the text says: "The schema requires a
Mobile Router to be able to receive messages from Home Agent and other
Mobile Routers unsolicited - that is, without first initiating a request."

>>> Upon receiving registration reply with a Route Optimization
>>> prefix advertisement extension, the Mobile Router SHALL insert
>>> the Mobile Router Home Addresses included in the extension as a
>>> host-prefixes to the local Route Optimization Cache if they do
>>> not already exist.
>> prefixlen route of the form: 192.0.1.1/32-192.0.1.2, where the .1
>> is the MR's HoA and .2 is the gateway.
>
>> Later on in the draft when reading "The above information on
>> network topology" makes think "network topology" is about NAT
>> information and how NATted addresses hide private addresses, or
>> so. Is it this? I think this is only a few aspects of what a
>> network topology is.
>

"information on rechability related to NAT divisions" or so.

>>> Two messages are sent to Correspondent Router's Home Address,
>>> one via Home Agent using Mobile Router's Home Address, and the
>>> other directly from the Mobile Router CoA, with two responses
>>> coming through same routes.
>>> Each Mobile Router maintains a 'correspondent router key', Kcr,
>>> which is MUST NOT be shared with any other entity. Kcr is used
>>> for
>
>>>  Mobile IPv6. Correspondent Router uses router key to verify
>>> that the keygen tokens sent by Mobile Router in registration
>>> request are its own.
>> I think when MR receives other MR's prefix from HA we already have
>> RO in place, although RR tests aren't performed yet... but I may be
>> wrong.
>
> optimization right away and form a "full-mesh" of tunnels, but if you
> have more routers (hundreds), it might be beneficial to only initiate
> route optimization after you know there's going to be traffic to and
> from the target MR.

I agree with the idea that RR tests should be started only when there is
traffic needing shorter-than-through-HA paths.

Speaking of which, I wonder why is there a need of RR tests at all,
knowing the trust relationships MR-HA-MR.

>>> It is RECOMMENDED to start Route optimization only be started
>>> when receiving a packet where destination address is in a
>>> locally managed prefix (and the prefix is registered as route
>>> optimizable) and source address exists in the network prefixes
>>> of Route Optimization Cache.
>>
>> ambiguous for implementation - how would an implementation make
>> this check? Is this longest-prefix match? (remark longest-prefix
>> match is specified and implemented for dst not src addresses).
>
> Idea is this that if you have network 192.168.1.0/24 as local, and
> you know that MR X manages network 192.168.2.0/24 (have it in your
> prefix table), and then you forward a packet from 192.168.2.5 to 1.5
> (that came in via reverse tunnel), you can start RO with MR X -
> basically telling it "Hey, I own network 192.168.1.0/24, check if HA
> if you don't believe me, but you could send the stuff for this
> network directly to me".

I agree with the idea.

I think though checking every incoming packet's src address (e.g.
192.168.2.5) against a table of prefixes and hoping success on
192.168.2.0/24 is a costly computational operation on a "critical path"
if I can say so.  This adds to the cost of checking the dst address,
which is mandatory.  The cost is in the way longest-prefix match works.
  Were it exact match (no prefix len) it would have been faster.

I mean this src check can slow the MR down.

Are there other less compute intensive ways to trigger RR.

>>> In addition, host-routes to Correspondent Routers' Care-of
>>> addresses SHOULD be associated with the assigned to the physical
>>> interfaces assigned with corresponding MR-CoA.
>> However, I doubt there is necessity to specify the need of a
>> host-based route towards the CoA - the default route should be
>> sufficient, no?
>
> I think so. This is mostly implementation detail that can be left
> out from the spec. Initially we used routing (since basically MR had
>  default route to reverse tunnel, and individual network routes to
> optimized-tunnels), the host-route to the CoA was there pointing to
> the physical interface so that the tunneled packets could get to
> their destination. Now we use socket option SO_BINDTODEVICE,
> instead, so no need to adjust routing tables for the tunnel.

A-ha.

>>> optimized tunnel
>> I am not sure what an optimized tunnel is. It may be that is the
>> tunnel interface on MR towards the other MR, for optimizing the
>> path. But that tunnel is not optimized ("optimized" with respect
>> to what?).
>
> MR<->MR-tunnel.

Hmmm... I just am not used to the term "optimized tunnel".

>>> When a Mobile Router wishes to leave network, 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.

Well no, when MR _leaves_ the home network it sets the lifetime in
RegReq to something else than 0.

>>> This also indicates that the Mobile Router is capable of
>>> receiving route optimization binding updates.

Ok, thanks,

Alex

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

---

From: Antti Mäkelä <[email-masked]>
Date: Thu, 28 Oct 2010 11:34:34 +0300 (EEST)

> This is obviously not black-and-white.

   I don't think it affects the RO process itself - only the conditions 
on when to use it. It could be a policy routing decision on the MR, based 
on whatever fields one wants to use - for example, have only packets with 
specific conditions going for RO-tunnels and others to the reverse tunnel 
to HA (TOS? Matching an access-list? ).

   In the end it comes to a discussion on what network element actually 
owns the network as a whole.

> that MR would retrieve MNP from RegRep and insert it in its (MR's)

   Ok, so the prefix information in implicit mode is purely informative 
with no functional implications?

   We can change the wording here, then.

> under MR couldn't talk to each other when MR is disconnected from

   Yes, well, I was under the impression that this was indeed a form of 
Prefix Delegation.

   If not, then there might be indeed a place for a new mechanism.

> Mobile Routers unsolicited - that is, without first initiating a request."

   Indeed - slash the HA from here. I think the HA was included here 
because the signaling path goes via HA, but of course HA is just a 
forwarder in this case.

> knowing the trust relationships MR-HA-MR.

   Ok, the trust model is thus:

   MR's trust HA.

   Info gained from HA: HoA's of potential peer MRs, and prefixes they own.

   MR's there trust that specific network is behind a specific HoA.

   RR procedure is there to establish CoA <-> HoA binding.

   So after RR, MR's will know that specific network is behind a specific 
CoA.

   So the RR does serve a purpose. Of course (as it says), the RR procedure 
can be skipped if desired and you can use some other key distribution 
mechanism (external to MIP).

> Are there other less compute intensive ways to trigger RR.

   Well, you could (on the assumption that traffic is bidirectional 
anyway), do the check on destination packets leaving the router instead. 
That way, when a packet is heading out to .2.5, you send the packet via 
reverse tunnel, sure, but at same time start the RO process "I'm sending 
some data to your network and your network is probably going to reply, so 
might as well send the reply directly to me".

   The triggering on the source has a bit more certainty "someone has sent 
my network a data packet, he'll probably do it again and could benefit 
from RO", with the destination you have "My network is sending someone 
else's network a data packet, his network will probably reply and could 
benefit from RO".

   However, the computational cost is clearly an argument to switch the 
trigger recommendation to matching on destination.

> RegReq to something else than 0.

   Ah, I'm seeing the misunderstanding here - When I talk about leaving 
network, I mean leaving it completely, not joining home link or anything 
else, either. We have been running with virtual home networks (so they 
exist only as an IP pool). Can change the terminology from leaving/joining 
network to joining/leaving home link instead.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Oct 2010 17:18:33 +0200

Le 28/10/2010 10:34, Antti Mäkelä a écrit :
>>> In my opinion, no, as such - from perspective of LFN the MR is
>>> just a gateway router and shouldn't even care what tricks it has
>>>  to do to get packets to their destination. If the LFN is setting
>>>  it's
>> In another sense I think LFN should be more in charge about who
>> does RO for whom, because it is LFN the end.
>>
>  on when to use it. It could be a policy routing decision on the MR,
>  based on whatever fields one wants to use - for example, have only
> packets with specific conditions going for RO-tunnels and others to
> the reverse tunnel to HA (TOS? Matching an access-list? ).
>
>>>> For Implicit Mode, the Mobile Network Acknowledgement informs
>>>> the Mobile Router the prefixes for which the Home Agent sets
>>>> up forwarding with respect to this Mobile Router.
>> wireshark logs and understand what the HA did. The spec does not
>> say that MR would retrieve MNP from RegRep and insert it in its
>> (MR's) routing table.
>

YEs, for implicit more the prefix info (only in RegRep, absent from
RegReq) is there only for debugging.

>>> So to me this sound very much that HA informs MR what prefixes
>>> are assigned to it - of course the ultimate source for that
>>> assignment may be somewhere else than the HA.
>> Hmm, if this is how you read it then we may need to clarify it in
>> the spec; there was no intention to require the HA to communicate
>> the MNP to MR such that MR to insert that MNP in its routing table.
>> MR is supposed to know its MNP prior to sending a RegReq to its HA,
>> otherwise LFNs under MR couldn't talk to each other when MR is
>> disconnected from infrastructure.
>

I agree.  NEMOv4 (like NEMOv6) doesn't offer a means to HA to assign a
prefix to MR; neither in implicit nor in explicit modes.

>>>> The comment: is it possible the HA sends a message to MR
>>>> without MR requesting it first? (as rfc3543 RegRevocation
>>>> message sent by HA to MR, without it being requested). I hope
>>>> not.
>>> No - the idea is that MR's may send registration messages to
>>> each other. It simply means that MR's must be able to receive
>>> signaling messages from other MRs (RR procedure and eventual Reg
>>>  requests)
>> Ok, so it doesn't mean that MR should receive unsolicited messages
>>  from HA, as the Revocation works. Yet the text says: "The schema
>> requires a Mobile Router to be able to receive messages from Home
>> Agent and other Mobile Routers unsolicited - that is, without first
>> initiating a request."
>

Ah I see.  HA as forwarder (MR sends through HA a message to another MR
which listens) it makes sense.

>>>> I think when MR receives other MR's prefix from HA we already
>>>> have RO in place, although RR tests aren't performed yet... but
>>>> I may be wrong.
>>> Basically the idea is (this is clarified in the examples a bit
>>> more) that if you have a small network of MR's, you can go ahead
>>>  with route optimization right away and form a "full-mesh" of
>>> tunnels, but if you have more routers (hundreds), it might be
>>> beneficial to only initiate route optimization after you know
>>> there's going to be traffic to and from the target MR.
>>
>> I agree with the idea that RR tests should be started only when
>> there is traffic needing shorter-than-through-HA paths.
>>
>> Speaking of which, I wonder why is there a need of RR tests at
>> all, knowing the trust relationships MR-HA-MR.
>

But HA _could_ tell CR about the CoA too of another MR (not only MR's
HoA and MNP), no?  If yes then RR tests wouldn't be absolutely
necessary, I think.

> So after RR, MR's will know that specific network is behind a
> specific CoA.
>
> So the RR does serve a purpose.

YEs I agree RR serves the purpose for CoA testing here.

LEt me remind a goal of why are there Return Routability tests in MIPv6
- it's because PKI and IPsec was not usable across the Internet at the
time of RR design.  Probably not now either.

One needed a means to develop security associations between two nodes
across the Internet.  PKI couldn't, IKE was too heavy (for both HoA and
CoA) and there may have been more reasons against IKE.  An earlier
similar security problem happened for TCP attacks and "cookies" were
developped in the same way as RR tests.

However, these two situations (MIP6 across Internet, TCP cookies) do not
seem to apply here because we have two MRs of same Home Agent - they
have a common "anchored" trust if I can say so.  With such a common
"anchor" the RR tests don't seem necessary, IMHO.

Of course, RR is cool and could be used.  I am not against it.

> Of course (as it says), the RR procedure can be skipped if desired
> and you can use some other key distribution mechanism (external to
> MIP).

Could it be that HA delivers HoA/CoA/MNP of an MR to another MR?  That
would still be MIP.

>>> Idea is this that if you have network 192.168.1.0/24 as local,
>>> and you know that MR X manages network 192.168.2.0/24 (have it in
>>> your prefix table), and then you forward a packet from
>>> 192.168.2.5 to 1.5 (that came in via reverse tunnel), you can
>>> start RO with MR X - basically telling it "Hey, I own network
>>> 192.168.1.0/24, check if HA if you don't believe me, but you
>>> could send the stuff for this network directly to me".
>>
>> I agree with the idea.
>>
>> 192.168.2.0/24 is a costly computational operation on a "critical
>> path" if I can say so. This adds to the cost of checking the dst
>> address, which is mandatory. The cost is in the way longest-prefix
>>  match works. Were it exact match (no prefix len) it would have
>> been faster.
>>
> anyway), do the check on destination packets leaving the router
> instead. That way, when a packet is heading out to .2.5, you send the
> packet via reverse tunnel, sure, but at same time start the RO
> process "I'm sending some data to your network and your network is
> probably going to reply, so might as well send the reply directly to
>  me".
>
> The triggering on the source has a bit more certainty "someone has
> sent my network a data packet, he'll probably do it again and could
> benefit from RO", with the destination you have "My network is
> sending someone else's network a data packet, his network will
> probably reply and could benefit from RO".
>

Ok.

>>>> This reads as if the MR wishes to join the home link, right?
>>>> Not to leave network, right?
>  network, I mean leaving it completely, not joining home link or
> anything else, either. We have been running with virtual home
> networks (so they exist only as an IP pool). Can change the
> terminology from leaving/joining network to joining/leaving home link
> instead.

Ah ok, I see now about "leaving" the network.  I am not used to this
term.  Moreover I use "join" and "leave" to talk exclusively multicast,
which is not here.

Antti - thanks for remarks.  I think this draft represents a good idea,
seems implemented and tested, is understandable.  It has a strong value
as being the only documented and implemented means of RO for network
mobility.  This topic of RO for NEMO has been struggled with
in many other drafts which expired, and articles but never(?) has there
been any implementation of RO for NEMO.

The particular comments I've sent are only about principle discussion,
they do not necessarily mean to change the draft (other than the
clarification of implicit mode of NEMOv4, and the typos).

Then, about the RO for NEMOv6 problem there are some RFCs which deserve
referral: rfc4888 and -9.

(a side note: in rfc4888 there is one particular problem which I
  consider difficult for NEMO: the "stalemate" situation with nested MRs
  and HA-in-moving-network, Appendix A.  I plan to ask each RO-NEMO
  solution whether or not it solves that stalemate situation.  I can not
  ask HAaRO because HAaRO only talks one HA, which is fine.)

Alex

---

From: Antti Mäkelä <[email-masked]>
Date: Thu, 28 Oct 2010 22:54:32 +0300 (EEST)

> HoA and MNP), no?  If yes then RR tests wouldn't be absolutely

   It could, but then if there's a handover there would have to be an 
active "routing update" by the HA towards whatever CRs the moving MR would 
have. So if MR is attached to CoA X and moves to CoA Y, he can basically 
just send a new RR + registration to his peers - and all the signaling is 
initiated by the moving MR.

   If the CoA information would be sent by the HA, then there would have to 
be a mechanism where HA, after having learned of the new CoA (when the MR 
registers from it's new point of attachment), would then have to somehow 
pass this information onwards to all existing and potential CRs - and we 
are back to situation where MRs would have to actively listen to some sort 
of "routing update" message from HA.

> "anchor" the RR tests don't seem necessary, IMHO.

   As the document states, the KRm doesn't have to be generated by RR 
procedure, if there are other ways that are better suited to specific 
situations. RR's good qualities and simplicity however are rather 
appealing.

> Could it be that HA delivers HoA/CoA/MNP of an MR to another MR?  That

   See above. If you forget RR, the thing that MR really trusts is the key, 
i.e. if the peer knows the correct key, then the CoA<->HoA binding is 
accurate. RR is just a method for acquiring the key.

   Well, of course peer MR's could solicit for validity of unknown CoA's of 
incoming registration requests (as they now have possibility for checking 
if HoA <-> prefix pair is valid), but this could create a nice avenue for 
a reflected DoS attack on the HA :)

> ask HAaRO because HAaRO only talks one HA, which is fine.)

   Yeah, apart from High Availability situations, we have left sharing info 
between HA's out of scope.

   Also, many thanks to you for all your comments.