Subject: [netlmm] On the Use of DAD NS to Trigger MAP Registration

From: Christian Vogt <[email-masked]>
Date: Mon, 03 Jul 2006 05:28:33 +0200

Hi Julien,

this is a comment on ticket #22 ("Multicast IPv6 ND triggers do not
provide MN with confirmation of MAP registration success/failure") in
the issue tracker, regarding draft-ietf-netlmm-mn-ar-if:

http://www1.tools.ietf.org/wg/netlmm/trac/ticket/22

The issue description ends by proposing a solution:

"Proposed Resolution: No text change. The only possibility of MAP
registration failure is 1) MN tries to use a duplicated address and 2)
AR cannot reach the MAP because the network is broken. [...]"

My comment is that both of /these/ cases are not that critical because
in either of them can a defending NA be sent to the mobile node:  In
case (1), the defending NA is proxied by the AR anyway, according to RFC
2462.  In case (2), the AR would end up waiting in vain for the MAP's
registration acknowledgment, so after a timeout, it may give up and send
the MN a "defending" NA, thus telling the mobile node not to use the new
address.

A more critical, additional issue, however, is loss of the NS or NA on
the MN-AR link.  In this case, there is indeed no way for the MN to
learn that it cannot use its new address.

Some thoughts on the probability for this to happen:

In plain IPv6, loss of a DAD NS or NA can lead to two nodes competing
for the same address, rendering both nodes unable to communicate through
that address.  The probability for such an event is the product of the
probability for an address collision times the probability for packet
loss of the NS or NA.

If you use the DAD NS for triggering NETLMM registration, failure would
also render the respective mobile node unable to communicate.  Yet, the
probability for this to happen is then the probability of packet loss.
This is much, much higher than the corresponding probability in plain IPv6!

Proposed solution:  Use the RS/RA exchange also for the initial
registration with the NETLMM domain.  The RA is then a positive
acknowledgment by means of which packet loss can be detected.  I did not
look carefully into this, but it seems that there is no reason why the
MN could not use DNA during the initial registration.  (Draft
draft-ietf-netlmm-mn-ar-if-01.txt currently differentiates between the
initial attachment and subsequent handoffs.)

Specifically, section 5.2.4 of draft-ietf-dna-protocol-01.txt says that
(1) the RS is sent "upon the occurrence of a Layer 2 link-up event
notification", which also applies during the boot-up process; that (2) a
Landmark Option SHOULD be added to the RS, which means that during the
initial registration the Landmark option could be omitted; and that (3)
"the source address MUST be the link local address of the host", which
is exactly what we need.

So upon initial registration, my suggestion is that the MN would
configure a link-local address, set it to Optimistic state, and send an
RS using the optimistic address as the source address--- just as
specified by DNA.  Due to the specified source address in the RS, the RS
can be secured through SEND, and the AR can also identify the MN.

Furthermore, using the RS/RA exchange as a trigger for MAP registration
also solves the issue with multiple ARs registering the MN at the MAP
simultaneously (ticket #23 in the tracker).  The DNA protocol uses
FastRA to come up with an ordering in which ARs respond to multicast RS.
 So you could either (1) define the AR that is first in this ordering to
be the one responsible for registering the MN; or, more reliably, (2)
have each on-link AR register the MN if, at the time this AR is
scheduled to send its RA (according to FastRA), no other AR has so far
sent an RA.  In case (2), loss of an RA may lead more than one AR to
register the MN, but that should be ok since it simply causes slightly
more registration traffic (between the ARs and the MAP) in the case of
packet loss.

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Julien Laganier <[email-masked]>
Date: Mon, 3 Jul 2006 12:34:36 +0200

Hi Christian, 

Thanks for your comment. More inlined below...

On Monday 03 July 2006 05:28, Christian Vogt wrote:
> provide MN with confirmation of MAP registration success/failure")
> in the issue tracker, regarding draft-ietf-netlmm-mn-ar-if:
>
> registration failure is 1) MN tries to use a duplicated address and
> 2) AR cannot reach the MAP because the network is broken. [...]"
>
> My comment is that both of /these/ cases are not that critical
> because in either of them can a defending NA be sent to the mobile
> node:  In case (1), the defending NA is proxied by the AR anyway,
> according to RFC 2462.  In case (2), the AR would end up waiting in
> vain for the MAP's registration acknowledgment, so after a timeout,
> it may give up and send the MN a "defending" NA, thus telling the
> mobile node not to use the new address.

Right.

