Subject: Re: [MOBILE-IP] Deregistration question...

From: Marc Hasson <[email-masked]>
Date: Mon, 19 Jun 2000 14:41:34 -0700

Steve,

I didn't understand the mechanism suggested so I'd like a clarifacation
on your response below to the proposed scenario.  If the B-bit is set I
assume that means to just relay IP broadcasts through the tunnel, not
ARPs.  This especially must be the case if IP-in-IP tunneling is the
current tunnel that the HA has to the MN's COA.  Yet an "erroneous
gratuitous ARP" isn't an IP packet that can be simply relayed unless it
can be repackaged/flagged as something the MN is supposed to treat as
an ARP, not IP, packet.

So what is it, exactly, that would be relayed through the tunnel to let
the MN know that someone back home had swiped its address?

I could envision some kind of "registration reply" message with a new
code to let the MN user know whats going on but I'm not sure thats
allowed if the MN had already received a successful registration reply
earlier in life from the HA.  I'm not aware of any other kind of
asynchronous mobile ip "notify" message that an HA could send an MN
when this situation occurs.  It could be useful for multiple reasons for
an HA to initiate a deregistration with a suitable code but I can't
find any verbiage in the specs about such HA-initiated
deregistrations.

   -- Marc --

 > Date:         Mon, 19 Jun 2000 14:45:42 -0400
 > From: Steven Glass - Solaris Software <[email-masked]>
 > Subject:      Re: [MOBILE-IP] Deregistration question...
 > X-To:         Yoshiyuki Tsuda <[email-masked]>
 > To: [email-masked]
 > X-Status: $$$$
 > X-UID: 0000001540
 >
 > > Hi, Steve,
 > >
 > >  I agree with you this isn't an MIP specific issue but a common issue.
 > >
 > >  I have another related issue:  an MN will often register its HA without
 > >  B-bit.  Then, if an erroneous node sends erroneous gratuitous ARPs, the
 > >  HA can detect them, but not relay them to the MN.  So, in this case,
 > >  the MN cannot detect such erroneous ARPs.
 > >  I think, it might be better an HA should relay such erroneous ARPs to
 > >  an MN, whether the B-bit is set or not.
 >
 >     Tsudasan,
 >
 >     This is a nice feature!   The HA lets the mobile node, if it's still on
 > the other end of the tunnel, know that someone's captured its address.  If
 > it's still at the other end of the tunnel, it reregisters to allow the HA to
 > resend a gratuitous arp and recapture the address.  Sure, the MN can't compete
 > with a bag-guy on the home subnet, but it could certainly let a user know
 > what's happening...
 >
 >                               Cheers,
 >                                   Steve
 >

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Mon, 19 Jun 2000 18:17:38 -0400

> can be repackaged/flagged as something the MN is supposed to treat as

    The issue really isn't related to M/Bcast forwarding support as it
suggests using this mechanism to potentially notify a mobile node that
someon's gratuitously arp'd its IP address on the home link (that is whether
or not the B-bit was set in the latest registration request), though obviously
[mostly] follows more naturally if the B-bit is supported by the HA, and was
request in the most recent registration request.  Yes, there are some
interpretations of "the rules" that in some light may need to be bent, but the
proposal was nothing more than that, an idea to let the MN know of a
potentially damaging situation on its home subnet.

> the MN know that someone back home had swiped its address?

    Of course, I invite Tsudasan to correct me if I've missunderstood!

    The gratuitous arp would be encapsulated as any M/Bcast in an IP header
with a dst of the mobile node's IP address, then put into the tunnel which
means adding another IP[inIP] header (type 4) with the HAs src address, and
the FA's dst address.  The FA then decapsulates, sees the inner dst is the MN,
so it forwards it link-local.  When the MN receives and decapsulates it
recovers the gratuitious arp which it then defends via the reverse tunnel
(which, if it's not colocated, requires encapsulated delivery into the reverse
tunnel), or simply reregisters to get the HA to send another gratuitous arp on
its home link.  Note that if the MN is colocated (D-bit set in the
registration request) just the tunnel IP header is required.

> find any verbiage in the specs about such HA-initiated

    According to 2002[-bis], the HA is not allowed to generate a registration
reply that is not in response to a registration request.

    I'm actually in the midst of finishing my draft on registration revocation
which handles this in a semi-related way.  I'm not going to stick my neck out
and guess a completion date as I did with the DHCP draft, though my sincere
intension is to submit it by the Pitsburg IETF draft deadline...

                              Cheers,
                                  Steve