Modify

Opened 3 years ago

Closed 3 years ago

#17510 closed defect (fixed)

/60 rather than /64 IPv6 'interface' route created on LAN interface

Reported by: markzzzsmith@… Owned by: developers
Priority: normal Milestone:
Component: base system Version: Barrier Breaker 14.07
Keywords: Cc: cyrus@…

Description

Hi,

Looking at the IPv6 route table on 14.07 rc-1 for the LAN interface, there is a /60 rather than a /64 route out the interface. This means that 16 x /64s are being routed out the LAN interface rather than a single one.

The RA Prefix Information Options in the RAs being sent out the router correctly list single /64s for my global /56 prefix and the ULA prefix.

e.g., for the ULA prefix, the IPv6 route table entry:

root@OpenWrt:~# ip -6 route list | grep fd0f:f1b5:2af::
fd0f:f1b5:2af::/60 dev br-lan proto kernel metric 256
unreachable fd0f:f1b5:2af::/48 dev lo proto static metric 2147483647 error -128
root@OpenWrt:~#

The corresponding correct IPv6 Router Advertisement PIO (from rdisc6 output):

Prefix : fd0f:f1b5:2af::/64

Valid time : 7200 (0x00001c20) seconds
Pref. time : 1800 (0x00000708) seconds

Attachments (0)

Change History (11)

comment:1 Changed 3 years ago by cyrus

  • Cc cyrus@… added
  • Resolution set to not_a_bug
  • Status changed from new to closed

You can adapt this behaviour by changing the option ip6assign value in /etc/config/network.

We assign a /60 by default to an interface so we can subdelegate all but the first /64 out of that via DHCPv6-PD to downstream routers if they request a prefix.

Add.: once a router get's a delegated prefix out of the pool another route is added which then takes precedence over the /60.

Last edited 3 years ago by cyrus (previous) (diff)

comment:2 Changed 3 years ago by markzzzsmith@…

  • Resolution not_a_bug deleted
  • Status changed from closed to reopened

If the more specific /64 route prefix is created when delegated to a downstream router, then there is no purpose to the /60. All it will do is cause problems. This is completely inconsistent with how IPv6 routing is configured, which is why I reported it. I've done a lot of work with IPv6+, if it is confusing to me then it will be confusing to people who don't understand it nearly as well as I do.

For example, attempting to ping a non-existent existent address on a non-existent prefix should cause the router to generate a destination unreachable message. For /64s outside of this /60 OpenWRT does (due to 'unreachable' /48), but for non-existent prefixes within the /60 it doesn't. e.g.,

[mark@opy ~]$ ping6 fd0f:f1b5:2af:000f::1
PING fd0f:f1b5:2af:000f::1(fd0f:f1b5:2af:f::1) 56 data bytes
C
--- fd0f:f1b5:2af:000f::1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

[mark@opy ~]$ ping6 fd0f:f1b5:2af:0010::1
PING fd0f:f1b5:2af:0010::1(fd0f:f1b5:2af:10::1) 56 data bytes
From fd0f:f1b5:2af::1 icmp_seq=1 Destination unreachable: No route
C
--- fd0f:f1b5:2af:0010::1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

[mark@opy ~]$

Silent failure can cause long application timeouts that create bad user experiences. This causes them unnecessarily.

+ And have worked with IPv6 CPE vendors and presented on what not to do:
"IPv6 CPE - What Not To Do and Other Observations"
http://www.ausnog.net/sites/default/files/ausnog-05/presentations/ausnog-05-d02p02-mark-smith.pdf

comment:3 Changed 3 years ago by cyrus

OK, you are right. I will put it on the TODO for post-BB. The problem is that setting custom on-link routes is very broken before linux 3.14. Once we have that, I can easily fix the on-link route and set it to /64 here.

Last edited 3 years ago by cyrus (previous) (diff)

comment:4 Changed 3 years ago by cyrus

Interesting slides btw. I've tried to make OpenWrt compliant with RFC 6204 and 7084 wherever possible. If you run into any other quirks like this, please let me know. FYI we are also working on some of the stuff from IETF's homenet WG.

comment:5 Changed 3 years ago by markzzzsmith@…

I don't think it should be necessary to create custom on-link routes. The /64s on-link routes should be created automatically when then the address is configured with a prefix length of /64. e.g,

root@OpenWrt:~# ip -6 addr add fd0f:f1b5:2af:ff00::1/64 dev br-lan
root@OpenWrt:~# ip -6 addr show dev br-lan | grep fd0f:f1b5:2af:ff

inet6 fd0f:f1b5:2af:ff00::1/64 scope global

root@OpenWrt:~# ip -6 route show | grep fd0f:f1b5:2af:ff
fd0f:f1b5:2af:ff00::/64 dev br-lan proto kernel metric 256
root@OpenWrt:~#

Not specifying the /64 on the address seems to make the 'ip' tool assume a /128 (which I think is reasonable), could that be why people think automatic creation of the corresponding /64 on-link route is broken in prior versions of Linux?

comment:6 Changed 3 years ago by markzzzsmith@…

I also noticed that IPv6 on the WAN interface isn't enabled by default, at least with PPP/PPPoE. That should be safe to do (and I'd encourage it), because there are two mechanisms that will should prevent it causing trouble.

