[support] Destination unreachable from HA on BU???

[Mattias Blomqvist]

Hi,

On Thu, Mar 26, 2009 at 5:40 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
> Hi,
>
> Mattias Blomqvist <mattias.blomqvist at gmail.com> writes:
>
>> I have only one interface defined and it is defined as a tunnel
>> interface. So no preference values.
>> The output from mip6d is (I know the time on the MN isn't set so the
>> timestamps have the wrong date and time):
>> Fri Jan 11 04:18:37 mn_move: in foreign net
>> ...
>> Fri Jan 11 04:18:37 mh_send: sending MH type 5
>> from xxxx:xxxx:0:1300:0:0:0:1
>> to xxxx:xxxx:0:0:0:0:0:1
>> Fri Jan 11 04:18:37 mh_send: local CoA xxxx:xxxx:0:1300:0:0:0:1
>> Fri Jan 11 04:18:37 bul_update_timer: Updating timer
>> == BUL_ENTRY ==
>> Home address    xxxx:xxxx:0:1300:0:0:0:1
>> Care-of address xxxx:xxxx:0:1300:0:0:0:1
>> CN address      xxxx:xxxx:0:0:0:0:0:1
>>  lifetime = 262140,  delay = 1000
>>  flags: IP6_MH_BU_HOME IP6_MH_BU_ACK
>> ...
>> etc.
>> xxxx:xxxx is the same for every address above.
>> This BU will obviously not work. The real problem is that it continues
>> to use the same address for CoA and HoA even after a RA resulting in
>> autoconf of a correct CoA has been received. The only way to correct
>> this problem is to restart mip6d after the tunnel interface have
>> received a RA so it has a useable CoA.
>
> There is something I don't understand in your setup which prevents me to
> see why or how umip would do what you have above: the CoA UMIP uses is
> always (otherwise it is a bug) configured (manually or statically) on
> the interface. So in your case, this means that your tunnel interface
> has the xxxx:xxxx:0:1300:0:0:0:1 address set initially, doesn't it?

Correct.

> Can you please provide the whole (anonymized) output of ip addr show for
> your system.

Before RA received:

Mobile-test:~# ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
24: tunnel: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500
    inet6 xxxx:xxxx:0:1300::1/56 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::13/64 scope link
       valid_lft forever preferred_lft forever

After RA received:

Mobile-test:~# ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
24: tunnel: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500
    inet6 yyyy:yyyy::13/64 scope global dynamic
       valid_lft 2591997sec preferred_lft 604797sec
    inet6 xxxx:xxxx:0:1300::1/56 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::13/64 scope link
       valid_lft forever preferred_lft forever


The output is exactly the same regardless if mip6d is running or not.

> Now, with regard to the Tunnel keyword, as explained in the man page, it
> expects that the tunnel interface be configured externally, either in an
> automatic fashion of by hand. This is compatible with ppp, 6to4 and
> Teredo (at least). Your interface seems to work differently. Can you
> provide some details.

It is configured externally. But only link-local address and HoA are
set. The CoA cannot be set since it will change when the tunnel's
other end moves (which is the whole point in using MIPv6).

> I may be wrong and I would have to check in the code but:
>
> - because autoconfig is deactivated by UMIP, no RS should be sent by the
>  kernel on the tunnel. Does a userland process does that?

Yes. Just as the manpage says, the interface has to be managed by
something else.

> - when an interface is a Tunnel one, UMIP does not send RS.

The user process sends an RS to receive an RA which is sent to the
tunnel interface. This RA is important because it is the only way to
get an autoconfigured address that is usable as CoA.

> - If a RA is received, it is not processed by UMIP, i explicitly
>  prevented that in the code for tunnel ifaces, so even if an
>  unsollicited RA is received, then, UMIP is not the one that will set
>  the address on the tunnel interface. Does a userland process does
>  that?

No. The kernel process the RA like it would for any other interface
and sets the address according to how it should be done for stateless
autoconfig.

> - Tunnel information as understood by umip is read again and updated
>  when the link status changes, i.e. on up and down or when an address
>  is removed/added. If this is done on the tunnel as you explain, it
>  should work. Can you verify the tunnel has a new address after
>  receiving a RA, as you report?

It doesn't seem to read it when an address is added if it is done by
the kernel upon receiving an RA.
Yes, the tunnel has a new address after an RA is received regardless
if mip6d is running or not. See ip command output above.

> It would help if you could be more specific on how your tunnel interface
> work (config, routes, ...)

It uses the standard linux tuntap driver in tunnel mode. The tunnel
device is opened, a link-local address is set in accordance with RFC
4291 and a static ipv6 address is also set (the HOA,
xxxx:xxxx:0:1300::1/56) and then the interface is brought up.
Addresses are set by normal "ip -6 addr add" commands. No additional
routes other than thoose resulting from the ip command or received RA
is set. Received RA is sent by radvd (running on another host at other
end of the tunnel) with the simplest possible config:

interface tunnel
{
   AdvSendAdvert on;
   prefix yyyy:yyyy::/64
   {
   };
};

BR,
Mattias