> A more critical, additional issue, however, is loss of the NS or NA
> on the MN-AR link.  In this case, there is indeed no way for the MN
> to learn that it cannot use its new address.

True.

> In plain IPv6, loss of a DAD NS or NA can lead to two nodes
> competing for the same address, rendering both nodes unable to
> communicate through that address.  The probability for such an
> event is the product of the probability for an address collision
> times the probability for packet loss of the NS or NA.
>
> If you use the DAD NS for triggering NETLMM registration, failure
> would also render the respective mobile node unable to communicate.

>  Yet, the probability for this to happen is then the probability of
> packet loss. This is much, much higher than the corresponding
> probability in plain IPv6!

Actually it would just cause the MN to be unreachable until it starts 
to source packets with its IP adddress. Then its AR would see IP 
packets sourced from an IP address it hasn't registered, and will 
hence solicit the IP address with a NS. When the AR receives the 
signed NA from the MN, it will registers it.

This behavior is specified in subsection 4.3.1. "Sending NSs"

   An AR sends an NS to a MN in the following cases:

[...]

   o  The AR receives from the MN an IP packet which is not a ND or 
      DHCP Message before the MN registers the IP packet's source
      address.

And subsection 4.2.2. "Receiving All Others ND Messages"

   If the AR receives any other ND message than those enumerated
   above, the message is secure according to [RFC3971], and the source
   address of the packet is not the unspecified address, it MUST try
   to register its source address with the MAP.

I think the first bullet would be clearer as:

   o  The AR receives from the MN an IP packet which is not a ND or 
      DHCP Message before it has registered the MN's address (i.e. the
      IP packet's source.)

> acknowledgment by means of which packet loss can be detected.  I
> did not look carefully into this, but it seems that there is no
> reason why the MN could not use DNA during the initial
> registration.  (Draft draft-ietf-netlmm-mn-ar-if-01.txt currently
> differentiates between the initial attachment and subsequent
> handoffs.)

I think you are referring to subsection 2.1 and included figures. This 
section, and all other subsection of Section 2. do not contain 
normative text and are intended as example of how it works. The 
normative text is in section 3 and 4. So the solution you propose is 
actually already covered by subsection 4.2.2. "Receiving All Others 
ND Messages" as cited above. The signed RA would trigger a NetLMM 
UPDATE.

> Specifically, section 5.2.4 of draft-ietf-dna-protocol-01.txt says
> that (1) the RS is sent "upon the occurrence of a Layer 2 link-up
> event notification", which also applies during the boot-up process;
> that (2) a Landmark Option SHOULD be added to the RS, which means
> that during the initial registration the Landmark option could be
> omitted; and that (3) "the source address MUST be the link local
> address of the host", which is exactly what we need.
>
> configure a link-local address, set it to Optimistic state, and
> send an RS using the optimistic address as the source address---
> just as specified by DNA.  Due to the specified source address in
> the RS, the RS can be secured through SEND, and the AR can also
> identify the MN.

Yes it is intent that the MN does not behave differently from the 
specification of DNA.

> Furthermore, using the RS/RA exchange as a trigger for MAP
> registration also solves the issue with multiple ARs registering
> the MN at the MAP simultaneously (ticket #23 in the tracker).  The
> DNA protocol uses FastRA to come up with an ordering in which ARs
> respond to multicast RS. So you could either (1) define the AR that
> is first in this ordering to be the one responsible for registering
> the MN; or, more reliably, (2) have each on-link AR register the MN
> if, at the time this AR is scheduled to send its RA (according to
> FastRA), no other AR has so far sent an RA.  In case (2), loss of
> an RA may lead more than one AR to register the MN, but that should
> be ok since it simply causes slightly more registration traffic
> (between the ARs and the MAP) in the case of packet loss.

True. 

Perhaps all of the above should be written down, to  highlight the 
fact that loss of DAD-NS is covered by reception of RS, or plain IP 
packets in the case of non-DNA nodes.

Thanks.

--julien

---

From: Christian Vogt <[email-masked]>
Date: Tue, 04 Jul 2006 10:09:20 +0200

Hi Julien.

> signed NA from the MN, it will registers it.

Alright, this will work.  It handles packet loss, and should also work
fine in spite of the lack of a positive acknowledgment for the MN.

> ND Messages" as cited above. The signed RA would trigger a NetLMM

Right.  You probably mean the signed /RS/ would trigger the NETLMM
Update. ;-)

Thanks!

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 04 Jul 2006 10:11:22 +0200

Hi Julien,

