Re: IPv6 routing problems with vether and vmm
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
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
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
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
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
> 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
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
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
. 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
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
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
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
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
