Misc. IPv6 problems

tore · Wed Aug 08, 2012 8:09 am

Hi all,

I have just bought a RouterBOARD 751G-2HnD I am planning to use as a home gateway. Running RouterOS 6.0beta2 (I've also tried 5.19 - didn't solve any of my problems). Nothing fancy about the setup - the default ether1-gateway interface (WAN) is connected to the cable modem provided by my ISP, while the LAN hosts connect to the default bridge-local which consistis of the other wired interfaces and the wireless one. For IPv4, this worked out of the box. For IPv6, however, I've not yet been able to make it work properly due to a number of issues:

Problem 1: RouterOS does not process my ISP's ICMPv6 Router Advertisements (nor does it send Router Solicitations when the WAN interface comes up). Because of this, no default route is being learned, which means it's not really connected to the internet in any useful fashion. The settings under /ipv6 nd appear to me to be related only to the transmission of Router Advertisements (which it obviously need to do on the LAN interface), but I have not been able to figure out where configure the receiving of Router Advertisements on the WAN interface. As a workaround I can hard-code a static route to the link-local address of my ISP's CMTS, but as that is an ugly and fragile hack I'd rather avoid it if possible.

Problem 2: RouterOS' DHCPv6 client does not request an IA_NA lease (single address) for its WAN port. Since my ISP is using only DHCPv6 for address assignment (Managed-flag set to 1 in their Router Advertisements, and no A-flag/SLAAC), this means that the WAN port does get its own global IPv6 address. This is not a huge problem for forwarding of traffic to and from the LAN, but it should ideally have had its own IPv6 address on the WAN interface it should have been using for its own IPv6 communication to the internet.

Problem 3: The DHCPv6 client does not request the DNS Recursive Name Server option (RFC 3646) from the DHCPv6 server. As this is the only way my ISP is advertising their IPv6 DNS servers to their customers, this means that RouterOS does not learn them at all. /ip dns print shows only their IPv4 DNS servers. I could hard-code them, but again, I'd like to make this work properly if possible.

Problem 4: IPv6 address assignment to the LAN interface does not derive the network part of the address from the prefix pool obtained from my ISP using DHCPv6 Prefix Delegation (IA_PD). At http://wiki.mikrotik.com/wiki/Manual:IP ... r_local_RA I find the syntax explained, but it simply doesn't seem to work. The following is all the commands I've entered since resetting RouterOS to the default configuration, and as you can see, acquiring a prefix using DHCPv6-PD works well enough, and the designated pd-from-isp pool gets initialised, but the IPv6 address definition on the bridge-local interface seems to simply ignore the from-pool option:

[admin@MikroTik] > /ipv6 dhcp-client add interface=ether1-gateway pool-name=pd-from-isp pool-prefix-length=64
[admin@MikroTik] > /ipv6 dhcp-client print detail
Flags: D - dynamic, X - disabled, I - invalid
 0    interface=ether1-gateway pool-name="pd-from-isp" pool-prefix-length=64 status=bound prefix=2a02:fe0:cf16:d0::/60 expires-after=1w6d23h59m45s
      duid="00030001d4ca6d4c47c3"
[admin@MikroTik] > /ipv6 pool print detail
Flags: D - dynamic
 0 D name="pd-from-isp" prefix=2a02:fe0:cf16:d0::/60 prefix-length=64 expire-time=1w6d23h59m13s
[admin@MikroTik] > /ipv6 address add interface=bridge-local from-pool=pd-from-isp address=::1/64 advertise=yes
[admin@MikroTik] > /ipv6 address print detail where interface=bridge-local
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
 4 DL address=fe80::d6ca:6dff:fe4c:47bf/64 interface=bridge-local actual-interface=bridge-local eui-64=no advertise=no

 7  G address=::1/64 interface=bridge-local actual-interface=bridge-local eui-64=no advertise=yes

On my Linux host connected to WiFi, you can see the result - RouterOS is advertising this bogus ::/64 prefix to the LAN with the A-flag set (causing SLAAC/autoconf), which leads to utterly bogus IPv6 addresses being added on the host:

linux-laptop$ ip -6 address list scope global dev wlan0
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 ::25e7:acdd:a7cf:493b/64 scope global temporary dynamic
       valid_lft 604569sec preferred_lft 85569sec
    inet6 ::21c:bfff:fe02:f2a5/64 scope global dynamic
       valid_lft 2591856sec preferred_lft 604656sec

I'm new to RouterOS, so it is certainly possible that I've missed something. Has anyone any suggestions on how to solve the above issues?

Tore

Wed Aug 08, 2012 9:53 am

1. Routers do not get addresses from Router Advertisements. They require static configuration

