Re: IPv6 routing problems with vether and vmm

[Peter Hessler]

On 2024 Jun 04 (Tue) at 12:46:11 +0300 (+0300), Kapetanakis Giannis wrote:
:
:On 04/06/2024 11:59, Stuart Henderson wrote:
:> On 2024-06-04, Kapetanakis Giannis  wrote:
:>> On 04/06/2024 08:50, jrmu wrote:
: When you manage a hypervisor, using only 1x/64 is less than ideal. It's 
just
: not enough because you can have more than 1 'type of usage'. I always
: request at least 1x/56.
:>>> Thanks. I spoke with the ISP and he gave me a larger subnet,
:>>>
:>>> 2602:fccf:4::/48, I've been experimenting it by manually adding the
:>>> route and it seems to have worked.
:>>
:>> ::/48 is probably the provider's network, not yours.
:> Unlikely. If the provider have their own assignment from an RIR it's
:> probably at least a /32. /48 is common for a single user running
:> multiple networks, many providers (even just end-user DSL/FTTP ISPs)
:> give their users a /48 that they can subnet as they wish.
:
:
:Well, our University's whole network is /48, so I thought this is the normal.
:
:G
:

In the RIPE Region the ISP get a /29 allocation as a LIR by default, or a
/48 if it is PI space.  In other regions it varies, but OP gave an
address from ARIN and that seems to be a /36 allocation.

A /48 or /56 to customers is fairly common for a lot of networks.


-- 
Advertising is a valuable economic factor because it is the cheapest
way of selling goods, particularly if the goods are worthless.
-- Sinclair Lewis

Re: IPv6 routing problems with vether and vmm

[Kapetanakis Giannis]

On 04/06/2024 11:59, Stuart Henderson wrote:
> On 2024-06-04, Kapetanakis Giannis  wrote:
>> On 04/06/2024 08:50, jrmu wrote:
 When you manage a hypervisor, using only 1x/64 is less than ideal. It's 
 just
 not enough because you can have more than 1 'type of usage'. I always
 request at least 1x/56.
>>> Thanks. I spoke with the ISP and he gave me a larger subnet,
>>>
>>> 2602:fccf:4::/48, I've been experimenting it by manually adding the
>>> route and it seems to have worked.
>>
>> ::/48 is probably the provider's network, not yours.
> Unlikely. If the provider have their own assignment from an RIR it's
> probably at least a /32. /48 is common for a single user running
> multiple networks, many providers (even just end-user DSL/FTTP ISPs)
> give their users a /48 that they can subnet as they wish.


Well, our University's whole network is /48, so I thought this is the normal.

G

Re: IPv6 routing problems with vether and vmm

[Willy Manga]

Hi,
On 04/06/2024 09:50, jrmu wrote:

When you manage a hypervisor, using only 1x/64 is less than ideal. It's just
not enough because you can have more than 1 'type of usage'. I always
request at least 1x/56.


Thanks. I spoke with the ISP and he gave me a larger subnet,

2602:fccf:4::/48, I've been experimenting it by manually adding the
route and it seems to have worked.


Great to know it is working for you now. But as much as possible, work 
with 1x/64 assigned to your interface and not 1x/48. Worst case 1x/127, 
1x/126 assigned especially for point to point links. Check RFC6164 [1]



1. https://datatracker.ietf.org/doc/html/rfc6164


--
Willy Manga

Re: IPv6 routing problems with vether and vmm

[Stuart Henderson]

On 2024-06-04, Kapetanakis Giannis  wrote:
> On 04/06/2024 08:50, jrmu wrote:
>>> When you manage a hypervisor, using only 1x/64 is less than ideal. It's just
>>> not enough because you can have more than 1 'type of usage'. I always
>>> request at least 1x/56.
>> Thanks. I spoke with the ISP and he gave me a larger subnet,
>>
>> 2602:fccf:4::/48, I've been experimenting it by manually adding the
>> route and it seems to have worked.
>
>
>::/48 is probably the provider's network, not yours.

Unlikely. If the provider have their own assignment from an RIR it's
probably at least a /32. /48 is common for a single user running
multiple networks, many providers (even just end-user DSL/FTTP ISPs)
give their users a /48 that they can subnet as they wish.

-- 
Please keep replies on the mailing list.

Re: IPv6 routing problems with vether and vmm

[Kapetanakis Giannis]

On 04/06/2024 08:50, jrmu wrote:
>> When you manage a hypervisor, using only 1x/64 is less than ideal. It's just
>> not enough because you can have more than 1 'type of usage'. I always
>> request at least 1x/56.
> Thanks. I spoke with the ISP and he gave me a larger subnet,
>
> 2602:fccf:4::/48, I've been experimenting it by manually adding the
> route and it seems to have worked.


::/48 is probably the provider's network, not yours.

G

Re: IPv6 routing problems with vether and vmm

[jrmu]

> When you manage a hypervisor, using only 1x/64 is less than ideal. It's just
> not enough because you can have more than 1 'type of usage'. I always
> request at least 1x/56.

Thanks. I spoke with the ISP and he gave me a larger subnet,

2602:fccf:4::/48, I've been experimenting it by manually adding the
route and it seems to have worked.

