| Summary: | netifrc - /lib64/rc/net/ip6rd.sh has two problems | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Alexander E. Patrakov <patrakov> |
| Component: | netifrc | Assignee: | netifrc Team <netifrc> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | gentoo, ironiridis |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | netifrc:ip6rd | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
ip6rd fixes
prefix and routing fixes |
||
Not sure if this bug the right place to drop this, but I've noticed that the 6rd method for calculating the prefix is wrong. CenturyLink provides 2602::/24 as a prefix, which means (assuming the host mask is 0 and the IP is WW.XX.YY.ZZ) the derived address should be of this format: 2602:00WW:XXYY:ZZ00::/56 Instead it derives this: 2602:WWXX:YYZZ::/56 In essence, it seems to ignore the prefix length specified. I'll mess around with this and see if my sick bash skills are enough to derive the correct address and submit a patch. (In reply to Christohper Harrington from comment #1) > I'll mess around with this and see if my sick bash skills are enough to > derive the correct address and submit a patch. I have a patch, and it's hideous, but I'll attach it if anyone is actually watching this bug. Otherwise I'll just carry it in my /etc/portage/patches. It correctly handles all n*4 masks: /4 /8 /12 /16 /20 /24 /28 /32 (whereas previously only /16 and /32 were actually being handled) Is this bug dead? It's been over a year. Nobody has any interest in fixing this? Created attachment 704940 [details, diff]
ip6rd fixes
I'm no expert on 6rd or even networking in general; but I really wanted this fixed so here's a patch to get started.
In this version the 6rd-relay_prefix is always added (calculated from local ip and provided ipv4mask).
_ip6rd_inet_get_network previously did not return the network address as expected, but is fixed in this patch. It is needed to calculate the 6rd-relay_prefix (previously I think it was only used to (unsuccessfully) verify that ip addresses was not RF1918).
As mentioned the ipv6 address was incorrectly calculated (at least for my prefix). I went the lazy route and added a dependency on the ipv6calc program to calculate the proper ipv6 address and mask. I'm sure it's possible to make an all-bash solution, but I don't think it's worth it; the few of us who uses 6rd can probably live with an extra dependency...
This shouldn't have been assigned to openrc@ in the first place, and that's why it seemed to get lost. Will review for inclusion. Created attachment 705069 [details, diff]
prefix and routing fixes
Thanks!
Minor revised patch which also sets a proper default route. 2000::/3 is probably enough, as it contains all current ipv6 unicast addresses, but I had some issues with some automation scripts which expects there to be a ::/0 route on the public facing interface...
|
There are multiple issues with the /lib64/rc/net/ip6rd.sh file. They were found by attempting to treat a 6in4 tunnel as a special case of 6rd. Please fix them. 1. There is no way to pass the 6rd-relay_prefix option to the "ip" binary. This option should go together with 6rd-prefix. Probably (not sure) the correct value is ${ip}/${ipv4mask}. 2. The _ip6rd_prefix_shave_bits function produces empty output if $2 -eq 32 (i.e. if someone wishes to treat his 6in4 tunnel as a special case of 6rd). This results in the eval ip6=... line producing unexpected result (containing "::" at the end) in ip6rd_pre_start(). Reproducible: Always