GSoC: Initial IPv6 code now in trunk

Blog post by kallisti5 on Tue, 2010-07-20 13:10
,

There is great news from the 2010 GSoC midterms... Atis' GSoC work thus far on IPv6 has been merged into the main-line Haiku trunk by Axel due to its quality.

Apply the buildfile diff attached to this post, to any post-r37604 sources to give IPv6 a whirl. Please keep in mind the IPv6 code is still extremely early, using IPv6 may result in dreaded KDL's and other general bugginess. See below for Atis' example usage of the IPv6 modules.

Bug reports on the new IPv6 support can be made on Trac under the Network & Internet >> IPv6 component.

#
# IPv6 command quick demonstration.
# Note that for the last test to work, there should be 
# a host with address fc00::2 connected to the link.
# Ping from outside is also spprted but not shown here.
#
 
ip6demo()
{
	# configure IPv6 address on loopback interface
	ifconfig loop:0 inet6 ::1 up
 
	# remove existing IPv4 interface
	ifconfig -d /dev/net/etherpci/0
 
	# configure IPv6 address on ethernet interface
	ifconfig /dev/net/etherpci/0 inet6 fc00::1 plen 64 up
 
	# configure IPv6 default route
	route add /dev/net/etherpci/0 inet6 :: plen 0 gateway fc00::2
 
	# test ping to local address
	ping6 -c 3 ::1
 
	# test ping to remote address
	ping6 -c 3 fc00::2
}
 
ip6demo

AttachmentSize
ipv6-build.diff_.txt1.12 KB

Comments

Re: GSoC: Initial IPv6 code now in trunk

by starsseed - 2010-07-20 17:45

I actually love this kind of news...

Congratulations Atis.

Re: GSoC: Initial IPv6 code now in trunk

by NoHaikuForMe - 2010-07-20 23:23

The address range used in the example is reserved, and should be not be used in this way.

Re: GSoC: Initial IPv6 code now in trunk

by kallisti5 - 2010-07-21 00:53
NoHaikuForMe wrote:

The address range used in the example is reserved, and should be not be used in this way.

A unique local unicast address was used as an example by the GSoC student. YMMV

RFC4193

Re: GSoC: Initial IPv6 code now in trunk

by NoHaikuForMe - 2010-07-21 18:02

Yes, as I said, a reserved address. The addresses in this range are "unique" because they're allocated by a registry. That registry does not yet exist, and until it does the entire range is reserved and thus not available for the use it was put to here.

RFC4193 mentions fc00::/8 only in passing, and is mostly about its neighbour fd00::/8 (it calls this distinction the 'L' bit in the relevant paragraphs) but even fd00::/8 is not to be allocated in the way described, by arbitrarily hard coding easy-to-type bit sequences.