I now understand that the protocol proposed in the draft will also
leverage a signed RS.  But this leaves us with issue #23 that you
mentioned in the tracker--- namely, that multiple on-link ARs (or MAGs)
would register the same MN simultaneously.

A related issue is that multiple MAGs would multicast NSs to the link in
case they hear an unauthenticated multicast ND message from the MN and
the MN is not yet registered.  You may want to add this to issue #23.

It seems that there is need for some sort of a coordination algorithm,
to be executed amongst neighboring MAGs, so that a single, well-defined
MAG can be selected to serve a particular MN.  This router is then the
only one responsible for registering all of the MN's IP addresses at the
LMA.

The question is how that algorithm may look like.  The NETLMM Protocol
draft does not yet describe one AFAIK, and neither does the AR-MN
Interface draft.  So here is a proposal:

- Take the algorithm which FastRA [1] uses for calculating the ranking
amongst routers, but use the first 64 bits of an SHA-1 hash on the MN's
public key as the "host token" [1] rather than the first 64 bits of an
SHA-1 hash on the source address of the ND message.

[1] draft-ietf-dna-protocol-01.txt

- Using the public key rather than the source address ensures that a
given MN will always be served by only a single MAG, even if the source
addresses in the ND messages vary.  (I was assuming that this is
desired.)  E.g., an NA may be sourced from a global IP address, while an
RS will always be sourced from the link-local address according to the
DNA protocol.  The standard FastRA algorithm always uses the MN's
link-local address in generating the host token.  Hence the host token
is always the same for a given MN.  But in our case, the source address
may vary, which is why the public key should be used instead.

- The "router (or MAG) token" [1] may be as defined in the FastRA
algorithm (i.e., the first 64 bits of an SHA-1 hash on the MAG's
link-local address), or it may be the first 64 bits of an SHA-1 hash on
the MAG's public key.  It doesn't really matter because router tokens
are always computed based on a router's link-local address--- namely,
the source address of an RA.

- Note that the MN's public key is carried in a CGA option attached to
the ND message even if the message cannot be authenticated due to an
incorrect nonce or an imprecise timestamp.

- If the ND message misses the CGA option, on-link MAGs won't be able to
determine which of them is responsible for the MN.  Then, if the ND
message has NOT the unspecified source address, the MAGs should use, as
a host token, the first 64 bits of an SHA-1 hash on the ND message's
source address to derive an ordering in which they solicit an
authenticated NA from the MN.  The ordering prevents a storm of NSs
without introducing desynchronization delays.

- If the ND message misses the CGA option and has an unspecified source
address, then the ND message will be a DAD NS.  In this case, MAGs can
use the NS's target address, rather than its source address, to compute
the host token.

- If a MN sends a data packet from a not-yet-registered source address,
the packet is authenticated, and the credentials used for authentication
are securely bound to the MN's SEND public key, then the MAG responsible
for the MN can be identified.  Otherwise, MAGs can again compute an
ordering--- with the host token equal to the data packet's source
address--- in which they solicit an authenticated NA from the MN.

What do you think?

- Christian

---

From: Julien Laganier <[email-masked]>
Date: Tue, 4 Jul 2006 15:36:59 +0200

Hi Christian,

Thanks for your comment. Cutting down (quite) a bit,

> [..]
>
> It seems that there is need for some sort of a coordination
> algorithm, to be executed amongst neighboring MAGs, so that a
> single, well-defined MAG can be selected to serve a particular MN. 
> This router is then the only one responsible for registering all of
> the MN's IP addresses at the LMA.

I agree that a coordination algorithm is required when multiple ARs 
are present on one link.

> The question is how that algorithm may look like.  The NETLMM
> Protocol draft does not yet describe one AFAIK, and neither does
> the AR-MN Interface draft.  So here is a proposal:

IMO such an algorithm is out-of-scope of the MN-AR interface because 
it has to do with inter-AR communications. I think it should be 
defined in the NetLMM protocol draft. More reasons for that below...

> - Take the algorithm which FastRA [1] uses for calculating the
> ranking amongst routers, but use the first 64 bits of an SHA-1 hash
> on the MN's public key as the "host token" [1] rather than the
> first 64 bits of an SHA-1 hash on the source address of the ND
> message.
>
> [...]

One difference I see between router coordination algorithm for FastRA 
and NetLMM is that FastRA needs an *ordered list* of routers, whereas 
NetLMM needs an *elected* router.

FastRA was designed to avoid risks of link flooding (caused by all 
routers replying at the same time) when routers don't wait for a 
random laps of time before replying. To do so, it orders the routers 
so that they will never reply at once.