2., 3. Currently we have support only for Prefix Delegation which is mentioned in documentation, no DNS, no NTP no other options.

4. Currently it doesn't work when configured from terminal. You need to configure it in winbox. We will fix it in future versions

tore · Wed Aug 08, 2012 10:29 am

1. Routers do not get addresses from Router Advertisements. They require static configuration

In my case I don't actually want to get an address from the RA (my ISP uses DHCPv6 IA_NA for addressing), but a default route. That said, your statement is certainly not true for SOHO gateways/CPEs - quoting from RFC 6204 «Basic Requirements for IPv6 Customer Edge Routers»:

WAN-side requirements:

W-1: When the router is attached to the WAN interface link, it MUST
act as an IPv6 host for the purposes of stateless [RFC4862] or
stateful [RFC3315] interface address assignment.

W-2: The IPv6 CE router MUST generate a link-local address and
finish Duplicate Address Detection according to [RFC4862] prior
to sending any Router Solicitations on the interface. The
source address used in the subsequent Router Solicitation MUST
be the link-local address on the WAN interface.

W-3: Absent other routing information, the IPv6 CE router MUST use
Router Discovery as specified in [RFC4861] to discover a
default router(s) and install default route(s) in its routing
table with the discovered router's address as the next hop.
[....]

2., 3. Currently we have support only for Prefix Delegation which is mentioned in documentation, no DNS, no NTP no other options.

Okay. That, along with problem 1, unfortunately means that the IPv6 implementation in RouterOS is not nearly complete enough for use as a general-purpose home gateway. Is there any plans to improve this? It should preferably be made compliant with RFC 6204, but at the very least it should be able to connect to an IPv6-capable ISP in the same automatic fashion as it can for IPv4. For what it's worth, the router I intended to replace with the RB751G, a ZyXEL P2812, manages this without any problems at all.

4. Currently it doesn't work when configured from terminal. You need to configure it in winbox. We will fix it in future versions

Okay, thanks. Is there a bug tracking page or similar for this issue I can subscribe to, so that I receive notification when it is fixed?

Tore

tore · Wed Aug 08, 2012 12:00 pm

In my case I don't actually want to get an address from the RA (my ISP uses DHCPv6 IA_NA for addressing), but a default route.
In ROS v5.20 you will be able to enable add-default-route option on DHCPv6-PD client.

There are no public bug tracking services. If you encounter any bugs you should write to support.

Huh, what happened here? I did not write the above post, even though it is attributed to me. My original post, which the above is a reply to, appears to have vanished. mrz - did you accidentally edit my post instead of replying to it? (If so, should I add it back? I still have the text here.)

In any case, add-default-route option on DHCPv6-PD client does not make any sense at all. DHCPv6 does not include any mechanism/option to advertise routes, so it is simply impossible learn the default route (or more-specific routes) from DHCPv6. The only way to dynamically learn the default route on regular Ethernet networks (disregarding the use of routing protocols like RIPng, OSPFv3, and so on) is from interpreting ICMPv6 Router Advertisements.

Tore

Wed Aug 08, 2012 12:43 pm

Yes sorry, wrong "edit" button

As I understood the problem is that after setting DHCP client you don't have default route (no access to internet for clients)?

tore · Wed Aug 08, 2012 1:08 pm

As I understood the problem is that after setting DHCP client you don't have default route (no access to internet for clients)?

I have no default route before enabling the DHCPv6 client, nor do I have one after enabling it. Since DHCPv6 doesn't concern itself with routing, it is not at all surprising that the state of the DHCPv6 client does not change whether or not I have a default route.

The root cause of the problem appears to be that RouterOS simply ignores the Router Advertisements sent by my ISP, and there appears to be no way to enable processing of them. By extension, this means that RouterOS simply has no way it can learn the default route in any standard native IPv6 ISP deployment (at least for plain Ethernet; PPPoE and stuff like that may be different).

One workaround is to manually add the default route, like so: (From memory, as I don't have access to the router from where I'm sitting now.)

/ipv6 neighbor print <--- to find the link-local address of the router, it will have the «R» flag set
/ipv6 route add gateway=<ll-adress of router>%ether1-gateway

This is a hack of course. If my ISP does any changes to their network, say a access router failover, moving my access to another router, changing a line card in their access router, and so on, I will be offline until I manually change the default route to point to the new link-local address.

Also, this prevents me from preconfiguring a router and sending it to a less technical family member of whatever, telling them to "plug and play", since I cannot possibly know in advance which link-local address their default route should use.

Bottom line is: In order to fully support IPv6 as a CE router, RouterOS needs to learn to interpret Router Advertisements from ISPs. RFC 6204 has all the gory details on how it should be done...

