Subject: Re: [mobile-ip] Connectathon 2003 issues for MIPv6 draft-20

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 14 Mar 2003 11:47:42 -0800 (PST)

[Catching up with the emails on this thread, sorry for the delay in response]

> 
> Registered as issue #273, plus point 3 went to #269.
> More inline:
> 
> > 1. HA De-registration
> > 
> >    During de-registration process, MN sends BU with lifetime=0
> >    to HA. After successful processing HA wants to send BA
> >    back to MN, HA does Neighbor Soliciation to MN to update
> >    its neighbor cache entry. 
> >   
> >    Problem : section 11.5.4 states:
> >    " After the Mobile Node sends the Binding Update, it MUST be prepared
> >    to reply to Neighbor Solicitations from its home agent." 
> > 
> >    Some MN implementations don't respond if the source address of
> >    the NS is link-local; it only replies when source address of NS 
> >    from HA is global. 
> > 
> >    Proposal : Should the draft clarify that MN should respond to
> >               all scopes of NS source address ?
> 
> Interesting. Yes, I suppose this is necessary. I looked at
> RFC 2461 but it gives some freedom for choosing the source
> address, so we can't stick to one. Suggested text: "... from
> either the link-local address of the home agent or from any
> of its global addresses."
> 

Ok.  But does the MN know about HA's link-local address ?

> Question: do we need to clarify where these addresses come
> from? I suppose the link-local address comes from the RA,
> and the global addresses come from the PI options?
> 

Vijay explained:

the spec currently says MN should respond to NS from the HA. but
if the HA uses link local address as the source address of the NS,
the MN cant figure out if it is the HA sending the NS or it is
some other node on the home link sending the NS. if the HA uses
its global address as the source address for the NS, the MN can
immediately recognize that it is the HA sending the NS.

IMO, there is no harm in the MN replying to any NS in this tiny
window. it is possible that some node on the home link might get
two Neighbor Advertisments for the MN's home address in this
window. but this is such a rare case, we shouldnt worry about it
at all. we dont have to change any spec if we follow this.

--------------------------------------------------------------------
For clarity, I'd think, HA should include PI with NS if it uses
link-local address as its source address (since RFC2461 is liberal
about scope of source address of NS), so MN can verify that it's indeed
coming from the HA.

On the other hand if we say that NA from MN's hoa always over-rides
the proxy NA from HA, I am afraid, that might create some security
hole. What if a malicous node starts sending NA by using a MN's home
address while the HA is defending the actual MN's address. Is it a 
valid concern ?

> > Proposal(s):
> > 
> >    * Draft should clarify that a router that  provides service to
> >      the mobile nodes, MUST be configured with unique link-local
> >      addresses on its each link.
> 
> Sounds pretty tough for *all* IPv6 routers.

Most of the IPv6 routers should have a way to do this, it may be
a matter of configuration. But I agree, it might be tough to impose
universally.

> 
> >    * Having some unique id to distinguish different ESD part of
> >      the link-local addresses of each interface of the router.
> 
> But we don't have any, do we?

No. 

> 
> >    * The mobile node SHOULD compare both link-local
> >      address of the default router(its reachability) and the prefix
> >      in the prefix option of router advertisement (with the prefix
> >      of the mobile's interface) to determine movement at the L3 level.
> 
> This seems like the only possibility, unless someone invents
> something new. I'm willing to go for this, though it means that
> when a router has the same link-local address, movement detection
> is delayed until you see also an advertisement. Maybe its the
> best we can do?
> 

I think, the movement detection only at the L3 level is a hard problem
to solve. But Mobile IPv6 main spec does not need to address that fully;
many believe another draft would be appropriate for this.
IMHO, the above solution is the best we could do here. The Mobile IPv6
draft already indicates that movement detection can be initially handled
at the L2 level.

> >  3. Simultaneous movement of two MNs while performing RO with each-other      
> > 
> >     Issue  #269.
> > 
> >     Problem : MN/CN implementations were using the correponding MN's
> >               COA as dst of HOTI message while both MNs moved at the
> >               sametime, resulting into loss of HOTI messages
> >               The implementatios were using RH type2 containing 
> >               destination MN's home address.
> > 
> >     Solution : 1. Never send RH with HOTI messages. 
> >                   Use home-address of the corresponding MN
> >                   as the dst field of the HOTI message when
> >                   a mobile node uses RO with another mobile node
> >   
> > 
> >                 2. Use home-address of the Mobile node in the
> >                 destination field of the COTI message when 
> >                 a mobile node corresponds with another mobile
> >                 node using RO
> >           
> >          
> >                 3. When using RO, a BU to a CN (which happens to be
> >                    MN) should be sent to the home address of that
> >                    mobile node.
> 
> I think we picked solution #1 in issue 269. Is this good enough
> or should we discuss the other alternatives?

All three of them are necessary to specify to avoid confusion.

> 
> > 5. Section 9.5.1
> > 
> >    For example, if the last
> >       received sequence number was 15, then messages with sequence
> >       numbers 0 through 15, as well as 32784 through 65535, would be
> >       considered less than or equal.    ^^^^^
> > 
> >       There is a typo--s/32784/32783
> 
> Wait.. something doesn't add up. The text says "last value and
> preceding 32767 values". That makes a total of 32768 values.
> Now 0...15 = 16 values and 32784...65535 is 32752. This is
> 32768 values in all. Am I missing something?
>

My math is failing here :-) We thought, for seq# 0-15, values
32767+16 = 32783...65535 should be considered less than/equal to
the current seq number. But I don't care much which value it should
be as long as we stick to one. BTW, what is the rational behind choosing
the windowsize half of 65K--just curious (perhaps I should look through
the issue index).
 
