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

From: Marc Hasson <[email-masked]>
Date: Mon, 19 Jun 2000 16:55:40 -0700

Steve,

 >     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

Yes, I understood its a separate issue.  I only (re)mentioned the B-bit
to emphasize that its *IP* broadcasts that are forwarded and so
how would non-IP (ARP) packets be differentiated.

 > 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.

Fine, I agree that detecting the conflict in addresses is a good
suggestion.  I'm just trying to discover how thats best conveyed.

 > > 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?
 >
 >     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

OK, maybe I'm being thick but this doesn't sound right.  The FA will
tear off the outer IP header.  This leaves the next IP header with a
unicast destination of MN and within it the {IP broadcast | ARP packet}.
As per 2002, the unicast destination MN packet, with its inner packet,
is forwarded link-local to the MN which decapsulates that packet to
recover the original packet inside.  Now the question I was trying to
get at in my first note is "How does the MN node at this point know the
inner packet is an ARP as opposed to an IP broadcast packet?" It has to
know somehow else the right processing isn't going to occur, no one's
passing the original packet's ethernet type or link-layer headers via
IP-in-IP tunneling.  (Are they?!  :-) )   Another way to ask this
question is, "On the first encapsulation the HA did above with the
unicast MN dst, what value was set for that IP header's protocol
field?"  I'm not aware of an "ARP tunneled within IP" value, is there
one?  If there is, that could be the differentiation needed if you used
it only when forwarding ARPs as opposed to IP broadcasts.  Even then,
I'm wondering if you'd need the original ARP packet's link-layer
headers to really do things correctly but I'll not pursue that thought
for now.

 > (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.

The same issue applies if its a co-located COA address that is used.
In that case the HA only applies one outer IP header to a broadcast to
tunnel it to the MN.  But the MN, to make this ARP suggestion work, is
still going to have to know somehow whether the inner packet is an ARP
or IP packet.  An ARP packet sent via IP-in-IP tunnel is going to be
rejected for an invalid IP header checksum (most likely).

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

Agreed.  I was "fishing" for a way to make this work cleanly.

 >
 >     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...

I like best the idea of a registration revocation and not getting into
this business of sending ARPs back and forth through these *IP* tunnels
to "defend" or be notified of an addressing conflict.  Such revocation
messages could be authenticated in the mobile IP protocol and I think
there are multiple termination reasons besides this address conflict
that would be useful for a HA to convey to its MNs.  Since the
revocation mechanism is probably useful for multiple things anyway it
might be nice to avoid having an additional "tunnel ARP within IP"
mechanism to serve this purpose, even if its fairly simple.

   -- Marc --

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Tue, 20 Jun 2000 13:26:15 +0900

Hello, Marc and Steve,

 Oh, I understood what I was missing in my previous email.  My issue
 wasn't related to M/Bcast forwarding support.  My previous email must
 have confused Steve a lot and a lot.  My apology to Steve.

 Anyway, I'm now concerned about this issue, because there may be a
 user in front of an MN, but there may not always be an administrator
 in front of an HA.  So, letting an MN know the problem is a better
 solution, I think.
 I had missed before.  But, before reading Marc's email, I had thought
 relaying ARP packets to an MN is much simpler, although there was a
 big problem how an ARP packet was packed in an IP packet.  Now, I feel
 a registration reply with some code may be more feasible, as Marc
 suggested.  But, according to this approach, I'm afraid another
 registration request with some code may also be necessary to request a
 gratuitous ARP to be sent from the HA and so on.
 I'd like to know this issue is worth adding such new mechanisms in MIP
 or not.

Thanks for your discussion.
-Yoshi

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Tue, 20 Jun 2000 12:07:32 -0400

> >     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
>
> one?

   No, not that I'm aware of.  This is what I meant by "bending some of the
rules" which really mean "bear with me" (and in the real world, if someone
wanted to implemnt this translates to figuring out a way to get some of this
done).  The original thought (as I saw it) was for the HA to simply get the
gratuitious arp through the tunnel so if the MN is still out there, it knows
what's going on.  The nice thing about this is it doesn't require the HA to
generate any registration messages, and it's in the spirit (at least) of using
the tunnel to communicate with the MN.  I agree with you the issue still
exists with a colocated MN.

> If there is, that could be the differentiation needed if you used

    I'm torn between saying "yes" and "no".  If the MN is going to defend its
address, then I suppose the answer is yes, it needs to form the defense as it
would normally, which means needing the original link-layer header (well, 1/2
of it anyway), then get it back up the [reverse] tunnel.  Of course, you'll
need a similar mechanism we're hand-waving through to get the HA to deal with
it as the MN must have.  If the MN is simply going to see this as a need to
reregister so the HA (read: if the HA were required to) send another
gratuitous arp to reclaim the address, then no.

> An ARP packet sent via IP-in-IP tunnel is going to be rejected for an
> invalid IP header checksum (most likely).

    Hmmm...  I didn't think about the checksum issues, then again if there was
an ARP-in-IP type, it would probably specify checksum the arp (as generic
payload).

> mechanism to serve this purpose, even if its fairly simple.

    I like it, too!  I'm not sure an ARP-in-IP mechanism is a case of "build
it and they'll come", but it was an interesting thought.

                              Cheers,
                                  Steve