diff mbox

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

Message ID 1364398673.21709.4.camel@localhost
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Wilco Baan Hofman March 27, 2013, 3:37 p.m. UTC 
On Wed, 2013-03-27 at 16:12 +0100, Hannes Frederic Sowa wrote:
> On Tue, Mar 26, 2013 at 11:04:17PM +0100, Wilco Baan Hofman wrote:
> > So I was wondering, is there any particular reason for the use of a /128
> > link-local or is this just a bug?
> 
> 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:

-- Wilco

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Hannes Frederic Sowa March 27, 2013, 6:11 p.m. UTC | #1 
On Wed, Mar 27, 2013 at 04:37:53PM +0100, Wilco Baan Hofman wrote:
> 
> On Wed, 2013-03-27 at 16:12 +0100, Hannes Frederic Sowa wrote:
> > On Tue, Mar 26, 2013 at 11:04:17PM +0100, Wilco Baan Hofman wrote:
> > > So I was wondering, is there any particular reason for the use of a /128
> > > link-local or is this just a bug?
> > 
> > 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

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wilco Baan Hofman March 27, 2013, 6:20 p.m. UTC | #2 
On Wed, 2013-03-27 at 19:11 +0100, Hannes Frederic Sowa wrote:
> On Wed, Mar 27, 2013 at 04:37:53PM +0100, Wilco Baan Hofman wrote:
> > 
> > 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
> 
> 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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hannes Frederic Sowa March 27, 2013, 6:35 p.m. UTC | #3 
On Wed, Mar 27, 2013 at 07:20:54PM +0100, Wilco Baan Hofman wrote:
> 
> 
> On Wed, 2013-03-27 at 19:11 +0100, Hannes Frederic Sowa wrote:
> > On Wed, Mar 27, 2013 at 04:37:53PM +0100, Wilco Baan Hofman wrote:
> > > 
> > > 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
> > 
> > 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

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wilco Baan Hofman March 27, 2013, 7:12 p.m. UTC | #4 
On Wed, 2013-03-27 at 19:35 +0100, Hannes Frederic Sowa wrote:
> On Wed, Mar 27, 2013 at 07:20:54PM +0100, Wilco Baan Hofman wrote:
> > http://tools.ietf.org/html/rfc4213
> 
> 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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wilco Baan Hofman March 28, 2013, 1 p.m. UTC | #5 
On Wed, 2013-03-27 at 19:35 +0100, Hannes Frederic Sowa wrote:
> On Wed, Mar 27, 2013 at 07:20:54PM +0100, Wilco Baan Hofman wrote:
> > http://tools.ietf.org/html/rfc4213
> 
> 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.
> 


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.

From rfc3056 section 3.1 [1]:

   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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hannes Frederic Sowa March 28, 2013, 1:12 p.m. UTC | #6 
On Thu, Mar 28, 2013 at 02:00:38PM +0100, Wilco Baan Hofman wrote:
> 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.
> 

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- linux-3.8.3.orig/net/ipv6/addrconf.c
+++ linux-3.8.3/net/ipv6/addrconf.c
@@ -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;
 	}