This seems different from what NetLMM requires: a mean to elect a 
router that would server a particular MN.

IMHO we cannot use FastRA as a way to elect a router, constraints 
seems to different. For example, in the DNA case, if the router 
supposed to reply first to a specific MN begin to experience failure, 
the other routers would still reply to the MN, albeit later. Nothing 
would break. 

With NetLMM, if the AR which is supposed to register the MN begin to 
fail, and other routers do not register it because "they weren't 
first in the list" but still replies with RA, then the MN is not 
registered at all and doesn't know it.

So I think we need something more evolved than FastRA to handle 
multiple routers on same link. Perhaps VRRP would do the trick, or 
the NetLMM protocol might handle it.

Best,

--julien

On Tuesday 04 July 2006 10:11, Christian Vogt wrote:
> mentioned in the tracker--- namely, that multiple on-link ARs (or
> MAGs) would register the same MN simultaneously.
>
> A related issue is that multiple MAGs would multicast NSs to the
> link in case they hear an unauthenticated multicast ND message from
> the MN and the MN is not yet registered.  You may want to add this
> to issue #23.
>
> It seems that there is need for some sort of a coordination
> algorithm, to be executed amongst neighboring MAGs, so that a
> single, well-defined MAG can be selected to serve a particular MN. 
> This router is then the only one responsible for registering all of
> the MN's IP addresses at the LMA.
>
> The question is how that algorithm may look like.  The NETLMM
> Protocol draft does not yet describe one AFAIK, and neither does
> the AR-MN Interface draft.  So here is a proposal:
>
> - Take the algorithm which FastRA [1] uses for calculating the
> ranking amongst routers, but use the first 64 bits of an SHA-1 hash
> on the MN's public key as the "host token" [1] rather than the
> first 64 bits of an SHA-1 hash on the source address of the ND
> message.
>
> - Using the public key rather than the source address ensures that
> a given MN will always be served by only a single MAG, even if the
> source addresses in the ND messages vary.  (I was assuming that
> this is desired.)  E.g., an NA may be sourced from a global IP
> address, while an RS will always be sourced from the link-local
> address according to the DNA protocol.  The standard FastRA
> algorithm always uses the MN's link-local address in generating the
> host token.  Hence the host token is always the same for a given
> MN.  But in our case, the source address may vary, which is why the
> public key should be used instead.
>
> link-local address), or it may be the first 64 bits of an SHA-1
> hash on the MAG's public key.  It doesn't really matter because
> router tokens are always computed based on a router's link-local
> address--- namely, the source address of an RA.
>
> - Note that the MN's public key is carried in a CGA option attached
> to the ND message even if the message cannot be authenticated due
> to an incorrect nonce or an imprecise timestamp.
>
> - If the ND message misses the CGA option, on-link MAGs won't be
> able to determine which of them is responsible for the MN.  Then,
> if the ND message has NOT the unspecified source address, the MAGs
> should use, as a host token, the first 64 bits of an SHA-1 hash on
> the ND message's source address to derive an ordering in which they
> solicit an authenticated NA from the MN.  The ordering prevents a
> storm of NSs without introducing desynchronization delays.
>
> - If the ND message misses the CGA option and has an unspecified
> source address, then the ND message will be a DAD NS.  In this
> case, MAGs can use the NS's target address, rather than its source
> address, to compute the host token.
>
> - If a MN sends a data packet from a not-yet-registered source
> address, the packet is authenticated, and the credentials used for
> authentication are securely bound to the MN's SEND public key, then
> the MAG responsible for the MN can be identified.  Otherwise, MAGs
> can again compute an ordering--- with the host token equal to the
> data packet's source address--- in which they solicit an
> authenticated NA from the MN.
>
> What do you think?
>
> - Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 05 Jul 2006 12:14:16 +0200

Julien,

I think we can handle MAG failure.  Actually, I was having 3 goals in mind:

(1)  Inbound MAG should be same as outbound MAG
(2)  Low latency for MN registrations
(3)  Coordination of MAGs independent of LMA
(4)  Handle MAG failures

Looking into each more closely...

(1)  The outbound MAG is the MAG chosen by the MN as its default router.
 This is likely to be the MAG responding first to the MN's RS, i.e., the
highest-ranking MAG wrt. the FastRA algorithm.  The inbound MAG is the
one that establishes the tunnel with the LMA.

To ensure that inbound MAG == outbound MAG (which is not strictly
required, but I guess would be desirable), it is sufficient to have the
highest-ranking MAG initiate the NETLMM registration, including tunnel
establishment, with the LMA.

