Vocabulary training: IPv6 on Link vs. IPv6 Routed

layer7

Hi,

this question might look strange, coming from a hoster but i was unable to find a clear, technical explanations about this topic.

Since a customer was asking for it, but could actually not explain what this means technically lol here my question:

What is a routed IPv6 network technically?

So what means an IPv6 network a routed one?

Thank you!

Moopah

@yoursunny

davide

https://serverfault.com/questions/684455/ipv6-differences-between-routed-prefix-and-link-prefix

layer7

@davide said:
https://serverfault.com/questions/684455/ipv6-differences-between-routed-prefix-and-link-prefix

Hi,

thanks, i found this too.

But either i dont understand it properly ( which is definitely not impossible ) or its simply not technically described well enough for me to understand it. Also it has multiple answers that collide. And having in serverfault 22 votes is for me personally not an explanation i would bet my money on.

What makes a /64 network a routed one? What makes a /48 network a routed one?

I fully do not understand this routed vs. linked network stuff. And maybe an explanation outside serverfault.com with 22 or 3 or what ever minor upvotes would be nice.

Something from a RIR / Manufacturer of router / wikipedia / what ever at least semi-official.

In my (good) old world all networks that are explicitly defined by the router are always routed networks.

And all networks ( which are not defined on the router of the network ) but maybe software defined within a private entity could be named "linked" while this vocabulary is for me completely unknown in this context actually.

I just hope that some other hoster(s) who advertise explicitly with "routed" networks could explain what he actually mean with this...

Andreix

I believe most users are familiarized with OVH's junky way to add floating IPs. A bunch of fiddling with post-up/pre-up scripting in interfaces file. Hetzner does that too.
That would be, what a user refers to, a routed setup.

While using the old, plug and play method with gw, netmask, bcast directly on eth interface is a non-routed setup.

layer7

@Andreix said:
I believe most users are familiarized with OVH's junky way to add floating IPs. A bunch of fiddling with post-up/pre-up scripting in interfaces file. Hetzner does that too.
That would be, what a user refers to, a routed setup.

While using the old, plug and play method with gw, netmask, bcast directly on eth interface is a non-routed setup.

Hi,

thanks for the answer.

If i check on hetzner:

https://docs.hetzner.com/cloud/floating-ips/getting-started/adding-a-floating-ip/

i can see:

or

https://docs.hetzner.com/cloud/floating-ips/persistent-configuration

i can see for persistent configs:

IPv4:

 auto eth0:1
 iface eth0:1 inet static
     address your.Float.ing.IP
     netmask 32

IPv6:

 auto eth0:1
 iface eth0:1 inet6 static
     address one IPv6 address of the subnet, e.g. 2a01:4f9:0:2a1::2
     netmask 64

which is for me the " good old way " just like you mentioned it.

And OVH writes on:

https://us.ovhcloud.com/public-cloud/floating-ip/

A Floating IP is a public, static IP address for exposing services that provide high flexibility. This type of IP can be assigned to an instance or a network function such as Load Balancer and then be quickly re-assigned.

Which is for me just a regular, normal IP, with a very short ARP Living time in their router so it can be switched between MAC addresses.

So, what ever "routed" networks are supposed to be, as it seems to me, its not what OVH / Hetzner calls Floating-IPs.....

Hrhr i seems not to be a too much easy topic / question to answer.

I hope a hoster who offers this routed magic stuff, will have time / can actually explain what he/she sells ^^;

Andreix

Maybe things changed since last time I used OVH. It used to be something like:

auto eth0
iface eth0 inet static
address 5.6.77.8
netmask 255.255.255.255
broadcast 5.6.77.8
post-up route add 123.4.5.254 dev eth0
post-up route add default gw 123.4.5.254
post-down route del default gw 123.4.5.254
post-down route del 123.4.5.254 dev eth0

davide

Take it with a ton of salt ... if it might help, my suspect is:

• on-link prefix: a prefix not routable outside the network segment, used only within the servers managed by the customers within the segment;
• routed prefix: packets from/to the prefix can cross the router.

Those Serverfault answers are confusing because they consider both the ISP's router and the CPE router.

Andreix

So basically a L2 vs L3 link...

layer7

@Andreix said:
Maybe things changed since last time I used OVH. It used to be something like:

auto eth0
iface eth0 inet static
address 5.6.77.8
netmask 255.255.255.255
broadcast 5.6.77.8
post-up route add 123.4.5.254 dev eth0
post-up route add default gw 123.4.5.254
post-down route del default gw 123.4.5.254
post-down route del 123.4.5.254 dev eth0

Hi,

this config actually says that those are /32 IPs, which means its actually a single IP with just itself in the "network", while you cant call that network here.

Thats used to avoid broadcasting traffic flowing through your network and eating your bandwidth.

Unfortunately i think it cant serve us as an example for an ipv6 routed network. But i get an idea of what you mean, but still, makes no sense to me why a customer would want that compared to something real.

Also what advantage ( for the customer ) should be there? A config like this is just fuck-up. It has if ever only disadvantages if you are using software that expects "proper" alias normal network config.

@davide said:
Take it with a ton of salt ... if it might help, my suspect is:

• on-link prefix: a prefix not routable outside the network segment, used only within the servers managed by the customers within the segment;
• routed prefix: packets from/to the prefix can cross the router.

Those Serverfault answers are confusing because they consider both the ISP's router and the CPE router.

yes, that was also my idea / understanding to sum it up.

But this has actually no advantages for the customer. Actually only disadvantages. At least nothing comes up in my mind.

If you would need it, you could build this behavior yourself, if you have a "real" -- "good old" network. ( Why ever you would want to complicate your network setup ).

