Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
On 18.06.2013 01:15, Thomas Bächler wrote: You're confusing me even more - how does the patch relate to ipv6cp? In ipv6cp, I am assigned a link-local address by the provider. I may be wrong, but doesn't my peer expect that I use this link-local address in its routing table in order to communicate with me? This means that I cannot change the assigned link-local address. Well I'm not sure about that but that but that was not what I meant. Maybe my wording was a bit confusing as. IIRC pppd provides an option to define the local interface identifier for use in IPv6CP and is then hand-shaked with the peer. And as we by default use the interface-identifier of the link-local address for the global addresses as well this should equally do what you want with the nice side-effect that the interface identifier of the LL-address matches those of the global ones. On the other hand, my peer doesn't care which IPv6 address I choose inside the advertised prefix, and if it is related to the link-local or not, so this is the address that I can change, and the client is the only place where I can change it. Yeah you're right, but honestly I still don't see the point of adding this in the DHCPv6/RA-client rather than just configuring pppd. If configuring ppp doesn't work for you we can reevaluate adding this feature to odhcp6c instead. Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Am 18.06.2013 10:03, schrieb Steven Barth: On 18.06.2013 01:15, Thomas Bächler wrote: You're confusing me even more - how does the patch relate to ipv6cp? In ipv6cp, I am assigned a link-local address by the provider. I may be wrong, but doesn't my peer expect that I use this link-local address in its routing table in order to communicate with me? This means that I cannot change the assigned link-local address. Well I'm not sure about that but that but that was not what I meant. Maybe my wording was a bit confusing as. IIRC pppd provides an option to define the local interface identifier for use in IPv6CP and is then hand-shaked with the peer. Documentation in pppd is incomplete here, at best. While I can define an interface identifier using the 'ipv6' option, it doesn't say anything about hand-shaking. My impression (from the wording of the documentation) is that this is useful if you have a static local and remote LL (know a-priori on both ends) and want to omit IPv6CP completely (just like specifying a local and remote IP for IPv4). In case there is a negotiation, the peer can still reject my requested local LL, and I suspect it will do so if I want it to be 'fe80::1' (right now, I use -H::1 on odhcp6c, which gives a nice and short address). As I said, pppd's documentation is not very explicit on the matter. I guess some experimentation and tcpdump'ing is in order to determine my ISP's behaviour. And as we by default use the interface-identifier of the link-local address for the global addresses as well this should equally do what you want with the nice side-effect that the interface identifier of the LL-address matches those of the global ones. The point of my patch was that we are not forced to do that. As long as we perform DAD (which the kernel does automatically), we do not violate RFC 4862 by choosing whatever interface identifier we want (I used the term hostid in the patch, but I just noticed that the RFC refers to interface identifier instead). Another point of my patch is that it takes the path of least resistance: Instead of messing with the pppd negotiation, it applies its settings at a point where there is no negotiation and a large degree of freedom. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Hi, On Tue, Jun 18, 2013 at 11:35:41AM +0200, Thomas Bächler wrote: Documentation in pppd is incomplete here, at best. While I can define an interface identifier using the 'ipv6' option, it doesn't say anything about hand-shaking. My impression (from the wording of the documentation) is that this is useful if you have a static local and remote LL (know a-priori on both ends) and want to omit IPv6CP completely (just like specifying a local and remote IP for IPv4). That interface identifier is used for the IPv6CP handshake - it's what the client proposes, and the server side can then accept it, or assign something else. DSL providers usually accept, 3G providers usually reject... [..] The point of my patch was that we are not forced to do that. As long as we perform DAD (which the kernel does automatically), we do not violate RFC 4862 by choosing whatever interface identifier we want (I used the term hostid in the patch, but I just noticed that the RFC refers to interface identifier instead). Another point of my patch is that it takes the path of least resistance: Instead of messing with the pppd negotiation, it applies its settings at a point where there is no negotiation and a large degree of freedom. I think this change is useful (without having looked at the actual code), for exactly these reasons. With the IPv6CP handshake, you'll arrive at something the provider controls - but then in the /64 that is announced by RA, you can choose whatever host id / interface identifier you want, and I can see people wanting to use something easy to type and remember, like ::1. (And you can't configure fully static IPv6 addresses here, as the assigned prefix can - and likely, will - change) 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 pgpiw7ZUJ1cYA.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Gert Doering g...@greenie.muc.de writes: On Tue, Jun 18, 2013 at 11:35:41AM +0200, Thomas Bächler wrote: Documentation in pppd is incomplete here, at best. While I can define an interface identifier using the 'ipv6' option, it doesn't say anything about hand-shaking. My impression (from the wording of the documentation) is that this is useful if you have a static local and remote LL (know a-priori on both ends) and want to omit IPv6CP completely (just like specifying a local and remote IP for IPv4). Just for the record: You can NEVER omit the NCP. Omitting it means that you don't run that protocol over the PPP session. This is a basic PPP concept. That interface identifier is used for the IPv6CP handshake - it's what the client proposes, and the server side can then accept it, or assign something else. DSL providers usually accept, 3G providers usually reject... Yes, but there can be good reasons for DSL providers to reject as well. When playing with the local DHCPv6 server on Juniper ERXes we discovered that they use the peer ifid as a hidden key in their lease database in addition to the DUID. This meant that a bouncing PPP session with a newly generated ifid was unable to reuse the same DHCPv6 prefix until the old lease expired, even if the DHCPv6 client (as identified by DUID) was the same. Requiring all users to configure a static ifid is impossible, so we push static ifids for PPP users with static prefixes from the ISP end. Meaning that we have to reject the peers choice. The point of my patch was that we are not forced to do that. As long as we perform DAD (which the kernel does automatically), we do not violate RFC 4862 by choosing whatever interface identifier we want (I used the term hostid in the patch, but I just noticed that the RFC refers to interface identifier instead). Another point of my patch is that it takes the path of least resistance: Instead of messing with the pppd negotiation, it applies its settings at a point where there is no negotiation and a large degree of freedom. I think this change is useful (without having looked at the actual code), for exactly these reasons. With the IPv6CP handshake, you'll arrive at something the provider controls - but then in the /64 that is announced by RA, you can choose whatever host id / interface identifier you want, and I can see people wanting to use something easy to type and remember, like ::1. I must be missing something here... Exactly how do you communicate an interface identifier via RA? Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Hi, On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote: I think this change is useful (without having looked at the actual code), for exactly these reasons. With the IPv6CP handshake, you'll arrive at something the provider controls - but then in the /64 that is announced by RA, you can choose whatever host id / interface identifier you want, and I can see people wanting to use something easy to type and remember, like ::1. I must be missing something here... Exactly how do you communicate an interface identifier via RA? You don't. Which is the point :-) - ISP announces the RA, end user gets to pick whatever prefix they like, inside the /64 announced. One could argue that they should only use the interface identifier that PPP/IPv6CP negotiated, but in practice, that would break at least privacy addresses - so what I've seen so far is if the ISP sends RA with A=1, the user can use any address in that /64 they want. Which even holds true for 3G networks that force link-local to very specific IDs. 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 pgpu1T_DL5sDR.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Gert Doering g...@greenie.muc.de writes: On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote: I think this change is useful (without having looked at the actual code), for exactly these reasons. With the IPv6CP handshake, you'll arrive at something the provider controls - but then in the /64 that is announced by RA, you can choose whatever host id / interface identifier you want, and I can see people wanting to use something easy to type and remember, like ::1. I must be missing something here... Exactly how do you communicate an interface identifier via RA? You don't. Which is the point :-) - ISP announces the RA, end user gets to pick whatever prefix they like, inside the /64 announced. One could argue that they should only use the interface identifier that PPP/IPv6CP negotiated, but in practice, that would break at least privacy addresses - so what I've seen so far is if the ISP sends RA with A=1, the user can use any address in that /64 they want. Which even holds true for 3G networks that force link-local to very specific IDs. Ah, right. Yes, sure, as long as DAD is OK you can configure global addresses with interface identifiers different from the one negotiated by IPV6CP. Personally I pick a nice looking /128 from the delegated prefix instead and configure it on the PPP interface (assuming that's the uplink), because the delegated prefix is more likely to be static and shorter than any RA prefix. But unfortunately RFC3633 doesn't really allow this, if we're going to be strict. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
On 18.06.2013 14:32, Gert Doering wrote: Hi, On Tue, Jun 18, 2013 at 02:14:18PM +0200, Bjørn Mork wrote: I think this change is useful (without having looked at the actual code), for exactly these reasons. With the IPv6CP handshake, you'll arrive at something the provider controls - but then in the /64 that is announced by RA, you can choose whatever host id / interface identifier you want, and I can see people wanting to use something easy to type and remember, like ::1. I must be missing something here... Exactly how do you communicate an interface identifier via RA? You don't. Which is the point :-) - ISP announces the RA, end user gets to pick whatever prefix they like, inside the /64 announced. One could argue that they should only use the interface identifier that PPP/IPv6CP negotiated, but in practice, that would break at least privacy addresses - so what I've seen so far is if the ISP sends RA with A=1, the user can use any address in that /64 they want. Which even holds true for 3G networks that force link-local to very specific IDs. gert Allright fine, you guys have convinced me. I just commited a modified version of that patch to trunk. Please test it. @Thomas: Please post patches against trunk and not AA in the future. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [odhcp6c] [PATCH] Add -H option to override the host id
Am 18.06.2013 14:57, schrieb Steven Barth: Allright fine, you guys have convinced me. I just commited a modified version of that patch to trunk. Please test it. I see that your version is slightly more straightforward. For the moment, I can only say that my original version works fine on AA, I'll backport your version to my next AA build (in case it hasn't been backported by then). Thanks for your time and all your work on the openwrt ipv6 stack, it has proven very useful to me. @Thomas: Please post patches against trunk and not AA in the future. That was sort of an accident, but when I realized it, I already sent it, and the patch was trivial enough. I'll try to remember next time. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Firewall3] Issue regarding masq_dest/masq_src parameters
Since the upstep to firewall3 in the attitude adjustment branch I notice NAT masquerade issues when the masq_dest and/or masq_src parameters are set to 0.0.0.0/0 in the zone topic. The running config for the zone lan and wan is as follows : firewall.@zone[0]=zone firewall.@zone[0].name=lan firewall.@zone[0].network=lan firewall.@zone[0].input=ACCEPT firewall.@zone[0].output=ACCEPT firewall.@zone[0].forward=REJECT firewall.@zone[1]=zone firewall.@zone[1].name=wan firewall.@zone[1].network=wan wan6 firewall.@zone[1].input=DROP firewall.@zone[1].output=ACCEPT firewall.@zone[1].forward=DROP firewall.@zone[1].masq=1 firewall.@zone[1].mtu_fix=1 firewall.@zone[1].masq_dest=0.0.0.0/0 Dump of the iptables NAT chain zone_wan_postrouting root@OpenWrt:/etc/init.d# iptables -t nat -L zone_wan_postrouting -v -n Chain zone_wan_postrouting (5 references) pkts bytes target prot opt in out source destination 3 200 postrouting_wan_rule all -- * * 0.0.0.0/0 0.0.0.0/0/* user chain for postrouting */ 0 0 MASQUERADE all -- * * 0.0.0.0/00.0.0.0 The masquerade rule has as destination value 0.0.0.0 (and breaks connectivity) although the masq_dest UCI parameter is set to 0.0.0.0/0. If the masq_dest UCI parameter is not specified; the dump of iptables NAT chain zone_wan_postrouting : root@OpenWrt:/etc/init.d# iptables -t nat -L zone_wan_postrouting -v -n Chain zone_wan_postrouting (5 references) pkts bytes target prot opt in out source destination 0 0 postrouting_wan_rule all -- * * 0.0.0.0/0 0.0.0.0/0/* user chain for postrouting */ 0 0 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 Br, Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Firewall3] Issue regarding masq_dest/masq_src parameters
On 18.06.2013 15:49, Hans Dedecker wrote: Since the upstep to firewall3 in the attitude adjustment branch I notice NAT masquerade issues when the masq_dest and/or masq_src parameters are set to 0.0.0.0/0 http://0.0.0.0/0 in the zone topic. Don't do it then? Setting a value of 0.0.0.0/0 is not the same as not specifying a value. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Firewall3] Issue regarding masq_dest/masq_src parameters
On 18.06.2013 15:49, Hans Dedecker wrote: * Since the upstep to firewall3 in the attitude adjustment branch I notice** NAT masquerade issues when the masq_dest and/or masq_src parameters are** set to 0.0.0.0/0 http://0.0.0.0/0 in the zone topic.* Don't do it then? Setting a value of 0.0.0.0/0 is not the same as not specifying a value. ~ Jow Same configuration was running with the replaced firewall scripts; the value in the iptables dump in that case was 0.0.0.0/0 and was working fine. Upstep to firewall3 introduces this NAT connectivity issue and means UCI is not backwards compatible Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Firewall3] Issue regarding masq_dest/masq_src parameters
Fixed with https://dev.openwrt.org/changeset/36960, https://dev.openwrt.org/changeset/36962 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
