sanghee
3 years ago
6 changed files with 118 additions and 107 deletions
@ -0,0 +1,7 @@
|
||||
# This image used for CI. |
||||
|
||||
FROM debian:latest |
||||
MAINTAINER Timothée Floure <timothee.floure@ungleich.ch> |
||||
|
||||
RUN apt-get update |
||||
RUN apt-get install -y make lektor imagemagick openssh-client rsync |
||||
@ -1,87 +0,0 @@
|
||||
title: How to route IPv4 via IPv6 |
||||
--- |
||||
pub_date: 2019-12-10 |
||||
--- |
||||
author: ungleich network |
||||
--- |
||||
twitter_handle: ungleich |
||||
--- |
||||
_hidden: yes |
||||
--- |
||||
_discoverable: no |
||||
--- |
||||
abstract: |
||||
Bringing IPv4 into the IPv6 world |
||||
--- |
||||
body: |
||||
|
||||
Imagine the following: you are running an IPv6 only network. And now |
||||
someone asks you to pass IPv4 traffic through it, without tunneling |
||||
it. Was sounds crazy at first, is actually quite feasible. |
||||
|
||||
## A short routing recap |
||||
|
||||
Routers have routing tables. The routing tables basically say |
||||
"if you receive a packet for this host, send it to that router". |
||||
|
||||
 |
