Message ID | 1364398673.21709.4.camel@localhost |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
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
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
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
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
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
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
--- 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; }