[PATCH] IPv6: (1/5) Fix bugs in ip6_tunnel.c ICMP error handler

Hi,

this patch fixes two byte order bugs in ip6ip6_err(). Please apply!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Hi,

this patch sets free_netdev() as the destructor for ip6_tnl dev. Please
apply!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Oops,
forgot to attach the patch in the original mail...

Sorry about that,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Hi,

I just only recently noticed MAX_ADDR_LEN had beed increased to 32. This
means the IPv6 addresses can now be copied into the dev->dev_addr and
dev->broadcast fields, just like the IPv4 addresses are for the other
tunnel drivers. Please apply!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Hi,

this patch removes all sockets from ip6_tunnel.c. It also allows nested
IPv6 encapsulations through different devices in the IPv6 tunnel
entry-point node, since the old restrictions caused by the sockets don't
apply any more. Please apply the patch!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

Hi,

unless (link-local) protocols like DHCPv6 or MLD are run over the virtual
link formed by IPv6 tunnels, the net_devices representing the tunnels
don't necessarily need to have an IPv6 address configured specifically to
them.

The inet6_dev structure of the device must however be configured for
neighbor discovery to work properly, even for IFF_NOARP devices like
ip6_tnls. This patch fixes that issue. Please apply!

Thanks,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

In article [off-list ref] (at Mon, 1 Sep 2003 03:11:58 +0300 (EEST)), Ville Nuorvala [off-list ref] says:

unless (link-local) protocols like DHCPv6 or MLD are run over the virtual
link formed by IPv6 tunnels, the net_devices representing the tunnels
don't necessarily need to have an IPv6 address configured specifically to
them.

Wrong. All interfaces have a link-local address. (RFC2462)

--yoshfuji

On Mon, 1 Sep 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:

In article [off-list ref] (at Mon, 1 Sep 2003 03:11:58 +0300 (EEST)), Ville Nuorvala [off-list ref] says:

quoted

unless (link-local) protocols like DHCPv6 or MLD are run over the virtual
link formed by IPv6 tunnels, the net_devices representing the tunnels
don't necessarily need to have an IPv6 address configured specifically to
them.

Wrong. All interfaces have a link-local address. (RFC2462)

Unfortunately the IPv6 tunneling spec (RFC2473) is broken on this point :(
I should probably raise this issue on the IETF ipv6 WG mailing list.

The first problem is, that the way to generate the interface-identifier
isn't currently specified in the tunnel spec.

The IPv6 over PPP spec (RFC2472) section 4.1 has some ideas:

1) if available, reuse any IEEE EUI-48 or EUI-64 identifiers on the node
2) use link-layer addresses, machine serial numbers, et cetera
3) if none of these can be found, use random bits

The second problem is, that this method alone doesn't yet guarantee
unique identifiers to the two tunnel endpoints.

In RFC2472 the IPv6 Control Protocol negotiates the identifiers between
the two peers beforehand, but unfortunately we don't have a similar
protocol in RFC2473.

Like the other tunnels (ipip, ip_gre, sit) ip6_tunnel is fundamentally a
IFF_NOARP device so you can't even use DAD to detect a duplicate address
on the virtual link. (Besides, the link doesn't even exist before both
devices have been brought up on the two separate nodes.)

This is something for the ipv6 WG to think about, I guess.

In the mean time, do we accept the in theory 1/2^64 (in practice of course
bigger) chance of duplicate addresses occurring on the link?

If yes, then I could (probably still later today) send a patch where the
interface-identifiers for the IPv6 tunnels are generated like in the IPv6
over PPP case above.

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

On Mon, 1 Sep 2003 02:34:55 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

this patch fixes two byte order bugs in ip6ip6_err(). Please apply!

Applied, thanks Ville.

On Mon, 1 Sep 2003 02:46:45 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

Oops,
forgot to attach the patch in the original mail...

Sorry about that,

That's ok :-)

Applied, thanks Ville.

On Mon, 1 Sep 2003 02:48:55 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

I just only recently noticed MAX_ADDR_LEN had beed increased to 32. This
means the IPv6 addresses can now be copied into the dev->dev_addr and
dev->broadcast fields, just like the IPv4 addresses are for the other
tunnel drivers. Please apply!