(2)  If we use a FastRA-like algorithm for both router discovery and
NETLMM registration, we eliminate desynchronization delays.  A
FastRA-like algorithm may also be used to determine the MAG reacting to
a DAD NS, as I suggested in my previous email.

(3)  It would be nice if the LMA need not know which MAGs are present on
a particular link.  MAGs can then be added to or removed from a
particular link without updating the LMA.  Using a FastRA-like algorithm
to coordinate the MAGs wrt. to NETLMM registrations, rather than
coordinating them through the NETLMM protocol, is one step into reaching
that goal.

(4)  Assume that MAGs use a FastRA-like algorithm to determine which MAG
does the NETLMM registration for a particular MN.  That router would
send an RA in response to the MN's RS.  This fails if the RS is lost or
if the responsible MAG is failing.  In the first case, the MN will
retransmit the RS.  In the second case, other on-link MAGs should snoop
on the link whether the highest-ranking MAG sends an RA.  If it doesn't,
the second-to-highest-ranking MAG will send one.  If the
second-to-highest-ranking MAG also fails, the third MAG in the ranking
will stand in.  So I think MAG failures can be handled quite elegantly.

Using the DAD NS to initiate MAG registration is less reliable, because
there is no positive acknowledgment for the MN.  So neither can loss of
a DAD NS be detected, nor can on-link routers determine if a MAG ranking
highest according to some FastRA-like algorithm is working or not.  So I
argue that you can use the DAD approach to add new IP addresses to a
MN's binding, but you should limit NETLMM registration to the RS/RA
exchanges.

So the idea was to adopt the FastRA for...

- router discovery, to determine which MAG should react to the RS and
register the MN's point of attachment with the LMA;

- DAD, to determine which MAG should react to the DAD NS and add the
MN's new IP address to the binding at the LMA.

The FastRA algorithm should be modified in 2 ways:

- MAGs use the MN's public keys rather than an ND message's source
addresses to compute the host token.  This ensures that the algorithm is
also applicable to DAD, where the NS has an unspecified source address.
 It also ensures that a given MN is (usually) served by only a single
MAG, be it for router discovery or for DAD.

- Only the highest-ranking router responds to an RS or DAD NS.  In case
of router discovery, other MAGs snoop for the responding RA and, if it
does not appear, stand in in the order given by the ranking.

Regards,
- Christian

Julien Laganier wrote:
>  and NetLMM is that FastRA needs an *ordered list* of routers, 
> whereas NetLMM needs an *elected* router.
> 
>>  the ND message's source address to derive an ordering in which
>> they solicit an authenticated NA from the MN.  The ordering
>> prevents a storm of NSs without introducing desynchronization
>> delays.
>> 
>>  authentication are securely bound to the MN's SEND public key,
>> then the MAG responsible for the MN can be identified.  Otherwise,
>> MAGs can again compute an ordering--- with the host token equal to
>> the data packet's source address--- in which they solicit an

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Jul 2006 13:15:40 +0200

Thanks Christian,

The scheme you are proposing seems to work.

There is however one problem which can happen: To be able to use 
FastRA, on-link routers have to multicast RAs so that each of the 
other routers can include it in its DNARouterList, along with its 
source address and token.

Issue is that it is foreseen that in some NetLMM deployments it might 
not be possible to send multicast RAs (see [1] below.)

Perhaps this issue can be circumvented by having routers send 
multicast RA anyway (to discover other routers and tokens), but 
without prefix information.

I'd like to hear what folks think.

Best,

--julien

[1] draft-ietf-netlmm-mn-ar-if-01 says "The use of multicast RAs may 
however not be acceptable in all NetLMM domains, e.g., when multiple 
MAPs and/or prefixes are used." The reason can be found by looking at 
this scenario:

The domain has more than one MAP (say two MAP_A and MAP_B) each one 
handling traffic sent to one prefix (PF_A and PF_B.)

When a MN enters the domain, it is assigned a MAP by a mechanism out 
of scope of this I-D (e.g. using AAA at network access 
authentication.) Then when it sends a RS, the router has to announce 
it the prefix handled by its assigned MAP.

Let's say that two MN (MN_A and MN_B) are attached to same link and 
same AR, but are bound to different MAPs (MAP_A and MAP_B.) MN_A has 
to be advertised PF_A while MN_B has to be advertised PF_B. If the AR 
sends multicast RA, both will receive the prefix information so it 
doesn't work. Only solution is that AR sends unicast RA with PF_A to 
MN_A, and unicast RA with PF_B to MN_B.

On Wednesday 05 July 2006 12:14, Christian Vogt wrote:
> (1)  The outbound MAG is the MAG chosen by the MN as its default
> router. This is likely to be the MAG responding first to the MN's
> RS, i.e., the highest-ranking MAG wrt. the FastRA algorithm.  The
> inbound MAG is the one that establishes the tunnel with the LMA.
>
> required, but I guess would be desirable), it is sufficient to have
> the highest-ranking MAG initiate the NETLMM registration, including
> tunnel establishment, with the LMA.
>
> (2)  If we use a FastRA-like algorithm for both router discovery
> and NETLMM registration, we eliminate desynchronization delays.  A
> FastRA-like algorithm may also be used to determine the MAG
> reacting to a DAD NS, as I suggested in my previous email.
>
> (3)  It would be nice if the LMA need not know which MAGs are
> present on a particular link.  MAGs can then be added to or removed
> from a particular link without updating the LMA.  Using a
> FastRA-like algorithm to coordinate the MAGs wrt. to NETLMM
> registrations, rather than coordinating them through the NETLMM
> protocol, is one step into reaching that goal.
>
> (4)  Assume that MAGs use a FastRA-like algorithm to determine
> which MAG does the NETLMM registration for a particular MN.  That
> router would send an RA in response to the MN's RS.  This fails if
> the RS is lost or if the responsible MAG is failing.  In the first
> case, the MN will retransmit the RS.  In the second case, other
> on-link MAGs should snoop on the link whether the highest-ranking
> MAG sends an RA.  If it doesn't, the second-to-highest-ranking MAG
> will send one.  If the
> second-to-highest-ranking MAG also fails, the third MAG in the
> ranking will stand in.  So I think MAG failures can be handled
> quite elegantly.
>
> Using the DAD NS to initiate MAG registration is less reliable,
> because there is no positive acknowledgment for the MN.  So neither
> can loss of a DAD NS be detected, nor can on-link routers determine
> if a MAG ranking highest according to some FastRA-like algorithm is
> working or not.  So I argue that you can use the DAD approach to
> add new IP addresses to a MN's binding, but you should limit NETLMM
> registration to the RS/RA exchanges.
>
> - router discovery, to determine which MAG should react to the RS
> and register the MN's point of attachment with the LMA;
>
> - DAD, to determine which MAG should react to the DAD NS and add
> the MN's new IP address to the binding at the LMA.
>
> addresses to compute the host token.  This ensures that the
> algorithm is also applicable to DAD, where the NS has an
> unspecified source address. It also ensures that a given MN is
> (usually) served by only a single MAG, be it for router discovery
> or for DAD.
>
> - Only the highest-ranking router responds to an RS or DAD NS.  In
> case of router discovery, other MAGs snoop for the responding RA
> and, if it does not appear, stand in in the order given by the
> ranking.
>
> Regards,
> - Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 05 Jul 2006 14:10:03 +0200

Yes, I had also been thinking about this.  In particular, since 3GPP
want to assign tailored prefixes to individual mobile nodes.  Multicast
RAs, hence the FastRA algorithm, are incompatible that approach.

And there are folks in NETLMM that might be concerned about this. :-)

But we have 3 possible solutions:

(i)  As you describe:  Use multicast RAs without Prefix Information options.

(ii)  Send RAs to the all-routers multicast address rather than to the
all-nodes multicast address.

(iii)  Combine (i) and (ii).

Option (i) reduces the size of the RAs, while option (ii) reduces the
overhead of multicasting.  So, I think, option (iii) is actually most
suitable.

Yes, option 2 changes the router behavior a bit compared to the
standard RFC 2461[bis] and DNA protocols.  But it does not break the
MN-MAG interaction for RFC-2461- and DNA-compliant MNs.

Ciao,
- Christian

---

From: Sathya Narayanan <[email-masked]>
Date: Wed, 05 Jul 2006 08:07:27 -0400

Julien -

I may not be upto speed on the context here, but ...

>without prefix information.
DNA also requires that the routers learn about all the prefixes
advertised on the link so that they can send completeRA and be able to
respond to landmark questions. Without the prefix information included
in the multicast RA that will not happen.

>it the prefix handled by its assigned MAP.
The problem in this scenario seems to be because of the MAP assignment
happening before the prefix assignment, right? My understanding has been
that the MN will pick a prefix (as any normal MN will do) and then a MAP
gets assigned to the MN based on the prefix it picked. Do you have a
good reason why you are changing that order? If we keep the original
order, which IMHO makes more intuitive sense, then we will not need to
change the behaviors of DNA routers/hosts. Does that make sense?