Firstly, the ISP's BRAS/BNG/NAS should generate an PPP LCP Protocol Reject if the client attempts to start a Network Control Protocol (like IPV6CP or IPCP for IPv4) that the BRAS/BNG/NAS doesn't support. This would cause further negotiation of IPv6 to cease.

Secondly, there have been issues with CPEs locking up when the BRAS/BNG/NAS has pro-actively attempted to bring up IPv6 and the CPE doesn't support it. In that case the CPE was broken, it should have been generating PPP LCP Protocol Rejects. However, as a work around, ISPs can make their BRAS/BNG/NAS 'passive' regarding NCP negotation. For these broken CPEs, they would only attempt to bring up IPCP and therefore would not cease up.

I can lodge another ticket for this feature if it would be better.

comment:7 Changed 3 years ago by cyrus

No the problems are actually a bit more tricky. I actually filed a bug against the kernel here which describes and fixes the issue http://patchwork.ozlabs.org/patch/320782/ but was rejected.

The core source of the trouble is that we handle RAs entirely in userspace to make our uplink routes source-restricted, so that we can do multihoming with IPv6 correctly (avoiding traffic going out an uplink with a source from another uplink's delegated prefix). Thus we need to deal with quirky and inconsistent netlink behavior as described above.

The reason for the /60 hack is that in order for the DHCPv6-server to be aware of changes of addresses and available prefixes for RA, IA_NA and IA_PD (so we can trigger sending RAs or send DHCPv6-Reconfigure etc.) we need a communication channel and I just let the server watch kernel netlink events here. Anyway I will change the on-link routes to /64 then your concerns are addressed and the DHCPv6 server is still happy.

comment:8 Changed 3 years ago by markzzzsmith@…

I'd need to understand the problem better to comment on it. It seems you're saying that if you delete an IPv6 address from an interface, the automatically created /64 hangs around?

While on face value that would seem incorrect, however it is quite possible for a device to know a /64 prefix is on-link but not to have any addresses from within it. Alternatively, it is possible for a host to have an address from within a /64, but to assume all other destinations within that /64 are off-link (with exception to the link-local prefix) This is better explained and clarified in:

IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
http://tools.ietf.org/html/rfc5942

This actually makes the assumption of a /128 when adding a static address via 'ip -6 address add <blah>' with no prefix specified consistent with that RFC. It specifically states that configuring a static IPv6 address on an interface should not automatically create an assumed /64 on-link prefix route.

One other thought in this area. I think there are three separate IPv6 related addressing functions:

  • address or rather IID generation methods - e.g., use MAC address, or hash as per RFC7217 opaque IDs
  • address configuration methods - currently SLAAC, DHCPv6 or static
  • address expiry methods - currently address aging via preferred and valid lifetimes

If you're having trouble with the last one, one trick would be to manually set the preferred and valid lifetimes to deprecated values, so that the host avoids using them if there are better addresses to use, as per RFC3484/RFC6724.

comment:9 Changed 3 years ago by markzzzsmith@…

Regarding homenet, I'd like to have participated in that, however I just don't have enough time. v6ops and 6man keep me busy enough.

I have written up an Internet Draft that discusses a topic relevant to it (and routers running DHCPv6 clients in general), which is why it isn't homenet specific, even though I started out from that POV.

IPv6 CE Device DHCPv6 Option Transparency
http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00

comment:10 Changed 3 years ago by cyrus

No the issue I'm talking about is not an issue of understanding IPv6. I know most of the trickery regarding on-link and off-link and DHCPv6 clients not honoring that or not honoring lifetimes etc. and were having lots of fun with it until I decided I was just sick of it wrote DHCPv6 and RA clients, servers and relays from scratch for OpenWrt.

The on-link route bug I'm talking about can actually be recreated very easily:

ip a a 2001:db80::1/64 dev eth0 valid_lft 1200 preferred_lft 600
ip a d 2001:db80::1/64 dev eth0
ip -6 r l dev eth0

You will see that while the address gets removed by the second call the on-link route still remains. Omit the valid_lft and preferred_lft in the first call and the second call with remove both address and on-link route correctly. One of the many funny IPv6 issues in the linux kernel, besides IPV6_PKTINFO sometimes not working for RAW-sockets, Linux not accepting MSRs / Route Info Options by default for no objective reason etc. etc.

Interesting matter in the draft though I don't really like the relaying approach. FYI we try to handle the issue in homenet as well. See http://tools.ietf.org/html/draft-ietf-homenet-hncp-01 (which I co-authored) and a colleague's draft http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02 where (as one out of many aspects) we pick-up dhcpv6-options from uplinks and share and announce them to clients in the whole homenet. Of course you can run into clashes when you have multiple uplinks with conflicting information but that's something for the mif-workinggroup to figure out. There is just no good solution for that atm.

As for PPP and IPv6, I've enabled IPv6CP in trunk by default now (see r42158) but won't do it for the BB-release since there are some weird ISP servers that just kill the whole PPP session when they encounter an IPv6CP handshake, so I want to see the actual effects in our unstable branch before hand. In the BB-branch you simply have to set:
option ipv6 1 in the PPP-section in addition to having the wan6-interface section which triggers our RA / DHCPv6 client to be run on-top.

comment:11 Changed 3 years ago by cyrus

  • Resolution set to fixed
  • Status changed from reopened to closed

Initial issue fixed in r42161.
Prefix assignments bigger than /64 (e.g. /60) are now created with a /64 on-link route.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.