Applied, thanks Ville.

On Mon, 1 Sep 2003 02:57:03 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

this patch removes all sockets from ip6_tunnel.c. It also allows nested
IPv6 encapsulations through different devices in the IPv6 tunnel
entry-point node, since the old restrictions caused by the sockets don't
apply any more. Please apply the patch!

Thank you very much for finishing this work.

Applied, thanks.

On Mon, 01 Sep 2003 11:24:09 +0900 (JST)
YOSHIFUJI Hideaki / _$B5HF#1QL@ [off-list ref] wrote:

In article [off-list ref] (at Mon, 1 Sep 2003 03:11:58 +0300 (EEST)), Ville Nuorvala [off-list ref] says:

quoted

unless (link-local) protocols like DHCPv6 or MLD are run over the virtual
link formed by IPv6 tunnels, the net_devices representing the tunnels
don't necessarily need to have an IPv6 address configured specifically to
them.

Wrong. All interfaces have a link-local address. (RFC2462)

Are you sure there isn't an exception in the ip6ip6 tunnel
RFC?

On Mon, 1 Sep 2003 11:18:30 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

Unfortunately the IPv6 tunneling spec (RFC2473) is broken on this point :(
I should probably raise this issue on the IETF ipv6 WG mailing list.

 ...

The first problem is, that the way to generate the interface-identifier
isn't currently specified in the tunnel spec.

 ...

The second problem is, that this method alone doesn't yet guarantee
unique identifiers to the two tunnel endpoints.

This is exactly what I was thinking.  I really don't think link-
local addresses make any sense on a software device such as the
ipip6 tunnels.

On Mon, 1 Sep 2003, David S. Miller wrote:

On Mon, 1 Sep 2003 11:18:30 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

quoted

Unfortunately the IPv6 tunneling spec (RFC2473) is broken on this point :(
I should probably raise this issue on the IETF ipv6 WG mailing list.

 ...

quoted

The first problem is, that the way to generate the interface-identifier
isn't currently specified in the tunnel spec.

 ...

quoted

The second problem is, that this method alone doesn't yet guarantee
unique identifiers to the two tunnel endpoints.

This is exactly what I was thinking.  I really don't think link-
local addresses make any sense on a software device such as the
ipip6 tunnels.

Well, link-local addresses are used e.g. by routing protocols and such, so 
having one is probably rather important..

FWIW, on FreeBSD platform they take the link-local address of the first
physical interface, and give the exact same link-local address on all of
the tunnels, disambiuating them with the scope identifier.  Seems like an
OK appaorach too, and guarantees (to the degree of unique MAC addresses)  
that the addresses of the endpoints do not clash.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Mon, 1 Sep 2003 13:48:44 +0300 (EEST)
Pekka Savola [off-list ref] wrote:

Well, link-local addresses are used e.g. by routing protocols and such, so 
having one is probably rather important..

Ok.

FWIW, on FreeBSD platform they take the link-local address of the first
physical interface, and give the exact same link-local address on all of
the tunnels, disambiuating them with the scope identifier.  Seems like an
OK appaorach too, and guarantees (to the degree of unique MAC addresses)  
that the addresses of the endpoints do not clash.

Interesting approach...  I'm not particularly picky about how this
uniqueness issue is solved.

On Mon, 1 Sep 2003, David S. Miller wrote:

On Mon, 1 Sep 2003 13:48:44 +0300 (EEST)
Pekka Savola [off-list ref] wrote:

quoted

Well, link-local addresses are used e.g. by routing protocols and such, so
having one is probably rather important..

Ok.

quoted

FWIW, on FreeBSD platform they take the link-local address of the first
physical interface, and give the exact same link-local address on all of
the tunnels, disambiuating them with the scope identifier.  Seems like an
OK appaorach too, and guarantees (to the degree of unique MAC addresses)
that the addresses of the endpoints do not clash.

Interesting approach...  I'm not particularly picky about how this
uniqueness issue is solved.

Ok, this incremental patch to my previous addrconf.c patch generates a
link-local address to the IPv6 tunnel device. It first tries to inherit
the EUI64 identifier of some other device and if this fails, uses a
random interface id.

Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

On Mon, 1 Sep 2003 17:24:42 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

Ok, this incremental patch to my previous addrconf.c patch generates a
link-local address to the IPv6 tunnel device. It first tries to inherit
the EUI64 identifier of some other device and if this fails, uses a
random interface id.

Yoshfuji, do you mind if I apply his patch 5 and "5/5+1"?

On Mon, 1 Sep 2003, Ville Nuorvala wrote:

On Mon, 1 Sep 2003, David S. Miller wrote:

quoted

On Mon, 1 Sep 2003 13:48:44 +0300 (EEST)
Pekka Savola [off-list ref] wrote:

quoted

Well, link-local addresses are used e.g. by routing protocols and such, so
having one is probably rather important..

Ok.

quoted

FWIW, on FreeBSD platform they take the link-local address of the first
physical interface, and give the exact same link-local address on all of
the tunnels, disambiuating them with the scope identifier.  Seems like an
OK appaorach too, and guarantees (to the degree of unique MAC addresses)
that the addresses of the endpoints do not clash.

Interesting approach...  I'm not particularly picky about how this
uniqueness issue is solved.

Ok, this incremental patch to my previous addrconf.c patch generates a
link-local address to the IPv6 tunnel device. It first tries to inherit
the EUI64 identifier of some other device and if this fails, uses a
random interface id.

Two comments:

+       /* try to inherit EUI64 from another device */
+       for (dev = dev_base; dev; dev = dev->next) {
+               if (!ipv6_generate_eui64(addr.s6_addr + 8, dev)) {
+                       addrconf_add_linklocal(idev, &addr);
+                       return;
+

==> does this really inherit _EUI64_, *or* MAC address (or something like
it) to derive an EUI64?  Note that there is a significant difference when
you've configured manually e.g. 3ffe:ffff:f00:ba::1 on a device, and the
case when you've auto-configured the interface identifier from the MAC
address of the device.

The latter is probably always unique.  The former is not necessarily
sufficiently unique (but better than nothing, of course).

+#ifdef CONFIG_IPV6_PRIVACY
+       /* else try to generate a random identifier */
+       if (!__ipv6_regen_rndid(idev)) {
+               memcpy(addr.s6_addr + 8, idev->rndid, 8);
+               addrconf_add_linklocal(idev, &addr);
+               return;
+

==> my question is: as the former method to steal an EUI64 should succeed
pretty much always, is it useful to add basically dead code which never
gets executed here?  I certainly can't think of any scenario where you'd
have no interface to steal the MAC address/EUI64 from and you'd have to
fall back to random identifiers?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Tue, 2 Sep 2003, Pekka Savola wrote:

Two comments:

+       /* try to inherit EUI64 from another device */
+       for (dev = dev_base; dev; dev = dev->next) {
+               if (!ipv6_generate_eui64(addr.s6_addr + 8, dev)) {
+                       addrconf_add_linklocal(idev, &addr);
+                       return;
+

==> does this really inherit _EUI64_, *or* MAC address (or something like
it) to derive an EUI64?  Note that there is a significant difference when
you've configured manually e.g. 3ffe:ffff:f00:ba::1 on a device, and the
case when you've auto-configured the interface identifier from the MAC
address of the device.

ipv6_generate_eui64() derives the interface identifier from the MAC
address on ARPHRD_{ETHER,FDDI,IEEE802_TR,ARCNET} interfaces, but doesn't
do anything for other types of devices

==> my question is: as the former method to steal an EUI64 should succeed
pretty much always, is it useful to add basically dead code which never
gets executed here?  I certainly can't think of any scenario where you'd
have no interface to steal the MAC address/EUI64 from and you'd have to
fall back to random identifiers?

If the node doesn't have an Ethernet (etc.) NIC it won't get a valid
identifier from ipv6_generate_eui64() and has to resort to something
else, for example generating a random address.

An alternative would be to use ipv6_inherit_eui64(), which just copies the
64-bit suffix from the first link-local address it can find. This includes
both manually and auto-configured addresses, which means the risk of
duplicate addresses might be (I assume) greater than in the random address
case.

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

In article [off-list ref] (at Tue, 2 Sep 2003 04:35:34 -0700), "David S. Miller" [off-list ref] says:

On Mon, 1 Sep 2003 17:24:42 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

quoted

Ok, this incremental patch to my previous addrconf.c patch generates a
link-local address to the IPv6 tunnel device. It first tries to inherit
the EUI64 identifier of some other device and if this fails, uses a
random interface id.

Yoshfuji, do you mind if I apply his patch 5 and "5/5+1"?

Well, I have a question and a comment.

        if (ifp->idev->cnf.forwarding == 0 &&
            (dev->flags&IFF_LOOPBACK) == 0 &&
+           dev->type != ARPHRD_TUNNEL6 &&
            (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
                struct in6_addr all_routers;

Why?

Comment: this strategy is the "default."  
We can (or even should) do this stretegy whenever we failed to 
ipv6_generate_eui64() in addrconf_dev_config().

-- 
Hideaki YOSHIFUJI @ USAGI Project [off-list ref]
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

On Tue, 2 Sep 2003, Ville Nuorvala wrote:

On Tue, 2 Sep 2003, Pekka Savola wrote:

quoted

Two comments:

+       /* try to inherit EUI64 from another device */
+       for (dev = dev_base; dev; dev = dev->next) {
+               if (!ipv6_generate_eui64(addr.s6_addr + 8, dev)) {
+                       addrconf_add_linklocal(idev, &addr);
+                       return;
+

==> does this really inherit _EUI64_, *or* MAC address (or something like
it) to derive an EUI64?  Note that there is a significant difference when
you've configured manually e.g. 3ffe:ffff:f00:ba::1 on a device, and the
case when you've auto-configured the interface identifier from the MAC
address of the device.

ipv6_generate_eui64() derives the interface identifier from the MAC
address on ARPHRD_{ETHER,FDDI,IEEE802_TR,ARCNET} interfaces, but doesn't
do anything for other types of devices

Ok, but then the command should be:

/* try to inherit MAC address from another device, to build an EUI64 */

quoted

==> my question is: as the former method to steal an EUI64 should succeed
pretty much always, is it useful to add basically dead code which never
gets executed here?  I certainly can't think of any scenario where you'd
have no interface to steal the MAC address/EUI64 from and you'd have to
fall back to random identifiers?

If the node doesn't have an Ethernet (etc.) NIC it won't get a valid
identifier from ipv6_generate_eui64() and has to resort to something
else, for example generating a random address.

And exactly how often does this happen? Eth (all variants), FDDI, TR, 
ARCnet.. what's missing?  Does IPv6 even work with any other physical 
interfaces? :-)
 

An alternative would be to use ipv6_inherit_eui64(), which just copies the
64-bit suffix from the first link-local address it can find. This includes
both manually and auto-configured addresses, which means the risk of
duplicate addresses might be (I assume) greater than in the random address
case.

A possible twist here could be to copy only those whose universal/local 
bits indicate that that address was NOT manually configured, i.e..:

2001:708:10:40:207:e9ff:fe7b:259
               ^
            this one

.. but as stated, I'm not sure this is really necessary anyway either.

Note: it is desirable to have link-local addresses reasonably stable.  
Randomizing them may not be the right choice.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Wed, 3 Sep 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:

In article [off-list ref] (at Tue, 2 Sep 2003 04:35:34 -0700), "David S. Miller" [off-list ref] says:

quoted

On Mon, 1 Sep 2003 17:24:42 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

quoted

Ok, this incremental patch to my previous addrconf.c patch generates a
link-local address to the IPv6 tunnel device. It first tries to inherit
the EUI64 identifier of some other device and if this fails, uses a
random interface id.

Yoshfuji, do you mind if I apply his patch 5 and "5/5+1"?

Well, I have a question and a comment.

        if (ifp->idev->cnf.forwarding == 0 &&
            (dev->flags&IFF_LOOPBACK) == 0 &&
+           dev->type != ARPHRD_TUNNEL6 &&
            (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
                struct in6_addr all_routers;

Why?

The other end of the tunnel might not yet be set up to receive the packet,
which causes an ICMP error message to be sent back to the sender.

Besides, RS and RA over a ipv6-in-ipv6 tunnel is a _bad_ idea. A default
route through a tunnel without more advanced (policy/flow/srcaddr/? based)
routing schemes can lead to local routing loops.

Come to think of it a more elegant solution might be:

        if (ifp->idev->cnf.forwarding == 0 &&
            (dev->flags&IFF_LOOPBACK) == 0 &&
+           ifp->idev->cnf.rtr_solicits > 0 &&
            (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
                struct in6_addr all_routers;

and set both idev->cnf.rtr_solicits = 0 and idev->cnf.accept_ra = 0 for
ARPHRD_TUNNEL6 devices

Comment: this strategy is the "default."
We can (or even should) do this stretegy whenever we failed to
ipv6_generate_eui64() in addrconf_dev_config().

Should I send a separate patch to enable the random interface ids in
addrconf_dev_config()?

Regards,
Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

In article [off-list ref] (at Wed, 3 Sep 2003 13:17:56 +0300 (EEST)), Ville Nuorvala [off-list ref] says:

Come to think of it a more elegant solution might be:

        if (ifp->idev->cnf.forwarding == 0 &&
            (dev->flags&IFF_LOOPBACK) == 0 &&
+           ifp->idev->cnf.rtr_solicits > 0 &&
            (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
                struct in6_addr all_routers;

and set both idev->cnf.rtr_solicits = 0 and idev->cnf.accept_ra = 0 for
ARPHRD_TUNNEL6 devices

Yes, something like that.

quoted

Comment: this strategy is the "default."
We can (or even should) do this stretegy whenever we failed to
ipv6_generate_eui64() in addrconf_dev_config().

Should I send a separate patch to enable the random interface ids in
addrconf_dev_config()?

No, just move them to addrconf_dev_config().

--yoshfuji

On Wed, 3 Sep 2003, Ville Nuorvala wrote:

On Wed, 3 Sep 2003, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote:

quoted

In article [off-list ref] (at Tue, 2 Sep 2003 04:35:34 -0700), "David S. Miller" [off-list ref] says:

quoted

On Mon, 1 Sep 2003 17:24:42 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

quoted

Ok, this incremental patch to my previous addrconf.c patch generates a
link-local address to the IPv6 tunnel device. It first tries to inherit
the EUI64 identifier of some other device and if this fails, uses a
random interface id.

Yoshfuji, do you mind if I apply his patch 5 and "5/5+1"?

Well, I have a question and a comment.

        if (ifp->idev->cnf.forwarding == 0 &&
            (dev->flags&IFF_LOOPBACK) == 0 &&
+           dev->type != ARPHRD_TUNNEL6 &&
            (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
                struct in6_addr all_routers;

Why?

The other end of the tunnel might not yet be set up to receive the packet,
which causes an ICMP error message to be sent back to the sender.

Besides, RS and RA over a ipv6-in-ipv6 tunnel is a _bad_ idea. A default
route through a tunnel without more advanced (policy/flow/srcaddr/? based)
routing schemes can lead to local routing loops.

Who are you to say it's a bad idea?  Users may have a lot of ideas, which 
some may think are bad but are OK.

There is nothing wrong with RS/RA over an IPv6-over-IPv6 tunnel.  I'd 
probably be concerned myself if it wasn't possible.  _However_, that 
doesn't make sense unless you have a more specific route to the 
destination IPv6 tunnel endpoint.

At the moment, I don't know who'd like to get a default IPv6 route over an
IPv6 tunnel, though.. IPv6 VPN users?  MIPv6 users who restrict themselves 
to bidirectional tunneling through the home agent, maybe?

just my 2 cents.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Wed, 3 Sep 2003, Pekka Savola wrote:

On Tue, 2 Sep 2003, Ville Nuorvala wrote:

quoted

ipv6_generate_eui64() derives the interface identifier from the MAC
address on ARPHRD_{ETHER,FDDI,IEEE802_TR,ARCNET} interfaces, but doesn't
do anything for other types of devices

Ok, but then the command should be:

/* try to inherit MAC address from another device, to build an EUI64 */

Ok, I'll update the comment :)

quoted

If the node doesn't have an Ethernet (etc.) NIC it won't get a valid
identifier from ipv6_generate_eui64() and has to resort to something
else, for example generating a random address.

And exactly how often does this happen? Eth (all variants), FDDI, TR,
ARCnet.. what's missing?  Does IPv6 even work with any other physical
interfaces? :-)

Not perhaps physical, but PPP for example. Can we assume _all_ devices
have an Eth, FDDI, TR or ARCnet NIC? I would say no.

Note: it is desirable to have link-local addresses reasonably stable.
Randomizing them may not be the right choice.

They will of course be configured only once when the interface is brought
up :)

-Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

On Wed, 3 Sep 2003, Pekka Savola wrote:

On Wed, 3 Sep 2003, Ville Nuorvala wrote:

quoted

The other end of the tunnel might not yet be set up to receive the packet,
which causes an ICMP error message to be sent back to the sender.

Besides, RS and RA over a ipv6-in-ipv6 tunnel is a _bad_ idea. A default
route through a tunnel without more advanced (policy/flow/srcaddr/? based)
routing schemes can lead to local routing loops.

Who are you to say it's a bad idea?

Someone who has been tackling with the issue of default routes through
tunnel interfaces in MIPL (our MIPv6 for Linux implementation) for quite
some time now ;)

Users may have a lot of ideas, which some may think are bad but are OK.

Well, I did already mention routing loops (and ICMP errors caused by IPv6
encapsulated RSs on a virtual link that isn't up yet). I think that
qualifies as bad enough :(

There is nothing wrong with RS/RA over an IPv6-over-IPv6 tunnel.  I'd
probably be concerned myself if it wasn't possible.

Who says it isn't possible? The user who thinks he knows better can change
the accept_ra (and rtr_solicits) flag for the tunnel dev and start
receiving RAs through it.

_However_, that doesn't make sense unless you have a more specific route
to the destination IPv6 tunnel endpoint.

Yes, exactly. And what should the node do if it just has two default
routes, one through a tunnel and one through an ethernet interface? This
will be the case if a normal host receives RAs through both interfaces.

At least two things can go wrong:
1) A packet intended to the tunnel is sent straight through the ethernet
   device
2) A packet already encapsulated by the tunnel is rerouted through it and
   is thus dropped

Based on my own experiences, I can say things like this do happen.

At the moment, I don't know who'd like to get a default IPv6 route over an
IPv6 tunnel, though.. IPv6 VPN users?  MIPv6 users who restrict themselves
to bidirectional tunneling through the home agent, maybe?

In MIPL, the MN uses a "default" ::/0 route through the IPv6 tunnel, but
it is only used for packets using the MN's home address as source. All
other traffic (including packets already encapsulated by the IPv6 tunnel,
thus having the care-of address as source) is routed normally through the
physical device.

Things like this aren't possible in the current IPv6 routing code, so I
had to modify the route lookup so it first checks the source address of
the packet, then the destination.

I sent a patch for this source address based routing, but it didn't make
it into the kernel, partly because the USAGI team has plans to introduce
IPv6 policy routing, which should also fix the problems.


-Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257

On Wed, 3 Sep 2003 19:57:56 +0300 (EEST)
Ville Nuorvala [off-list ref] wrote:

In MIPL, the MN uses a "default" ::/0 route through the IPv6 tunnel, but
it is only used for packets using the MN's home address as source. All
other traffic (including packets already encapsulated by the IPv6 tunnel,
thus having the care-of address as source) is routed normally through the
physical device.

Things like this aren't possible in the current IPv6 routing code, so I
had to modify the route lookup so it first checks the source address of
the packet, then the destination.

I sent a patch for this source address based routing, but it didn't make
it into the kernel, partly because the USAGI team has plans to introduce
IPv6 policy routing, which should also fix the problems.

Well, it was rejected for another reason :-)

Doing route selection in the way you propose is completely backwards.

Routing engine is asked only where one would like to go, and in
response we are told how to get there and who to advertise ourselves
as (ie. source address selection).

That is, source address selection is a product of the routing lookup
not an input.

The whole engine works this way.  When TCP connects, unless user has
specified a specific source address when bind()'ing the socket, we
take source address from the route.  Source address selection is
routing task.

I do not see what it is about MIPV6 which changes this.  So you either
have to show me this thing, or accept what I say :-)