summaryrefslogtreecommitdiff
path: root/hurd/translator/pfinet/ipv6.mdwn
blob: edd31017df0e7ec30ed431941d6947bd25fbe445 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
[[!meta copyright="Copyright © 2007, 2008, 2010, 2012 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[Stefan_Siegl|stesie]] has added IPv6 support to the pfinet [[translator]].
This was [Savannah task #5470](http://savannah.gnu.org/task/?5470).


# Implementation

Because the IPv4 and IPv6 protocols are
quite related to each other (think of mapped IPv4 addresses, etc.), there is no
separate [[server|translator]] for IPv6 but support for the latter has been
incorporated into the common pfinet.  Unfortunately it's a little bit clumsy
now to set the [[translator]] up, since it has to be bound to
*/servers/socket/2* (like before) as well as */servers/socket/26* (for IPv6).

To achieve this, you can tell pfinet to install [[active_translators|active]]
on specified nodes, using **-4** and **-6** options.  This is, you have to
install a [[passive_translator|passive]] on */servers/socket/2* that also binds
the IPv6 port and vice versa.


# Examples

Normal IPv4 network setup, address 192.168.7.23/24 and gateway 192.168.7.1.
IPv6 address shall be assigned using IPv6 auto-configuration.

    settrans -fgp /servers/socket/2 ↩
      /hurd/pfinet -6 /servers/socket/26-i eth0 -a 192.168.7.23 -m 255.255.255.0 -g 192.168.7.1
    settrans -fgp /servers/socket/26 ↩
      /hurd/pfinet -4 /servers/socket/2-i eth0 -a 192.168.7.23 -m 255.255.255.0 -g 192.168.7.1

Quite the same, but with static IPv6 address assignment:

    settrans -fgp /servers/socket/2 ↩
      /hurd/pfinet -6 /servers/socket/26-i eth0 -a 192.168.7.23 -m 255.255.255.0 -g 192.168.7.1-A 2001:4b88:10e4:0:216:3eff:feff:4223/64 -G 2001:4b88:10e4::1
    settrans -fgp /servers/socket/26 ↩
      /hurd/pfinet -4 /servers/socket/2-i eth0 -a 192.168.7.23 -m 255.255.255.0 -g 192.168.7.1-A 2001:4b88:10e4:0:216:3eff:feff:4223/64 -G 2001:4b88:10e4::1


# Missing Functionality

Amongst other things, support for [[IOCTL]]s is missing.


## IRC, freenode, #hurd, 2012-12-10

[[!tag open_issue_hurd]]

    <braunr> looks like pfinet -G option doesn't work
    <braunr> if someone is interested in fixing this (it concerns static IPv6
      routing)
    <braunr> youpi: have you ever successfully used pfinet with global
      statically configured ipv6 addresses ?
    <youpi> never tried
    <braunr> ok
    <braunr> i'd like to set this up on my VMs but it looks bugged :/
    <braunr> i can't manage to set correctly set the gateway


### IRC, freenode, #hurd, 2012-12-12

    <braunr> hm, pfinet seems not to support ipv6 well at all :(
    <pinotree> braunr: really?
    <braunr> pinotree: i can't manage to set a global address statically and
      make it communicate with neighbours
    <braunr> pfinet receives the advertisement (during neighbour discovery) but
      immediately resends the same solicitation again
    <gnu_srs> According to the pfinet/README IPv6 support was added in 2007
      from Linux 2.2.14 while the rest is from 2.2.12
    <braunr> according to me, bugs were added at the same time
    <braunr> :p
    <braunr> in addition, ipv6 in linux 2.2 was, uh, not working well either
    <braunr> even with 2.4, it was still messy
    <gnu_srs> maybe we should try to upgrade the TCP/IP stack to something
      2.6+?
    <gnu_srs> (a lot of work though)
    <braunr> we've already had that discussion
    <gnu_srs> Yes. What is the best way forward, a GSoC task? 
    <gnu_srs> There is one already:
      http://www.gnu.org/software/hurd/community/gsoc/project_ideas/tcp_ip_stack.html
    <braunr> personally, i'd advocate resuing code from netbsd