Subject: Re: [MEXT] [mext] #11: De-registration when returning home[VijayDevarapalli <[email-masked]>]

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 9 Jul 2008 17:50:37 -0400

My point is that there are two different things here: 1) HA to stop
proxying, 2) HA to stop forwarding packets to CoA. Going with the
current semantics, both are tied together, which is perhaps unnecessary.

(something to note: ND does not have a way to request proxying, MIP BU
does. But, ND does have a way to unproxy (NA, 'O'=1), and we should let
the MN do this)

We could have the Unsolicited NA sent just to stop the proxying first
and let every node know that the actual owner of the address is on-link.
I do realize that the on-link nodes still resolve the address (even
after processing the UNA), but without it, they will be sending packets
to the HA. 

The following BU can delete the BCE.

-Rajeev

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2008 12:06 PM
> To: Koodli, Rajeev; Sri Gundavelli; Giaretta, Gerardo
> Cc: [email-masked]; [email-masked]
> Subject: RE: [MEXT] [mext] #11: De-registration when returning
> home[VijayDevarapalli <[email-masked]>]
> 
> Rajeev,
> 
> > 1. HA to stop proxying. Of course the Dereg-BU is supposed to do
this.
> > However, other nodes on the link will still have their NCE pointing
to
> > the HA. This leads me to suggest that the MN MUST send an NA (with
> > 'O'=1) on the _home link only_ to stop the HA from proxying.
> > ND has link
> > scope only and does not affect other links with which the MN may be
> > connected to different visited networks (at the same time that it is
> > connected to the home link using a different interface).
> 
> RFC 3775 already says that the mobile node should sent a Neighbor
> Advertisement with the 'O' flag set after it receives the binding ack
> from the home agent.
> 
>    After receiving the Binding Acknowledgement for its Binding Update
to
>    its home agent, the mobile node MUST multicast onto the home link
(to
>    the all-nodes multicast address) a Neighbor Advertisement [12], to
>    advertise the mobile node's own link-layer address for its own home
>    address.  The Target Address in this Neighbor Advertisement MUST be
>    set to the mobile node's home address, and the Advertisement MUST
>    include a Target Link-layer Address option specifying the mobile
>    node's link-layer address.  The mobile node MUST multicast such a
>    Neighbor Advertisement for each of its home addresses, as defined
by
>    the current on-link prefixes, including its link-local address and
>    site-local address.  The Solicited Flag (S) in these Advertisements
>    MUST NOT be set, since they were not solicited by any Neighbor
>    Solicitation.  The Override Flag (O) in these Advertisements MUST
be
>    set, indicating that the Advertisements SHOULD override any
existing
>    Neighbor Cache entries at any node receiving them.
> 
> > 3. When the MN returns home, we should have a consistent
> > semantics about
> > de-registration regardless of other networks the MN may be
> > connected to.
> > Limiting the actions to a) NA ('O'=1), followed by, b) Dereg-BU on
the
> > particular home link, I believe we can achieve that.
> 
> Currently, RFC 3775 specifies b) followed by a). For changing the
order,
> we might need a separate discussion. Not on this thread.
> 
> Vijay
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 9 Jul 2008 17:52:42 -0400

Hi Suresh,

I understand the nodes still probe after processing NA ('O'=1), because
bidirectional reachability is not confirmed. However, if you don't send
the NA('O'=1), they will continue to send packets to the HA, which you
can avoid.

-Rajeev

> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2008 12:30 PM
> To: Koodli, Rajeev
> Cc: Vijay Devarapalli; Sri Gundavelli; Giaretta, Gerardo;
> [email-masked]; [email-masked]
> Subject: Re: [MEXT] [mext] #11: De-registration when returning
> Hi Rajeev,
>    Agree with you in principle with the steps, but I don't think we
> should mandate (MUST) the use of O(verride)=1 since it makes no
> difference at all to the receiving node.
> 
> case a) S(olicited)=0 and O(verride)=0 in the NA
> Node sets the NCE to STALE but does not update the LL address. When it
> needs to send packets it starts to perform NUD and detects the MN
coming
> back.
> 
> case b) S(olicited)=0 and O(verride)=1 in the NA
> Node sets the NCE to STALE but and updates the LL address. When it
needs
> to send packets it still performs NUD and detects the MN coming back.
> 
> Hence setting the O bit does not make a difference.
> 
> Cheers
> Suresh
> 
> Koodli, Rajeev wrote:
> > I see more than one issue here :)
> >
this.
to
> > 'O'=1) on the _home link only_ to stop the HA from proxying. ND has
link
> > 2. The MN SHOULD send a Dereg-BU, again on that home link where it
does
> > not wish to have the HA forward packets to the CoA anymore. This
should
> > allow it to maintain CoA bindings on other links.
> >
> > 3. When the MN returns home, we should have a consistent semantics
about
> > de-registration regardless of other networks the MN may be connected
to.
the
> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >> Vijay Devarapalli
> >> Sent: Wednesday, July 09, 2008 11:32 AM
> >> To: Sri Gundavelli; Giaretta, Gerardo
> >> Subject: Re: [MEXT] [mext] #11: De-registration when returning
> >> Hi Sri,
> >> We need to have a discussion on whether a neighbor advertisement
with
> >> the override flag set can convince the home agent to remove the
proxy
> >> neighbor cache entry for the home address. The proxy neighbor cache
> >> entry was created as a result for processing a binding update. I
think
> >> only another binding update should remove it. But that is a
separate
> >> discussion.
> >>
> >> Perhaps, a minor fix will satisfy you. How about the following?
> >>
> >>    A mobile node detects that it has returned to its home link
through
> >>    the movement detection algorithm in use (Section 11.5.1), when
the
> >>    mobile node detects that its home subnet prefix is again
on-link.
> >>    In case the mobile node has only one interface active at any
time,
> >>    it MUST send a Binding Update to its home agent, to instruct its
> > home
> >>    agent to no longer intercept or tunnel packets for it.  In case
the
> >>    mobile node has more than one interface active at a time, it MAY
> >>    send a Binding Update to its home agent, to instruct its home
agent
> >>    to no longer intercept or tunnel packets for it. Until the
mobile
> >>    node sends a de-registration Binding Update, it may not be able
to
> >>    send and receive packets using its home address from the home
link.
> >>    The home agent will continue to intercept all packets sent to
the
> >>    mobile node's home address, as long as the home agent is
proxying
> >>    for the home address.
> >>
> >> Two modifications. Replaced "..it will not be able to.." with "..it
> > may
> >> not be able to.." and re-wrote the last sentence.
> >>
> >> Vijay
> >>
> >>
> >>> From: Sri Gundavelli [mailto:[email-masked]]
> >>> Sent: Wednesday, July 09, 2008 11:26 AM
> >>> To: Giaretta, Gerardo
> >>> Cc: Vijay Devarapalli; Benjamin Lim; [email-masked];
> >>> [email-masked]
> >>> Subject: Re: [MEXT] [mext] #11: De-registration when
> >>> returning home [VijayDevarapalli <[email-masked]>]
> >>>
> >>>
> >>> Just one comment.
> >>>
> >>>
> >>>> Until the mobile node sends a de-registration Binding
> >>> Update, it will
> >>>> not
> >>>> be able to send and receive packets using its home address
> >>> from the home
> >>>> link.
> >>> I have a problem with this. As Pascal and Rajiv pointed out,
nothing
> >>> really stops the MN, which is the legitimate address owner to
> > reclaim
> >>> and start using its home address on the home link and without
> > sending
> >>> a BU with life=0. This has to confirm to the override flag purpose
> > in
> >>> ND.
> >>>
> >>> Sri
> >>>
> >>>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 11 Jul 2008 00:04:02 -0400

Hi Benjamin,

> 
> Now this is the part it gets fuzzy.  In the BCE, HA would have an
entry
> for
> HoA.  This lets HA know to defend HoA.  Yet, HA see a packet coming
from
> home link with source address as HoA.  Since HA did not send such a
packet
> and HA should only be the one defending this address (other than MN),
I am
> not sure if this would confuse the hell out of HA.  What would HA do
with
> this packet? Forward? Drop?
> 

[RKo:>] It should be similar to what the HA would do once it would
remove the outer tunnel header had the packet arrived from a visited
network. That is, forward the packet to the CN. 

-Rajeev

> Regards,
> Benjamin Lim
> > Behalf Of Koodli, Rajeev
> > Sent: Friday, July 11, 2008 6:05 AM
> > To: [email-masked]; Vijay Devarapalli
> > Cc: [email-masked]
> > returning home[VijayDevarapalli <[email-masked]>]
> >
> >
> > Hi Charlie, Vijay,
> >
> > The text is mostly fine with me. Please see below:
> >
> >
> > > >    mobile node detects that its home subnet prefix is
> > again on-link.
> > > >    To be able to send and receive packets using its home address
> > from
> > > >    the home link, the mobile node MUST send a Binding
> > Update to its
> > > >    home agent to instruct its home agent to no longer intercept
or
> > > >    tunnel packets for it. Until the mobile node sends a
> > de-registration
> > > >    Binding Update, it will not be able to send and receive
packets
> >                                ^^^^^^^^^^^^^^^^^^^^
> >
> > [RKo:>] I am not sure why the MN will not be able send
> > packets until de-registration completes. If there is no
> > reason, we should re-word it ".. will not be able to receive
> > packets.."
> >
> > -Rajeev
> >
> >
> >
> >

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 11 Jul 2008 14:20:50 -0400

Hi Vijay,

> 
> I suggest you guys open a separate issue on whether a mobile node can
> claim its address without first sending a de-registration BU when it
> returns to the home link.

[RKo:>] I assume you mean sending an Unsolicited NA prior to sending
Dereg-BU.

