Re: [OpenWrt-Devel] dslite tunnel setup
Hi, On Tue, Apr 08, 2014 at 10:34:21PM +0200, Steven Barth wrote: Hi Gert, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. I'm sorry but it seems you misunderstood me. We were talking about IPv6 addresses here. Indeed, I misunderstood you. I was just returning from yet another discussion about the unfairness of global IPv4 run-out... It seems that Hennings' ISP only offers a delegated prefix but no global IPv6-address on the WAN-connection (or there is an unknown issue acquiring said address which I don't know of). I know that RFC 7084 requires a CER to actually deal with this (Weak ES model and all) so I added a fix to allow the DS-Lite source endpoint address to be acquired from a downstream interface. There has been quite a bit of discussion in the ISP camp regarding WAN IPv6 addresses. It's not actually straightforward what to do as an ISP, so multiple variants exist - RA for WAN, DHCPv6-PD for LAN disadvantage: on PPPoE-type deployments, you need two prefixes per client, one /64 for the WAN-RA, one /56 for DHCP (but this works quite nicely in cable deployments where you have a large shared WAN segment anyway) - DHCPv6-IA for WAN, DHCPv6-PD for LAN disadvantage: extra pool management for WAN needed, basically similar to RA for WAN - require use of an IPv6 address out of the delegated /56 for WAN disadvantage: this sort of forces a certain way to segment the /56 onto the client, so I have not actually seen this in the wild - run the WAN over link-local only advantage: only single prefix per customer, easier management for the ISP (in point-to-point deployment scenarios, like PPPoE) disadvantage: well, it complicates source address selection on the CPE, as locally sourced packets leaving via WAN need to use a global address elsewhere - you named it, already. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpMFKHwsHgb4.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi Gert, There has been quite a bit of discussion in the ISP camp regarding WAN IPv6 addresses. It's not actually straightforward what to do as an ISP, so multiple variants exist - RA for WAN, DHCPv6-PD for LAN - DHCPv6-IA for WAN, DHCPv6-PD for LAN - require use of an IPv6 address out of the delegated /56 for WAN - run the WAN over link-local only Now you can feel my pain trying to make OpenWrt compatible with all of that + deal with weird quirks from every other ISP. On a side note not all ISPs seem to like ds-lite as it requires Carrier-Grade-NAT. So I hope to get other stuff like lw4o6 and / or MAP-E/T in there at some point. Soo much todo, so little time *sigh*. Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi Henning, yeah that is another side-effect of your - well - irregular ISP-behaviour. I will try to put it on the TODO but it's not very high on the list as its more or less cosmetic, sorry I'm a little short on time at the moment. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Gert Doering g...@greenie.muc.de writes: There has been quite a bit of discussion in the ISP camp regarding WAN IPv6 addresses. It's not actually straightforward what to do as an ISP, so multiple variants exist - RA for WAN, DHCPv6-PD for LAN disadvantage: on PPPoE-type deployments, you need two prefixes per client, one /64 for the WAN-RA, one /56 for DHCP (but this works quite nicely in cable deployments where you have a large shared WAN segment anyway) You may get away with a shared /64 for all PPPoE links terminated on the same BNG, since you effectively control all the interface identifiers through IPV6CP. - DHCPv6-IA for WAN, DHCPv6-PD for LAN disadvantage: extra pool management for WAN needed, basically similar to RA for WAN Note that this scheme has a great advantage (for the ISP) when compared to RA, especially if the link is shared: The ISP selects the address when using DHCPv6-NA. This way it can be recorded and used for e.g. CPE management purposes. Also note that the RA is still required for (default) routing. But it doesn't need to announce any prefix. - require use of an IPv6 address out of the delegated /56 for WAN disadvantage: this sort of forces a certain way to segment the /56 onto the client, so I have not actually seen this in the wild Not to mention that this is explicitly forbidden by RFC 3633: 12.1. Requesting router behavior .. the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router. - run the WAN over link-local only advantage: only single prefix per customer, easier management for the ISP (in point-to-point deployment scenarios, like PPPoE) disadvantage: well, it complicates source address selection on the CPE, as locally sourced packets leaving via WAN need to use a global address elsewhere - you named it, already. From an end user perspective, this source address selection can actually be seen as an advantage. I want to use addresses from my delegated prefix for all traffic, including CPE locally sourced traffic. The only way to achieve that, if you want to follow RFC 3633 (see above), is by *not* assigning any global address to the WAN link. Note that even if you ignore the RFC 3633 restriction and add a /128 from your delegated prefix to thw WAN link, you cannot guarantee that it will be used for every destination if there are other global addresses on the WAN interface. DHCPv6-NA assigned addresses will also be /128 and you end up with rule 8 - longest match against destination wins. Which is going to be pretty arbitrary if both addresses come out of the same ISP block... So I prefer the link local only WAN interface. That way I can add a /128 from my delegated prefix on the loopback interface and make the CPE use it for locally source globally scoped traffic. Those who claim that applications should always explictly bind to their wanted source address do have a point, though. Source address selection is otherwise going to be pretty confusing. At least for me :-) Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Well its also not a pressing issue for me. I just wanted to report it so it ends up on a TODO list ;). Henning Steven Barth cy...@openwrt.org hat am 9. April 2014 um 12:28 geschrieben: Hi Henning, yeah that is another side-effect of your - well - irregular ISP-behaviour. I will try to put it on the TODO but it's not very high on the list as its more or less cosmetic, sorry I'm a little short on time at the moment. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hello Henning, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. please see: https://dev.openwrt.org/changeset/40422 I added an option weakif which allows you to specify an interface from which we take the local IPv6 address defaulting to lan. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi, On Tue, Apr 08, 2014 at 08:22:45AM +0200, Steven Barth wrote: i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpBKyu5CNqOd.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi Gert, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. I'm sorry but it seems you misunderstood me. We were talking about IPv6 addresses here. It seems that Hennings' ISP only offers a delegated prefix but no global IPv6-address on the WAN-connection (or there is an unknown issue acquiring said address which I don't know of). I know that RFC 7084 requires a CER to actually deal with this (Weak ES model and all) so I added a fix to allow the DS-Lite source endpoint address to be acquired from a downstream interface. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
I am not an ipv6 expert at all but from what i understand it has to do with the providers configuration that my wan6 does not actually have a routeable ipv6 addr. On a subject related to that dslite setup i found another problem. I am not sure what i am supposed to see on the overview page of luci. But i certainly would like to see the routers current ipv6 addr, which i do not see because my wan6 interface does not have one. I can derive it from the dhcpv6 leas section if dhcpv6 clients are connected, but that is not really what one would expect. /usr/lib/lua/luci/view/admin_status/index.htm does not really seem to allow me to configure another interface for that section. The ipv6 section should show my current prefix, ip and a ticking clock for the current leas. Henning On Tue, 08 Apr 2014 08:22:45 +0200 Steven Barth cy...@openwrt.org wrote: Hello Henning, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. please see: https://dev.openwrt.org/changeset/40422 I added an option weakif which allows you to specify an interface from which we take the local IPv6 address defaulting to lan. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi, judging from Gerts mail domain he might well be stuck with the very same provider i unfortunatelly signed a contract with. Small, local German providers seem to be going for native ipv6 with dslite. That allows them to grow even though they own a relatively small ipv4 pool. Most users are probably happy with the high bandwidth connection they get, most likely subsidized by the state ... But if you would like to use any service listening on an ipv4 port in your home, you will react allergic to the term dslite. Henning On Tue, 08 Apr 2014 22:34:21 +0200 Steven Barth cy...@openwrt.org wrote: Hi Gert, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. I'm sorry but it seems you misunderstood me. We were talking about IPv6 addresses here. It seems that Hennings' ISP only offers a delegated prefix but no global IPv6-address on the WAN-connection (or there is an unknown issue acquiring said address which I don't know of). I know that RFC 7084 requires a CER to actually deal with this (Weak ES model and all) so I added a fix to allow the DS-Lite source endpoint address to be acquired from a downstream interface. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] dslite tunnel setup
Hi,
i set up an openwrt router a few days ago. My provider offers native
IPv6 and v4 is available via a dslite tunnel. I ran into trouble
setting it up according to the available documentation and decided to
get a trunk image first. Now my router runs a trunk image with version
(Bleeding Edge, r40383).
Still i could not figure out how to get the dslite tunnel to work so i
started digging through the code. Eventually i patched the dslite
script to get my setup to work. Now i would like to find out whether my
configuration is wrong or whether a patch is necessary.
So lets start with the relevant parts of my network config:
config interface 'lan'
option ifname 'eth0.1'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '64'
option ip6hint 'ab'
config interface 'wan'
option ifname 'eth1.40'
option proto 'pppoe'
option username ''
option password ''
option ipv6 '1'
config interface 'wan6'
option ifname '@wan'
option proto 'dhcpv6'
config interface 'wan4'
option proto 'dslite'
option peeraddr '2001:'
I am getting a /56 prefix from my provider. The pppoe runs in vlan 40
on the wan interface. wan6 gets the prefix via dhcpv6 and i assign
a /64 to my lan.
Now dslite.sh will find wan6 to be the wanif using network_find_wan6.
And later it will use network_get_ipaddr6 to try to get its ip6addr.
But wan6 does not actually have an ip6addr
# network_find_wan6 wanif echo $wanif
wan6
# network_get_ipaddr6 ip6addr wan6 echo $ip6addr
The only interface that actually has a global IPv6 address is lan but
setting it as tunlink did not work and does not seem to make sense
anyways.
The solution was to use the ip6addr from lan and not set tunlink or
set it to wan6. But since my v6 prefix is dynamic that can not be done
with the current dslite.sh.
So as a workaround i added
network_get_ipaddr6 ip6addr lan
just above the
[ -z $ip6addr ] {
...
I guess what i really want is that wan6 actually has an ip6addr from
the prefix range it got via dhcp. But i did not find a way to assign
one. The second option would be to tell wan4 to use the ip6addr from
lan directly in the configuration. Is there a way to express
network_get_ipaddr6 ip6addr lan in the configuration file?
regards,
Henning
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