- Sathya

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Jul 2006 15:58:52 +0200

Hi Sathya,

On Wednesday 05 July 2006 14:07, Sathya Narayanan wrote:
> advertised on the link so that they can send completeRA and be able
> to respond to landmark questions. Without the prefix information
> included in the multicast RA that will not happen.

You are right, I overlooked that.

> >[1] draft-ietf-netlmm-mn-ar-if-01 says "The use of multicast RAs
> > may however not be acceptable in all NetLMM domains, e.g., when
> > multiple MAPs and/or prefixes are used." The reason can be found
> > by looking at this scenario:
> >
> >The domain has more than one MAP (say two MAP_A and MAP_B) each
> > one handling traffic sent to one prefix (PF_A and PF_B.)
> >
> >When a MN enters the domain, it is assigned a MAP by a mechanism
> > out of scope of this I-D (e.g. using AAA at network access
> >authentication.) Then when it sends a RS, the router has to
> > announce it the prefix handled by its assigned MAP.
>
> The problem in this scenario seems to be because of the MAP
> assignment happening before the prefix assignment, right? My
> understanding has been that the MN will pick a prefix (as any
> normal MN will do) and then a MAP gets assigned to the MN based on
> the prefix it picked. Do you have a good reason why you are 
> changing that order? If we keep the original order, which IMHO
> makes more intuitive sense, then we will not need to change the
> behaviors of DNA routers/hosts. Does that make sense?

I am not sure I understand how "the MN will pick a prefix (as any
normal MN will do)." My understanding is that the MN will configure 
one global unicast per prefix announced, and not pick one. If I 
follow that, according to what you wrote above the MN would be 
assigned with all MAPs.

Because AFAICT the motivation for having multiple MAPs is to do load 
splitting, it seems to me that one MN shall have only one MAP. 
Corollary is that the MAP assignment has to be done prior to prefix 
advertisement.

But perhaps I am confused.

Best,

--julien

---

From: Christian Vogt <[email-masked]>
Date: Wed, 05 Jul 2006 16:16:05 +0200

Note that the issue you are discussing right now is separate from the
algorithm for coordinating multiple on-link MAGs.

- If you need tailored per-MN RAs, then let MAGs send unsolicited RAs
w/o Prefix Information options to the all-routers multicast address.

- If you can do w/o tailored RAs, let MAGs send unsolicited multicast
RAs in the standard manner.

- Christian

---

From: Julien Laganier <[email-masked]>
Date: Wed, 5 Jul 2006 16:23:04 +0200

On Wednesday 05 July 2006 14:10, Christian Vogt wrote:
> Yes, I had also been thinking about this.  In particular, since
> 3GPP want to assign tailored prefixes to individual mobile nodes. 
> Multicast RAs, hence the FastRA algorithm, are incompatible that
> approach.

I don't think the FastRA/multiple router is relevant to to 3GPP 
because 3GPP nodes typically have a point-to-point link to their 
default router, so there can't be multiple of them and FastRA is 
useless; draft-ietf-dna-network-00 acknowledge that:

   Routers on point-to-point links MAY avoid delay by not waiting for
   the prescribed random time before responding for the Router
   Solicitation message [7] [9].

> (i)  As you describe:  Use multicast RAs without Prefix Information

As Sathya mentioned this doesn't work.

> (ii)  Send RAs to the all-routers multicast address rather than to
> the all-nodes multicast address.

Looks like it would work. 

> (iii)  Combine (i) and (ii).

Not applicable because (i) doesn't work.

> Option (i) reduces the size of the RAs, while option (ii) reduces
> the overhead of multicasting.  So, I think, option (iii) is
> actually most suitable.

In fact we just have option (ii) above, and still:

(iv) have a specific inter-AR protocol taking care of the multiple 
on-link AR coordination.

> standard RFC 2461[bis] and DNA protocols.  But it does not break
> the MN-MAG interaction for RFC-2461- and DNA-compliant MNs.

As you say, option (ii) is changing ND/DNA behavior, so somehow it's 
no longer ND/DNA but rather also belongs to category (iv) above.

It seems that the real question might be whether inter on-link ARs 
coordination is achieved:

(a) independently of the MN/AR interface and NetLMM protocol (e.g. 
VRRP)

(b) via integration to the MN/AR interface, requiring modification to 
DNA and ND on the router side.

(c) via integration to the NetLMM protocol.

--julien

---

From: Sathya Narayanan <[email-masked]>
Date: Wed, 05 Jul 2006 15:30:26 -0400

