Re: SOHO IPv6 router problems
Em 13-07-2015 17:42, Daniel Melameth escreveu: I’d love it if someone would be open to spending the time to do a “PHD” write up on getting OpenBSD base usable as a stateless IPv6 router/firewall with Comcast. While I agree that write ups like these should be unnecessary, and man pages should have all the relevant information needed for someone to do this without hand holding, IPv6 is still “new,” has a lot of moving parts and still isn’t widely used. For one, I didn’t know all of this could be done without DHCPv6 so I’m very interested in doing this at home. Well, I prepared myself studying IPv6 years ago using tunnel brokers like sixxs. You can find a lot of relevant information on the man pages, but, since a man page is better to be simple and clean, some things need RFC's digging and/or source code. I will take some time in the near future to try to port a NDP proxy to OpenBSD. I'm currently using a bridge firewall between my CPE and the client machines. While this works, the machines get the DNS servers from the CPE, and not from my firewall, which is far from optimal. But I can at least filter on the packets as they pass through my bridge. Better to have the clients talk directly to the CPE,which, by the way, comes from factory with no firewall enabled. Any connection from outside gets routed to the clients. Better enable firewall on your clients too. You never know when you will connect to an IPv6 enabled network that routes every incoming connection. I know, I know, end to end connectivity, etc. But people aren't prepared to this. The CPE routers today do not allow incoming connections, because we have to use NAT. So it would never know where to forward the packets to, unless you tell it to. But, with IPv6 end to end, there will be a lot of people that will be caught off guard, specially because almost every OS (except OpenBSD) will automatically configure IPv6 if present. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
On Mon, Jul 13, 2015 at 2:42 PM, Daniel Melameth wrote: > I’d love it if someone would be open to spending the time to do a > “PHD” write up on getting OpenBSD base usable as a stateless IPv6 > router/firewall with Comcast. While I agree that write ups like these > should be unnecessary, and man pages should have all the relevant > information needed for someone to do this without hand holding, IPv6 > is still “new,” has a lot of moving parts and still isn’t widely used. > For one, I didn’t know all of this could be done without DHCPv6 so I’m > very interested in doing this at home. > > Thanks. I meant to say PHD as in “Push Here Dummy.” Cheers.
Re: SOHO IPv6 router problems
On Mon, Jul 13, 2015 at 1:17 PM, Michael McConville wrote: > On Mon, Jul 13, 2015 at 03:12:50PM -0300, Giancarlo Razzolini wrote: >> The client doesn't need inbound UDP ports to be open. The OpenBSD >> firewall do, if you're using DHCPv6 to configure it. If using SLAAC, >> only RS and RA icmp messages are needed. Since stateless configuration >> is done using multicast (ff02) and link-local (fe80) addresses, no >> need to worry. You can even make a rule allowing only your CPE >> link-local, if you want. > > I stand corrected. > > I just disabled all of my IPv6-related pf exceptions and it still works. > I must have inadvertantly fixed something else when I added them. > >> You don't need DHCPv6. I use stateless both for my firewall getting >> it's IPv6 address from the CPE and for it advertising the prefix on >> the internal network. Most modern systems can configure the dns using >> stateless configuration. So only a subset of ICMPv6 messages need to >> be allowed both on the router and clients. > > Also correct. I just checked, and Comcast home routers let you choose > between stateless and stateful IPv6 config in their control panel. > > Sorry for the noise, > Michael I’d love it if someone would be open to spending the time to do a “PHD” write up on getting OpenBSD base usable as a stateless IPv6 router/firewall with Comcast. While I agree that write ups like these should be unnecessary, and man pages should have all the relevant information needed for someone to do this without hand holding, IPv6 is still “new,” has a lot of moving parts and still isn’t widely used. For one, I didn’t know all of this could be done without DHCPv6 so I’m very interested in doing this at home. Thanks.
Re: SOHO IPv6 router problems
On Mon, Jul 13, 2015 at 03:12:50PM -0300, Giancarlo Razzolini wrote: > The client doesn't need inbound UDP ports to be open. The OpenBSD > firewall do, if you're using DHCPv6 to configure it. If using SLAAC, > only RS and RA icmp messages are needed. Since stateless configuration > is done using multicast (ff02) and link-local (fe80) addresses, no > need to worry. You can even make a rule allowing only your CPE > link-local, if you want. I stand corrected. I just disabled all of my IPv6-related pf exceptions and it still works. I must have inadvertantly fixed something else when I added them. > You don't need DHCPv6. I use stateless both for my firewall getting > it's IPv6 address from the CPE and for it advertising the prefix on > the internal network. Most modern systems can configure the dns using > stateless configuration. So only a subset of ICMPv6 messages need to > be allowed both on the router and clients. Also correct. I just checked, and Comcast home routers let you choose between stateless and stateful IPv6 config in their control panel. Sorry for the noise, Michael
Re: SOHO IPv6 router problems
Em 13-07-2015 14:42, Michael McConville escreveu: Part of it was that you need inbound IPv6 ICMP and UDP ports open. This seems like a fundamentally bad idea because it prevents client machines from just blocking all incoming connections (something I've done since starting with OpenBSD). The client doesn't need inbound UDP ports to be open. The OpenBSD firewall do, if you're using DHCPv6 to configure it. If using SLAAC, only RS and RA icmp messages are needed. Since stateless configuration is done using multicast (ff02) and link-local (fe80) addresses, no need to worry. You can even make a rule allowing only your CPE link-local, if you want. Also, DHCPv4 seems to do fine without incoming connections. Maybe there's a good reason for them, though. DHCPv4 needs port 68 udp to be open. The difference is that many firewall implementations (not pf) have this allowed in their default configuration. Here's the guide that solved my pf woes: http://pivotallabs.com/configuring-freebsd-9-1-as-an-ipv6-dhcp-client/ I was considering trying to develop a tool to make it a smoother process. However, it increasingly seems like a consequence of DHCPv6 being unnecessarily complex. You don't need DHCPv6. I use stateless both for my firewall getting it's IPv6 address from the CPE and for it advertising the prefix on the internal network. Most modern systems can configure the dns using stateless configuration. So only a subset of ICMPv6 messages need to be allowed both on the router and clients. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
On Mon, Jul 13, 2015 at 04:39:39PM +, Christian Weisgerber wrote: > On 2015-07-02, Patrik Lundin wrote: > > > In summary, using the following commands (together with ip6 > > forwarding enabled) allows us to have a working setup without any > > other manual intervention: > >=== > > # ifconfig em0 inet6 autoconf > > # ifconfig em1 inet6 autoconf > > # dhcp6c -Df -c /etc/dhcp6c.conf em0 > > # rtadvd em1 > >=== > > > > But like stated initially, we do not really like the idea of > > enabling autoconf on em1. > > Once you get that far, you might notice that dynamic addresses for > your network are rather inconvenient. You'll need to update all > references to your internal hosts in > * pf.conf > * DNS zones > * ... any other daemons that might refer to them ... > > You'll also need to distribute the addresses to your hosts. If you > don't like SLAAC-style addresses, you'll need DHCPv6. Which you might > also need for the nameserver, NTP server, etc. > > Out of the box, OpenBSD is poorly equipped for all of this. I found setting up IPv6 on a Comcast home network to be very painful. Part of it was that you need inbound IPv6 ICMP and UDP ports open. This seems like a fundamentally bad idea because it prevents client machines from just blocking all incoming connections (something I've done since starting with OpenBSD). Also, DHCPv4 seems to do fine without incoming connections. Maybe there's a good reason for them, though. Here's the guide that solved my pf woes: http://pivotallabs.com/configuring-freebsd-9-1-as-an-ipv6-dhcp-client/ I was considering trying to develop a tool to make it a smoother process. However, it increasingly seems like a consequence of DHCPv6 being unnecessarily complex.
Re: SOHO IPv6 router problems
Em 13-07-2015 13:39, Christian Weisgerber escreveu: Once you get that far, you might notice that dynamic addresses for your network are rather inconvenient. You'll need to update all references to your internal hosts in * pf.conf * DNS zones * ... any other daemons that might refer to them ... And you need to reload you pf rules when any of them changes (specially privacy addresses). You'll also need to distribute the addresses to your hosts. If you don't like SLAAC-style addresses, you'll need DHCPv6. Which you might also need for the nameserver, NTP server, etc. This for a IPv6 only network. My approach is to keep the RFC 1918 internal IPv4 net for these. Out of the box, OpenBSD is poorly equipped for all of this. Agreed. On the other hand it's quite equipped in the routing and firewalling of IPv6 networks. Even NAT64 is simple to do with pf. I recently switched ISPs and the new one offers native IPv6 the TR-187 way, but given that level of pain I'll stay with my SixXS tunnel and my static /48 for the time being. I'm doing the exact same thing. My tunnel have an acceptable latency and, since I'm using it only for a site to site VPN, I'll stay with it for a while. But my ISP is implementing native IPv6 and sooner or later I'll have to deal with this. So will you. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
On 2015-07-02, Patrik Lundin wrote: > In summary, using the following commands (together with ip6 forwarding > enabled) > allows us to have a working setup without any other manual intervention: >=== > # ifconfig em0 inet6 autoconf > # ifconfig em1 inet6 autoconf > # dhcp6c -Df -c /etc/dhcp6c.conf em0 > # rtadvd em1 >=== > > But like stated initially, we do not really like the idea of enabling autoconf > on em1. Once you get that far, you might notice that dynamic addresses for your network are rather inconvenient. You'll need to update all references to your internal hosts in * pf.conf * DNS zones * ... any other daemons that might refer to them ... You'll also need to distribute the addresses to your hosts. If you don't like SLAAC-style addresses, you'll need DHCPv6. Which you might also need for the nameserver, NTP server, etc. Out of the box, OpenBSD is poorly equipped for all of this. I recently switched ISPs and the new one offers native IPv6 the TR-187 way, but given that level of pain I'll stay with my SixXS tunnel and my static /48 for the time being. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: SOHO IPv6 router problems
On Mon, Jul 06, 2015 at 03:51:04PM +, Christian Weisgerber wrote: > > FWIW, this scheme is specified here: > > TR-187: IPv6 for PPP Broadband Access > https://www.broadband-forum.org/technical/download/TR-187.pdf > Thanks for the information! There is no PPP involved in our situation but otherwise it seems to match what we are working with. -- Patrik Lundin
Re: SOHO IPv6 router problems
On 2015-06-30, Patrik Lundin wrote: > The setup looks like this: We are supposed to get a default route on the > outside interface (em0), using autoconf, and then recieve an IPv6 prefix > on the inside (em1) using DHCP6-PD (prefix delegation). FWIW, this scheme is specified here: TR-187: IPv6 for PPP Broadband Access https://www.broadband-forum.org/technical/download/TR-187.pdf -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: SOHO IPv6 router problems
On Thu, Jul 02, 2015 at 08:18:52AM +0200, Stefan Sperling wrote: > > Your windows box is trying to reach address ff02:2::1:ff51:78e9, a mix of > 'all routers' ff02::2 and em1's link local address. > But there is no address in the ff02::/32 prefix on em1 for some reason. > Note that em0 does have an address in this prefix: ff02::1:2%em0 > This got me thinking. It was obvious that the ff02 entry was created by running "autoconf" on em0. When we initially tried this on 5.6 dhcp6c failed setting the address on em1 at all if we did not first prime the interface with "ifconfig em1 inet6 eui64". It turns out, if we set "autoconf" on both em0 and em1 we can get the setup to work. This is a bit ugly though since we do not want to accept router advertisements on the inside interface. Below are transcripts from trying to get this to work first using "eui64" (since I assumed this was the most minimalistic way to prime em1). This still required the manual creation of the /64 route. Second is the attempt using "autoconf" on the inside interface which did not require the manual route creation, but the route still pops up in a bit of a "strange" way. See below for details. Before starting: === # ifconfig lo0: flags=8049 mtu 32768 priority: 0 groups: lo inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 em0: flags=8843 mtu 1500 lladdr d0:50:99:51:78:e8 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet XX.XXX.8.17 netmask 0xff80 broadcast XX.XXX.8.127 em1: flags=8843 mtu 1500 lladdr d0:50:99:51:78:e9 priority: 0 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.212.254 netmask 0xff00 broadcast 192.168.212.255 enc0: flags=0<> priority: 0 groups: enc status: active pflog0: flags=141 mtu 33144 priority: 0 groups: pflog === # netstat -rn Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultXX.XXX.8.1 UGS4 2081 - 8 em0 XX.XXX.8.0/25 XX.XXX.8.17UC 10 - 8 em0 XX.XXX.8.1 00:0c:db:f6:1c:00 UHLc 10 - 8 em0 XX.XXX.8.17d0:50:99:51:78:e8 UHLl 00 - 1 lo0 XX.XXX.8.127 XX.XXX.8.17UHb00 - 1 em0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHl10 32768 1 lo0 192.168.212/24 192.168.212.254UC 60 - 8 em1 192.168.212.1 0c:c4:7a:31:d7:38 UHLc 0 82 - 8 em1 192.168.212.2 00:25:90:ae:ca:4a UHLc 0 119 - 8 em1 192.168.212.3 b8:27:eb:22:72:8b UHLc 0 342 - 8 em1 192.168.212.4 b8:27:eb:32:0b:66 UHLc 0 118 - 8 em1 192.168.212.136ec:a8:6b:f9:6e:35 UHLc 0 138 - 8 em1 192.168.212.252d0:bf:9c:45:0c:a0 UHLc 0 945 - 8 em1 192.168.212.254d0:50:99:51:78:e9 HLl00 - 1 lo0 192.168.212.255192.168.212.254UHb00 - 1 em1 224/4 127.0.0.1 URS00 32768 8 lo0 Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface ::/104 ::1UGRS 0 0 32768 8 lo0 ::/96 ::1UGRS 0 0 32768 8 lo0 ::1::1UHl 14 0 32768 1 lo0 ::127.0.0.0/104::1UGRS 0 0 32768 8 lo0 ::224.0.0.0/100::1UGRS 0 0 32768 8 lo0 ::255.0.0.0/104::1UGRS 0 0 32768 8 lo0 :::0.0.0.0/96 ::1UGRS 0 0 32768 8 lo0 2002::/24 ::1UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1UGRS 0 0 32768 8 lo0 fe80::/10 ::1UGRS 0 0 32768 8 lo0 fe80::%lo0/64 fe80::1%lo0U 0 0 32768
Re: SOHO IPv6 router problems
On Wed, Jul 01, 2015 at 11:57:01PM +0200, Patrik Lundin wrote: > ff02::/16 ::1UGRS > 00 32768 8 lo0 > ff02::%em0/32 fe80::d250:99ff:fe51:78e8%em0 UC > 10 - 4 em0 > ff02::1:2%em0 link#1 UHLc > 02 - 4 em0 > ff02::%em1/32 fe80::d250:99ff:fe51:78e9%em1 UC > 00 - 4 em1 > ff02::%lo0/32 ::1UC > 00 32768 4 lo0 > nd6_ns_input: NS packet from non-neighbor > nd6_ns_input: src=:XXX::a01:30c1:d3d7:a677:d09e > nd6_ns_input: dst=ff02:2::1:ff51:78e9 > nd6_ns_input: tgt=fe80::d250:99ff:fe51:78e9 Your windows box is trying to reach address ff02:2::1:ff51:78e9, a mix of 'all routers' ff02::2 and em1's link local address. But there is no address in the ff02::/32 prefix on em1 for some reason. Note that em0 does have an address in this prefix: ff02::1:2%em0
Re: SOHO IPv6 router problems
On Wed, Jul 01, 2015 at 04:47:25PM +0200, Patrik Lundin wrote: > > We will retry using a snapshot and see where we end up. > We have now attempted the same setup described earlier, using a current snapshot. The first problem of not getting a default route via autoconf when forwarding was enabled has been solved. The route appears as expeced The other problems still remain though. Initial ifconfig/routing table before enabling v6 stuff: # ifconfig lo0: flags=8049 mtu 32768 priority: 0 groups: lo inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 em0: flags=8843 mtu 1500 lladdr d0:50:99:51:78:e8 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet XX.XXX.8.17 netmask 0xff80 broadcast XX.XXX.8.127 em1: flags=8843 mtu 1500 lladdr d0:50:99:51:78:e9 priority: 0 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.212.254 netmask 0xff00 broadcast 192.168.212.255 enc0: flags=0<> priority: 0 groups: enc status: active pflog0: flags=141 mtu 33144 priority: 0 groups: pflog === === # netstat -rn Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultXX.XXX.8.1 UGS4 158401 - 8 em0 XX.XXX.8.0/25 XX.XXX.8.17UC 10 - 8 em0 XX.XXX.8.1 00:0c:db:f6:1c:00 UHLc 10 - 8 em0 XX.XXX.8.17d0:50:99:51:78:e8 UHLl 00 - 1 lo0 XX.XXX.8.127 XX.XXX.8.17UHb00 - 1 em0 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHl10 32768 1 lo0 192.168.212/24 192.168.212.254UC 60 - 8 em1 192.168.212.1 0c:c4:7a:31:d7:38 UHLc 0 268 - 8 em1 192.168.212.2 00:25:90:ae:ca:4a UHLc 0 604809 - 8 em1 192.168.212.3 b8:27:eb:22:72:8b UHLc 0 815 - 8 em1 192.168.212.4 b8:27:eb:32:0b:66 UHLc 0 152 - 8 em1 192.168.212.136ec:a8:6b:f9:6e:35 UHLc 1 586 - 8 em1 192.168.212.252d0:bf:9c:45:0c:a0 UHLc 0 1091 - 8 em1 192.168.212.254d0:50:99:51:78:e9 HLl00 - 1 lo0 192.168.212.255192.168.212.254UHb00 - 1 em1 224/4 127.0.0.1 URS00 32768 8 lo0 Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface ::/104 ::1UGRS 0 0 32768 8 lo0 ::/96 ::1UGRS 0 0 32768 8 lo0 ::1::1UHl 14 0 32768 1 lo0 ::127.0.0.0/104::1UGRS 0 0 32768 8 lo0 ::224.0.0.0/100::1UGRS 0 0 32768 8 lo0 ::255.0.0.0/104::1UGRS 0 0 32768 8 lo0 :::0.0.0.0/96 ::1UGRS 0 0 32768 8 lo0 2002::/24 ::1UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1UGRS 0 0 32768 8 lo0 fe80::/10 ::1UGRS 0 0 32768 8 lo0 fe80::%lo0/64 fe80::1%lo0U 0 0 32768 4 lo0 fe80::1%lo0fe80::1%lo0UHl0 0 32768 1 lo0 fec0::/10 ::1UGRS 0 0 32768 8 lo0 ff01::/16 ::1UGRS 0 0 32768 8 lo0 ff01::%lo0/32 ::1UC 0 0 32768 4 lo0 ff02::/16 ::1UGRS 0 0 32768 8 lo0 ff02::%lo0/32 ::1UC 0 0 32768 4 lo0 === The sysctl settings: === net.inet6.ip6.forwarding=1 net.inet6.icmp6.nd6_debug=1 === Enabling
Re: SOHO IPv6 router problems
Em 01-07-2015 16:29, Florian Obser escreveu: What I was trying to say: ifconfig IF inet6 autoconf was supposed to do the same as rtsol IF before I removed it. Turns out it does more; it allows sending of router solicitations and accepts (part) of router advertisments even if forwarding is enabled. That was an oversight and wasn't supposed to be possible. So don't depend on it, it can't possibly work. On the other hand it's not really a bug either. More of a missing feature. So using it hurts, so don't do it;) That missing feature was added in -current This is consistent with behaviour I've seen on -stable. Good to know that it's fixed on -current. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
On Wed, Jul 01, 2015 at 04:47:25PM +0200, Patrik Lundin wrote: > On Wed, Jul 01, 2015 at 08:59:55AM +, Florian Obser wrote: > > > > yes, that was an artifact of moving the sending of router > > solicitations from rtsol(8) to the kernel. rtsol(8) flat out refused > > to do anything with forwarding enabled. There is no such check in > > place for "ifconfig inet6 autoconf". But as you note weird stuff > > starts to happen on 5.7 if you do this. > > > > However, if you continue using the "rtsol" keyword in hostname.if that > > check is still in place (in netstart(8)). I think this is a case of > > "Doctor, Doctor! If I do this it hurts." ;) > > > > We do not use the "rtsol" keyword anywhere when testing, so I do not > feel we qualify for the "it hurts when i do this" category :). > Heh. For the archives: What I was trying to say: ifconfig IF inet6 autoconf was supposed to do the same as rtsol IF before I removed it. Turns out it does more; it allows sending of router solicitations and accepts (part) of router advertisments even if forwarding is enabled. That was an oversight and wasn't supposed to be possible. So don't depend on it, it can't possibly work. On the other hand it's not really a bug either. More of a missing feature. So using it hurts, so don't do it ;) That missing feature was added in -current -- I'm not entirely sure you are real.
Re: SOHO IPv6 router problems
Em 01-07-2015 11:47, Patrik Lundin escreveu: Thanks for the pointers, the first commit was pointed at by another developer off list, and seems like exactly the fix needed for the initial issue we ran into. I've ran exactly into this same issue, and had to add the default router manually. Your thread, and mine (a few days ago): https://marc.info/?t=14352773773&r=1&w=2 They show how IPv6 is being implemented in the real world. Most ISP's are being forced to implement IPv6 and all sorts of things, mostly bad, are coming out of it. In my case, I ended up implementing a bridge. But I believe in the near future I will have to use a NDP proxy, because my CPE advertise itself as a dns server, both in SLAAC and through DHCPv6, so it overrides my own configuration. But it's good to know that OpenBSD current is moving into RFC 7084 direction. Please, report back to the list if you can make it work with -current. Cheers, Giancarlo Razzolini
Re: SOHO IPv6 router problems
On Wed, Jul 01, 2015 at 08:59:55AM +, Florian Obser wrote: > > yes, that was an artifact of moving the sending of router > solicitations from rtsol(8) to the kernel. rtsol(8) flat out refused > to do anything with forwarding enabled. There is no such check in > place for "ifconfig inet6 autoconf". But as you note weird stuff > starts to happen on 5.7 if you do this. > > However, if you continue using the "rtsol" keyword in hostname.if that > check is still in place (in netstart(8)). I think this is a case of > "Doctor, Doctor! If I do this it hurts." ;) > We do not use the "rtsol" keyword anywhere when testing, so I do not feel we qualify for the "it hurts when i do this" category :). > > This changed in -current, so please test that report back. > These two commits are relevant: > https://marc.info/?l=openbsd-cvs&m=142730518728044&w=2 > https://marc.info/?l=openbsd-cvs&m=143359644918955&w=2 > > We don't have this extra knob (the "1" case). You can enable v6 > forwarding in sysctl and enable acceptance of router advertisments per > interface. So if you don't want to accept router advertisments when > forwarding is enabled don't configure the interfaces that way. > > I'm not sure if this will solve all your problems but it should solve > some. This should cut down your report considerably and should make it > easier to work through the rest. > Thanks for the pointers, the first commit was pointed at by another developer off list, and seems like exactly the fix needed for the initial issue we ran into. We will retry using a snapshot and see where we end up. -- Patrik Lundin
Re: SOHO IPv6 router problems
On Wed, Jul 01, 2015 at 07:24:25AM +, David Dahlberg wrote: > > No global inet6 address available. Looks like autoconf did not succeed. > As I stated in my original message we are only supposed to recieve a default route via autoconf, not an IP address. The "Managed address configuration" flag is set in the RA, meaning IP assignment should be achieved in "some other way". In our case this is handled by DHCP6. Having a global address on the outside interface is not necessary in out case either, since the default route uses an fe80 address. > > defrouter_select: called unexpectedly (forwarding=1) > > nd6_ra_input: invalid prefixlen 48 for rfc2374 prefix > > :XXX:::, ignored > > === > > See? ;-) > >From the error message it is not obvious if it is only the prefix that is being ignored, or the RA as a whole. However, since disabling ip6 forwarding allowed the route to be created, the RA is still considered for other information. > > It is a common assumtion, that autoconf only works on /64 prefixes. > Even Wikipedia claimed this, citing the wrong RFC, which did not even > support their claim m( > > True is, that SLAAC is defined in RFC 4826, that it es defined > regardless of the prefix length, but /64 is assumed to be the usual > one. Also true is, hat OpenBSD seems to require a 64 bit prefix, just > like most other implementations. > > I cannot estimate, how much work it would be to support other prefix > lengths (e.g. as EUI-64 cannot be uses on non-64-bit prefixes) and > whether or not it is a worthwhile target to persue. > There indeed seems to be some confusion how v6 should behave in the real world as opposed to (some) papers. This is one of the reasons I wanted to lift the issues with the mailing list. -- Patrik Lundin
Re: SOHO IPv6 router problems
On Tue, Jun 30, 2015 at 08:27:03PM +0200, Patrik Lundin wrote: > This is where possibly unexpected things start happening. Our first > note is that no default route is appearing for IPv6: yes, that was an artifact of moving the sending of router solicitations from rtsol(8) to the kernel. rtsol(8) flat out refused to do anything with forwarding enabled. There is no such check in place for "ifconfig inet6 autoconf". But as you note weird stuff starts to happen on 5.7 if you do this. However, if you continue using the "rtsol" keyword in hostname.if that check is still in place (in netstart(8)). I think this is a case of "Doctor, Doctor! If I do this it hurts." ;) [...] > Any input on this would be much appreciated! As a side note, related to > the "should i handle RAs when I am a router": another friend noted that the > Linux camp allows two levels of this setting: > > https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt: > === > accept_ra - INTEGER > Accept Router Advertisements; autoconfigure using them. > > It also determines whether or not to transmit Router > Solicitations. If and only if the functional setting is to > accept Router Advertisements, Router Solicitations will be > transmitted. > > Possible values are: > 0 Do not accept Router Advertisements. > 1 Accept Router Advertisements if forwarding is disabled. > 2 Overrule forwarding behaviour. Accept Router Advertisements > even if forwarding is enabled. > > Functional default: enabled if local forwarding is disabled. > disabled if local forwarding is enabled. > === > > So basically, setting it to 0 disables the handling of router advertisements, > setting it to 1 accepts them given that forwarding is disabled (pretty close > to what we are seeing OpenBSD doing right now when handling of RAs are > enabled) > and 2 makes it handle the RAs without any regard of forwarding status (what we > would probably need in this SOHO case). > This changed in -current, so please test that report back. These two commits are relevant: https://marc.info/?l=openbsd-cvs&m=142730518728044&w=2 https://marc.info/?l=openbsd-cvs&m=143359644918955&w=2 We don't have this extra knob (the "1" case). You can enable v6 forwarding in sysctl and enable acceptance of router advertisments per interface. So if you don't want to accept router advertisments when forwarding is enabled don't configure the interfaces that way. I'm not sure if this will solve all your problems but it should solve some. This should cut down your report considerably and should make it easier to work through the rest. > -- > Patrik Lundin > -- I'm not entirely sure you are real.
Re: SOHO IPv6 router problems
Am Dienstag, den 30.06.2015, 20:27 +0200 schrieb Patrik Lundin:
> We start out by enabling autoconf on em0 to get a default route via
> fe80:
> ===
> # ifconfig em0 inet6 autoconf
> ===
>
> The interface configuration now looks like this:
[...]
> em0: flags=208843
> mtu 1500
> lladdr d0:50:99:51:78:e8
> priority: 0
> groups: egress
> media: Ethernet autoselect (1000baseT full-duplex)
> status: active
> inet XX.XXX.8.17 netmask 0xff80 broadcast XX.XXX.8.127
> inet6 fe80::d250:99ff:fe51:78e8%em0 prefixlen 64 scopeid 0x1
No global inet6 address available. Looks like autoconf did not succeed.
> defrouter_select: called unexpectedly (forwarding=1)
> nd6_ra_input: invalid prefixlen 48 for rfc2374 prefix
> :XXX:::, ignored
> ===
See? ;-)
Okay, I probably know the problem:
As RFC 2374 (superseded by 3587) is mentioned, SLAAC assumes a local
part of 64:
nd6_rtr.c:
| /* aggregatable unicast address, rfc2374 */
| if ((pi->nd_opt_pi_prefix.s6_addr8[0] & 0xe0) == 0x20
| && pi->nd_opt_pi_prefix_len != 64) {
| nd6log((LOG_INFO,
| "nd6_ra_input: invalid prefixlen "
| "%d for rfc2374 prefix %s, ignored\n",
| pi->nd_opt_pi_prefix_len,
| inet_ntop(AF_INET6, &pi->nd_opt_pi_prefix,
| src, sizeof(src;
| continue;
|}
It is a common assumtion, that autoconf only works on /64 prefixes.
Even Wikipedia claimed this, citing the wrong RFC, which did not even
support their claim m(
True is, that SLAAC is defined in RFC 4826, that it es defined
regardless of the prefix length, but /64 is assumed to be the usual
one. Also true is, hat OpenBSD seems to require a 64 bit prefix, just
like most other implementations.
I cannot estimate, how much work it would be to support other prefix
lengths (e.g. as EUI-64 cannot be uses on non-64-bit prefixes) and
whether or not it is a worthwhile target to persue.
Cheers,
David