> 
> RFC 3775 does not allow this. It is clearly a violation of RFC 3775.
An
> RFC 3775-compliant mobile node is supposed to behave as described in
RFC
> 3775 when it returns home. Not according to what RFC 4861 might allow
an
> IPv6 host to do.

[RKo:>] Well, "violation of RFC 3775" is interesting, since anything we
might do (e.g., changing a SHOULD to MUST) can also be interpreted as
"violation".

More to the point below.

> For the issue we were discussing, lets go with the following text.
> 
>    A mobile node detects that it has returned to its home link through
>    the movement detection algorithm in use (Section 11.5.1), when the
>    mobile node detects that its home subnet prefix is again on-link.
>    To be able to send and receive packets using its home address from
>    the home link, the mobile node MUST send a Binding Update to its
>    home agent to instruct its home agent to no longer intercept or
de-registration
>    Binding Update, it will not be able to send and receive packets
>    using its home address from the home link. The home agent will
>    continue to intercept all packets sent to the mobile's home address
>    and tunnel to the previously registered care-of address.
> 

[RKo:>] I still did not hear what goes wrong if the MN sends packets
using HoA as source IP address. If something does go wrong, we need to
fix it. If not, I don't see why we need the above statement ".. it will
not be able to send and receive packets .."

Otherwise, the text is okay with me.

-Rajeev

> We need to close this issue.
> 
> Based on what we decide later on whether the mobile node can claim its
> address without first sending a de-registration BU, we can revisit the
> above text.
> 
> Vijay
> 
> 
> > Behalf Of Pascal Thubert (pthubert)
> > Sent: Friday, July 11, 2008 9:40 AM
> > To: Sri Gundavelli (sgundave)
> > I won't reply to all your mails but I'm 100 % with you all the way
> > through.
> >
> > In particular, you're very right that it would just be
> > nonsense for a HA
> > to try and reclaim SeND based addresses when a MN proves ownership
on
> > link. We need to prepare for the coming changes and adapt the spec.
In
> > short the HA is a proxy and it should behave as such.
> >
> > RFC3775bis might live in its bubble and expect that all MN will act
> > proper. But there are a number of scenarios, including reboot
> > with loss
> > of state, where the MN might not. And the real attacks against the
MN
> > home address might not come from nodes that behave proper, whether
> > that's voluntary or not.
> >
> > When the MN comes back home and does not have the right states to
> > unbind,
> >
> > - if the MN is a good citizen, it should DAD its address and the HA
> > should defend it. I'm asking that upon DAD, the HA do not set the
> > Override bit; that change to the spec would allow the MN to
> > differentiate a real collision from a proxy collision. I
> > would call that
> > a proxy-success for the DAD flow.
> >
> > - but to avoid trouble when coming home, I'd expect that
> > implementations
> > that do not wish to get angry customer calls in the middle of
> > the night
> > would send RA (Override) right away. I know, that's bad. But
> > that's damn
> > quick and efficent. That's how we do hot standby...
> >
> > What happens next?
> >
> > - A node should get its address back if only proxies are
> > defending it.
> > In MIP case, whether the MN can clean up the binding properly or
fails
> > for some reason, it should NA(override) its address. At least that
> > should be rightful if DAD proxy-succeeds.
> >
> > - Upon NA override, a proxy should yield silently.
> > The HA should remove its binding. This flow would also
> > enables a HA that
> > gets a new BU to take over the binding from the old HA.
> >
> > Proxy or not proxy? That is the question...
> >
> > Pascal
> >
> > >From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of
> > Sri Gundavelli (sgundave)
> > >Sent: mercredi 9 juillet 2008 20:26
> > >To: Giaretta, Gerardo
> > >Subject: Re: [MEXT] [mext] #11: De-registration when returning home
> > [VijayDevarapalli
> > ><[email-masked]>]
> > >
> > >
> > >Just one comment.
> > >
> > >
> > >> be able to send and receive packets using its home address from
the
nothing
reclaim
sending
in

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 11 Jul 2008 15:09:55 -0400

Hi Rajeev,
 
> not be able to send and receive packets .."

Lets say a home agent has a binding cache entry for a particular home
address and is defending the address. It starts seeing packets from the
home link with the home address as the source address. Lets further
assume that the home agent is the default router for the home link. Now
does the home agent consider this as some other mobile node using the
home address? Or does it consider it as the real mobile node using its
home address from the home link? 

In the first case, the home agent would be dropping the packets. In the
second case, it may forward the packets. The behavior is undefined. So I
don't think we can claim that the mobile node will be able to send
packets before de-registering with the home agent.

Vijay

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 11 Jul 2008 20:56:53 -0400

> home address from the home link?

[RKo:>] I don't know if there is text anywhere in 3775 to drop the
packets if it sees packets with HoA as source IP address; I could be
wrong.

> packets before de-registering with the home agent.

[RKo:>] This needs to be fixed I think.

-Rajeev