Hi Julien -

> <snip>
>one global unicast per prefix announced, and not pick one. 
>
My mistake - bad choice of words, I guess. I was thinking about the
particular prefix using which the MN will try to communicate, i.e. the
one (or more) address based on a particular prefix which the MN will use
as its source address.

>If I 
I don't really see this - I think it makes sense to wait for a MN to use
a particular prefix in its packets and then assign a MAP to it, rather
than fixing the MAP for given MN before the prefix is selected for
communication. I am not sure how load splitting can be achieved
consistently, may be by ensuring that different prefixes are announced
first to different MNs when they arrive at the NETLMM domain.

Your suggestion to get rid of multicast RA will also work (only
multicast to all-routers multicast address as Christian suggested), I
guess. But that seems too drastic a change to me. For example, what will
happen if a RS arrives when the token bucket is empty at the router -
right now a multicast RA will be sent in response which could
potentially help a group of MNs. But, if you remove multicasting of RA
entirely, that is not possible.

rgds,
Sathya

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Jul 2006 14:51:02 -0700 (PDT)

http://personal.ie.cuhk.edu.hk/~lampk3/Publications/cuip_MSWiM05.pdf

The above link describes a protocol for global mobility called CUIP. I think that it might be of interest to netlmm community.

Take a look and enjoy.

--behcet

---

From: Andy Huang <[email-masked]>
Date: Fri, 07 Jul 2006 16:24:13 +0800

Hi all

>>Corollary is that the MAP assignment has to be done prior to prefix

=> I agree. IMHO, MAGs can pick one LMA to serve the MN according to load 
balancing. Tthen it send the unicast RA with LMA's prefix to MN.

> entirely, that is not possible.

=> I agree with Sathya on this point. It changes a lot from RFC2461.
And I think it's unnecessary to send RA with all prefixes in PIO. Because 
generally MAGs(ARs) just get all the LMMD prefixes from LMAs in the LMMD. In 
this way, MAGs can know the all the LMMD prefixes, that is complete prefixes 
on link defined in DNA protocol. Of course, it need a mechanism to make MAGs 
ensure that thess LMMD prefixes from LMAs are same as those prefixes from 
Complete RA.

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 9 Jul 2006 16:06:07 -0700

Christian,

> Right.  You probably mean the signed /RS/ would trigger the NETLMM

I was confused by this at first, too, but I think Julian actually mean
signed *NA*, because he was talking about the case of the AR (MAG)
sending an NS to the MN upon receipt of a packet with an unregistered
IP address (which would cause the MN to respond with a signed NA).

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 9 Jul 2006 16:20:24 -0700

Folks,

I'm coming to this discussion late and have not read all the details,
but I have a general concern for going too far down the path of having
excessive signaling between multiple ARs (MAGs) on the link. If there
is a lot of messaging going on there, it might be better to just
co-locate the LMA function on the AR (MAG) to reduce the messaging that
needs to occur on the backhaul network. I am also concerned for links
on which the transitive property for neighbors does not hold, i.e., if
A is a neighbor of B and B is a neighbor of C, it is not necessarily
true that A is a neighbor of C. So consider the possibility of links
for which a MN could be a neighbor of AR1 and AR2, but AR1 and AR2 are
not neighbors of each other. (This might also be a concern for the DNA
fast RA stuff.)

Fred

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]] 
Sent: Tuesday, July 04, 2006 1:11 AM
To: Julien Laganier
Cc: Mark Doll; [email-masked]
Subject: Coordinating Multiple On-Link MAGs (was Re: [netlmm] On the Use
ofDAD NS to Trigger MAP Registration)

Hi Julien,

What do you think?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 10 Jul 2006 08:37:08 +0200

Fred,

section 4.2 covers the router operation when receiving NDP messages.  It
differentiates between DAD NS (section 4.2.1) and other NDP messages
(section 4.2.2).

As far as I understand, in this specific case, Julien meant to say that
the RS-RA exchange, which I was referring to, is covered by the latter
section.  I.e., a MAG would already register a MN upon receiving a
signed RS.

- Christian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 10 Jul 2006 04:39:44 -0700

OK, maybe I've gotten out-of-context; I thought we were talking
about the case of receiving all other packets before ND or DHCP
(i.e., Sections 4.3.1 and 4.4).

Fred

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]] 
Sent: Sunday, July 09, 2006 11:37 PM
To: Templin, Fred L
Cc: Julien Laganier; [email-masked]
Subject: Re: [netlmm] On the Use of DAD NS to Trigger MAP Registration

Fred,

- Christian