||||
|
||||
The important thing about this process is that the information on |
||||
where to send it to, is **not in the packet**. |
||||
|
||||
## How to send IPv4 packets via IPv6 |
||||
|
||||
Because the next hop is not written into the IPv4 packet, the router |
||||
is free to forward the packet via any method it thinks is the |
||||
best. And if that happens to be IPv6 - well, it will forward the IPv4 |
||||
packet via an IPv6 neighbour. |
||||
|
||||
## A practical example! |
||||
|
||||
``` |
||||
[root@diamond ~]# ip -6 r |
||||
::1 dev lo proto kernel metric 256 pref medium |
||||
2a0a:e5c1:137::/48 dev wgungleich proto kernel metric 256 pref medium |
||||
fe80::/64 dev wlp0s20f3 proto kernel metric 256 pref medium |
||||
[root@diamond ~]# ip r |
||||
default via 192.168.84.1 dev wlp0s20f3 proto dhcp src 192.168.84.7 metric 302 |
||||
192.168.84.0/22 dev wlp0s20f3 proto dhcp scope link src 192.168.84.7 metric 302 |
||||
[root@diamond ~]# ip route add 10.0.0.0/8 via inet6 2a0a:e5c1:137::22 |
||||
[root@diamond ~]# ip -6 route |
||||
::1 dev lo proto kernel metric 256 pref medium |
||||
2a0a:e5c1:137::/48 dev wgungleich proto kernel metric 256 pref medium |
||||
fe80::/64 dev wlp0s20f3 proto kernel metric 256 pref medium |
||||
[root@diamond ~]# ip r |
||||
default via 192.168.84.1 dev wlp0s20f3 proto dhcp src 192.168.84.7 metric 302 |
||||
10.0.0.0/8 via inet6 2a0a:e5c1:137::22 dev wgungleich |
||||
192.168.84.0/22 dev wlp0s20f3 proto dhcp scope link src 192.168.84.7 metric 302 |
||||
[root@diamond ~]# |
||||
``` |
||||
|
||||
## More in the cloud |
||||
|
||||
Actually, what happens behind the scenes is that the VM is running VNC |
||||
(we are also experimenting with XRDP), so I have actually full access |
||||
to a remote Linux desktop via browser and can even run applications |
||||
like libreoffice, blender or gimp remotely. |
||||
|
||||
Because I think it's a cool thing to have, our team at ungleich added |
||||
it as an offer to our [Black IPv6 Friday |
||||
Crowdfunding](https://swiss-crowdfunder.com/campaigns/black-ipv6-friday?locale=en). |
||||
|
||||
Below you can actually see how it looks like: |
||||
|
||||
|
||||
root@beebox ~ # route add 192.168.0.0/16 2a0a:e5c1:100::1 |
||||
add net 192.168.0.0/16: gateway 2a0a:e5c1:100::1 |
||||
root@beebox ~ # route -n get 192.168.1.2 |
||||
route to: 192.168.1.2 |
||||
destination: 192.168.0.0 |
||||
mask: 255.255.0.0 |
||||
gateway: 2a0a:e5c1:100::1 |
||||
interface: tun3 |
||||
if address: 2a0a:e5c1:11e::1 |
||||
priority: 8 (static) |
||||
flags: <UP,GATEWAY,DONE,STATIC> |
||||
use mtu expire |
||||
2 0 0 |
||||
@ -0,0 +1,97 @@
|
||||
title: How to route IPv4 via IPv6 |
||||
--- |
||||
pub_date: 2020-02-10 |
||||
--- |
||||
author: ungleich network |
||||
--- |
||||
twitter_handle: ungleich |
||||
--- |
||||
_hidden: no |
||||
--- |
||||
_discoverable: yes |
||||
--- |
||||
abstract: |
||||
Bringing IPv4 into the IPv6 world |
||||
--- |
||||
body: |
||||
|
||||
Imagine the following: you are running an IPv6 only network. And now |
||||
someone asks you to pass IPv4 traffic through it, without tunneling |
||||
it. Was sounds crazy at first, is actually quite feasible. |
||||
|
||||
## A short routing recap |
||||
|
||||
Routers have routing tables. The routing tables basically say |
||||
"if you receive a packet for this host, send it to that router". |
||||
|
||||
 |
||||
|
||||
The important thing about this process is that the information on |
||||
where to send it to, is **not in the packet**. |
||||
|
||||
## How to send IPv4 packets via IPv6 |
||||
|
||||
Because the next hop is not written into the IPv4 packet, the router |
||||
is free to forward the packet via any method it thinks is the |
||||
best. And if that happens to be IPv6 - well, it will forward the IPv4 |
||||
packet via an IPv6 neighbour. |
||||
|
||||
## A practical example! |
||||
|
||||
In the IPv6 only coworking network in the [Digital |
||||
Chalet](/u/projects/digital-chalet/), I can add an IPv4 default route |
||||
via the IPv6 router: |
||||
|
||||
``` |
||||
[root@diamond ~]# ip route add 0/0 nexthop via inet6 fe80::21b:21ff:febb:6934 dev wlp0s20f3 |
||||
[root@diamond ~]# ip r |
||||
default via inet6 fe80::21b:21ff:febb:6934 dev wlp0s20f3 |
||||
[root@diamond ~]# |
||||
``` |
||||
|
||||
Now to be able to actually transmit IPv4 packets, I do need a source |
||||
IPv4 address. In the current network I can use an address in the |
||||
unused 10.0.8.0/22 network, however I'll add it with a /32 mask to |
||||
make it clear that there is no interface local route applied: |
||||
|
||||
``` |
||||
[root@diamond ~]# ip addr add 10.0.8.42/32 dev wlp0s20f3 |
||||
[root@diamond ~]# ip r |
||||
default via inet6 fe80::21b:21ff:febb:6934 dev wlp0s20f3 |
||||
[root@diamond ~]# ip a sh dev wlp0s20f3 |
||||
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 |
||||
link/ether 24:ee:9a:54:c3:bf brd ff:ff:ff:ff:ff:ff |
||||
inet 10.0.8.42/32 scope global wlp0s20f3 |
||||
valid_lft forever preferred_lft forever |
||||
inet6 2a0a:e5c0:0:4:c6ea:b1a8:ec14:6f35/64 scope global dynamic mngtmpaddr noprefixroute |
||||
valid_lft 86400sec preferred_lft 14400sec |
||||
inet6 fe80::3b98:cb58:ed02:c25/64 scope link |
||||
valid_lft forever preferred_lft forever |
||||
[root@diamond ~]# |
||||
|
||||
``` |
||||
|
||||
And I can indeed ping another IPv4 address, routed via IPv6! |
||||
|
||||
``` |
||||
[root@diamond ~]# ping -4 10.0.8.3 |
||||
PING 10.0.8.3 (10.0.8.3) 56(84) bytes of data. |
||||
64 bytes from 10.0.8.3: icmp_seq=1 ttl=64 time=2.37 ms |
||||
^C |
||||
--- 10.0.8.3 ping statistics --- |
||||
1 packets transmitted, 1 received, 0% packet loss, time 0ms |
||||
rtt min/avg/max/mdev = 2.365/2.365/2.365/0.000 ms |
||||
[root@diamond ~]# |
||||
``` |
||||
|
||||
## Why? |
||||
|
||||
Why would anyone want to do this? It's quite easy: with this you can |
||||
route an IPv4 address to an IPv6 only host. This enables IPv6 only |
||||
resources to create and send IPv4 packets, even if they don't have |
||||
IPv4 routes. |
||||
|
||||
## Do it yourself |
||||
|
||||
If you don't believe us that it is possible, you can test it yourself |
||||
on IPv6 only VMs on [IPv6OnlyHosting.com](https://ipv6onlyhosting.com). |
||||
Loading…
Reference in new issue