Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Johan Beisser (jbcaustic.org)
Date: Tue May 14 2013 - 18:14:54 CDT
On Tue, May 14, 2013 at 3:13 PM, Stuart Henderson <stuspacehopper.org> wrote:
> On 2013-05-14, Mattias Lindgren <mlindgrenrunelind.net> wrote:
>> I'm using a OpenBSD 5.3 (release) machine as my router connecting
>> to Comcast. Comcast provides native IPv6 access, however it does
>> so a little bit differently than what is probably best practice.
>> I use wide-dhcpv6-20080615p2 from ports to get an address on my
>> outside interface, as well as a prefix which gets assigned to my
>> inside interface. However, the default route is announced via Route
> That is pretty common practice for ISPs doing IPv6 (see RFC 6204),
> but OpenBSD doesn't support it at present.
I tried to use the DHCPv6 client but found it didn't quite work right
(no assigned IP to the interface). Rtsold gets the prefix and gateway
just fine, but Comcast assigns a /64 prefix to my firewall. But, the
DHCPv6 server won't actually issue me a V6 IP (as of yet..)
I've assigned an arbitrary IPv6 address to my firewall, and it can
reach out over Comcast's network with no problem.
I started to look at setting up an internal local network before
getting distracted by paying work.
>> However since I would also like for my router to forward
>> IPv6 packets, I'm not sure of how to make it work. Rtsol states that
>> net.inet6.ip6.forwarding=0. I've tried running rtsol with forwarding
>> set to 1, but it complains and does not grab a default route. The other
>> option would be to manually set the v6 default route, but I'd prefer to
>> not have to do that. Does anyone know of a workaround for this issue?
> Manually setting the route is the only current workaround afaik.
I might give that a shot. The RA (at least the one near me) gives a
link local advert (fe80::) with a /64 prefix.
> FreeBSD turned accept_rtadv into a per-interface flag which can be
> set (only) on the "upstream" interface so you can continue to send
> adv's on the "downstream" interfaces.
That seems to be a good solution, but not necessarily the "right" one.