> > 6. The spec does not say that HA MUST not respond to NS when src=HOA
> >    before MN deregisters.
> > 
> >    Spec states a few steps regarding what HA should do during 
> >    deregistration, however the above not clear. Thus some HA
> >    make the mistakes easily.
> 
> Agree. Suggested text: "The home agent MUST NOT respond to
> Neighbor Solicitations sent to its own address when the Source
> Address of the solicitation is a home address of a mobile node
> for which the home agent has a Binding Cache entry."
> 

Looks fine to me.

> > 8. Can a HA be a CN to the same mobile node ?
> > 
> >  
> >    Problem scenario:
> > 
> >    1. A node acts as both HA and CN
> >    2. A MN sends RR messages and does BU with H=0 to this node.
> >        (pressumably it had been using a different HA)
> >    3. The same MN sends BU H=1 to the same HA/CN node
> > 
> >    Should this HA/CN node accept or ignore the second BU ?
> >    Or
> >    Should this HA/CN delete the old BCE and create a new BCE
> >    and also starts acting as HA.
> > 
> >   Proposal : For simplicity, it's better for HA to ignore the
> >              second BU.
> > 
> >            [ Otherwise, the combination of HA/CN and order of 
> >              H bit (0/1) in successive BUs make implementation
> >              unnecessary complex ] 
> 
> I agree. Add text to 9.5.1 where we talk about the conditions
> for BUs that use RR as the authz mechanism: "If receiving node
> is also acting as a home agent, it does not have a home registration
> Binding Cache entry for the given home address." This will lead
> to silent discard. Hmm... but wait. This isn't quite sufficient.
> It wouldn't work in the order of your example above. Also, following
> your order, how does the receiver know in Step 2 that it will act as
> a home agent in Step 3? Perhaps it is pre-configured with the home
> addresses... but even so, what if there are multiple redundant
> home agents? If I register with one of the for H=1, does it imply
> that I can do RR with the others, in case they also host a web
> server or something?

We have discussed the situations at the Connectathon and it could be
quite complex with the order of H bits ( 0, 1 or 1, 0 ) and then
whether its HA and CN at that point for the MN. Also you brought up
interesting question about multiple HAs while one being HA for MN1, the
other non-active HA is acting as CN for the same MN1.

Would it make sense then to impose a rule like the following ?

* If the node is acting as HA for a particular mobile node and 
   it receives a BU with H=0 for the same mobile node, the second
   BU is silently discarded. This would imply that a node cannot 
   act as both HA and CN for the same mobile node home-address.
   
   Also, I need to check if the draft has any wording about handling
   HOTI messages from the same home-address it's serving as HA.
   To me it does not make sense for HA to act as CN for the same MN.
   
* Similarly, it is just simple to say that a node serving as CN for a
  MN (with route optimization and thus having a corresponding BCE with
  H flag =0) should ignore a subsequent BU with H flag=1.
  
  Thus if a MN decides to make the current serving CN as its HA, it must
  de-register first from the CN and start with a new HA registration.
  
  Generally  CN/MN nodes or CN only node always rejects BU with H =1, so
  it's not an issue with them.  

   Question remains should (do) we allow a node to configure to do HA and CN
   operations at the same time (even if we apply the first bullet rule above) ?
   
   I suppose the spec may not want to disallow this feature provided the
   first rule is applied.
   
   -Samita

---

From: MOMOSE Tsuyoshi <[email-masked]>
Date: Mon, 17 Mar 2003 18:47:29 +0900

I'm implementing Mobile IPv6 code at kame project.

KAME mip6 mobile node has this problem.

> draft already indicates that movement detection can be initially 

I agree to Samita.

The mechanism of kame Mobile IPv6 implementation depends
on NUD default router. And this cause failure of movement
detection as told here.
But I think it is the best way for kame mipv6 at this time.
Most of Kame mobile ipv6 code is implemented in kernel part,
and kame aims generic ipv6 (also including mipv6) protocol stack.
So, it is required using the most generic way to detect it's
movement.
There may be a lot of network configurations such as 1 router
with sending several RAs separately, multiple nodes which
sends same prefix RA, multiple routers with multiple prefix
RAs, etc. Using NUD of default router is the best way to
be able to move such various type networks.

I believe it isn't necessary to describe more complex
movement mechanism in the MIPv6 spec.

---
MOMOSE Tsuyoshi
NEC Networks
KAME Project