Subject: Re: [Mip4] I-D Action:draft-ietf-mip4-rfc3344bis-10.txt

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Sep 2010 14:40:22 +0200

I guess rfc3344bis is not out yet.  I have a comment about a Mobile Node
returning home.

Currently, the 3344bis-10 says:
> Before transmitting the (de)Registration Request message to its home
> agent, the mobile node MUST transmit this gratuitous ARP on its home
> network as a local broadcast on this link.

That is good.

However, it does not say that the HA MUST receive this gratuitous ARP
and interpret it.  I don't find a place in the draft requiring the HA to
do so.

The result is that one implementation of HA (dynamics) does not receive
and interpret this gratuitous ARP.  Worse, the HA complains about
"duplicate address", which can be seen as normal because HA already
proxy ARP for that address.

There are several ways to fix this: (1) suggest HA text in Returning
Home saying HA MUST receive and interpret the gratuitous ARP sent by MN
returning home. (2) use IPv4 link local address on the MN, for the
registration (deletion) when returning home and write related text.

I personally prefer the second solution because: it requires only
modifications on the MN, has been implemented here locally, avoids
ARP-proxyARP complications.

Packet dumps of the problem available upon request.

Comments welcome,

Alex

Le 08/04/2010 01:15, [email-masked] a écrit :
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Mobility for IPv4
> Working Group of the IETF.
>
>
> Title           : IP Mobility Support for IPv4, revised Author(s) :
> C. Perkins Filename        : draft-ietf-mip4-rfc3344bis-10.txt Pages
>  : 105 Date            : 2010-04-07
>
> This document specifies protocol enhancements that allow transparent
>  routing of IP datagrams to mobile nodes in the Internet.  Each
> mobile node is always identified by its home address, regardless of
> its current point of attachment to the Internet.  While situated away
>  from its home, a mobile node is also associated with a care-of
> address, which provides information about its current point of
> attachment to the Internet.  The protocol provides for registering
> the care-of address with a home agent.  The home agent sends
> datagrams destined for the mobile node through a tunnel to the
> care-of address.  After arriving at the end of the tunnel, each
> datagram is then delivered to the mobile node.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mip4-rfc3344bis-10.txt
>
>
>
>
>
Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
> _______________________________________________ I-D-Announce mailing
> list [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
> directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Sep 2010 16:42:22 +0200

I wanted to add the following.

rfc3344bis is missing an important step when returning home, step 
performed by many linux implementations: that of sending an ARP "Who 
Has" about the HA.

Currently rfc3344bis-10 says:
>    When a mobile node later returns to its home network, the following
>    steps, in this order, MUST be performed:
>
>    o  The mobile node decides to register at home, perhaps because it
>       has received an Agent Advertisement from its home agent.
>
>    o  Before transmitting the Registration Request, the mobile node re-
>       enables its own future processing of any ARP Requests it may
>       subsequently receive requesting its link-layer address.
>
>    o  The mobile node performs a gratuitous ARP for itself.  In this
>       gratuitous ARP, the ARP Sender Hardware Address is set to the
>       link-layer address of the mobile node.
>    [xxx]
>    o  The mobile node transmits its Registration Request.
 >
>    o  When the mobile node's home agent receives and accepts the  [...]

But when looking at the packet dump I always see an ARP "Who Has" sent 
by MN, link dst broadcast, about the HA address, right before the 
Registration Request [xxx].

Why is the RFC silent about this step?  It is of paramount importance 
for Returning Home to work.  Besides, some implementation makes it does 
not work because that step is mnissing.

Alex

Le 09/09/2010 14:40, Alexandru Petrescu a écrit :
> --
> Mip4 mailing list: [email-masked]
> Web interface: https://www.ietf.org/mailman/listinfo/mip4
> Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 9 Sep 2010 13:54:30 -0400

Hi, Alex,

3344bis is currently in AUTH48 (and has been for some time).
We are still waiting on Charlie's final approval of the document.
It is a bit late to be making technical changes of this nature.

I don't think we can put a requirement on a node that it MUST
receive a given message; Ethernet is unreliable and so the protocol
must function even without this message getting through to the
HA.  Also, the gratuitous ARP isn't authenticated, so it may not
be a good basis for removing the binding.  The real state removal
happens after an authenticated de-registration with lifetime zero.

Is it a fatal error when the dynamics HA complains about a duplicate
address?  Is it just a complaint about the MN's gratuitous ARP or
is it a complaint when it receives (and drops?) the MN's de-registration?
I expect it's the OS doing the complaining and not the dynamics code; 
they probably did something easy like configure the MN's address onto 
a local interface.  It does seem like using a link-local address would
be a way to get the de-registration through in case the HA's interface
is dropping the packet (do you have rp_filter turned on?).

On the ARP request just before the de-registration: this seems like
a natural consequence of the MN trying to send a packet to the HA's
IP address.  If it doesn't have an ARP entry for that IP address, it
sends out WHO-HAS.  I wouldn't think we need to specify this behavior
in 3344bis when we say it sends a packet addressed to the HA.  If the
MN has the MAC address already configured, why would skipping this
WHO-HAS break anything?

-Pete

Alexandru Petrescu wrote:
>>    When a mobile node later returns to its home network, the
>>    following steps, in this order, MUST be performed:
>> 
>>    o  Before transmitting the Registration Request, the mobile node
>>       re- enables its own future processing of any ARP Requests it
>>       may subsequently receive requesting its link-layer address.
>> 
> But when looking at the packet dump I always see an ARP "Who Has"
> sent by MN, link dst broadcast, about the HA address, right before
> the Registration Request [xxx].  
> 
> for Returning Home to work.  Besides, some implementation makes it
> does not work because that step is mnissing.  
> 
> Alex
> 
> 
>> I guess rfc3344bis is not out yet.  I have a comment about a Mobile
>> Node returning home. 
>> 
>> and interpret it. I don't find a place in the draft requiring the HA
>> to do so. 
>> 
>> The result is that one implementation of HA (dynamics) does not
>> receive and interpret this gratuitous ARP. Worse, the HA complains
>> about "duplicate address", which can be seen as normal because HA
>> already proxy ARP for that address.
>> 
>> Home saying HA MUST receive and interpret the gratuitous ARP sent by
>> MN returning home. (2) use IPv4 link local address on the MN, for the
>>>> 105 Date : 2010-04-07
>>> routing of IP datagrams to mobile nodes in the Internet. Each mobile
>>> node is always identified by its home address, regardless of its
>>> current point of attachment to the Internet. While situated away

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Sep 2010 20:47:39 +0200

Le 09/09/2010 19:54, McCann Peter-A001034 a écrit :
> Hi, Alex,
>
> 3344bis is currently in AUTH48 (and has been for some time). We are
> still waiting on Charlie's final approval of the document. It is a
> bit late to be making technical changes of this nature.
>
> must function even without this message getting through to the HA.
> Also, the gratuitous ARP isn't authenticated, so it may not be a good
> basis for removing the binding.  The real state removal happens after
> an authenticated de-registration with lifetime zero.
>
>  address?

Not fatal, dynamics proper doesn't complain anything.

> Is it just a complaint about the MN's gratuitous ARP or is it a
> complaint when it receives (and drops?) the MN's de-registration? I
> expect it's the OS doing the complaining and not the dynamics code;

YEs, it is actually wireshark "expert" complaining about it.

> a local interface.

No, it's not HA configuring the MN's address on a local interface.
ifconfig on HA doesn't show so at least.

> It does seem like using a link-local address would be a way to get
> the de-registration through in case the HA's interface is dropping
> the packet (do you have rp_filter turned on?).

The HA's interface does not drop the RegReq packet because the packet is
not received at HA at all.  The RegReq packet is sent to the ff
broadcast ll address because dynamics HA does not respond to the
WHO-HAS.  The problem is HA not responding to a WHO-HAS.

I need to check rp_filter because I don't know what is.

For now we use link-local address as src of this RegReq (dst HA global
address) and it works.

>  sends out WHO-HAS.  I wouldn't think we need to specify this
> behavior in 3344bis when we say it sends a packet addressed to the
> HA.  If the MN has the MAC address already configured, why would
> skipping this WHO-HAS break anything?

The MN does not have that MAC address (of HA) already configured
on its arp cache because the MN previously went away to other networks
(this is "Returning Home") and reconfigured its eth interface according
to these visited networks and its arp cache.

Comments welcome.

There is also a question of whether it is reasonable to believe that MN
can send its deregistering Registration Request via another link that
its home link.  In practice it is reasonable to send a deregistering
RegReq via the link soon-to-disappear (3g+ in my case, just before
attaching to WiFi) - this deregistration via 3g+ does work.  But I
suppose it is RFC-illegal to send this deregistering RegReq via another
link than the home link, by RFC, but I wanted to check with RFC.

Alex

>> performed by many linux implementations: that of sending an ARP
>> "Who Has" about the HA.
>>
>>> o  The mobile node decides to register at home, perhaps because
>>> it has received an Agent Advertisement from its home agent.
>>>
>>> link-layer address of the mobile node. [xxx] o  The mobile node
>>> transmits its Registration Request.
>>>
>> Why is the RFC silent about this step?  It is of paramount
>> importance for Returning Home to work.  Besides, some
>> implementation makes it does not work because that step is
>> mnissing.
>>
>> Alex
>>
>>
>>> I guess rfc3344bis is not out yet.  I have a comment about a
>>> Mobile Node returning home.
>>>
>>>> Before transmitting the (de)Registration Request message to
>>>> its home agent, the mobile node MUST transmit this gratuitous
>>>> ARP on its home network as a local broadcast on this link.
>>>
>>> That is good.
>>>
>>> However, it does not say that the HA MUST receive this
>>> gratuitous ARP and interpret it. I don't find a place in the
>>> draft requiring the HA to do so.
>>>
>>> receive and interpret this gratuitous ARP. Worse, the HA
>>> complains about "duplicate address", which can be seen as normal
>>> because HA already proxy ARP for that address.
>>>
>>> There are several ways to fix this: (1) suggest HA text in
>>> Returning Home saying HA MUST receive and interpret the
>>> gratuitous ARP sent by MN returning home. (2) use IPv4 link
>>> local address on the MN, for the registration (deletion) when
>>> returning home and write related text.
>>>
>>> modifications on the MN, has been implemented here locally,
>>> avoids ARP-proxyARP complications.
>>>
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories. This draft is a work item of the
>>>> Mobility for IPv4 Working Group of the IETF.
>>>>
>>>>
>>>> Title : IP Mobility Support for IPv4, revised Author(s) : C.
>>>> Perkins Filename : draft-ietf-mip4-rfc3344bis-10.txt Pages
>>>>> 105 Date : 2010-04-07
>>>>
>>>> This document specifies protocol enhancements that allow
>>>> transparent routing of IP datagrams to mobile nodes in the
>>>> Internet. Each mobile node is always identified by its home
>>>> address, regardless of its current point of attachment to the
>>>> Internet. While situated away from its home, a mobile node is
>>>> also associated with a care-of address, which provides
>>>> information about its current point of attachment to the
>>>> Internet. The protocol provides for registering the care-of
>>>> address with a home agent. The home agent sends datagrams
>>>> destined for the mobile node through a tunnel to the care-of
>>>> address. After arriving at the end of the tunnel, each
Internet-Drafts are also available by anonymous FTP at:
>>>> Below is the data which will enable a MIME compliant mail
>>>> reader implementation to automatically retrieve the ASCII
>>>> version of the Internet-Draft.
>

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 9 Sep 2010 15:09:37 -0400

Hi, Alex,

Alexandru Petrescu wrote:
>> I don't think we can put a requirement on a node that it MUST receive
>> a given message; Ethernet is unreliable and so the protocol must
>> function even without this message getting through to the HA.

So it's some monitoring software doing the complaining?  Seems like
this aspect isn't so relevant.
 
> The HA's interface does not drop the RegReq packet because the packet
> is not received at HA at all.  The RegReq packet is sent to the ff

Ah, it seems like something on the HA is checking the sender
IP address encoded in the request and is ignoring it because it
matches one of its own addresses.  That's odd because I would
think the arp code would just respond to the hardware address;
it doesn't need to do anything with the IP address except maybe
populate its own arp cache.  Maybe this step is failing in the
dynamics case so it drops the request.
 
> I need to check rp_filter because I don't know what is.

If you're using Linux, rp_filter does some checks on incoming
packets to see if the source addresses in them make sense.  You
can turn it off by doing "echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter".
But, I didn't think it filtered ARP packets too.  Maybe it does.

> For now we use link-local address as src of this RegReq (dst HA global

Does the MN send a WHO-HAS for the HA global address?  Does it
get a response?
 
>> On the ARP request just before the de-registration: this seems like a
>> natural consequence of the MN trying to send a packet to the HA's IP
>> address.  If it doesn't have an ARP entry for that IP address, it
> The MN does not have that MAC address (of HA) already configured on
> its arp cache because the MN previously went away to other networks
> (this is "Returning Home") and reconfigured its eth interface
> according to these visited networks and its arp cache.   

Right, makes sense that it would be sent.  You seemed to indicate
in your last mail that it was the *absence* of the WHO-HAS that
caused the scenario to fail.  Now it seems you are saying that
the WHO-HAS is there (when the MN is using its Home Address) but
the HA just doesn't respond to it.

> Comments welcome.
> 
> There is also a question of whether it is reasonable to believe that
> MN can send its deregistering Registration Request via another link
> that its home link.  In practice it is reasonable to send a
> deregistering RegReq via the link soon-to-disappear (3g+ in my case,
> just before attaching to WiFi) - this deregistration via 3g+ does
> work.  But I suppose it is RFC-illegal to send this deregistering
> RegReq via another link than the home link, by RFC, but I wanted to
> check with RFC.       

That should be fine - we made changes in the latest version to explicitly
allow de-registration of a care-of address from a link that is neither
the home link nor the same foreign link on which the care-of address
was originally registered.  We even mandated that the FA not add an
authentication extension to any de-registration so it won't have
the potential to fail.  See Issue 45.

-Pete

>>>>  re- enables its own future processing of any ARP Requests it may
>>> implementation makes it does not work because that step is mnissing.
>>> 
>>> Alex
>>> 
>>> 
>>>>> Before transmitting the (de)Registration Request message to its
>>>>> home agent, the mobile node MUST transmit this gratuitous ARP on
>>>>> its home network as a local broadcast on this link.
>>>> 
>>>> That is good.
>>>> 
>>>> However, it does not say that the HA MUST receive this gratuitous
>>>> ARP and interpret it. I don't find a place in the draft requiring
>>>> the HA to do so. 
>>>> 
>>>> Returning Home saying HA MUST receive and interpret the gratuitous
>>>> ARP sent by MN returning home. (2) use IPv4 link local address on
>>>> the MN, for the registration (deletion) when returning home and
>>>> write related text. 
>>>> 
>>>>> Internet. While situated away from its home, a mobile node is also
>>>>> associated with a care-of address, which provides information
>>>>> about its current point of attachment to the Internet. The
>>>>> protocol provides for registering the care-of address with a home
>>>>> agent. The home agent sends datagrams destined for the mobile
>>>>> node through a tunnel to the care-of address. After arriving at
>>>>> the end of the tunnel, each datagram is then delivered to the
>>>>> mobile node. 
>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 08:56:15 +0200

Le 09/09/2010 21:09, McCann Peter-A001034 a écrit :
>>> 3344bis is currently in AUTH48 (and has been for some time). We
>>> are still waiting on Charlie's final approval of the document. It
>>> is a bit late to be making technical changes of this nature.
>>>
>>> receive a given message; Ethernet is unreliable and so the
>>> protocol must function even without this message getting through
>>>  to the HA. Also, the gratuitous ARP isn't authenticated, so it
>>> may not be a good basis for removing the binding.  The real state
>>> removal happens after an authenticated de-registration with
>>> lifetime zero.
>>>
>>> Is it a fatal error when the dynamics HA complains about a
>>> duplicate address?
>>
>>> complaint when it receives (and drops?) the MN's de-registration?

It is wireshark packet analyzer "expert info" on HA complaining
"duplicate use of [HA] address detected".

I wonder why it's disqualified as irrelevant.  At a first thought indeed
the monitoring software may be responsible of not much.  But this
software often implements large parts of protocol code in order to work
  properly (e.g. checks checksums, checks security, links packets between
them based on carried ids, and so on - all hard parts to implement).
One has to really understand a protocol in order to implement parts in
wireshark - the acceptance standards are high.

Wireshark (and other analyzers) are essential tools used by protocol
designers and implementers - without it it's hardly possible to debug
anything.

I'd go as far to say that if wireshark complains then protocol may have
a problem.

You seem to suggest that a better implementation in wireshark would
probably not complain about it, if it realizes this is Mobile IP and
different than other ARP.  But this is hard to achieve knowing there's
little in ARP which makes think Mobile IP.

>>> they probably did something easy like configure the MN's address
>>>  onto a local interface.
>>
>>> It does seem like using a link-local address would be a way to
>>> get the de-registration through in case the HA's interface is
>>> dropping the packet (do you have rp_filter turned on?).
>>
>> The HA's interface does not drop the RegReq packet because the
>> packet is not received at HA at all.  The RegReq packet is sent to
>>  the ff broadcast ll address because dynamics HA does not respond
>> to the WHO-HAS.  The problem is HA not responding to a WHO-HAS.
>
> Ah, it seems like something on the HA is checking the sender IP
> address encoded in the request and is ignoring it because it matches
>  one of its own addresses.

Reads so to me too.

> That's odd because I would think the arp code would just respond to
> the hardware address; it doesn't need to do anything with the IP
> address except maybe populate its own arp cache.  Maybe this step is
> failing in the dynamics case so it drops the request.

Dynamics is userspace and gets packets that kernel wants delivered to
it.  I think it may be the kernel not delivering, because it's kernel
maintaining arp cache, I think.

> If you're using Linux, rp_filter does some checks on incoming packets
> to see if the source addresses in them make sense.  You can turn it
> off by doing "echo 0> /proc/sys/net/ipv4/conf/all/rp_filter". But, I
> didn't think it filtered ARP packets too.  Maybe it does.

Will check that.

>> For now we use link-local address as src of this RegReq (dst HA
>> global address) and it works.
>
> Does the MN send a WHO-HAS for the HA global address?  Does it get a
>  response?

MN sends WHO-HAS for the HA global address, and the dst address in the
MAC header is broadcast (48 1s: "0xfff...").

The wireshark on HA displays this WHO-HAS but no ARP "is-at" is
generated in response.  Hence the MN sends RegReq to the IP address but
with dst MAC address "0xffff..." as a last resort (it could have not
sent it at all because its ARP failed to obtain the MAC address of HA).

>>> On the ARP request just before the de-registration: this seems
>>> like a natural consequence of the MN trying to send a packet to
>>> the HA's IP address.  If it doesn't have an ARP entry for that IP
>>> address, it sends out WHO-HAS.  I wouldn't think we need to
>>> specify this behavior in 3344bis when we say it sends a packet
>>> addressed to the HA.  If the MN has the MAC address already
>>> configured, why would skipping this WHO-HAS break anything?
>>
>> on its arp cache because the MN previously went away to other
>> networks (this is "Returning Home") and reconfigured its eth
>> interface according to these visited networks and its arp cache.
>
> Right, makes sense that it would be sent.  You seemed to indicate in
>  your last mail that it was the *absence* of the WHO-HAS that caused
>  the scenario to fail.  Now it seems you are saying that the WHO-HAS
>  is there (when the MN is using its Home Address) but the HA just
> doesn't respond to it.

I owe an explanation. Many things happen, but let me try to isolate the
key problem to this unfolding:

-MN wants to send RegReq with IP src==HoA
-MN does ARP broadcast MAC 0xff to the HA address asking "WHO-HAS"
  which is actually asking "what is the MAC address of the ... IP
  address" (the HA IP address).
-Wireshark on HA displays this "WHO-HAS" in which wireshark inserts a
  header "expert info" saying "duplicate IP address configured xxx"
  where xxx is the Home Address.
-contrary to expectations, HA does not seem to reply and generate
  "IS-AT": nothing shows on wireshark HA neither on wireshark MN.
-MN waits a little then sends RegReq to the 0xfff MAC and IP dst HA
  address.

That is an absence of "IS-AT" which is wrong: the HA should send "IS-AT"
for its own HA address.  It leads to the MN sending RegReq to
MAC-broadcast (instead of MAC of HA), and this is not interpreted by the
HA.  This means HA does not delete its entry in the regtable for that
HoA.  This means HA continues to believe it is MN itself, which is wrong.

There is also an absence of "WHO-HAS" which is wrong: the HA should
generate a "WHO-HAS" prior to sending the RegRep to the MN.  It does not
send this WHO-HAS because it didn't delete the HoA registration and
believes it is MN itself.  This problem turns back to the problem above,
that key problem.

>> Comments welcome.
>>
>> There is also a question of whether it is reasonable to believe
>> that MN can send its deregistering Registration Request via another
>> link that its home link.  In practice it is reasonable to send a
>> deregistering RegReq via the link soon-to-disappear (3g+ in my
>> case, just before attaching to WiFi) - this deregistration via 3g+
>> does work.  But I suppose it is RFC-illegal to send this
>> deregistering RegReq via another link than the home link, by RFC,
>> but I wanted to check with RFC.
>
> That should be fine - we made changes in the latest version to
> explicitly allow de-registration of a care-of address from a link
> that is neither the home link nor the same foreign link on which the
>  care-of address was originally registered.  We even mandated that
> the FA not add an authentication extension to any de-registration so
> it won't have the potential to fail.  See Issue 45.

That sounds fine, it means in some cases where the 3G+ is still
available but MN prefers 3G+ then it could deregister via 3G+.  This is
good to know we'll do this in some cases.

Alex

>>>> rfc3344bis is missing an important step when returning home,
>>>> step performed by many linux implementations: that of sending
>>>> an ARP "Who Has" about the HA.
>>>>
>>>>> o  The mobile node decides to register at home, perhaps
>>>>> because it has received an Agent Advertisement from its home
>>>>>  agent.
>>>>>
>>>>> o  Before transmitting the Registration Request, the mobile
>>>>> node re- enables its own future processing of any ARP
>>>>> Requests it may subsequently receive requesting its
>>>>> link-layer address.
>>>>>
>>>>> o  The mobile node performs a gratuitous ARP for itself.  In
>>>>>  this gratuitous ARP, the ARP Sender Hardware Address is set
>>>>>  to the link-layer address of the mobile node. [xxx] o  The
>>>>> mobile node transmits its Registration Request.
>>>>>
>>>> But when looking at the packet dump I always see an ARP "Who
>>>> Has" sent by MN, link dst broadcast, about the HA address,
>>>> right before the Registration Request [xxx].
>>>>
>>>>>> its home agent, the mobile node MUST transmit this
>>>>>> gratuitous ARP on its home network as a local broadcast on
>>>>>>  this link.
>>>>>
>>>>> That is good.
>>>>>
>>>>> The result is that one implementation of HA (dynamics) does
>>>>> not receive and interpret this gratuitous ARP. Worse, the HA
>>>>>  complains about "duplicate address", which can be seen as
>>>>> normal because HA already proxy ARP for that address.
>>>>>
>>>>> I personally prefer the second solution because: it requires
>>>>>  only modifications on the MN, has been implemented here
>>>>> locally, avoids ARP-proxyARP complications.
>>>>>
>>>>>> Internet-Drafts directories. This draft is a work item of
>>>>>> the Mobility for IPv4 Working Group of the IETF.
>>>>>>
>>>>>>
>>>>>> address, regardless of its current point of attachment to
>>>>>> the Internet. While situated away from its home, a mobile
>>>>>> node is also associated with a care-of address, which
>>>>>> provides information about its current point of attachment
>>>>>> to the Internet. The protocol provides for registering the
>>>>>> care-of address with a home agent. The home agent sends
>>>>>> datagrams destined for the mobile node through a tunnel to
>>>>>> the care-of address. After arriving at the end of the
>>>>>> tunnel, each datagram is then delivered to the mobile
>>>>>> node.
>>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-mip4-rfc3344bis-10.t
>>>>>>
>>>>>>
>>>>>>
>>>>>>
xt

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Sep 2010 17:37:12 +0200

[...]
> didn't think it filtered ARP packets too.  Maybe it does.

I just checked rp_filter.  It was indeed set to 1 on both MR and HA.
However, clearing it does not improve the situation: returning home
still does not send an ARP "is-at" from the HA to MR, which makes
deregistration still impossible.

At least I learn rp_filter, thanks.

Alex

> care-of address was originally registered.  We even mandated that the
> FA not add an authentication extension to any de-registration so it
> won't have the potential to fail.  See Issue 45.
>
> -Pete
>
>> Alex
>>
>>> -Pete
>>>
>>>>>> Internet. Each mobile node is always identified by its
>>>>>> home address, regardless of its current point of attachment
>>>>>> to the Internet. While situated away from its home, a
>>>>>> mobile node is also associated with a care-of address,
>>>>>> which provides information about its current point of
>>>>>> attachment to the Internet. The protocol provides for
>>>>>> registering the care-of address with a home agent. The home
>>>>>> agent sends datagrams destined for the mobile node through
>>>>>> a tunnel to the care-of address. After arriving at the end
>>>>>> of the tunnel, each datagram is then delivered to the
>>>>>> mobile node.
>>>>>>
xt