Hrhr, i have to admit that i am getting excited, if in the next days some ultra 1337 pr0 will come around the corner and solve this mystery full of interpretation and assumption

davide

@layer7 said::
But this has actually no advantages for the customer. Actually only disadvantages. At least nothing comes up in my mind.

In AWS, the same availability zone has 200 µs latency toward private addresses, and higher toward the same destinations over their public addresses. Perhaps that's the expectation here, perhaps with the additional expectation that internal traffic is unmetered.

Perhaps

lukast__

The explanation by @yoursunny (https://lowendspirit.com/discussion/2815/ipv6-neighbor-discovery-responder-for-kvm-vps):

The server has on-link IP address 192.0.2.2.

• The router knows this IP address is on-link because it is in the 192.0.2.0/24 subnet that is configured on the router interface.
• To deliver a packet to 192.0.2.2, the router sends an ARP query of 192.0.2.2 to learn the server's MAC address, which should be responded by the server.

The server has routed IP subnet 198.51.100.0/24.

• The router must be configured to know: 198.51.100.0/24 is reachable via 192.0.2.2.
• To deliver a packet to 198.51.100.2, the router first queries its routing table and finds the above entry, then sends an ARP query to learn the MAC address of 192.0.2.2 which should be responded by the server, and finally delivers the packet to the learned MAC address.

The main difference is what IP address is enclosed in the ARP query:

• If the destination IP address is an on-link IP address, the ARP query contains the destination IP address itself.
• If the destination IP address is in a routed subnet, the ARP query contains the nexthop IP address, as determined by the routing table

The situation is a bit more complex in IPv6 because each network interface can have multiple IPv6 addresses, but the same concept applies.
Instead of Address Resolution Protocol (ARP), IPv6 uses Neighbor Discovery Protocol that is part of ICMPv6.

davide

RFC5942 said:
The original Neighbor Discovery (ND) specification [RFC4861] was
unclear in its usage of the term "on-link" in a few places. In
IPv6, an address is on-link (with respect to a specific link), if
the address has been assigned to an interface attached to that
link. Any node attached to the link can send a datagram directly
to an on-link address without forwarding the datagram through a
router. However, in order for a node to know that a destination
is on-link, it must obtain configuration information to that
effect. [...]

If I understand, the reason for a hosting customer to prefer a routed prefix over an on-link prefix is to reduce the NDP chatter?

ehab

i am only interested to know all about the female anatomy.

layer7

@davide said:

RFC5942 said:
The original Neighbor Discovery (ND) specification [RFC4861] was
unclear in its usage of the term "on-link" in a few places. In
IPv6, an address is on-link (with respect to a specific link), if
the address has been assigned to an interface attached to that
link. Any node attached to the link can send a datagram directly
to an on-link address without forwarding the datagram through a
router. However, in order for a node to know that a destination
is on-link, it must obtain configuration information to that
effect. [...]

If I understand, the reason for a hosting customer to prefer a routed prefix over an on-link prefix is to reduce the NDP chatter?

Hi,

mymymy you are really diving in Thank you for that!

So this clarifies what "on-link" means for IPv6. IP assigned on interface AND the IPv6 addresses on the link can talk with each other directly according to:

RFC5942:

 Nodes
   consider addresses covered by an on-link prefix to be directly
   attached to the same link as the sending node, i.e., they send
   traffic for such addresses directly rather than to a router.

So a routed network, if we assume its just the opposite would mean that the network config will forbid direct communication between the IPv6 addresses.

They will have to be send to / through a gateway alias router that will handle it.

Good for the hoster:

• Less Network noise / NDP
• Improved security so customers can less easily hack other customers
• Full control / observation of traffic

But actually i can not see anything good for the customers.... except maybe they dont want to be bothered by their neighbors directly... but i dont see a technical advantage for the customers why they should specifically ask for it ( some usecase / application will require routed networks ) ....

VittG

The main point with "routed" IPv6 is that you could for example route a whole subnet (/64, /48, etc) to a single server (eg. using as via/nexthop the fe80:... link-local address of the server that's derived from the MAC address of the network interface) and that server would be able to fully use it, with just a single route entry and a single neighbor entry on the router of the provider. The standard alternative would quickly fill the neighbor table with each and every single IPv6 address being actively used by the server.

With "routed" IPv4, you could fully utilize public subnets this way, without wasting any single address. You could directly use public /32s, like OVH does, or you could use a "softer"/hybrid approach. Consider for example having every server in a big private LAN, without direct public IPv4s. Or maybe, you could instead have each server in a private/isolated VLAN that can only see the router directly. In both examples, ARP is done with private IPv4s only. Then, each public IPv4 (even .0, .255 and so on) can be individually routed as /32 via the private IPv4 of the server that has to use the public IPv4. It's still not straightforward unfortunately, for example the servers need specific routing configuration (in Linux that'd be something like ip -4 address add private.ip/20 dev eth0, ip -4 address add public.ip/32 dev eth0 and ip -4 route add default via gw.ip dev eth0 src public.ip) and/or explicit address binding configuration in programs, in order to use the public IP, and not the private one, to communicate with external networks. That's because in IPv4 there is no explicit concept of public and private addresses embedded directly in the protocol, like there is in IPv6 with the link-local fe80:... and the like. In other words, fe80:... gets a "special treatment" by the routing stacks in IPv6, but 192.168.... and the other IPv4 private subnets do not in IPv4 (IIRC, only loopback, multicast and broadcast addresses are "special" in IPv4).

pwned

I seem to recall yoursunny running into problems with Docker and on-link IPv6. Routed IPv6 works better. He describes the issue in detail and provides a workaround at https://yoursunny.com/t/2021/ndpresponder/