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

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 14 Mar 2003 12:41:53 -0800 (PST)

> >>>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."
> > 
> > 
> > Is that right?  It doesn't respond to its own address?  Is this
> > proposed for 11.5.4?
> 
> Samita didn't say why this rule would be needed. But my
> assumption was: the answer would go to the home agent
> itself and not to the sender of the NS.
> 
> OTOH, the home agent would drop the NA since it didn't send
> any NS, and the end result would be the same. Hmm.... maybe
> its better if Samita or someone else from the Connecthathon
> would say more about this item and why its needed.
>

Vijay already explained this very nicely on my behalf.

--------------------------------------------------------
>    When sending this Binding Update to its home agent, the mobile node
>    must be careful in how it uses Neighbor Solicitation [12] (if needed)
>    to learn the home agent's link-layer address, since the home agent
>    will be currently configured to intercept packets to the mobile
>    node's home address using Duplicate Address Detection (DAD).  In
>    particular, the mobile node is unable to use its home address as the
>    Source Address in the Neighbor Solicitation until the home agent
>    stops defending the home address.

going by this paragraph, the MN shouldnt be sending the NS 
(src=MN_HoA, dst=HA, target=HA).

------------------------------------------
The draft is very clear what MN should do in case it needs to do the
NS for HA's link-layer address before sending de-registration request.

But the question is :
   Should the draft specify HA behavior if in case it receives a NS from
   a src=MN's HOA for which it's defending. Currently draft does not specify
   that and perhaps that's why some implementations did not have a check
   for BCE entry when it receives a NS (src=MN_HoA, dst=HA, target=HA).

   Naturally, if the
  HA is defending MN's homeaddress it should not be able to NA to the same
  homeaddress. I guess it is  safe to clarify the HA behavior in this case.
  
  Thanks,
  -Samita

> >>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?
> > 
> > 
> > I'll try and clarify.  What does the receiver do if they have a
> > binding, and get a BU to update that binding with a different value
> > in the H-bit field than the current binding?  The MN shouldn't have
> > sent it since it should know from its binding list what "state" your
> > binding has, but it did.
> 
> Ok. That sounds good. So we would add a rule that a BU should not
> change the H-bit value in a binding? And if you break the rule,
> its a silent discard?
> 
> Jari
>

---

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

> 
> > there is more. section 11.5.4
> > 
> > 
> > maybe nothing needs to be changed in the spec. (?)
> 
> So, what we are seeing is an illegal situation, and different
> home agents respond in different ways. As far as I can see, the NAs
> from some of the home agents -- even if a bit suspicious -- do not
> really cause damage. So, perhaps we should not change anything...
> 

I don't have a strong opinion on this. I am OK either way. 

-Samita

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Mar 2003 19:37:33 +0100 (CET)

> In the scenario described above of overlapping RF coverage areas, one of the
> routers that the mobile node is hearing may not be bi-directionally
> reachable, while the other router is. In that case, the mobile node should
> be using the 2nd router (which is bi-directionally reachable) as its current
> default router. Per issue #170, it must only use a primary CoA which is
> covered by the prefix information advertised by that router. This guarantees
> that when it sends packets using that primary CoA as the source address, its
> current default router will recognize the source address of the packet as
> being on-link and not discard it due to ingress filtering. Also, it
> guarantees that packets sent to it at the primary CoA will be sent through
> the router which the mobile node has confirmed to be bi-directionally
> reachable.

The case of overlapping RF coverage makes me want to ask a rather basic 
question: what delineates the boundary between one link and another?
Shouldn't there be something (other than the extent of coverage)
that delineates this boundary at L2? (some L2 implicit or explicit
notion of a link such as different channels or something)

If you don't have that then how do you know whether the routers can
advertise the same prefix or different prefixes?
If it's raining maybe they shouldn't because of poorer coverage? :-)

So I think what is being discussed is a case of partially overlapping *links*
due to RF coverage issues. True that to the Mobile IP software this
might not look much different (since it might not be aware of the L2 handover)
but conceptually this feels different.

  Erik