-- 
jrmu
IRCNow (https://ircnow.org)


signature.asc
Description: PGP signature

Re: IPv6 routing problems with vether and vmm

[Stuart Henderson]

On 2024/05/21 20:30, jrmu wrote:
> Greetings,
> 
> > > I also don't control the entire /48.
> > >
> > > Here is the information I was given:
> > >
> > > My IPv6 Address Subnet: 2602:fccf:400:41::/64
> > > Hypervisor' IPv6 Gateway: 2602:fccf:400::1
> > >
> > > I was only given a /64.
> > 
> > So you should use a /64 prefix length not the /48 which you have.
> > 
> > See EXAMPLES in route(8) for how to set the gateway.
> 
> Please excuse my ignorance here, as I am unfamiliar with networking. Can
> you explain why /64 is the correct prefix length?

Because that is the information they gave you:

"Here is the information I was given:
My IPv6 Address Subnet: 2602:fccf:400:41::/64"

> I am confused because it seems not analogous to IPv4.

Your provider has decided to use a different config method for v6
compared to v4.

They probably have a route for the whole /64 to your MAC address to
avoid having to do neighbour discovery (NDP) for addresses in your
subnet.

If they did NDP, they have to try to find the MAC address to send
packets for that individual address. So if that address isn't in
the (limited size) NDP cache their router would need to buffer the
packet, try to resolve the address, if that address is not configured
anywhere they'd need to wait for a timeout before possibly generating a
host-unreachable icmp6 message and discarding the packet. These are all
slow operations using cpu resources on a router where those resources
are usually quite limited.

Now consider the number of addresses in the subnet and that someone
on the internet can send packets to any address. There are similar
issues for v4 (using ARP rather than NDP to find MAC addresses) but the
scale is vastly different - and most addresses will be in use anyway
so most of the time a randomly addressed packet will already have the
MAC address in the ARP cache.

There are other ways to handle this (e.g. add a small 'link net' between
the router and your host) but config for that is a bit more hassle
to do on the provider's side - typically with that setup you'd have
a separate vlan per customer too, as well as the route table entry
across the provider's network for the link net, using more resources on
routers/switches.

> In the IPv4 example, my address is 104.167.241.211, the gateway is
> 104.167.241.193, and the subnet mask 255.255.255.192. The network length
> then is /26. I don't control the entire /26 subnet, only one single IPv4
> address within it, but my network would have a prefix length of /26.

All of the /26 is probably directly reachable (using ARP to lookup
the MAC address). And vice-versa, other addresses in the /26 will
be expecting to be able to send packets to you directly rather than
going via the gateway.

> Isn't using a prefix length of /48 the same in the case of IPv6? I don't
> control the entire /48, but the gateway 2602:fccf:400::1 shares the
> first 48 network bits with my IPv6 address 2602:fccf:400:41::

You almost certainly can't reach the rest of the /48 without going
via the gateway.

> If I were to set the routing prefix length to 64, then I could manually
> add an extra route to the IPv6 gateway. But then, wouldn't I want to set
> my IPv4 address with a subnet mask of 255.255.255.255, so that the
> network length would be 32 rather than 26, and also add a manual route
> there?

Some providers do do that for v4, but if they had they'd be telling you
to use the /32. There's a lot less reason to do it for v4 though.

Re: IPv6 routing problems with vether and vmm

[jrmu]

Greetings,

> > I also don't control the entire /48.
> >
> > Here is the information I was given:
> >
> > My IPv6 Address Subnet: 2602:fccf:400:41::/64
> > Hypervisor' IPv6 Gateway: 2602:fccf:400::1
> >
> > I was only given a /64.
> 
> So you should use a /64 prefix length not the /48 which you have.
> 
> See EXAMPLES in route(8) for how to set the gateway.

Please excuse my ignorance here, as I am unfamiliar with networking. Can
you explain why /64 is the correct prefix length?

I am confused because it seems not analogous to IPv4.

In the IPv4 example, my address is 104.167.241.211, the gateway is
104.167.241.193, and the subnet mask 255.255.255.192. The network length
then is /26. I don't control the entire /26 subnet, only one single IPv4
address within it, but my network would have a prefix length of /26.

Isn't using a prefix length of /48 the same in the case of IPv6? I don't
control the entire /48, but the gateway 2602:fccf:400::1 shares the
first 48 network bits with my IPv6 address 2602:fccf:400:41::

If I were to set the routing prefix length to 64, then I could manually
add an extra route to the IPv6 gateway. But then, wouldn't I want to set
my IPv4 address with a subnet mask of 255.255.255.255, so that the
network length would be 32 rather than 26, and also add a manual route
there?

-- 
jrmu
IRCNow (https://ircnow.org)


signature.asc
Description: PGP signature

Re: IPv6 routing problems with vether and vmm

[Willy Manga]

.
On 21/05/2024 22:04, jrmu wrote:

Greetings,


Here is my configuration:



Inside hypervisor:



hypervisor$ cat /etc/hostname.em1
inet 104.167.241.211 0xffc0
inet6 2602:fccf:400:41:: 48


Why are you using 48 as mask here and not 64?


I don't have control over the hypervisor's gateway, that is provided by
my ISP.


Okay but my question still apply here. em1 IPv6 address should have /64 
as mask and not 48.




Your gateway must have a (static) route saying we can reach 2602:fccf::/36
(or a any smaller subnet you will use in your hypervisor) via
em1.IPv6.address. I will pick 2602:fccf:400::/48 as the block you plan to
use for all your VMs.


I also don't control the entire /48.

Here is the information I was given:

My IPv6 Address Subnet: 2602:fccf:400:41::/64
Hypervisor' IPv6 Gateway: 2602:fccf:400::1
I was only given a /64.


When you manage a hypervisor, using only 1x/64 is less than ideal. It's 
just not enough because you can have more than 1 'type of usage'. I 
always request at least 1x/56.


You have at least 2 solutions:

1. Use  the prefix 2602:fccf:400:41::/64 for all your interfaces . For 
em1 , avoid the first address. It works but some device will not happily 
accept your packets. Use anything else between  2602:fccf:400:41::1 and 
2602:fccf:400:41:::: . Again use 64 as your mask and not 
48 on em1.


2. Ask your ISP 2 things:
2.1 Establish point to point with you from 1 prefix
2.2 Route you *another* prefix (as explained in my previous email).

If they find difficult to route more than 1x/64 (that will be a shame ) 
they can stick to 1x/64 but honestly it should not be a big deal.



--
Willy Manga

Re: IPv6 routing problems with vether and vmm

[Stuart Henderson]

On 2024-05-21, jrmu  wrote:
>
> --qhuug7BO2jqFJSbi
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Greetings,
>
>> > Here is my configuration:
>>=20
>> > Inside hypervisor:
>>=20
>> > hypervisor$ cat /etc/hostname.em1
>> > inet 104.167.241.211 0xffc0
>> > inet6 2602:fccf:400:41:: 48
>>=20
>> Why are you using 48 as mask here and not 64?
>
> I don't have control over the hypervisor's gateway, that is provided by
> my ISP.
>
>> Your gateway must have a (static) route saying we can reach 2602:fccf::/36
>> (or a any smaller subnet you will use in your hypervisor) via
>> em1.IPv6.address. I will pick 2602:fccf:400::/48 as the block you plan to
>> use for all your VMs.
>
> I also don't control the entire /48.
>
> Here is the information I was given:
>
> My IPv6 Address Subnet: 2602:fccf:400:41::/64
> Hypervisor' IPv6 Gateway: 2602:fccf:400::1
>
> I was only given a /64.

So you should use a /64 prefix length not the /48 which you have.

See EXAMPLES in route(8) for how to set the gateway.

Re: IPv6 routing problems with vether and vmm

[jrmu]

Greetings,

> > Here is my configuration:
> 
> > Inside hypervisor:
> 
> > hypervisor$ cat /etc/hostname.em1
> > inet 104.167.241.211 0xffc0
> > inet6 2602:fccf:400:41:: 48
> 
> Why are you using 48 as mask here and not 64?

I don't have control over the hypervisor's gateway, that is provided by
my ISP.

> Your gateway must have a (static) route saying we can reach 2602:fccf::/36
> (or a any smaller subnet you will use in your hypervisor) via
> em1.IPv6.address. I will pick 2602:fccf:400::/48 as the block you plan to
> use for all your VMs.

I also don't control the entire /48.

Here is the information I was given:

My IPv6 Address Subnet: 2602:fccf:400:41::/64
Hypervisor' IPv6 Gateway: 2602:fccf:400::1

I was only given a /64.

Thanks for your help.

-- 
jrmu
IRCNow (https://ircnow.org)


signature.asc
Description: PGP signature

Re: IPv6 routing problems with vether and vmm

[Willy Manga]

Hi


On 21/05/2024 04:01, jrmu wrote:
> Here is my configuration:

> Inside hypervisor:

> hypervisor$ cat /etc/hostname.em1
> inet 104.167.241.211 0xffc0
> inet6 2602:fccf:400:41:: 48

Why are you using 48 as mask here and not 64?

Here is a suggestion in term of routing.

From your configuration, you can even restrict the mask here since it's 
a point to point between your hypervisor and your gateway.

something like

/etc/hostname.em1
inet6 2602:fccf::2 127

should be okay.
Of course you configure your gateway with

2602:fccf::3/127


> hypervisor$ cat /etc/mygate
> 104.167.241.193
> 2602:fccf:400::1

From my suggestion, you can change that IPv6 with 2602:fccf::3

Your gateway must have a (static) route saying we can reach 
2602:fccf::/36 (or a any smaller subnet you will use in your hypervisor) 
via em1.IPv6.address. I will pick 2602:fccf:400::/48 as the block you 
plan to use for all your VMs.


Assuming your gateway is running OpenBSD, the route will be:

route add -inet6 2602:fccf:400::/48  2602:fccf::2

Now from the hypervisor, you originate that prefix. e.g

route add -inet6 -blackhole  2602:fccf:400::/48 ::1

All packets in that block by default is 'swallowed' here.

Now any subnet used by any interface (like vether0) here will be 
reachable from the Internet and of course the VM as well will reach 
other networks.



--
Willy Manga

IPv6 routing problems with vether and vmm

[jrmu]

Greetings,

I'm running into issues with IPv6 networking using vmm with an openbsd guest, 
both running OpenBSD 7.5. Setup and diagnostic info here: 

https://paste.ircnow.org/05ejwpmf4hi74xuz0h2n

I am setting up an openbsd virtual machine inside vmm using this
configuration:

https://wiki.ircnow.org/?n=Vmm.Configure

IPv4 networking inside the virtual machine works fine, but IPv6 is
failing. I can use the hypervisor's IPv6 address 2602:fccf:400:41:: but
am unable to use IPv6 from the virtual machines.

Here is my configuration:

Inside hypervisor:

hypervisor$ cat /etc/hostname.em1
inet 104.167.241.211 0xffc0
inet6 2602:fccf:400:41:: 48
hypervisor$ cat /etc/mygate
104.167.241.193
2602:fccf:400::1
hypervisor$ cat /etc/hostname.vether0
inet 104.167.241.49 255.255.255.248
inet6 2602:fccf:400:41::1 64
hypervisor$ cat /etc/hostname.bridge0
add vether0

Inside virtual machine:
vm# cat /etc/hostname.vio0
inet 104.167.241.51 0xffc0
inet6 2602:fccf:400:41:51:: 64
vm# cat /etc/mygate
104.167.241.49
2602:fccf:400:41::1

Hypervisor ifconfig, route, arp, and ndp:

hypervisor$ ifconfig
lo0: flags=2008049 mtu 32768
index 4 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff00
em0: flags=8802 mtu 1500
lladdr 00:25:90:5a:2d:93
index 1 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
em1: flags=8843 mtu 1500
lladdr 00:25:90:5a:2d:92
index 2 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 104.167.241.211 netmask 0xffc0 broadcast 104.167.241.255
inet6 fe80::225:90ff:fe5a:2d92%em1 prefixlen 64 scopeid 0x2
inet6 2602:fccf:400:41:: prefixlen 48
enc0: flags=0<>
index 3 priority 0 llprio 3
groups: enc
status: active
bridge0: flags=41 mtu 1500
description: switch1-switch0
index 5 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
tap1 flags=3
port 15 ifpriority 0 ifcost 0
tap2 flags=3
port 10 ifpriority 0 ifcost 0
tap0 flags=3
port 8 ifpriority 0 ifcost 0
vether0 flags=3
port 6 ifpriority 0 ifcost 0
vether0: flags=8943 mtu 1500
lladdr fe:e1:ba:d0:6f:27
index 6 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 104.167.241.49 netmask 0xfff8 broadcast 104.167.241.55
inet6 fe80::fce1:baff:fed0:6f27%vether0 prefixlen 64 scopeid 0x6
inet6 2602:fccf:400:41::1 prefixlen 64
pflog0: flags=141 mtu 33136
index 7 priority 0 llprio 3
groups: pflog
tap0: flags=8943 mtu 1500
lladdr fe:e1:ba:d1:76:b7
description: vm1-if0-mattbsd
index 8 priority 0 llprio 3
groups: tap
status: active
tap2: flags=8943 mtu 1500
lladdr fe:e1:ba:d3:f5:02
description: vm3-if0-errorbsd
index 10 priority 0 llprio 3
groups: tap
status: active
tap1: flags=8943 mtu 1500
lladdr fe:e1:ba:d8:99:f9
description: vm2-if0-jrmu
index 15 priority 0 llprio 3
groups: tap
status: active

hypervisor$ route -n show

Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default104.167.241.193UGS   1146767 - 8 em1  
224/4  127.0.0.1  URS00 32768 8 lo0  
104.167.241.192/26 104.167.241.211UCn112147 - 4 em1  
104.167.241.48/29  104.167.241.49 UCn60 - 4 vether0
104.167.241.48 link#6 UHLc   0   17 - 3 vether0
104.167.241.49 fe:e1:ba:d0:6f:27  UHLl   0 8098 - 1 vether0
104.167.241.50 e8:8b:27:7b:7a:01  UHLc   0 1439 - 3 vether0
104.167.241.51 e8:8b:27:7b:7a:02  UHLc   022740 - 3 vether0
104.167.241.52 link#6 UHLc   0   84 - 3 vether0
104.167.241.53 link#6 UHLc   0   15 - 3 vether0
104.167.241.54 e8:8b:27:7b:7a:03  UHLc   0 1069 - 3 vether0
104.167.241.55 104.167.241.49 UHb0 1005 - 1 vether0
104.167.241.193ac:1f:6b:fe:ca:98  UHLch  1 5705 - 3 em1  
104.167.241.21100:25:90:5a:2d:92  UHLl   0 9427 - 1 em1  
104.167.241.255104.167.241.211UHb0 4455 - 1 em1  
127/8  127.0.0.1  UGRS   00 32768 8 lo0  
127.0.0.1  127.0.0.1  UHhl   12 32768 1 lo0  

Internet6:
Destination Gateway 
Flags   Refs  Use   Mtu  

Re: Openbsd pf firewall ipv6 routing

[Daniel Melameth]

On Thu, Jul 29, 2021 at 10:10 PM Irshad  wrote:
> I have following setup at home ,I am sharing internet 
> with neighbour , our ISP provides IPV6
> With 2001:16a2:cdd2:xx00::/56 prefix delegation , until now I was only using 
> IPv4 NAT with following setup
>
> ISP-RouterOPENBSD/PFVLAN10—openWRT—Macbook
> |
> VLAN20__openWRT  some Devices
> |
> |
> Neighbour Access Point
>
> Recently I tried to enable IPv6 in openbsd
> i can ping6 google.com from openbsd firewall itself
> but i cannot route ipv6 traffic from LAN side devices
> i can get ipv6 address assigned to my LAN devices
>
> ps:isp provides only dynamic ip's not static
>
> /etc/hostname.iwn0
> inet6 autoconf -soii -temporary
> inet 192.168.100.177 255.255.255.0
>
> Ifconfig iwn0
> inet 192.168.100.177 netmask 0xff00 broadcast 192.168.100.255
> inet6 2001:16a2:cdd2:xx00:xxx:faff:fe92:c7c6 prefixlen 64 autoconf pltime 
> 86081 vltime 86081
>
> This is connecting to ISP Router with ipv4 LAN side ip
>
> And NAT with pf firewall
>
> vlan10
> /etc/hostname.vlan10
> 192.168.10.1/24 192.168.10.255 parent em0 vnetid 10
> inet6 autoconf
>
> ifconfig vlan10
> inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255
> inet6 fe80::5e26:aff:fe0e:d6ea%vlan10 prefixlen 64 scopeid 0x8
>
> ip forwarding for ipv6
> sysctl net.inet6.ip6.forwarding=1
>
>  rad.conf(5)
> interface vlan10 {
> prefix 2001:16a2:cdd2:xx01::/64
> }
>
> openbsd  netstat -nr
> DestinationGatewayFlags   
> Refs  Use   Mtu  Prio Iface
> defaultfe80::1%iwn0   UGS
> 0   90 -12 iwn0
>
> macOS netstat -nr
> Internet6:
> Destination Gateway Flags 
> Netif Expire
> default fe80::5e26:aff:fe0e:d6ea%en0UGcg  
>   en0
> 2001:16a2:cdd2:9500::/64link#4  UC
>   en0
> 2001:16a2:cdd2:xx00:1c07:xxc4:1577:55e1 8:6d:41:de:6d:4aUHL   
>   lo0

You might want to consider using dhcpcd, in ports, to help you with
the PD and doling out /64s to your networks.

Openbsd pf firewall ipv6 routing

[Irshad]

Hi 

I have following setup at home ,I am sharing internet 
with neighbour , our ISP provides IPV6 
With 2001:16a2:cdd2:xx00::/56 prefix delegation , until now I was only using 
IPv4 NAT with following setup


ISP-RouterOPENBSD/PFVLAN10—openWRT—Macbook 
|
VLAN20__openWRT  some Devices 
|   

|
Neighbour Access Point 

Recently I tried to enable IPv6 in openbsd 
i can ping6 google.com from openbsd firewall itself
but i cannot route ipv6 traffic from LAN side devices 
i can get ipv6 address assigned to my LAN devices

ps:isp provides only dynamic ip's not static


/etc/hostname.iwn0
inet6 autoconf -soii -temporary
inet 192.168.100.177 255.255.255.0

Ifconfig iwn0
inet 192.168.100.177 netmask 0xff00 broadcast 192.168.100.255
inet6 2001:16a2:cdd2:xx00:xxx:faff:fe92:c7c6 prefixlen 64 autoconf pltime 86081 
vltime 86081

This is connecting to ISP Router with ipv4 LAN side ip 

And NAT with pf firewall

vlan10 
/etc/hostname.vlan10
192.168.10.1/24 192.168.10.255 parent em0 vnetid 10
inet6 autoconf

ifconfig vlan10
inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255
inet6 fe80::5e26:aff:fe0e:d6ea%vlan10 prefixlen 64 scopeid 0x8


ip forwarding for ipv6
sysctl net.inet6.ip6.forwarding=1

 rad.conf(5) 
interface vlan10 {
prefix 2001:16a2:cdd2:xx01::/64
}

openbsd  netstat -nr 
DestinationGatewayFlags   Refs  
Use   Mtu  Prio Iface
defaultfe80::1%iwn0   UGS0  
 90 -12 iwn0


macOS netstat -nr
Internet6:
Destination Gateway Flags   
  Netif Expire
default fe80::5e26:aff:fe0e:d6ea%en0UGcg
en0
2001:16a2:cdd2:9500::/64link#4  UC  
en0
2001:16a2:cdd2:xx00:1c07:xxc4:1577:55e1 8:6d:41:de:6d:4aUHL 
lo0



Thanks 
Irshad 

Re: troubles with IPv6 routing to VMD guests

[Max Parmer]

On Sat, Mar 17, 2018 at 05:21:53PM -0700, Max Parmer wrote:
> I've been having a good time running some VMD guests on 6.2 and assigning them
> external IPs which are binat'd to them by the VM host. Recently I learned my
> hosting provider delegates a /64 to it's dedicated boxes and thought this 
> might
> be an interesting scenario to improve, and possibly simplify, by routing IPv6
> directly to my guests.
> 
> To start, I ensured that IPv6 was properly functional on the host:
> > # cat /etc/hostname.em0
> > inet6 autoconf
> > inet6 2607:53xx:6x:7a3b:: 64 eui64
> > inet xxx.xxx.211.59 255.255.255.0
> > inet alias xxx.xxx.219.108 255.255.255.0
> > inet alias xxx.xx.248.240 255.255.255.0
> > inet alias xxx.xx.248.241 255.255.255.0
> > inet alias xxx.xx.248.242 255.255.255.0
> > inet alias xxx.xx.248.243 255.255.255.0
> > # cat /etc/mygate
> > xxx.xxx.211.254
> > fe80::205:73ff:fea0:1%em0
> > # ifconfig em0
> > em0: flags=208843 mtu 1500
> > lladdr 0c:c4:7a:45:37:34
> > index 1 priority 0 llprio 3
> > groups: egress
> > media: Ethernet autoselect (1000baseT full-duplex,master,rxpause)
> > status: active
> > inet6 fe80::ec4:7aff:fe45:3734%em0 prefixlen 64 scopeid 0x1
> > inet6 2607:53xx:6x:7a3b:ec4:7aff:fe45:3734 prefixlen 64
> > inet xxx.xxx.211.59 netmask 0xff00 broadcast xxx.xxx.211.255
> > inet xxx.xxx.219.108 netmask 0xff00 broadcast xxx.xxx.219.255
> > inet xxx.xx.248.240 netmask 0xff00 broadcast xxx.xx.248.255
> > inet xxx.xx.248.241 netmask 0xff00 broadcast xxx.xx.248.255
> > inet xxx.xx.248.242 netmask 0xff00 broadcast xxx.xx.248.255
> > inet xxx.xx.248.243 netmask 0xff00 broadcast xxx.xx.248.255
> > # ifconfig vether0
> > vether0: flags=8943 mtu 1500
> > lladdr 00:00:d3:00:d0:0d
> > index 5 priority 0 llprio 3
> > groups: vether
> > media: Ethernet autoselect
> > status: active
> > inet6 fe80::200:d3ff:fe00:d00d%vether0 prefixlen 64 scopeid 0x5
> > inet 10.0.23.1 netmask 0xff00 broadcast 10.0.23.255
> > # ifconfig bridge0
> > bridge0: flags=41
> > description: switch1-local
> > index 6 llprio 3
> > groups: bridge
> > priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
> > designated: id 00:00:00:00:00:00 priority 0
> > vether0 flags=3
> > port 5 ifpriority 0 ifcost 0
> > tap0 flags=3
> > port 8 ifpriority 0 ifcost 0
> > Addresses (max cache: 100, timeout: 240):
> > 00:00:d3:00:12:00 tap0 1 flags=0<>
> > # slaacctl show interface em0
> > em0:
> >  index:   1 running: yes privacy: yes
> > lladdr: 0c:c4:7a:45:37:34
> >  inet6: fe80::ec4:7aff:fe45:3734%em0
> > Router Advertisement from fe80::205:73ff:fea0:1%em0
> > received: 2018-03-17 20:01:39; 143s ago
> > Cur Hop Limit:  64, M: 0, O: 0, Router Lifetime:  1800s
> > Default Router Preference: Medium
> > Reachable Time: 0ms, Retrans Timer: 0ms
> > prefix: 2607:53xx:6x:7aff:ff:ff:ff:ff/56
> > On-link: 1, Autonomous address-configuration: 1
> > vltime:2592000, pltime: 604800
> > Default router proposals
> > id:1, state:  CONFIGURED
> > router: fe80::205:73ff:fea0:1%em0
> > router lifetime:   1800
> > Preference: Medium
> > updated: 2018-03-17 20:01:39; 143s ago, timeout:   1642s
> > # route -nv show -inet6
> > Routing tables
> > 
> > Internet6:
> > DestinationGatewayFlags   
> > Refs  Use   Mtu  Prio Iface Label
> > defaultfe80::205:73ff:fea0:1%em0  UGS   
> >  04 -56 em0   "slaacd"
> > ::/96  ::1UGRS  
> >  00 32768 8 lo0
> > ::/104 ::1UGRS  
> >  00 32768 8 lo0
> > ::1::1UHhl  
> > 14   28 32768 1 lo0
> > ::127.0.0.0/104::1UGRS  
> >  00 32768 8 lo0
> > ::224.0.0.0/100::1UGRS  
> >  00 32768 8 lo0
> > ::255.0.0.0/104::1UGRS  
> >  00 32768 8 lo0
> > :::0.0.0.0/96  ::1UGRS  
> >  00 32768 8 lo0
> > 2002::/24  ::1UGRS  
> >  00 32768 8 lo0
> > 2002:7f00::/24 ::1UGRS  
> >  00 32768 8 lo0
> > 2002:e000::/20 

troubles with IPv6 routing to VMD guests

[Max Parmer]

I've been having a good time running some VMD guests on 6.2 and assigning them
external IPs which are binat'd to them by the VM host. Recently I learned my
hosting provider delegates a /64 to it's dedicated boxes and thought this might
be an interesting scenario to improve, and possibly simplify, by routing IPv6
directly to my guests.

To start, I ensured that IPv6 was properly functional on the host:
> # cat /etc/hostname.em0
> inet6 autoconf
> inet6 2607:53xx:6x:7a3b:: 64 eui64
> inet xxx.xxx.211.59 255.255.255.0
> inet alias xxx.xxx.219.108 255.255.255.0
> inet alias xxx.xx.248.240 255.255.255.0
> inet alias xxx.xx.248.241 255.255.255.0
> inet alias xxx.xx.248.242 255.255.255.0
> inet alias xxx.xx.248.243 255.255.255.0
> # cat /etc/mygate
> xxx.xxx.211.254
> fe80::205:73ff:fea0:1%em0
> # ifconfig em0
> em0: flags=208843 mtu 1500
>   lladdr 0c:c4:7a:45:37:34
>   index 1 priority 0 llprio 3
>   groups: egress
>   media: Ethernet autoselect (1000baseT full-duplex,master,rxpause)
>   status: active
>   inet6 fe80::ec4:7aff:fe45:3734%em0 prefixlen 64 scopeid 0x1
>   inet6 2607:53xx:6x:7a3b:ec4:7aff:fe45:3734 prefixlen 64
>   inet xxx.xxx.211.59 netmask 0xff00 broadcast xxx.xxx.211.255
>   inet xxx.xxx.219.108 netmask 0xff00 broadcast xxx.xxx.219.255
>   inet xxx.xx.248.240 netmask 0xff00 broadcast xxx.xx.248.255
>   inet xxx.xx.248.241 netmask 0xff00 broadcast xxx.xx.248.255
>   inet xxx.xx.248.242 netmask 0xff00 broadcast xxx.xx.248.255
>   inet xxx.xx.248.243 netmask 0xff00 broadcast xxx.xx.248.255
> # ifconfig vether0
> vether0: flags=8943 mtu 1500
>   lladdr 00:00:d3:00:d0:0d
>   index 5 priority 0 llprio 3
>   groups: vether
>   media: Ethernet autoselect
>   status: active
>   inet6 fe80::200:d3ff:fe00:d00d%vether0 prefixlen 64 scopeid 0x5
>   inet 10.0.23.1 netmask 0xff00 broadcast 10.0.23.255
> # ifconfig bridge0
> bridge0: flags=41
>   description: switch1-local
>   index 6 llprio 3
>   groups: bridge
>   priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
>   designated: id 00:00:00:00:00:00 priority 0
>   vether0 flags=3
>   port 5 ifpriority 0 ifcost 0
>   tap0 flags=3
>   port 8 ifpriority 0 ifcost 0
>   Addresses (max cache: 100, timeout: 240):
>   00:00:d3:00:12:00 tap0 1 flags=0<>
> # slaacctl show interface em0
> em0:
>index:   1 running: yes privacy: yes
>   lladdr: 0c:c4:7a:45:37:34
>inet6: fe80::ec4:7aff:fe45:3734%em0
>   Router Advertisement from fe80::205:73ff:fea0:1%em0
>   received: 2018-03-17 20:01:39; 143s ago
>   Cur Hop Limit:  64, M: 0, O: 0, Router Lifetime:  1800s
>   Default Router Preference: Medium
>   Reachable Time: 0ms, Retrans Timer: 0ms
>   prefix: 2607:53xx:6x:7aff:ff:ff:ff:ff/56
>   On-link: 1, Autonomous address-configuration: 1
>   vltime:2592000, pltime: 604800
>   Default router proposals
>   id:1, state:  CONFIGURED
>   router: fe80::205:73ff:fea0:1%em0
>   router lifetime:   1800
>   Preference: Medium
>   updated: 2018-03-17 20:01:39; 143s ago, timeout:   1642s
> # route -nv show -inet6
> Routing tables
> 
> Internet6:
> DestinationGatewayFlags   
> Refs  Use   Mtu  Prio Iface Label
> defaultfe80::205:73ff:fea0:1%em0  UGS
> 04 -56 em0   "slaacd"
> ::/96  ::1UGRS   
> 00 32768 8 lo0
> ::/104 ::1UGRS   
> 00 32768 8 lo0
> ::1::1UHhl  
> 14   28 32768 1 lo0
> ::127.0.0.0/104::1UGRS   
> 00 32768 8 lo0
> ::224.0.0.0/100::1UGRS   
> 00 32768 8 lo0
> ::255.0.0.0/104::1UGRS   
> 00 32768 8 lo0
> :::0.0.0.0/96  ::1UGRS   
> 00 32768 8 lo0
> 2002::/24  ::1UGRS   
> 00 32768 8 lo0
> 2002:7f00::/24 ::1UGRS   
> 00 32768 8 lo0
> 2002:e000::/20 ::1UGRS   
> 00 32768 8 lo0
> 2002:ff00::/24 ::1UGRS   
> 

Re: IPV6 routing issue

[Giancarlo Razzolini]

Em 25-07-2015 11:50, Stuart Henderson escreveu:
 Actually that's fine, a point-to-point interface can be unnumbered,
 or in the case of IPv6, it can just have a link-local address.

In my case I don't have a ppp interface, my CPE talks to my OpenBSD
firewall through normal LAN.

 DHCPv6 PD would give you a /64 or (if allowed by the ISP) a larger
 prefix to assign to interfaces as you choose. Normally you would
 assign this to internal interface/s, but assuming the ISP allows
 more than a /64, you *can* apply part of that delegation to the
 PPP interface if you would like it to have a globally routable
 address.
This is one of my problems, my ISP would only give me a /64 prefix, not
a /56 or other manageable size. I can ask a PD from the CPE, but the
only prefix already is delegated to the CPE itself. So the CPE keeps
asking me neighbor solicitation messages, and won't route the packets.
Unless I use NDP proxying, I can't do normal routing. As I stated, I did
a bridge. When I have some free time I'll visit the NDP proxy again.
Perhaps I'll be able to port some of the existing solutions to OpenBSD.

Cheers,
Giancarlo Razzolini

Re: IPV6 routing issue

[Stuart Henderson]

On 2015-06-26, Christian Weisgerber na...@mips.inka.de wrote:
 On 2015-06-26, Giancarlo Razzolini grazzol...@gmail.com wrote:

  I've recently changed my ISP and they have native IPv6. My customer 
 premises equipment, which is a GPON, supports both stateless as DHCPv6 
 on it's LAN interface. I want to put a OpenBSD firewall between this CPE 
 and my internal network.

 So you have TWO networks.  One between the CPE and your OpenBSD
 firewall, and one containing the firewall and your internal machines.

 I'm using OpenBSD 5.7 stable. My CPE receive a 
 /64 prefix delegation from my ISP.

 So you get ONE network address.

 You can't use a single network address for two networks.  This has
 nothing to do with IPv6.  It's the same with IPv4.

Actually that's fine, a point-to-point interface can be unnumbered,
or in the case of IPv6, it can just have a link-local address.

So PPP can *only* configure a link-local address. To get a globally
routable address you must use another method, either SLAAC, DHCPv6 PD,
or static configuration.

SLAAC would only give you an address on a /64 for use on the PPP
interface itself.

DHCPv6 PD would give you a /64 or (if allowed by the ISP) a larger
prefix to assign to interfaces as you choose. Normally you would
assign this to internal interface/s, but assuming the ISP allows
more than a /64, you *can* apply part of that delegation to the
PPP interface if you would like it to have a globally routable
address.

Re: IPV6 routing issue

[Gregor Best]

On Fri, Jun 26, 2015 at 03:07:41PM +0200, Patrik Lundin wrote:
 [...]
 This would explain why you see neighbour solicitations on the outside
 interface. The upstream router is not aware that the prefix should be
 routed to you.
 [...]

I've also seen something similar. A friend of mine suggested [0], though
I haven't tried it. I circumvented my problem by using a routed /64 on a
Hurricane Electric tunnel.

Depending on your hosting provider, their setup might actually be
vulnerable to a neat little trick: If you see NDP requests for prefixes
that are not your own while tcpdump'ing your external interface, you
might be able to add an address inside one of those networks to your
external interface and have it reachable from the outside, so that in
effect you can use an IPv6 address that's outside of your prefix.

[0]: https://github.com/DanielAdolfsson/ndppd

-- 
Gregor Best

Re: IPV6 routing issue

[Giancarlo Razzolini]

Em 26-06-2015 10:43, Gregor Best escreveu:

I've also seen something similar. A friend of mine suggested [0], though
I haven't tried it. I circumvented my problem by using a routed /64 on a
Hurricane Electric tunnel.


I wouldn't like to use a tunnel, since my ISP is (kind of) providing 
native IPv6 connectivity.




Depending on your hosting provider, their setup might actually be
vulnerable to a neat little trick: If you see NDP requests for prefixes
that are not your own while tcpdump'ing your external interface, you
might be able to add an address inside one of those networks to your
external interface and have it reachable from the outside, so that in
effect you can use an IPv6 address that's outside of your prefix.


Since my CPE is working in routed mode, I don't see anything like that. 
But, I believe that this will be a problem for many ISP's, since I doubt 
they will implement authenticated NDP. I will look into this ndp proxy 
daemon, since I couldn't make the ndp(8) proxy functionality to work. 
Thank all you guys who replied. Both on and off list.


Cheers,
Giancarlo Razzolini

Re: IPV6 routing issue

[Patrik Lundin]

I have struggled with a similar problem a few years back. Can it be that
the upstream equipment does not create a route for the delegated prefix
pointing to your openbsd machine?

This would explain why you see neighbour solicitations on the outside
interface. The upstream router is not aware that the prefix should be
routed to you.

-- 
Patrik Lundin

- Original message -
From: Giancarlo Razzolini grazzol...@gmail.com
To: Openbsd-Misc misc@openbsd.org
Subject: IPV6 routing issue
Date: Thu, 25 Jun 2015 21:06:51 -0300

HI all,

 I've recently changed my ISP and they have native IPv6. My customer 
premises equipment, which is a GPON, supports both stateless as DHCPv6 
on it's LAN interface. I want to put a OpenBSD firewall between this CPE 
and my internal network. I'm using OpenBSD 5.7 stable. My CPE receive a 
/64 prefix delegation from my ISP. Unfortunately, this is a dynamic 
prefix, so I can't configure anything manually.

 I've managed to get wide-dhcp6 working and requesting the prefix to 
be delegated to my internal network. After that, all I needed to do was 
to run rtadvd on my internal interface, and my internal LAN machines 
began to be autoconfigurated getting ip's from the delegated prefix.

 The OpenBSD firewall has 2 ipv6 addresses. One on the WAN interface 
and another on the LAN interface. If I use ping6 to ping any ipv6 host 
from my firewall, I can ping them with no problems. But, If I ping 
setting the source to be the ipv6 address from the internal interface, 
it won't work. Also, no machine from my LAN can connect to any host 
through ipv6.

 I've inspected the traffic with tcpdump, and I can see the packets 
leaving my network and getting on the destination. The problem is the 
packets never gets back. My CPE equipment keeps asking for neighbour 
solicitation asking who has the ipv6 address, but the OpenBSD firewall 
never replies, so the packts get dropped. I'm currently with PF 
disabled. But I had the same problem with it enabled and with the 
default firewall configuration. I'm trying first to get ipv6 
connectivity working to after filter the packets. Anyone had a similar 
issue?

Cheers,
Giancarlo Razzolini

Re: IPV6 routing issue

[Giancarlo Razzolini]

Em 26-06-2015 10:43, Gregor Best escreveu:
https://github.com/DanielAdolfsson/ndppd 
This doesn't compile on OpenBSD. I'm correcting it's includes and 
headers, but it seems it's linux centric. I'll probably need to change 
it's code.


I've found some other tools but it seems almost all of them are linux 
centric:


[0]: https://github.com/fishilico/autoneighxy
[1]: https://github.com/andriyanov/ndp-proxy

I don't know if OpenBSD does have any NDP proxying functionality, 
besides the one in ndp(8). But it seems to me that, besides a bridge, a 
NDP proxy is the only viable solution (besides my ISP allowing me to 
change my router configuration).


Cheers,
Giancarlo Razzolini

Re: IPV6 routing issue

[Giancarlo Razzolini]

Em 26-06-2015 10:07, Patrik Lundin escreveu:

I have struggled with a similar problem a few years back. Can it be that
the upstream equipment does not create a route for the delegated prefix
pointing to your openbsd machine?

This would explain why you see neighbour solicitations on the outside
interface. The upstream router is not aware that the prefix should be
routed to you.
Yes, I believe it to be te problem. The prefix is delegated to the CPE, 
not the OpenBSD machine. When I run the dhcp6c program, it asks for a 
prefix delegation from the CPE and gets one. But I don't think that the 
CPE is trully delegating the prefix, hence that's why he's issuing 
neighbor solicitation messages. Someone pointed to me that I'll need to 
use a ndp proxy or use the openbsd machine as a bridge filter. I can't 
change the CPE configuration, it's locked by my ISP.


Cheers,
Giancarlo Razzolini

Re: IPV6 routing issue

[Giancarlo Razzolini]

Em 26-06-2015 16:17, Christian Weisgerber escreveu:

So you have TWO networks.  One between the CPE and your OpenBSD
firewall, and one containing the firewall and your internal machines.


Yes. Two interfaces, to be more exactly.


So you get ONE network address.


I get a prefix on the CPE. And I can configure any address in the prefix 
on any machine on my LAN (or the OpenBSD LAN iface). And traffic gets 
out. Just won't get replies.




You can't use a single network address for two networks.  This has
nothing to do with IPv6.  It's the same with IPv4.


I'm aware of that fact. But, since my CPE replies to an IA_PD request, I 
imagined it would be able to route the packets correctly.




You can use private addresses for your internal network and run NAT
on the firewall.  Or you can configure your firewall as a bridge
and filter there.
http://www.openbsd.org/faq/faq6.html#Bridge


I'm trying to get some NDP proxy running on OpenBSD. But all of them are 
linux centric. Perhaps, for now, I will use it as a filtering bridge. 
Since I have enough interfaces on my OpenBSD machine, I will have a 
bridge specifically for IPv6. And IPv4 will still be NATed.


Cheers,
Giancarlo Razzolini

Re: IPV6 routing issue

[Christian Weisgerber]

On 2015-06-26, Giancarlo Razzolini grazzol...@gmail.com wrote:

  I've recently changed my ISP and they have native IPv6. My customer 
 premises equipment, which is a GPON, supports both stateless as DHCPv6 
 on it's LAN interface. I want to put a OpenBSD firewall between this CPE 
 and my internal network.

So you have TWO networks.  One between the CPE and your OpenBSD
firewall, and one containing the firewall and your internal machines.

 I'm using OpenBSD 5.7 stable. My CPE receive a 
 /64 prefix delegation from my ISP.

So you get ONE network address.

You can't use a single network address for two networks.  This has
nothing to do with IPv6.  It's the same with IPv4.

You can use private addresses for your internal network and run NAT
on the firewall.  Or you can configure your firewall as a bridge
and filter there.
http://www.openbsd.org/faq/faq6.html#Bridge

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: IPV6 routing issue

[Christian Weisgerber]

On 2015-06-26, Giancarlo Razzolini grazzol...@gmail.com wrote:

 I don't know if OpenBSD does have any NDP proxying functionality, 
 besides the one in ndp(8). But it seems to me that, besides a bridge, a 
 NDP proxy is the only viable solution (besides my ISP allowing me to 
 change my router configuration).

Well, you can add an IPv6 address for each internal host to the
external interface of your firewall, use private addresses on the
internal network, and then use pf's binat to map between the two.
This will preserve port numbers, although it may not be enough for
nasty protocols like SIP.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: IPV6 routing issue

[Giancarlo Razzolini]

Em 26-06-2015 16:44, Christian Weisgerber escreveu:

Well, you can add an IPv6 address for each internal host to the
external interface of your firewall, use private addresses on the
internal network, and then use pf's binat to map between the two.
This will preserve port numbers, although it may not be enough for
nasty protocols like SIP.
I know I could use NAT. But, I really think it's almost an abomination 
to use it, when you have native IPv6 support. I'll contact my ISP to see 
if they can change my CPE mode of operation or, at least, allow me to 
configure it. In the meantime, I'll go with a bridge firewall. It seems 
like the most hassle free way to go. Perhaps I'll hack some NDP proxy. 
But I need IPv6 connectivity, and I need it now.


Cheers,
Giancarlo Razzolini

IPV6 routing issue

[Giancarlo Razzolini]

HI all,

I've recently changed my ISP and they have native IPv6. My customer 
premises equipment, which is a GPON, supports both stateless as DHCPv6 
on it's LAN interface. I want to put a OpenBSD firewall between this CPE 
and my internal network. I'm using OpenBSD 5.7 stable. My CPE receive a 
/64 prefix delegation from my ISP. Unfortunately, this is a dynamic 
prefix, so I can't configure anything manually.


I've managed to get wide-dhcp6 working and requesting the prefix to 
be delegated to my internal network. After that, all I needed to do was 
to run rtadvd on my internal interface, and my internal LAN machines 
began to be autoconfigurated getting ip's from the delegated prefix.


The OpenBSD firewall has 2 ipv6 addresses. One on the WAN interface 
and another on the LAN interface. If I use ping6 to ping any ipv6 host 
from my firewall, I can ping them with no problems. But, If I ping 
setting the source to be the ipv6 address from the internal interface, 
it won't work. Also, no machine from my LAN can connect to any host 
through ipv6.


I've inspected the traffic with tcpdump, and I can see the packets 
leaving my network and getting on the destination. The problem is the 
packets never gets back. My CPE equipment keeps asking for neighbour 
solicitation asking who has the ipv6 address, but the OpenBSD firewall 
never replies, so the packts get dropped. I'm currently with PF 
disabled. But I had the same problem with it enabled and with the 
default firewall configuration. I'm trying first to get ipv6 
connectivity working to after filter the packets. Anyone had a similar 
issue?


Cheers,
Giancarlo Razzolini

Re: IPv6 routing

[Denis Fondras]

A bit late perhaps, but this is how I do it :

route add -inet6 -net $PREFIX:: -prefixlen 48 -interface ::1 -reject

Of course, you have to set PREFIX to the prefix you want to reject.
After this, all routes you add should be more specific (smaller
prefix) so should work anyway.

I add this line in the /etc/hostname.IF file of the interface where
the prefix is routed to (with a ! at the start, of course).

Cheers,

Paul 'WEiRD' de Weerd



Thank you very much for the tip :)

Denis

Re: IPv6 routing

[Paul de Weerd]

On Fri, Nov 07, 2008 at 09:41:35PM +0100, Denis Fondras wrote:
 BTW: Don't forget to route the prefix to lo at the last hop so that any
 unassigned subnets don't cause the packet to be bounced back up to the
 default route.


 Could you explain how to do that on OpenBSD please ?
 Perhaps my box is misconfigured... :p

A bit late perhaps, but this is how I do it :

route add -inet6 -net $PREFIX:: -prefixlen 48 -interface ::1 -reject

Of course, you have to set PREFIX to the prefix you want to reject.
After this, all routes you add should be more specific (smaller
prefix) so should work anyway.

I add this line in the /etc/hostname.IF file of the interface where
the prefix is routed to (with a ! at the start, of course).

Cheers,

Paul 'WEiRD' de Weerd

-- 
[++-]+++.+++[---].+++[+
+++-].++[-]+.--.[-]
 http://www.weirdnet.nl/ 

Re: IPv6 routing

[Denis Fondras]

BTW: Don't forget to route the prefix to lo at the last hop so that any
unassigned subnets don't cause the packet to be bounced back up to the
default route.



Could you explain how to do that on OpenBSD please ?
Perhaps my box is misconfigured... :p

TIA,
Denis

Re: IPv6 routing

[Claudio Jeker]

On Wed, Nov 05, 2008 at 10:37:27AM +0100, Michael wrote:
 Hi,
 
 I've got trouble adding a IPv6 route to the routing table. Looked at the
 man pages and searched the web but that didn't help.
 
 I've got a setup like this
 
 [ISP A]---
|---[router]
 [ISP B]---
 
 [ISP A] and [ISP B] are ALIX boxes and [router] is another box I where
 want to add the rule. All traffic to 2a01:198:xxx::/48 should go through
 the [ISP B] box. To do that I tried:
 
 route add -inet6 2a01:198:xxx::/48 2a01:198:yyy::3
 
 but I always get:
 
 route: 2a01:198:xxx::/48: bad value
 
 Also tried other formats of 2a01:198:xxx::/48 but nothing seems to work.
 Adding just 2a01:198:xxx:: will rewrite it to /64 in the routing table.
 
 Any ideas?
 

The man page does not mention that you can use CIDR notation for IPv6.
Use -prefixlen instead that will work:
route add -inet6 2a01:198:xxx:: -repfixlen 48 2a01:198:yyy::3


-- 
:wq Claudio

Re: IPv6 routing

[Jeroen Massar]

Michael wrote:
 Hi,

 I've got trouble adding a IPv6 route to the routing table. Looked at the
 man pages and searched the web but that didn't help.

 I've got a setup like this

 [ISP A]---
|---[router]
 [ISP B]---

 [ISP A] and [ISP B] are ALIX boxes and [router] is another box I where
 want to add the rule. All traffic to 2a01:198:xxx::/48 should go through
 the [ISP B] box. To do that I tried:

 route add -inet6 2a01:198:xxx::/48 2a01:198:yyy::3

You probably need to use:

route add -inet6 2001:db8:f33d:: -prefixlen 48 2001:db8:f00d::3

BTW: Don't forget to route the prefix to lo at the last hop so that any
unassigned subnets don't cause the packet to be bounced back up to the
default route.

Greets,
 Jeroen

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: IPv6 routing

[Michael]

Hi,

Claudio Jeker schrieb:
 The man page does not mention that you can use CIDR notation for IPv6.
 Use -prefixlen instead that will work:
 route add -inet6 2a01:198:xxx:: -repfixlen 48 2a01:198:yyy::3

Thanks, that worked. :-)

# route add -inet6 2a01:198:xxx:: -prefixlen 48 2a01:198:yyy::3
add net 2a01:198:xxx::: gateway 2a01:198:yyy::3


Michael

IPv6 routing

[Michael]

Hi,

I've got trouble adding a IPv6 route to the routing table. Looked at the
man pages and searched the web but that didn't help.

I've got a setup like this

[ISP A]---
   |---[router]
[ISP B]---

[ISP A] and [ISP B] are ALIX boxes and [router] is another box I where
want to add the rule. All traffic to 2a01:198:xxx::/48 should go through
the [ISP B] box. To do that I tried:

route add -inet6 2a01:198:xxx::/48 2a01:198:yyy::3

but I always get:

route: 2a01:198:xxx::/48: bad value

Also tried other formats of 2a01:198:xxx::/48 but nothing seems to work.
Adding just 2a01:198:xxx:: will rewrite it to /64 in the routing table.

Any ideas?


Thanks in advance,

Michael

strange ipv6 routing issue

[Olivier Mehani]

Hello list,

I'm playing with IPv6 in 3.8 and came up to this strange problem.

My IPv6 connectivity is given by a broker (xs26.net) and I have set up a gif
interface to use it (gif0):

/etc/hostname.gif0 contains:

tunnel SIS0IPv4 BROKERIPv4
inet6 IPv6PREFIX::1
!route add -inet6 default IPv6PREFIX::1

gif0: flags=8151UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST mtu 1500
groups: gif 
physical address inet SIS0IPv4 -- BROKERIPv4
inet6 fe80::202:6fff:fe21:ea79%gif0 -  prefixlen 64 scopeid 0x8
inet6 IPv6PREFIX::1 -  prefixlen 64

The funny thing is that I _can_ ping a given machine.

[EMAIL PROTECTED]:~$ ping6 DISTANTHOSTNAME
PING6(56=40+8+8 bytes) IPv6PREFIX::1 -- DISTANTHOSTIPv6
16 bytes from DISTANTHOSTIPv6, icmp_seq=0 hlim=53 time=207.974 ms
16 bytes from DISTANTHOSTIPv6, icmp_seq=1 hlim=53 time=176.176 ms
16 bytes from DISTANTHOSTIPv6, icmp_seq=2 hlim=53 time=241.964 ms
16 bytes from DISTANTHOSTIPv6, icmp_seq=3 hlim=53 time=253.56 ms
^C
--- zorglub.ssji.net ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 176.176/219.918/253.560/30.306 ms

but I get a no route to host when trying to ssh to it

[EMAIL PROTECTED]:~$ ssh -v6 DISTANTHOSTNAME
OpenSSH_4.1, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to DISTANTHOSTNAME [DISTANTHOSTIPv6] port 22.
debug1: connect to address DISTANTHOSTIPv6 port 22: No route to host
ssh: connect to host DISTANTHOSTNAME port 22: No route to host

(/etc/ssh/ssh_config reads $OpenBSD: ssh_config,v 1.20 2005/01/28
09:45:53 dtucker Exp $ and has not been modified)

To be even weirder, the machines behind the router, which get IPv6 in the same
prefix manage to ssh to the very same host using IPv6 through the router.

Does somebody have some ideas/solutions about this problem ?

Useful information (note the illegal prefix len in the output of route for 
::/4, which seems to be what default resolves to when route -add'ing)

[EMAIL PROTECTED]:~$ uname -a
OpenBSD mudrublic.narf.ssji.net 3.8 GENERIC#224 i386
[EMAIL PROTECTED]:~$ route -n show -inet6
Routing tables

Internet6:
DestinationGatewayFlagsRefs
UseMtu  Interface
route: illegal prefixlen
::/4   IPv6PREFIX::1  UGS 0
1591  -   gif0
::1::1UH  0
0  33224   lo0
IPv6PREFIX::/64link#8 UC  0
0  -   gif0
IPv6PREFIX::1  link#8 UHLc0
12  -   lo0
IPv6PREFIX:100::/64link#3 UC  0
0  -   sis1
IPv6PREFIX:100::1  00:00:24:c4:22:5d  UHLc0
0  -   lo0
IPv6PREFIX:101::/64link#1 UC  0
0  -   ath0
IPv6PREFIX:101::1  00:02:6f:21:ea:79  UHLc0
0  -   lo0
IPv6PREFIX:101:211:95ff:febb:812f 00:11:95:bb:81:2f  UHLc
0 1857  -   ath0
IPv6PREFIX:101:230:65ff:fe0f:2795 00:30:65:0f:27:95  UHLc
02  -   ath0
fe80::%ath0/64 link#1 UC  0
0  -   ath0
fe80::202:6fff:fe21:ea79%ath0  00:02:6f:21:ea:79  UHLc0
0  -   lo0
fe80::211:95ff:febb:812f%ath0  00:11:95:bb:81:2f  UHLc0
109  -   ath0
fe80::230:65ff:fe0f:2795%ath0  00:30:65:0f:27:95  UHLc0
4  -   ath0
fe80::%sis0/64 link#2 UC  0
0  -   sis0
fe80::%sis1/64 link#3 UC  0
0  -   sis1
fe80::%lo0/64  fe80::1%lo0U   0
0  -   lo0
fe80::%gif0link#8 UHLc0
0  -   gif0
fe80::%gif0/64 link#8 UC  0
0  -   gif0
fe80::202:6fff:fe21:ea79%gif0  link#8 UHLc0
0  -   lo0
fe80::260:8ff:fe34:275f%gif0   link#8 UHLc0
606  -   gif0
ff01::/32  ::1UC  0
0  -   lo0
ff02::%ath0/32 link#1 UC  0
0  -   ath0
ff02::%sis0/32 link#2 UC  0
0  -   sis0
ff02::%sis1/32 link#3 UC  0
0  -   sis1
ff02::%lo0/32  ::1UC  0
0  -   lo0
ff02::%gif0/32 link#8 UC  0
0  -   gif0

dmesg not included as it does not seem to be relevant for this problem,
correct me if I'm wrong (;

thanks

-- 
Olivier Mehani [EMAIL 

Re: strange ipv6 routing issue

[David Hill]

On Sat, Feb 18, 2006 at 12:57:05PM +0100, Olivier Mehani wrote:
 Hello list,
 
 I'm playing with IPv6 in 3.8 and came up to this strange problem.
 
 My IPv6 connectivity is given by a broker (xs26.net) and I have set up a gif
 interface to use it (gif0):
 
 /etc/hostname.gif0 contains:
 
 tunnel SIS0IPv4 BROKERIPv4
 inet6 IPv6PREFIX::1
 !route add -inet6 default IPv6PREFIX::1
 
 gif0: flags=8151UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST mtu 1500
 groups: gif 
 physical address inet SIS0IPv4 -- BROKERIPv4
 inet6 fe80::202:6fff:fe21:ea79%gif0 -  prefixlen 64 scopeid 0x8
 inet6 IPv6PREFIX::1 -  prefixlen 64
 
 The funny thing is that I _can_ ping a given machine.
 
 [EMAIL PROTECTED]:~$ ping6 DISTANTHOSTNAME
 PING6(56=40+8+8 bytes) IPv6PREFIX::1 -- DISTANTHOSTIPv6
 16 bytes from DISTANTHOSTIPv6, icmp_seq=0 hlim=53 time=207.974 ms
 16 bytes from DISTANTHOSTIPv6, icmp_seq=1 hlim=53 time=176.176 ms
 16 bytes from DISTANTHOSTIPv6, icmp_seq=2 hlim=53 time=241.964 ms
 16 bytes from DISTANTHOSTIPv6, icmp_seq=3 hlim=53 time=253.56 ms
 ^C
 --- zorglub.ssji.net ping6 statistics ---
 4 packets transmitted, 4 packets received, 0.0% packet loss
 round-trip min/avg/max/std-dev = 176.176/219.918/253.560/30.306 ms
 
 but I get a no route to host when trying to ssh to it
 
 [EMAIL PROTECTED]:~$ ssh -v6 DISTANTHOSTNAME
 OpenSSH_4.1, OpenSSL 0.9.7g 11 Apr 2005
 debug1: Reading configuration data /etc/ssh/ssh_config
 debug1: Connecting to DISTANTHOSTNAME [DISTANTHOSTIPv6] port 22.
 debug1: connect to address DISTANTHOSTIPv6 port 22: No route to host
 ssh: connect to host DISTANTHOSTNAME port 22: No route to host
 
 (/etc/ssh/ssh_config reads $OpenBSD: ssh_config,v 1.20 2005/01/28
 09:45:53 dtucker Exp $ and has not been modified)
 
 To be even weirder, the machines behind the router, which get IPv6 in the same
 prefix manage to ssh to the very same host using IPv6 through the router.
 
 Does somebody have some ideas/solutions about this problem ?
 
 Useful information (note the illegal prefix len in the output of route for 
 ::/4, which seems to be what default resolves to when route -add'ing)
 
 [EMAIL PROTECTED]:~$ uname -a
 OpenBSD mudrublic.narf.ssji.net 3.8 GENERIC#224 i386
 [EMAIL PROTECTED]:~$ route -n show -inet6
 Routing tables
 
 Internet6:
 DestinationGatewayFlags
 Refs
 UseMtu  Interface
 route: illegal prefixlen
 ::/4   IPv6PREFIX::1  UGS 0
 1591  -   gif0
 ::1::1UH   0
 0  33224   lo0
 IPv6PREFIX::/64link#8 UC  0
 0  -   gif0
 IPv6PREFIX::1  link#8 UHLc0
 12  -   lo0
 IPv6PREFIX:100::/64link#3 UC  0
 0  -   sis1
 IPv6PREFIX:100::1  00:00:24:c4:22:5d  UHLc0
 0  -   lo0
 IPv6PREFIX:101::/64link#1 UC  0
 0  -   ath0
 IPv6PREFIX:101::1  00:02:6f:21:ea:79  UHLc0
 0  -   lo0
 IPv6PREFIX:101:211:95ff:febb:812f 00:11:95:bb:81:2f  UHLc
 0 1857  -   ath0
 IPv6PREFIX:101:230:65ff:fe0f:2795 00:30:65:0f:27:95  UHLc
 02  -   ath0
 fe80::%ath0/64 link#1 UC   0
 0  -   ath0
 fe80::202:6fff:fe21:ea79%ath0  00:02:6f:21:ea:79  UHLc 0
 0  -   lo0
 fe80::211:95ff:febb:812f%ath0  00:11:95:bb:81:2f  UHLc 0
 109  -   ath0
 fe80::230:65ff:fe0f:2795%ath0  00:30:65:0f:27:95  UHLc 0
 4  -   ath0
 fe80::%sis0/64 link#2 UC   0
 0  -   sis0
 fe80::%sis1/64 link#3 UC   0
 0  -   sis1
 fe80::%lo0/64  fe80::1%lo0U0
 0  -   lo0
 fe80::%gif0link#8 UHLc 0
 0  -   gif0
 fe80::%gif0/64 link#8 UC   0
 0  -   gif0
 fe80::202:6fff:fe21:ea79%gif0  link#8 UHLc 0
 0  -   lo0
 fe80::260:8ff:fe34:275f%gif0   link#8 UHLc 0
 606  -   gif0
 ff01::/32  ::1UC   0
 0  -   lo0
 ff02::%ath0/32 link#1 UC   0
 0  -   ath0
 ff02::%sis0/32 link#2 UC   0
 0  -   sis0
 ff02::%sis1/32 link#3 UC   0
 0  -   sis1
 ff02::%lo0/32  ::1UC   0
 0  -   lo0
 ff02::%gif0/32