[hipl-users] Re: HIP mobility testings

  • From: Mika Kousa <mkousa@xxxxxxxxx>
  • To: HIPL Users <hipl-users@xxxxxxxxxxxxx>
  • Date: Tue, 9 Mar 2004 14:53:51 +0200 (EET)

On Mon, 8 Mar 2004, Simon Schuetz wrote:

-> Hi,
-> has anybody tested HIP Mobility in a different way than proposed in the
-> HOWTO?

Practically no. We do not have enough hardware to test many different
network combinations. We have tested mainly the scenario of hosts
connected with direct cable.

-> I'm experiencing problems using the following setup:
-> 3 machines: Server (S), Router (R), and a Client (C).
-> S and R are connected via one ethernet cable, using static IP6
-> addresses.
-> C and R are connected via two ethernet cables, IP6 addresses are
-> configured such that each connection is a different network.
->
-> 1st scenario:
-> - shutting down one of C's interfaces
-> - completing a hipsetup
-> - connecting C with S via HITs
-> - send data
-> - shutting down C's active interface

At this point C tries to send a REA, but I guess it will fail because C
has no usable network interface to use for sending packets. S sees no
REAs.

-> - starting the other interface
-> - send data

C sends a REA, but S might think that the previous interface of C is still
usable, because it has not received any new information about the state
changes of the C's previous interface.


-> 2nd scenario:
-> - shutting down one of C's interfaces
-> - completing a hipsetup
-> - connecting C with S via HITs
-> - send data
-> - unplug ethernet cable

Current HIPL implementation does not know when the network link status
changes.

-> - delete current IP

Practically the same issue as before: C sends REA, but it fails because C
has no usable network interface to use for sending packets. S sees no
REAs.

-> - add new IP

C sends REA, but it fails because C has no network connection to use for
sending packets. S sees no REAs.

-> - plugin ethernet cable
-> - send data

Network link goes up, but because HIPL does not recognize link status
changes (HIPL does not buffer outgoing REAs neither), no REAs are sent, so
S does not know about C's new address or deleted old address.

-> Both testings did not work. The fact is, that no HIP REA packets arrive
-> at the server side.

Yes, for reasons I explained before.

-> Either they are not sent when bringing up the interfaces or they are
-> sent before they can be routed to the correct destination. The requests
-> arrive at the server-side, but the server responds to the old IP that
-> is no longer valid.

Current implementation sends REAs when IPv6 address is added or deleted,
or when network device goes down (eg. ifconfig ethX down) or it is
unregistered from the system (eg. when you plug PCMCIA network card out).

The problem when S tries to validate C's new address is known. Current
implementation just uses the new address in the REA, though we should wait
until Duplicate Address Detection procedure is finished. When C receives
AC packet to the new address from S, C drops the packet because C does not
yet know if the new address can be used or not (REA-AC-ACR takes much less
time than typical DAD time, which is usually a couple of seconds). I'm
planning to move the REA sending code to the DAD related code, but I do
not know when I have enough time to experiment with this issue.

Other related posts: