D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-860L => Topic started by: v6 on January 13, 2014, 06:44:55 AM
-
Hi :-)
I just bought this wonderful 860L with hardware version A1 and I updated the firmware version to 1.05 (from DIR860LA1_FW105b02.bin which I downloaded through the "Check Online Now for Latest Firmware Version" function on the firmware page in 860L) since it was born with 1.01.
I did a factory reset after upgrading to firmware version 1.05.
I live in Denmark/Europe.
I have a problem regarding ipv6.
The problem is that the clients cannot access ipv6 outside of the LAN.
The strange thing is that the 860L itself is able to do that through IPv6 ping (Tools - Systemcheck) e.g. ipv6.google.com works. Result: "ipv6.google.com is alive!"
(and the 860L can of course also ping its clients.)
I am aware that the router itself has a WAN IPv6 Address, which it might use instead of its LAN IPv6 address, to get ping6 working.
The router is as well given a /64 subnet with DHCP-PD from which it can give the LAN clients addresses (but yet it does not work.)
I have tried different things regarding the IPv6 firewall in the 860L without getting it to work however my thoughts are, that if "Enable IPv6 Simple Security" is disabled and "Turn IPv6 Filtering OFF" is selected then it should work without a hazzle, however - it does not.
I haven't touched IPv6 routing (inside 860L) at all since I understand that it is only for cases where you would want to route somewhere else than to the default gateway.
I have tried all the 3 options available for the client computers for autoconfiguration: SLAAC+RDNSS, SLAAC+Stateless DHCP, Stateful DHCPv6.
The client was given some addresses (or autoconfigured itself regarding SLAAC vs Stateful DHCPv6) in each case however none of those made ipv6 work outside of the LAN.
Now, I run Ubuntu 12.04 and IPv6 works just fine if I plug the ethernet cable from the computer into the wall socket (my ISP). Then http://test-ipv6.com/ passes just fine with 10/10.
Now, to make sure that a random address within the DHCP-PD range (that the 860L was given before I unplugged the ethernet cable from the wall socket) actually does work I have manually/statically added a random address into my computers ipv6 configuration while it is still directly connected to my wall socket. And it works! Both a very, very low number as well as a high one for instance someprefix:ffff:ffff:ffff:ffff works!
Besides that my Ubuntu firewall was disabled during all tests.
So my question is - have I done something wrong, can I supply you with more information or might there be a bug somewhere?
I have added some pictures - maybe they are useful for finding the problem! :-)
Thanks in advance for helping me!
(http://s10.postimg.org/ubc4waqif/image.png)
(http://s10.postimg.org/iky7ewxpz/image.png)
(http://s10.postimg.org/qt04zwpmf/image.png)
-
Link>Welcome! (http://forums.dlink.com/index.php?topic=41537.0)
- Was a Factory Reset performed before and after any firmware updates then set up from scratch?
- Was the router working before any firmware updates?
Internet Service Provider and Modem Configurations
- What ISP Service do you have? Cable or DSL?
- What ISP Modem Mfr. and model # do you have?
- What ISP Modem service link speeds UP and Down do you have?
- Check ISP MTU requirements, Cable is usually 1500, DSL is around 1492 down to 1472. Call the ISP and ask. Link>Checking MTU Values (http://forums.dlink.com/index.php?topic=53008.0)
Do other types of connections work for IPv6 under the Setup/IPv6, there are several other connection types listed.
Did you use the IPv6 connection wizard to set it up?
-
Link>Welcome!
Thank you!
> Was a Factory Reset performed before and after any firmware updates then set up from scratch?
No. I unboxed the router changed the LAN network to 10.3.2.x, because my ISP uses 192.168.0.x on the routers (860L) WAN side. Besides that I only set the "host name" and "local domain name". I did not use the setup wizard.
Right after that I checked for new firmware and saw that 1.05 was out (in contrast to 1.01).
Maybe it was foolish of me, but I thought why deal with older firmware if bugs and features have been fixed in the newer firmware.
The only time I ran factory reset was after the update to 1.05.
> Was the router working before any firmware updates?
I did not check whether wireless, ipv6 or anything else was working. I had only the firmware update on my mind before setting up the rest.
If you think it is an idea I can try to downgrade, if the router lets me downgrade?
> Internet Service Provider and Modem Configurations
> What ISP Service do you have? Cable or DSL?
Actually it is neither in my case. It is ethernet.
> What ISP Modem Mfr. and model # do you have?
My ISP is using pfSense 2.1 (http://pfsense.org/) because my ISP has a 100/100 Mbit/s fiber connection that 28 houses are sharing.
> What ISP Modem service link speeds UP and Down do you have?
100/100 Mbit/s
> Check ISP MTU requirements, Cable is usually 1500, DSL is around 1492 down to 1472. Call the ISP and ask. Link>Checking MTU Values
I know the guy/ISP, so I asked him. He tells that the interface (of the ISP router that my 860L sees) uses MTU of 1500. And the cisco switches we use (SLM248G - http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9994/ps10003/data_sheet_c78-504112.pdf ) follows some 802.3u standard meaning (at least) MTU of 1500 if I am not mistaken.
I also tried your "Checking MTU Values" link:
ping -M do -s 1472 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 1472(1500) bytes of data.
1480 bytes from 192.168.0.3: icmp_req=1 ttl=64 time=2.00 ms
1480 bytes from 192.168.0.3: icmp_req=2 ttl=64 time=1.91 ms
1480 bytes from 192.168.0.3: icmp_req=3 ttl=64 time=1.90 ms
1480 bytes from 192.168.0.3: icmp_req=4 ttl=64 time=1.87 ms
1480 bytes from 192.168.0.3: icmp_req=5 ttl=64 time=1.88 ms
1480 bytes from 192.168.0.3: icmp_req=6 ttl=64 time=1.93 ms
1480 bytes from 192.168.0.3: icmp_req=7 ttl=64 time=2.13 ms
^C
--- 192.168.0.3 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6009ms
rtt min/avg/max/mdev = 1.877/1.952/2.135/0.090 ms
, where 192.168.0.3 is the ISP router, "-M do" which is a hint where "do" means "prohibit fragmentation, even local one" according to "man ping" in Ubuntu. And "-s 1472" is the packet size. It seems to work fine and and 1472+28=1500.
If I for instance try with: ping -M do -s 1474 192.168.0.3
, I get: From 10.3.2.100 icmp_seq=1 Frag needed and DF set (mtu = 1500)
> Did you use the IPv6 connection wizard to set it up?
No, I did not.
I have tried it know however. The wizard went on for some time before it finally said it had configured itself.
It has chosen to use SLAAC+Stateless DHCP. But still it does not work.
The strange thing I noticed (just after the wizard ran) is that the "STATUS - IPV6 ROUTING" shows 5 entries.
But now after a minute or two have passed there is now only 4 left. The one that vanished is the top one (the one with Metic 0). But with the same result of no ipv6 connection.
> Do other types of connections work for IPv6 under the Setup/IPv6, there are several other connection types listed.
The only logical other option for me to try is to use "Static IPv6".
So I have tried that since my last post.
Making the WAN configuration static however made no change. I configured it so that "Use Link-Local address" is disabled and the WAN ipv6 address is within the right subnet and I can ping it from the outside.
The subnet prefix length is 48. And both default gateway and primary dns is that of my ISPs router.
Besides that, no change in configuration. But that does also not make ipv6 work.
I have also tried to see if I could get a Windows Vista computer online.
The same happens. Vista gets the configuration from the router, but never gets outside of the LAN.
I hope my answers make sense. :-)
Thank you once again for helping!
-
- If the router isn't getting a public IP address, it's possible this could be the cause connection problems: Link>Double NAT (http://www.practicallynetworked.com/networking/fixing_double_nat.htm) and How NAT Works (http://cognitiveanomalies.com/cisco-nat-how-nat-works/). To tell if the modem is bridged or not, look at the routers web page, Status/Device Info/Wan Section, if there is a 192.168.0.# address in the WAN IP address field.
-
Thank you for your answer FurryNutz.
I have read both the pages you linked to.
There is no problem in getting IPv4 to work. It works without a problem on both 860L and on my old D-Link DI-524.
There is only a problem in getting IPv6 to work. IPv6 does not utilize NAT at all, so there should not be any double NAT problem at all.
My ISP has native IPv6 (meaning he is not using a tunnelbroker like Hurricane Electric https://tunnelbroker.net/ or the like) and again we do not use modems, dsl or the like, but plain ethernet and rj45 wall plugs.
I am wondering about the best way to get in contact with D-Link and file e.g. a bug report if that is possible.
Do you know what the best way is?
Thanks once again! :-)
-
To rule out any issues with the ISP modem, I would recommend testing the router out in a configuration with your ISP modem so the router can be in a single NAT condition just to make sure that your ISP modem isn't doing anything suspicious. Just to be sure.
Does your router have True Gigabit Routing option under Setup/Internet/Manual settings?
The best way to get in contact with D-Link is on the phone with your regional office for immediate help and information.
-
I have checked and there is no such "True Gigabit Routing" option.
Curious to find out what this option is I made a google search and found a manual for the DIR-826 (DIR_826L_MANUAL_EN_UK.pdf).
Here I could see what the option looks like.
So I can confirm that there is no such option on the 860L with firmware 1.05 (regardless whether I choose Static IP or Dynamic IP (DHCP)).
Regarding trying the 860L on my ISPs internet connection I will try asking him if I could be allowed to test it after midnight (so I will avoid making any trouble for most of the users of our ISP).
The ISP fiber connection is delivered by a Cisco ME3400-2CS switch (and through other switches directly to the houses). I will ask our ISP/the guy I know if I can connect the 860L directly to the Cisco ME3400-2CS switch just to rule out problems with other equipment.
Both IPv4 and IPv6 will have to be statically configured on the 860L when connected directly to the Cisco switch.
It is likely that I will first be able to make the test in a couple of days. But if you until then have other suggestions for now or for the "ISP test" just tell me. :-)
Thank you for helping!
-
Yes, TGR is only in a few different model routers and isn't seen in all of them. I was wondering if yours had this option that maybe this could be a factor, and it's not. ::)
Let us know what you and the ISP can do to test this. I'll have another IPv6 person review this and offer any other help for you...as I'm running out of ideas. :-\
Keep us posted. :)
-
Hi,
a few weeks ago a wrote some description about how to configure IPv6, see here (http://forums.dlink.com/index.php?topic=56778.msg221409#msg221409). Although it is for a DIR-655 router it is probably not too far away from your model because D-LINK's IPv6 implementation is similar in any newer devices. Please check if it is conducive to you.
Anyway it might be helpful to reveal some more details:
WAN IPv6 address + Prefix length (/48?) ?
IPv6 default gateway address at your ISP ?
IPv6 DNS server address(es) of your ISP ?
LAN IPv6 prefix XXXX:XXXX:XXXX:XXXX::/64 ?
For some example LAN client:
IPv6 address + Prefix length (should be 64)
IPv6 default gateway (with SLAAC it should be the link local address of your router fe80::...) ?
DNS server IPv6 address(es) ?
Are your clients configured to listen to and accept Router Advertisements (RA) for autoconfiguration? As far as I know Linux/Unix machines offer some configuration switches which you can use to modify their reaction on RA, for example they might only evaluate RA in order to learn a default gateway and advertised onlink prefixes but refuse to use an advertised prefix for address autoconfiguration.
PacketTracer
-
Hi
Sorry for the radio silence. I had some things that needed my attention. But I have tried to approach a solution to the problem in different ways.
I have also read your advice.
Regarding 'to reveal' the IPv6 addresses I am not too thrilled about it, but the answers to your questions:
WAN IPv6 address + Prefix length (/48?) ?
(WAN side of the 860L I assume) e.g. 2a02:188:4401:0::abcd /48
(Well, a /48 address that looks like a /64. Explanation follows below.)
IPv6 default gateway address at your ISP ?
2a02:188:4401::1
IPv6 DNS server address(es) of your ISP ?
2a02:188:4401::1 (only reachable from within my ISPs network)
LAN IPv6 prefix XXXX:XXXX:XXXX:XXXX::/64 ?
(LAN side of the 860L I assume) /64
For some example LAN client:
Everything provided by SLAAC+RDNSS. It seems to work fine in Ubuntu. In Windows Vista SLAAC+Stateless DHCP for instance.
Info provided below, (which should be enough to provide access.)
IPv6 address + Prefix length (should be 64)
2a02:188:4401:3fff:b16a:xxxx:xxxx:d6ae /64
IPv6 default gateway (with SLAAC it should be the link local address of your router fe80::...) ?
It is: fe80::c2a0:xxxx:xxxx:1418
DNS server IPv6 address(es) ?
2a02:188:4401::1
If you want the full addresses I can send it as a PM to you.
And yes, my client computers are configured to listen to RA. I am unfamiliar with how to configure the Linux client to refuse to use an advertised prefix for address autoconfiguration. However when I lookup the address given to the client e.g. through NetworkManager or "ifconfig -a", then it is always
1) a /64 if 860L configures my computer
or
2) e.g. /48 if my ISPs routing software (pfSense) configures my computer (but _as a side note_ if my ISPs routing software is configured to use a DHCPv6 scope to be less than a /64 subnet my client computers seems to be given a /128 prefix, but I can reach the internet and local LAN ISP addresses anyway. If DHCPv6 scope inside my ISP LAN is /64 then my Linux client also registers a /64 prefix).
Is that the answer you sought?
The tests:
First of all. Now I have done the "ISP test" where I had the 860L directly connected to the fiber switch of my ISP.
The first obstacle was that the network offered was a /48 subnet (through a /64 WAN subnet).
(The /48 subnet is the subnet my ISP is offered from the ISP of my ISP.)
The 860L is sold as a home product, so I understand why the 860L only operates in a /64 subnet for its client computers on the LAN side.
But what I then did in the test was to use the /48 subnet as if it was a /64 subnet.
So the WAN side of the ISP was then /64 as well as the LAN of the ISP was /64 (both sides connected to the 860L).
Effectively that also meant that I now only had 1 out of 65k subnets available, but it would suffice for the test if it worked...
This setup seemed to work! http://test-ipv6.com/ test was passed with 10/10. So there was IPv6 connectivity on the 860L. I tested it on my old IBM T43 with an ethernet cable connected to the 860L at the ISP site. My T43 runs Ubuntu 13.10. I also use my T43 to perform tests at home regarding the IPv6 connectivity. I took pictures with my camera to document the IPv4+IPv6 connectivity (PM me I you would like to have some of those pictures). Besides that I used googles DNS servers 2001:4860:4860::8888 and 2001:4860:4860::8844.
Guess 1:
My very best guess is that perhaps there is a bug in the 860L 1.05 firmware that cannot handle that its WAN side is a /48 subnet. /48 is the case in my setup. (E.g. if I put a cable directly from my wall outlet from my ISP at home to one of my computers then IPv6 works fine in the /48 environment.)
At the place where we live (these 28 houses) we need a subnet like /48 or /56 because each home should be able to have its own /64 subnet - but that means that each home router has to be able to live within a /48 WAN environment, also because there might for instance be connections between the houses.
So the main problem is (I think) what I have just described. Below is simply my thoughts about how to try to "convince" the 860L to give me IPv6 access anyway - although I was unsuccessful (also tested on Windows Vista):
-------------------
This test was about trying to mimic a /64 WAN (from the perspective of home routers) inside the network of my ISP (instead of a /48 subnet). We have tried to move the DHCPv6 address range at my ISP down so it can fit within a /64 subnet (meaning that the gateway on the LAN side of the ISP shares a /64 range with the DHCPv6 addresses that the home routers WAN sides will get), but still advertising DHCP-PD with address ranges inside the /48 subnet. The thought was, that we might get the 860L to work in such an environment.
First I tried to configure the 860L accordingly to what I just described. I had no success with that. I could not pass the WAN side of the 860L from within the router and out to the Internet or the LAN of my ISP.
Secondly I tried to configure the WAN side of the 860L statically regarding IPv6 (since it had worked in the "ISP test" although the conditions were different (The ISP WAN side is a true /64 subnet)). In this case I can only traceroute until and including the WAN side IP address of the 860L - meaning I try to traceroute (Windows tracert) from within the router and out to the Internet or the LAN of my ISP but unsuccessfully.
-------------------
Guess 2:
Although guess 1 seems most likely to me I have also had another thought. In the router software pfSense there is the term "bogon networks" see this wiki article http://en.wikipedia.org/wiki/Bogon_filtering :
"Bogon filtering is the practice of filtering bogons, which are bogus IP addresses. Bogon is also an informal name for an IP packet on the public Internet that claims to be from an area of the IP address space reserved, but not yet allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated Regional Internet Registry (RIR). The areas of unallocated address space are called the bogon space."
My question: Could it be 1) that the DIR-860L and perhaps other D-Link routers also use such lists and 2) that these lists are not updated to the recent situation?
It seems however unlikely since 2a02:188:4401 is part of the ISPs (parent) ISP network (and that network worked in the "ISP test" mentioned above), but well a guess. A list can be seen here: http://6session.wordpress.com/2009/04/08/ipv6-martian-and-bogon-filters/ and among other things it can be seen that "currently" (if the list on the page is up to date then) e.g. 2a10::/12 is a bogon, but 2a02 should not be.
Is it likely that the D-Link engineers can fix the problem with the information I have given so far?
Or what can I do as the next step?
In any case if I can help solve the problem (either with you or the D-Link engineers) then that is fine with me. I understand and write English, German and Danish.
Once again thanks for helping me! :-)
-
Hi v6,
I had to read all the information of all your posts several times in order to figure out what exactly your scenario is and I'm still not sure if I understood things right:
> What ISP Service do you have? Cable or DSL?
Actually it is neither in my case. It is ethernet.
... my ISP has a 100/100 Mbit/s fiber connection that 28 houses are sharing
The ISP fiber connection is delivered by a Cisco ME3400-2CS switch (and through other switches directly to the houses
Is my interpretation correct that 28 houses would use 28 CPEs (e.g. of type D-Link DIR-860L) whose WAN uplinks are plugged to the same L2 fiber network sharing the same IPv6 network [1]? Or do you (or rather your ISP) use e.g. VLAN or some pseudo wire technique to form dedicated point-to-point uplinks from CPE to ISP edge isolated from each other and each one having its own IPv6 network (usually a /64 or according to RFC6164 (http://tools.ietf.org/html/rfc6164) even a /127 if supported by both ends of the connection) [2]?
At the place where we live (these 28 houses) we need a subnet like /48 or /56 because each home should be able to have its own /64 subnet - but that means that each home router has to be able to live within a /48 WAN environment, also because there might for instance be connections between the houses.
I can't follow your argumentation: In a shared environment (case [1] above) a single /64 for the WAN IPv6 network the CPEs are connected to is more than enough to address 28 devices out of an address space of size 2^64 of a single /64. In case [2] you would only need one /64 (or one /127 if RFC6164 (http://tools.ietf.org/html/rfc6164) is supported) per CPE/point-to-point uplink respectively.
WAN IPv6 address + Prefix length (/48?) ?
(WAN side of the 860L I assume) e.g. 2a02:188:4401:0::abcd /48
IPv6 default gateway address at your ISP ?
2a02:188:4401::1
IPv6 DNS server address(es) of your ISP ?
2a02:188:4401::1
For some example LAN client:
Everything provided by SLAAC+RDNSS. It seems to work fine in Ubuntu. In Windows Vista SLAAC+Stateless DHCP for instance.
IPv6 address + Prefix length (should be 64)
2a02:188:4401:3fff:b16a:xxxx:xxxx:d6ae /64
IPv6 default gateway (with SLAAC it should be the link local address of your router fe80::...) ?
It is: fe80::c2a0:xxxx:xxxx:1418
DNS server IPv6 address(es) ?
2a02:188:4401::1
"
Comments:
- Your WAN uplink uses 2a02:188:4401::/48. Why such a huge address range? A /64 would be more than enough; see my arguments above.
- Your LAN prefix is 2a02:188:4401:3fff::/64 which is a subrange of your WAN range 2a02:188:4401::/48. While this might theoretically work if router implementations and configuration are sophisticated (e.g. the ISP edge router's routing table has to have an entry for 2a02:188:4401::/48 as directly attached network and a more specific route for the subrange 2a02:188:4401:3fff::/64 needed to forward packets with destination addresses within this range to the WAN address of your CPE) I don't think this configuration is a good idea and might confuse the CPE. Usually one would use IPv6 prefixes for WAN and LAN that are mutually exclusive (having no subrange in common or one not being a subrange of the other).
The /48 subnet is the subnet my ISP is offered from the ISP of my ISP.
So when you say "the subnet" instead of "a subnet" does that mean your ISP only got delegated a /48 out of a possibly /32 delegated via a LIR or RIR to your ISP's ISP? Hence your ISP would be a very small one or this single /48 is for a testbed for a future IPv6 rollout?
Given my conclusions a right so far one could construct for example the following addressing model to subdivide your ISP's /48 (assuming 2a02:188:4401::/48) to provide IPv6 access to up to 254 customers each one getting a /56:
- Set aside the block 2a02:188:4401::/56 for ISP internal purposes. This results in 256 /64 networks for use inside your ISP's network.
- Set aside the block 2a02:188:4401:100::/56 for WAN uplinks from the customer's CPEs to your ISP's edge router. Your can form up to 256 /64 uplink networks (2a02:188:4401:100::/64, 2a02:188:4401:101::/64, 2a02:188:4401:102::/64, ..., 2a02:188:4401:1ff::/64) from this range where you only need one in case [1] and 28 in case [2] as mentioned above.
- Use the rest of the /48 address range to deploy up to 254 /56 blocks via DHCP-PD to your customers for use inside their LANs: 2a02:188:4401:200::/56, 2a02:188:4401:300::/56, 2a02:188:4401:400::/56, ... , 2a02:188:4401:ff00::/56
For example: Your ISP would use 2a02:188:4401:1ff::/64 for the WAN uplink from your CPE to your ISP's edge router, your CPE using 2a02:188:4401:1ff::2 and your ISP's router using 2a02:188:4401:1ff::1 (simultaneously being the DNS server address). He might delegate the block 2a02:188:4401:ff00::/56 via DHCP-PD for use inside your LAN. Your CPE would take for example (implementation dependent) the first /64 out of this block (2a02:188:4401:ff00::/64) and use it for address autoconfiguration inside your LAN (usually via SLAAC+stateless DHCPv6). Your ISP's edge router would have the follwing entry in its routing table: 2a02:188:4401:ff00::/56 next hop: 2a02:188:4401:1ff::2
By the way from some other of your remarks I feel the urge to tell the following general rules:
- Receiving an IPv6 block of size greater than /64 (greater = shorter prefix length, e.g. /56) via DHCP-PD will not mean, that the CPE would deploy it to a single attached LAN. Rather, as /64 is the standard size of any IPv6 network (RFC4291 (http://tools.ietf.org/html/rfc4291#section-2.5.1), Chapter 2.5.1: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format". Exceptions: /127, see RFC6164 (http://tools.ietf.org/html/rfc6164), or statically configured IPv6 addresses with embeddes IPv4 addresses resulting from IP4v/IPv6 address translation, see RFC6052 (http://tools.ietf.org/html/rfc6052)) and hence SLAAC (RFC4862 (http://tools.ietf.org/html/rfc4862)) only works with /64 networks, the CPE will subdivide the delegated block (e. g. a /56) into several /64, namely one per directly attached LAN segment (in most cases meaning only one) and might use the rest of the unused address space for deployment of smaller subranges (e.g. /60) to "second hierarchy" routers that connect to additional lan segments.
- In contrast to DHCPv4 statefull DHCPv6 will only deploy /128 addresses without any prefix length (subnet mask in IPv4) and default gateway information. Hence in addition to DHCPv6 you always need a router interface connected to a LAN segment with DHCPv6 clients that sends router advertisments ("RA", RFC4861 (http://tools.ietf.org/html/rfc4861)). From these RA the DHCPv6 clients should learn the default gateway (always the link local address of the router the RA was send from) and at least one IPv6 prefix being "onlink" (the one that starts with the first 64 bits of the address received from the DHCPv6 server) and usually having a prefix length of 64. Ideally within this RA the A-flag for this prefix should be set to 0 to prevent the clients to autoconfigure a second IPv6 address in addition to the one received via stateful DHCPv6.
The client's behaviour for prefixes advertised with other prefix lengths than 64 is implementation dependent (e.g. not accepting it, as was the case when you attached your Linux machine directly to your ISP router which advertises a /48 resulting your Linux machine working without knowledge of the valid /48 onlink prefix -- this works, although inefficiently, because the machine in this case due to lack of better information will send any packet to its default gateway, even those destined for neighbors).
PacketTracer
-
PacketTracer - Thank you very much! You said some keywords about routing in your last post that I had totally overlooked, or to say it in another way, searched for a solution at a wrong place.
To give you some insight: We have/are an organisation that among other things provide Internet to the houses (not for profit). So the organisation is our ISP. I am, among other things, helping to get the network to work in the organisation although not the only one. So besides having the DIR-860L I do also every now and then work on pfSense, the router software. What I had thought of, but forgotten again and later looked for, but at the wrong place was to make the actually routing of the subnets actually work (besides what I had already set up regarding DHCP-PD). A bit embarrassing. (Besides that GUIs are sometimes dangerous because you think stuff gets done automatically behind the scene, which they do not always do - especially not what is overlooked.)
I think I owe you a big thank you! Your keywords put me back on track...
I will read your last post several times, and then rethink the layout of the IPv6 network, but I think your ideas are very much worth considering.
I will do some reading now, and then later make a drawing in InkScape of the network and post it here. And... I think I have some routing to make ;-)
Thanks once again. You will hear from me! :-)
-
Hi
I am a little frustrated at the moment however I want to give an update now even though I have not made an InkScape drawing of the network.
The situation is like [1]. There is only one ISP router (We/the ISP have no individual network for an edge router.)
That means that the ISP router (its LAN side), _an_ ISP server, client computers and CPEs (with their client computers) are part of _one_ /64 network. The CPEs then get a /56 for their client computers (well, that is the new plan - thanks to your comments. :-) )
I have rearranged the network scope of the LAN of the ISP router now so (as just mentioned above) it only actively operates in the lowest /64-area of the /48 subnet.
(I tried to make some /127 routes, but it seems that the ISP router (that uses pfSense) do not follow/is compatible with RFC 6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) so I gave up on that. /126 does however work, but I also gave up on that and instead chose to have a more simple setup.)
I managed to get the 860L router to work with IPv6 when connected to my ISPs LAN. So that is great!
I had to manually create a route in the /64 network of the ISPs LAN (created in the ISP-router) to the /56 network (like you suggested). And then I had IPv6 connectivity on the 860L to the outside world.
I have however a problem. :-/
I can neither from clients of the 860L reach clients in the /64 ISP LAN network as well as clients from the /64 ISP LAN network can neither get in contact with clients in the 860L /56 network.
So I guess I have some reading to do about routing.
What I wish is to setup routing _once_ and then clients and CPEs should be able to reach each others subnets, but without having to setup routes manually. I thought setting that route (mentioned above) should have been enough.
Besides that I have something else I have to investigate more because I am not totally sure about it yet:
The pfSense LAN DHCP-PD functionality seems to be broken. It does not create routes on the fly (if it was intended to be that way)
neither it seems to "link" a wan ip given to the CPE with the correct /56 network - if a route was created manually in advance by the netadministrator. (But I have to test it more thoroughly.)
(Besides that pfSense also has some Router Advertisements - RA Subnet(s) functionality. It does not completely state for what it is worth besides to advertise to the listed networks. On this page http://pfsensesetup.com/ipv6-integration-a-look-at-pfsense-2-1/ (http://pfsensesetup.com/ipv6-integration-a-look-at-pfsense-2-1/) the second image shows that pfSense page.)
But I wait for the pfSense 2.1 book to be published and buy it. Maybe I have overlooked something regarding DHCP-PD as well as Router Advertisements and subnets.
-
Perhaps I should add some details
/64 LAN network of ISP: 2a02:188:4401:0:: /64
ISP route to 2a02:188:4401:8100::/56 from gw address 2a02:188:4401:0::8100
From DIR-860L IPv6 status page and routing page:
IPV6 CONNECTION INFORMATION
IPv6 Connection Type:Static
Network Status:Connected
Connection Up Time:0 Day 0 Hour 36 Min 2 Sec
WAN IPv6 Address:2a02:188:4401::8100 /64
IPv6 Default Gateway:2a02:188:4401::1
Primary IPv6 DNS Server:2a02:188:4401::1
Secondary IPv6 DNS Server:None
LAN IPv6 Link-Local Address:fe80::c2a0:xxxx:xxxx:1418 /64
IPv6 Network assigned by DHCP-PD:None
LAN IPv6 Address:2a02:188:4401:8100::1 /64
IPV6 ROUTING TABLE
Destination IP Gateway Metric Interface
2a02:188:4401::/64 :: 256 INTERNET
2a02:188:4401:8100:xxxx:xxxx:xxxx:6e8b :: 0 LAN
2a02:188:4401:8100::/64 :: 256 LAN
::/0 2a02:188:4401::1
Should these routes be enough for inter subnet communication and particularly between my CPE (and computers of my CPE) and ISP LAN (and computers of ISP LAN)?
-
Hi v6,
your scenario goes far beyond what the average problems deal with in this forum. But on the other hand it is more challenging and hence more interesting for me to discuss it.
The situation is like [1]. There is only one ISP router (We/the ISP have no individual network for an edge router.) That means that the ISP router (its LAN side), _an_ ISP server, client computers and CPEs (with their client computers) are part of _one_ /64 network. The CPEs then get a /56 for their client computers
/64 LAN network of ISP: 2a02:188:4401:0::/64
"/64 ISP LAN network": In what follows I will simply call this network "WAN network" because it is the "WAN" from CPE's perspective.
Though called "WAN" it is nothing more than a usual LAN using Ethernet based on a L2 fiber network which is populated by the LAN interface of your "ISP router" (using pfSense), 28 CPE WAN interfaces and additional "client computers" you didn't mention so far. So this WAN network resembles a DMZ where the directly connected client computers will possibly be used as servers (Web, FTP, DNS, NTP, ...) (?) and the CPEs operate as firewalls that connect to protected networks.
(I tried to make some /127 routes, but it seems that the ISP router (that uses pfSense) do not follow/is compatible with RFC 6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) so I gave up on that. /126 does however work, but I also gave up on that and instead chose to have a more simple setup.)
Using /127 would have made sense only in case [2] but your scenario is case [1] where you have more than 2 network nodes that want to talk to each other via the WAN network. This means you have to use a /64 as you did.
I have however a problem. :-/ I can neither from clients of the 860L reach clients in the /64 ISP LAN network as well as clients from the /64 ISP LAN network can neither get in contact with clients in the 860L /56 network.
...
What I wish is to setup routing _once_ and then clients and CPEs should be able to reach each others subnets, but without having to setup routes manually. I thought setting that route (mentioned above) should have been enough.
Just for clarity: Besides simple Internet access for clients behind the CPEs you want to establish the following communication relationships:
- Clients behind a CPE shall be able to initiate communication to clients in the WAN network and vice versa
- Clients behind one CPE shall be able to initiate communication to any client behind another CPE (not quite sure if I understood you right and this is a demand either)
What kind of reachability tests did you do, just PING6 (meaning ICMPv6 echoes) or also trying TCP/IPv6 connections or UDP/IPv6 requests?
Can the clients connected to your WAN network ping6 each other, the ISP router and any CPE's WAN interface?
Is a PING6 test within DIR-860L successful for any client connected to your WAN network or other CPE's WAN interface?
Perhaps I should add some details
/64 LAN network of ISP: 2a02:188:4401:0:: /64
ISP route to 2a02:188:4401:8100::/56 from gw address 2a02:188:4401:0::8100
From DIR-860L IPv6 status page and routing page:
...
Should these routes be enough for inter subnet communication and particularly between my CPE (and computers of my CPE) and ISP LAN (and computers of ISP LAN)?
If you neglect any possible negative influence of the DIR-860L IPv6 firewall (meaning it will allow any traffic in both directions -- and this might be not the case in your present configuration) these routes should be enough though not optimal, given that the clients connected to your WAN network will use your ISP router's address (2a02:188:4401::1) as default gateway (please check this) and that your ISP router has complete routing information for all /56 networks behind the CPEs.
For example:
- Client behind a CPE wants to talk to a client connected to your WAN network: IPv6 packet is sent from client to the CPE because it is the client's default gateway. CPE looks at destination address and discovers that this address belongs to the WAN network it is directly attached to. It forwards the packet directly to to the destination.
But: If the client in the WAN network wants to send back a reply to the client behind the CPE it has no adequate routing information for doing so. Hence it simply sends the reply packet to its default gateway which should be your ISP router 2a02:188:4401::1. Your ISP router should have a routing entry for the /56 the destination address of the reply packet belongs to and hence forward the packet to the corresponding CPE WAN interface. Hence the reply packet is routed back through the network it came from and that's why your ISP router will also send back an ICMPv6-Redirect packet to the WAN client this way conveying the host routing information, that the next time the WAN client wants to send a packet to the specific client behind the CPE it might directly send it to the CPE WAN interface omitting the ISP router as an interim hop. Hence the WAN client learns a host route to the specific client behind the CPE but only keeps it within its so called "destination cache" and usually forgets it within less than a minute if no further communication to this destination occurs - hence the next time it has to learn it again, that's what I meant when saying "not optimal" - Client connected to your WAN network wants to talk to a client behind a CPE: This is the same as for the reply packet in the case above (first bullet: paragraph starting with But:) while a reply packet now send back from the client behind the CPE to the client in the WAN network follows the path described by the first paragraph in the first bullet.
- Client behind a CPE talking to a client behind another CPE: Works similar: CPE forwards the packet due to lack of better information to your ISP router which in turn forwards it to the destination CPE thereby sending back an ICPMv6-Redirect to the source CPE hence it will temporarily cache a host route for the destination
I suppose depending on its present configuration the CPE firewall might block either ICMPv6 echo replies or generally any connection requests coming from outside. In order to allow connection initiation from WAN network clients and clients behind any other CPE you must allow any incoming traffic coming from 2a02:188:4401::/48.
Hence I propose to configure the following IPv6 firewall settings within your CPEs:
(1) Switch FW on via "Turn IPv6 Firewall ON and ALLOW rules listed"
(2) Specify a rule that allows anything going out:
- Activate the checkbox of the first rule
- Give it a Name, e.g. "AllowAllOut"
- Schedule = Always
- Source Interface = LAN
- Source IP Address Range = :: (*)
- Protocol = Any
- Dest Interface = WAN
- Dest IP Address Range = ::
- Port Range: leave as is, not relevant (=any value) for Protocol = Any
(*) Depending on model you might have to specify the range as START - END:
:: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
(3) Specify a second rule that allows packets with source address within 2a02:188:4401::/48 coming in:
- Activate the checkbox of the second rule
- Give it a Name, e.g. "AllowISPIn"
- Schedule = Always
- Source Interface = WAN
- Source IP Address Range = 2a02:188:4401::/48 (*)
- Protocol = Any
- Dest Interface = LAN
- Dest IP Address Range = ::
- Port Range: leave as is, not relevant (=any value) for Protocol = Any
(*) Depending on model you might have to specify the range as START - END:
2a02:188:4401:: - 2a02:188:4401:ffff:ffff:ffff:ffff:ffff
(4) If the "Simple Security" option is available activate it.
The pfSense LAN DHCP-PD functionality seems to be broken. It does not create routes on the fly (if it was intended to be that way) neither it seems to "link" a wan ip given to the CPE with the correct /56 network - if a route was created manually in advance by the netadministrator.
Sorry but I don't have any pfSense knowledge so I can't help you here.
PacketTracer
-
Hi PacketTracer
Once again - thank you for your help!
Regarding DMZ there are different definitions on what it is, but the definition here http://en.wikipedia.org/wiki/DMZ_(computing) goes fine hand in hand with your description. And yes I agree.
(Regarding /127: Yes, you are right. I was at the time trying to experiment if it was possible to bind a virtual IPv6 address to the ISP-router and connect that to the WAN side of the 860L/CPE to get in compliance with RFC-6164. Besides the /127 problem in pfSense, it seems only possible if I had an extra NIC (which I do not have) or better a virtual interface in the ISP router (which feature it does not have to my knowledge).)
Regarding "communication relationships": Yes, that is what I want. :-)
Reachability test CPE LAN --> WAN (ISP LAN):
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
Test:
I did ping6 (icmpv6 echoes) and rltraceroute6 (UDP), tcptraceroute6 (TCP) and tracert6 (IMCPv6 Echo) from my desktop machine behind the LAN of my CPE/860L towards 2a02:188:4401::6.
Result:
I only reach 2a02:188:4401:8100::1 with the *traceroute6 programs - never the actual target. ping6 no success.
Reachability test WAN (ISP LAN) --> CPE LAN/my desktop computer (2a02:188:4401:8100:1337:1337:1337:1337)
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
Test:
I did ping6 (icmpv6 echoes) and traceroute6 (UDP/ICMP <-- http://www.freebsd.org/cgi/man.cgi?query=traceroute6&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE&arch=i386&format=html ) from the ISP router (2a02:188:4401::1) towards my LAN of my CPE/860L with target my desktop machine (2a02:188:4401:8100:1337:1337:1337:1337).
Result:
ping6 succeeds
traceroute6 UDP succeeds
traceroute6 ICMP succeeds
Reachability test DMZ Server (2a02:188:4401::6) --> CPE LAN/my desktop computer (2a02:188:4401:8100:1337:1337:1337:1337):
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
3) DMZ server has gateway set to 2a02:188:4401::1.
Test:
I did ping6 (icmpv6 echoes) and rltraceroute6 (UDP), tcptraceroute6 (TCP) and tracert6 (IMCPv6 Echo) from the ISP DMZ server towards the LAN of my CPE/860L.
Result:
ping6 (ICMPv6) fails. 2a02:188:4401:8100:1337:1337:1337:1337(2a02:188:4401:8100:1337:1337:1337:1337) 56 data bytes
tracert6 (ICMPv6) fails. Never reaches anything.
rltraceroute6 (UDP) fails. -"-
tcptraceroute6 (TCP) fails. -"-
Clients of the WAN can ping eachother and the ISP router without a problem
From within the DIR-860L I can ping e.g. 2a02:188:4401::6. I have added an image of this to this post.
(http://bjoernemosen.dk/~al/dlink/IPv6PingTest.png)
Some selected IPv6 routes from the ISP router:
Destination Gateway Flags Refs Use Mtu Netif Expire
default 2a02:188:130:2::1 UGS 0 3012 1500 rl0
::1 ::1 UH 0 0 16384 lo0
2a02:188:130:2::/64 link#4 U 0 96855 1500 rl0
2a02:188:130:2::2 link#4 UHS 0 0 16384 lo0
2a02:188:4401::/64 link#1 U 0 89921 1500 fxp0
2a02:188:4401::1 link#1 UHS 0 174 16384 lo0
2a02:188:4401:8100::/56 2a02:188:4401::8100 UGS 0 8525 1500 fxp0
Regarding the DIR-860L firewall: Protocol now has ALL instead of ANY.
Source start address has to differ from destination start address else a javascript popup window poped up. I circumvented this by choosing a destination start address that was within range of LAN, WAN, INTERNET (seen from CPE) meaning 1000:: to ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
Regarding activating firewall rules I had some strange experiences.
It seemed that everytime I switched "Turn IPv6 Filtering ON and ALLOW rules listed" (and the check boxes is selected ;-) ) and regardless of Simple Security is on or not the result is that Status - Logs - Router Status (radio button) gets filled with the firewall dropping my traffic. E.g. it drops if I go to ANY address that needs to pass either WAN or INTERNET e.g. http://[2a02:188:4401::6]/ (yeah a webserver as well) :-) or http://test-ipv6.com/
If I however choose "Turn IPv6 Filtering ON and DENY rules listed" then (also regardless of Simple Security is on or not) suddenly I have access to http://test-ipv6.com/ but still not e.g. http://[2a02:188:4401::6]/
I did try your settings (less network scope for AllowISPIn), but that did not make a change in the outcome.
I have added an image to this post about my fw settings. It has DENY rules listed set but the address ranges, interfaces and protocol applies to my test situation with "ALLOW rules listed".
(http://bjoernemosen.dk/~al/dlink/fwrules.png)
-
Forgot to mention a test from my VPS in Italy.
Test: target 2a02:188:4401:8100:1337:1337:1337:1337 from my VPS in Italy
Preconditions: like the other tests
Test: I tested with ping6, rltraceroute6 (UDP), tcptraceroute6 (TCP), tracert6 (ICMPv6 echo)
Results:
ping6 succeeds
rltraceroute6 only reaches 2a02:188:4401::8100 - so kind of fail.
tcptraceroute6 only reaches 2a02:188:130:2::2 - fail!
tracert6 succeeds
Comment: Regarding the *traceroute6 results it might be because 2a02:188:4401::8100 does not have inbound traffic allowed (from the Internet) in the ISP router. I will try to fix that and make a new test.
I have however a meeting I must attend to in about one hour from now, but I will make a new post.
-
Here comes a follow-up to my last post regarding testing from my VPS in Italy and towards 2a02:188:4401:8100:1337:1337:1337:1337.
To make sure that nothing blocks this test I made 2a02:188:4401::8100 and 2a02:188:4401::1 publicly available to inbound traffic coming from the Internet.
This made one change.
Now the result is:
tcptraceroute6 - fails!
rltraceroute6 succeeds
tracert6 succeeds
ping6 succeeds
Meaning that tcptraceroute6 still fails under the same preconditions as the other tests.
I do not know why, but to compensate I tried to make a ssh test from my VPS in Italy to 2a02:188:4401:8100:1337:1337:1337:1337 and that worked!
So I will conclude at least the Internet connection also works from outside my ISP and into my LAN.
So what is left is the routing part which (I guess) does not work. Is it pfSense that does not know how to route within the LAN (DMZ/WAN of CPE/DIR-860L) when one of its clients contacts it or has it something to do with e.g. the DIR-860L routing/routing table?!?
The only thing that comes to my mind is to probe the network with e.g. WireShark at select points in the DMZ/WAN and see where possible icmp data floats around and make some packet captures and trace.
Do you have any suggestions - also regarding the firewall test I made in the CPE/DIR-860L?
Thanks once again PacketTracer! :-)
-
Hi v6,
Reachability test DMZ Server (2a02:188:4401::6) --> CPE LAN/my desktop computer (2a02:188:4401:8100:1337:1337:1337:1337):
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
3) DMZ server has gateway set to 2a02:188:4401::1.
Test:
I did ping6 (icmpv6 echoes) and rltraceroute6 (UDP), tcptraceroute6 (TCP) and tracert6 (IMCPv6 Echo) from the ISP DMZ server towards the LAN of my CPE/860L.
Result:
ping6 (ICMPv6) fails. 2a02:188:4401:8100:1337:1337:1337:1337(2a02:188:4401:8100:1337:1337:1337:1337) 56 data bytes
tracert6 (ICMPv6) fails. Never reaches anything.
rltraceroute6 (UDP) fails. -"-
tcptraceroute6 (TCP) fails. -"-
This is interesting: tracert6 (ICMPv6) fails. Never reaches anything.
You should see at least that 2a02:188:4401::1 is reached, because due to "3) DMZ server has gateway set to 2a02:188:4401::1." the packet will be sent to your ISP router first.
If your ISP router (for some unknown reason, maybe via some policy) will not forward packets coming from WAN network back through this network (sort of "bouncing"), this would completely explain your observed negative results (First negative case: Reply packets from 2a02:188:4401::6 will not be routed back by your ISP router towards 2a02:188:4401:8100:1337:1337:1337:1337. Second negative case: Request packets from 2a02:188:4401::6 will not be forwarded by your ISP router towards 2a02:188:4401:8100:1337:1337:1337:1337). Just a theory ...
PacketTracer
EDIT
You could configure a route for 2a02:188:4401:8100::/56 next hop 2a02:188:4401::8100 within your DMZ host 2a02:188:4401::6. This would circumvent your ISP router. Check if connectivity tests 2a02:188:4401:8100:1337:1337:1337:1337 <--> 2a02:188:4401::6 will work with this
-
I made a mistake. Sorry! I had added the new gateway on the DMZ server to a configuration file, but forgot that there was an existing route to the old /48 network, so I made a quick reboot just to be absolutely sure! Then the results where somewhat different:
So the results are:
Reachability test DMZ Server (2a02:188:4401::6) --> CPE LAN/my desktop computer (2a02:188:4401:8100:1337:1337:1337:1337):
Precondition:
1) CPE fw off & no simple security.
2) IPv6 connectivity to the Internet
3) DMZ server has gateway set to 2a02:188:4401::1.
4) No old routes ;-)
Test:
I did ping6 (icmpv6 echoes) and rltraceroute6 (UDP), tcptraceroute6 (TCP) and tracert6 (IMCPv6 Echo) from the ISP DMZ server towards the LAN of my CPE/860L.
Result:
ping6 (ICMPv6) succeeds! Hip Hip Hurray :-)
tracert6 (ICMPv6) succeeds!
rltraceroute6 (UDP) succeeds!
tcptraceroute6 (TCP) router.bjoernemosen.dk (2a02:188:4401::1) 0.289 ms * * - fails! but it does not matter ;-)
ssh succeeds!
Reachability test CPE LAN desktop machine --> WAN (ISP LAN) DMZ server:
To make it quick: It works!
So... ehm... It works. A little embarrassing - a forgotten route on the DMZ server.
Thank you!
And you know what! Now there is a solution described for everyone else having the same sort of network/problem:
Add a route (and no need to adjust ipv6 firewall settings as it seems on the CPE.)
Please tell me if you would like something for your help! E.g. if I can order you some beer or chocolates e.g. from a local web store near you. PM me your address in that case. :-)
-
Hi v6,
looking at ...
Besides that I have something else I have to investigate more because I am not totally sure about it yet: The pfSense LAN DHCP-PD functionality seems to be broken. It does not create routes on the fly (if it was intended to be that way) neither it seems to "link" a wan ip given to the CPE with the correct /56 network - if a route was created manually in advance by the netadministrator. (But I have to test it more thoroughly.)
... there is still some homework left to do for you. Good luck!
tcptraceroute6 (TCP) router.bjoernemosen.dk (2a02:188:4401::1) 0.289 ms * * - fails! but it does not matter ;-)
...
Please tell me if you would like something for your help! E.g. if I can order you some beer or chocolates e.g. from a local web store near you. PM me your address in that case. :-)
Nice 28 houses at Bjørnemosen (watched them following the Google Streetview link on your website). Instead of drinking beer or eating chocolate I'd prefer spending my next holidays there!
;) :D
PacketTracer
-
Thank you
You shall be welcome! :)
And yes you are right about DHCP-PD.
It is going to be interesting if I can get it to work.
I will try to google for info about how it is supposed to work e.g. in setup guides and in other products so that I get an idea about how it actually should work regarding routing.
(To add to that I am still waiting for the book about pfSense 2.1 to be released. There should be about 200 additional pages compared to the old book.)
Should it turn out that pfSense does not have the kind of DHCP-PD support I need (regarding dynamically adding a route as long as the DHCP-PD lease is still valid) then
_maybe_ if I am able to understand the code of pfSense I suppose I could try to make a (little?) patch where the netadmin has an option he could click to enable that sort of support.
-
... this case of IPv6 firewall failure has been added as case [4] to a list of other cases, see here (http://forums.dlink.com/index.php?topic=58287.msg226285#msg226285).
PT