/128 link-local subnet on 6in4 (sit) tunnels?

Hi,

I was trying to get OSPFv3 working on NBMA 6in4 tunnel on linux 3.8, but it does not work. I noticed it uses a /128 fe80 link-local subnet instead of the rfc4213[1]-mandated /64.. This breaks bird (likely for other reasons), but also interoperability with cisco, which mandates OSPFv3 NBMA on link-local addresses.

So I was wondering, is there any particular reason for the use of a /128 link-local or is this just a bug?

Regards,

Wilco Baan Hofman

[1] http://tools.ietf.org/html/rfc4213

Can you show me the commands how you set up the tunnel. It does create /64 ll with embedded ipv4 addresses for me here on v3.8.

Weird, but sure, here goes:

ip tunnel add tunv6-uplink1 mode sit remote 192.168.1.1 local 192.168.1.21
ip link set tunv6-uplink1 up mtu 1472

Also, this patch seems to fix it:

@@ -2487,7 +2487,7 @@ static void sit_add_v4_addrs(struct inet
 	}
 
 	if (addr.s6_addr32[3]) {
-		add_addr(idev, &addr, 128, scope);
+		add_addr(idev, &addr, 64, scope);
 		return;
 	}
 

-- Wilco

In my test I didn't specify the local address so addr.s6_addr32[3] seems to be zero. I'll have to search the RFCs why this is the case.

See section 3.7, rfc4213:

The interface identifier [RFC3513] for such an interface may be based on the 32-bit IPv4 address of an underlying interface, or formed using some other means, as long as it is unique from the other tunnel endpoint with a reasonably high probability.

http://tools.ietf.org/html/rfc4213

-- Wilco

Thanks, I have seen that already. The sit driver is used for more than 6in4 (6to4, isatap, 6rd). So such a change has to be ok with all the other protocols implemented by sit. I also looked in the historic git archive for a rationale of this but couldn't find one. Commit messages 2002 where not as descriptive as today("Import changeset"). :)

I also added YOSHIFUJI Hideaki as Cc, perhaps he knows the reason.

Fair enough, I sort of expected a comment to be there as to why it would be a /128 as well.. :)

-- Wilco

I've been doing some RFC checking of my own..

As far as 6to4 and 6rd go, a link-local address is optional and not very useful at all. ISATAP should have a /64 subnet configured as far as I can tell, same for 6in4.

The link-local address of a 6to4 pseudo-interface performing 6to4 encapsulation would, if needed, be formed as described in Section 3.7 of [MECH]. However, no scenario is known in which such an address would be useful, since a peer 6to4 gateway cannot determine the appropriate link-layer (IPv4) address to send to.

For 6rd, rfc5969 section 9 specifies that a link *may*, if needed, have a non-used link-local address [2], this may be where the /128 comes in:

The 6rd link is modeled as an NBMA link similar to other automatic IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs and BRs defined as off-link neighbors from one other. The link-local address of a 6rd virtual interface performing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213]. However, no communication using link-local addresses will occur.

For ISATAP, it basically states that a link-local should have a "subnet of appropriate length".
rfc5214 section 6.2 refers to rfc4862 [2] for link local addressing:

ISATAP interfaces form ISATAP interface identifiers from IPv4 addresses in their locator set and use them to create link-local ISATAP addresses (Section 5.3 of [RFC4862]).

Which states:

A link-local address is formed by combining the well-known link-local prefix FE80::0 [RFC4291] (of appropriate length) with an interface identifier as follows: >snip<

[1] http://tools.ietf.org/html/rfc3056#section-3.1
[2] http://tools.ietf.org/html/rfc5969#section-9
[3] http://tools.ietf.org/html/rfc5214#section-6.2
[4] http://tools.ietf.org/html/rfc4862#section-5.3

Hm, perhaps this is the reason. Also, RFC3964 ("Security Considerations for 6to4") states that the use of non-global addresses on a 6to4 link should be prohibited:

|   o  Disallow traffic in which the destination IPv6 address is not a
|      global address; in particular, link-local addresses, mapped
|      addresses, and such should not be used.

Could you check if the creation of a /128 ll address does act as a guard against that and does suppress ll traffic? I am not sure.

Perhaps a patch where we check the IFF_POINTTOPOINT flag and selectively create a /128 or /64 would be a solution.

Thanks,

Hannes