(I put back my original post by the way.)

Tore

Wed Aug 08, 2012 2:10 pm

The root cause of the problem appears to be that RouterOS simply ignores the Router Advertisements sent by my ISP, and there appears to be no way to enable processing of them. By extension, this means that RouterOS simply has no way it can learn the default route in any standard native IPv6 ISP deployment (at least for plain Ethernet; PPPoE and stuff like that may be different).

There is no need to process RAs in order to install default route. Consider setup below.

    ISP-GW
        |
      CPE
     /    \
    /      \
client1 client2

ISP-GW has DHCP server which delegates prefix to CPEs.

CPE router (mikrotik) has DHCPv6-PD client. Receives prefix and adds it to the pool. Also if add-default-route is set it will install default route automatically as you mentioned
gateway=<ll-adress of router>%ether1-gateway (this option will be working in ROS v5.20).

client1 and client2 get addresses using stateless config.

If there is something unclear or other suggestions please write to support.

tore · Wed Aug 08, 2012 2:49 pm

There is no need to process RAs in order to install default route. Consider setup below.
Code: Select all
    ISP-GW
        |
      CPE
     /    \
    /      \
client1 client2
ISP-GW has DHCP server which delegates prefix to CPEs.

CPE router (mikrotik) has DHCPv6-PD client. Receives prefix and adds it to the pool. Also if add-default-route is set it will install default route automatically as you mentioned
gateway=<ll-adress of router>%ether1-gateway (this option will be working in ROS v5.20).

client1 and client2 get addresses using stateless config.

If there is something unclear or other suggestions please write to support.

Question: How does the DHCPv6 client know what the next-hop of the default route should be? The answer is: It can't! The DHCPv6 protocol simply does not have an option that specifies the address of the default router. This is one of the key differences between DHCPv4 and DHCPv6. In DHCPv4, Option 3 defines the default router address. In DHCPv6 however, there is no such option, as the equivalent functionality is provided by ICMPv6 Router Advertisements.

There have been some attempts to specify a default router option for DHCPv6 too, for example http://tools.ietf.org/html/draft-droms- ... -router-00. However, none of these have made it to standards track. So again, attempting to use DHCPv6 to discover the IPv6 default route simply isn't the way IPv6 is supposed to work.

The only way I can see this "accidentally" working is if it happens to be the case that the DHCPv6 server/relay is running on the default gateway, so that you can look at the source address in the IPv6 header of the DHCPv6 replies and install a default route pointing to it. The DHCPv6 server/relay function is completely independent from the default router function though, so making such an assumption is fundamentally flawed.

Tore

Wed Aug 08, 2012 3:20 pm

Yes, it knows next-hop address using the same method as in case of Router Advertisements. By looking at source address of received packets from the server.

tore · Wed Aug 08, 2012 3:41 pm

Yes, it knows next-hop address using the same method as in case of Router Advertisements. By looking at source address of received packets from the server.

The difference between Router Advertisements and DHCPv6 packets is the very purpose of a RA is to inform you of the existence of a default router, while a DHCPv6 packet does not have any relation, neither explicit nor implicit, to routing.

Consider a network that looks something like this:

(The IPv6 Internet)
         | 
[ISP Access Router]       [ISP DHCPv6 Server]
       fe80::1                  fe80::2
         |                         | 
         +------------+------------+
                      | 
                [MikroTik HGW]
                      | 
                +-----+------+
                |            | 
           [Client 1]    [Client 2]

RAs will be sent from fe80::1, DHCPv6 replies from fe80::2. If I have understood you correctly, the add-default-route DHCPv6 client option would in this case add a default route to fe80::2. I hope you can see that doing so is simply the wrong thing to do and that just won't work at all. The right next-hop for the default route is fe80::1 - and again, the only way you can find that address is by listening for Router Advertisements.

Tore

frittentheke · Mon Dec 24, 2012 1:44 am

4. Currently it doesn't work when configured from terminal. You need to configure it in winbox. We will fix it in future versions

Just as you said, it's still broken in 6.0rc6. I now successfully set that up using winbox. The main question is, if this will be dynamic to a chaning delegated prefix. So the issue here is not comfort but actual functionality.
My ISP gives out changing prefixes so the address on the internal LAN interface has to change with it.

4. Currently it doesn't work when configured from terminal. You need to configure it in winbox. We will fix it in future versions
Okay, thanks. Is there a bug tracking page or similar for this issue I can subscribe to, so that I receive notification when it is fixed?
Tore

Is there?

Misc. IPv6 problems

Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Re: Misc. IPv6 problems

Who is online