[Redbrick-ipv6] RedBrick IPv6 Network

Neil Costigan ncostiga at redbrick.dcu.ie
Sun Dec 21 20:26:48 GMT 2003


even less interesting but

to compare....

ipv4 traceroute from the same machine/location has tons more hops, less 
time lages between them but doesn;t get to finland

traceroute to carbon.redbrick.dcu.ie (136.206.15.1), 30 hops max, 40 
byte packets
  1  212-112-186-129.viae.wtnord.net (212.112.186.129)  1.309 ms  0.395 
ms  0.347 ms
  2  192.168.2.21 (192.168.2.21)  0.61 ms  0.539 ms  0.468 ms
  3  192.168.2.17 (192.168.2.17)  0.758 ms  0.595 ms  0.522 ms
  4  192.168.2.13 (192.168.2.13)  0.74 ms  0.71 ms  0.561 ms
  5  192.168.2.9 (192.168.2.9)  0.8 ms  0.719 ms  0.578 ms
  6  192.168.2.5 (192.168.2.5)  0.855 ms  0.785 ms  0.668 ms
  7  192.168.2.1 (192.168.2.1)  0.899 ms  0.804 ms  0.717 ms
  8  192.168.16.1 (192.168.16.1)  2.717 ms  2.546 ms  2.31 ms
  9  212.112.160.157 (212.112.160.157)  2.356 ms  146.649 ms  1.546 ms
10  sl-gw10-sto-11-1.sprintlink.net (80.77.97.81)  1.52 ms  1.234 ms  
1.271 ms
11  sl-bb21-sto-8-0.sprintlink.net (80.77.96.41)  1.411 ms  1.27 ms  
1.741 ms
12  sl-bb21-cop-12-0.sprintlink.net (213.206.129.33)  163.661 ms  
73.237 ms  36.841 ms
13  sl-bb20-cop-15-0.sprintlink.net (80.77.64.33)  9.988 ms  46.297 ms  
25.491 ms
14  so0-1-0-155m.ar1.cph1.gblx.net (64.212.107.17)  28.708 ms  25.249 
ms  54.971 ms
15  pos5-0-622m.cr2.cph1.gblx.net (67.17.65.177)  24.39 ms  25.622 ms  
25.245 ms
16  pos1-0-2488m.cr1.lon3.gblx.net (67.17.64.46)  54.422 ms  29.662 ms  
29.858 ms
17  so0-0-0-2488m.ar1.dub1.gblx.net (67.17.66.6)  78.983 ms  54.026 ms  
39.272 ms
18  heanet-2.so-3-0-0.ar1.dub1.gblx.net (208.48.23.54)  38.359 ms  
38.114 ms  38.142 ms
19  deimos-gige5-3.cwt.core.hea.net (193.1.195.161)  77.169 ms  40.106 
ms  43.386 ms
20  hyperion-gige5-2.bh.core.hea.net (193.1.195.130)  56.095 ms  40.505 
ms  40.909 ms
21  calpurnia-vlan99.bh.access.hea.net (193.1.196.122)  59.739 ms  
41.742 ms  43.045 ms
22  mantova-vlan3.bh.access.hea.net (193.1.198.245)  53.994 ms  40.131 
ms  41.399 ms
23  dcu.bh.client.hea.net (193.1.194.78)  54.72 ms  42.009 ms  41.604 ms

/neil c.

On 21 Noll 2003, at 20:17, Neil Costigan wrote:

>
> not so interesting. but i'm happy
>
>
> I've just managed an ipv6 connect to redbrick from sweden on my mac.
> my first stab at ipv6.
>
> [alice:~] neil% ping6 carbon.redbrick.dcu.ie
> PING6(56=40+8+8 bytes) 2002:d470:ba8d:1::1 --> 
> 2001:770:107:15:206:5bff:fefc:fb70
> 16 bytes from 2001:770:107:15:206:5bff:fefc:fb70, icmp_seq=0 hlim=61 
> time=66.977 ms
> 16 bytes from 2001:770:107:15:206:5bff:fefc:fb70, icmp_seq=1 hlim=61 
> time=83.693 ms
>
> and
>
> alice:~] neil% /usr/sbin/traceroute6 carbon.redbrick.dcu.ie
> traceroute6 to carbon.redbrick.dcu.ie 
> (2001:770:107:15:206:5bff:fefc:fb70) from 2002:d470:ba8d:1::1, 30 hops 
> max, 12 byte packets
>  1  2002:3eec:20cb::1  28.881 ms *  11.131 ms
>  2  ltt-p1.hel.fi.6.sn.net  14.435 ms  11.903 ms  11.551 ms
>  3  eunet.ficix1-ge.ficix.fi  13.809 ms  12.948 ms  51.638 ms
>  4  at1-0-100.r3.alto.esp.fi.v6.eunetip.net  24.899 ms  30.626 ms  
> 19.855 ms
>  5  nl-ams06d-re1-t-6.ipv6.aorta.net  65.09 ms  50.025 ms  55.301 ms
>  6  nl-ams04a-re1.ipv6.aorta.net  271.346 ms  272.242 ms  277.892 ms
>  7  eth10-0-0.xr1.ams1.gblx.net  73.519 ms  74.812 ms  71.058 ms
>  8  salinger-tun12.bh.core.hea.net  67.248 ms  66.522 ms  67.891 ms
>  9  exodus.bh.access.hea.net  68.627 ms  81.946 ms  67.235 ms
> 10  cl-10.dub-01.ie.sixxs.net  82.025 ms  78.096 ms  84.027 ms
> 11  carbon.redbrick.dcu.ie  80.228 ms  81.386 ms  72.999 ms
> [alice:~] neil%
>
> its very snowy&dark here. but the broadband pipe is fat  !
>
> /neil c.
>
>
> On 18 Noll 2003, at 12:29, Colm MacCarthaigh wrote:
>
>> After a gap of almost a year on the project. RedBrick now has working
>> IPv6 connectivity, making us the first Networking Society in Ireland
>> to offer IPv6 services (though not the first to have IPv6 - that 
>> honour
>> goes to TCD netsoc).
>>
>>   colmmacc at carbon (~) $ ping6 www.ipv6.net
>>   PING www.ipv6.net(cl-111.ams-04.nl.sixxs.net) 56 data bytes
>>   64 bytes from cl-111.ams-04.nl.sixxs.net: icmp_seq=1 ttl=57 
>> time=186 ms
>>   64 bytes from cl-111.ams-04.nl.sixxs.net: icmp_seq=2 ttl=57 
>> time=182 ms
>>   64 bytes from cl-111.ams-04.nl.sixxs.net: icmp_seq=3 ttl=57 
>> time=182 ms
>>   64 bytes from cl-111.ams-04.nl.sixxs.net: icmp_seq=4 ttl=57 
>> time=189 ms
>>   64 bytes from cl-111.ams-04.nl.sixxs.net: icmp_seq=5 ttl=57 
>> time=186 ms
>>
>>   --- www.ipv6.net ping statistics ---
>>   5 packets transmitted, 5 received, 0% loss, time 4042ms
>>   rtt min/avg/max/mdev = 182.263/185.266/189.177/2.674 ms
>>
>> Earlier this week, James Healy (DCU CSD) was able to open up protocol
>> 41 access between RedBrick and a SiXXS IPv6 node in HEAnet, after
>> we gave some assurances and explained it all. James has also given
>> us full access to the RedBrick switch, which also helped with the move
>> :)
>>
>> I'll try and explain how it all works, for future reference, and
>> because well - we're a networking society. Feel free to ask for
>> more if I havn't explained something well.
>>
>> First of all, our access is through a SixXS (www.sixxs.net) PoP 
>> located
>> in HEAnet, and we are tunneling an IPv6 allocation over IPv4 to this. 
>> This
>> tunnel is a /64, we then route our IPv6 allocation over the tunnel. 
>> The
>> allocation is a /48. For now, deathray is the nominated IPv6 router 
>> and
>> firewall.
>>
>>
>>    136.206.15.3 < ----- Protocol 41 over IPv4 -----> 193.1.31.74
>>
>>         2001:770:100:9::2                  2001:770:100:9::1
>>
>>
>> Our tunnel (2001:770:100:9::/64) is SixXS tunnel number 1900, and is
>> registered in my NIC handle (CM2064-RIPE). It's configured on deathray
>> with;
>>
>>   auto sixxs
>>   iface sixxs inet6 v4tunnel
>>     address 2001:770:100:9::2
>>     netmask 64
>>     endpoint 193.1.31.74
>>     ttl 64
>>     up ip link set mtu 1280 dev sixxs
>>     up ip route add 2000::/3 via 2001:770:100:9::1 dev sixxs
>>
>>
>> in /etc/network/interfaces. If anyone else has a Ripe or 6bone NIC 
>> handle
>> and would like to be appended to the allocation, mail and I'll see 
>> what
>> I can sort out. Our allocation is;
>>
>> 	2001:770:107::/48
>>
>> And this is routed over our tunnel. So, from an IPv6 topology point
>> of view;
>>
>>
>>                      ->  2001:770:107::/48 ->
>>
>> 	    SixXS				Deathray
>> 	2001:770:100:9::1		   2001:770:100:9::2
>>
>>
>> So, deathray is the IPv6 router on our end. I've added an IPv6 
>> firewall
>> using ip6tables to deathray, which meets both our (only allow inbound
>> on services we offer) and James's (Don't allow any outbound)
>> requirements. The ruleset is;
>>
>>   # This is the subnet used for the tunnel itself,
>>   # and is used only for routing.
>>   LINK="2001:770:100:9::2/64"
>>
>>   # This is RedBrick's IPv6 Allocation
>>   ALLOCATION="2001:770:107::/48"
>>
>>   # Flush the existing rules
>>   ip6tables -F INPUT
>>   ip6tables -F OUTPUT
>>
>>   # Allow IPv6 ICMP
>>   ip6tables -A INPUT  -i sixxs -p icmpv6 -d $LINK       -j ACCEPT
>>   ip6tables -A OUTPUT -o sixxs -p icmpv6 -s $LINK       -j ACCEPT
>>   ip6tables -A INPUT  -i sixxs -p icmpv6 -d $ALLOCATION -j ACCEPT
>>   ip6tables -A OUTPUT -o sixxs -p icmpv6 -s $ALLOCATION -j ACCEPT
>>
>>   # ip6tables does not yet have connection tracking, so we permit
>>   # packets which claim to be established (same as Cisco established)
>>   ip6tables -A INPUT  -i sixxs -p tcp -d $ALLOCATION ! --syn -j ACCEPT
>>   ip6tables -A OUTPUT -o sixxs -p tcp -s $ALLOCATION ! --syn -j ACCEPT
>>
>>   # Allow ssh, web, mail, imap, https and irc inbound
>>   ip6tables -A INPUT  -i sixxs -p tcp -d $ALLOCATION --dport 22   -j 
>> ACCEPT
>>   ip6tables -A INPUT  -i sixxs -p tcp -d $ALLOCATION --dport 25   -j 
>> ACCEPT
>>   ip6tables -A INPUT  -i sixxs -p tcp -d $ALLOCATION --dport 80   -j 
>> ACCEPT
>>   ip6tables -A INPUT  -i sixxs -p tcp -d $ALLOCATION --dport 143  -j 
>> ACCEPT
>>   ip6tables -A INPUT  -i sixxs -p tcp -d $ALLOCATION --dport 443  -j 
>> ACCEPT
>>   ip6tables -A INPUT  -i sixxs -p tcp -d $ALLOCATION --dport 6667 -j 
>> ACCEPT
>>
>>   # Drop everything else, including all unestablished outbound
>>   # connectivity
>>   ip6tables -A INPUT  -i sixxs -j LOG --log-prefix "INPUT:"
>>   ip6tables -A INPUT  -i sixxs -j DROP
>>   ip6tables -A OUTPUT -o sixxs -j LOG --log-prefix "OUTPUT:"
>>   ip6tables -A OUTPUT -o sixxs -j DROP
>>
>>
>> Not allowing any outbound is slightly harsh, however it mirrors the 
>> IPv4
>> setup, and is one of the concerns James had about the connectivity. So
>> for the time being it remains, but will be kept under review. From an
>> offering-services-to-members point of view, it makes no difference :)
>>
>> Now, having connectivty and an allocation wouldnt be much use without
>> the ability to route IPv6, so in /etc/sysctl.conf on deathray, we 
>> have;
>>
>> 	net/ipv6/conf/all/forwarding=1
>>
>> This allows deathray to route IPv6 for all of our hosts. The next
>> step in the process was to assign IPv6 addresses from our allocation
>> to Carbon, Prodigy and Deathray. To achieve this we are doing two
>> things.
>>
>> First of all, we are only using a /64 from our /48 for the RedBrick
>> subnet, this gives us lots of spare subets for later in RedBrick
>> life. Because we're ".15" in IPv4, I went with 2001:770:107:15::/64.
>> For deathray itself, the IPv6 address is staticaly configured, again
>> in /etc/network/interfaces;
>>
>> 	iface eth0 inet6 static
>>         address 2001:770:107:15:20d:56ff:fe70:c857
>>         netmask 64
>>
>> In order to get addresses to other machines on the Subnet, we are 
>> using
>> radvd - the IPv6 router advertisement daemon. This is running on
>> deathray, and advertising out of eth0. The following is the config
>> in /etc/radvd.conf;
>>
>> 	interface eth0
>> 	{
>> 	   AdvSendAdvert on;
>> 	   prefix 2001:770:107:15::/64
>> 	   {
>> 	   };
>> 	};
>>
>> radvd works in IPv6 multicast mode, which means all IPv6 machines
>> within a local ethernet segment will see the router advertisement.
>> To make sure we didnt end up giving IPv6 address to the private
>> RFC1918 interfaces on carbon/deathray/prodigy, we used our enable
>> access on the switch yesterday to partition the switchports using
>> vlans. It's important that we make sure to keep things this way :)
>>
>> Anyway, after all that, deathray and carbon were fully working
>> in IPv6. Prodigy needed us to touch /etc/hostname6.eth0 and reboot
>> (goddamn Solaris!) but now it too has an IPv6 address.
>>
>> 	deathray	2001:770:107:15:20D:56FF:FE70:C857
>> 	carbon		2001:770:107:15:206:5BFF:FEFC:FB70
>> 	prodigy		2001:770:107:15:A00:20FF:FEAB:E119
>>
>> And the following services have been IPv6 enabled;
>>
>> 	deathray - ssh/scp
>> 	carbon   - ssh/scp
>> 	prodigy	 - ssh/scp,imap,http,webmail
>>
>> In other words, every outfacing user available service :)
>>
>> I've added two reverse DNS zones for our allocation;
>>
>> 	7.0.1.0.0.7.7.0.1.0.0.2.ip6.int
>> 	7.0.1.0.0.7.7.0.1.0.0.2.ip6.arpa
>>
>> And added the neccessary fu for carbon/prodigy/deathray. Fergus has 
>> kindly
>> configured the DCU nameservers to slave the zones from us and serve 
>> them,
>> HEAnet is also acting as a secondary. For the forward zone, I've added
>> .ipv4 and .ipv6 records, ie;
>>
>> 	Machines;
>> 	carbon.ipv4.redbrick.dcu.ie, carbon.ipv6.redbrick.dcu.ie
>> 	deathray.ipv4.redbrick.dcu.ie, deathray.ipv6.redbrick.dcu.ie
>> 	prodigy.ipv4.redbrick.dcu.ie, prodigy.ipv6.redbrick.dcu.ie
>> 	
>> 	Services;
>> 	www.ipv4.redbrick.dcu.ie , www.ipv6.redbrick.dcu.ie
>> 	login.ipv4.redbrick.dcu.ie , login.ipv6.redbrick.dcu.ie
>> 	lists.ipv4.redbrick.dcu.ie, lists.ipv6.redbrick.dcu.ie
>> 	webmail.ipv4.redbrick.dcu.ie, webmail.ipv6.redbrick.dcu.ie
>> 	imap.ipv4.redbrick.dcu.ie, imap.ipv4.redbrick.dcu.ie
>>
>>
>> These records are all live now :) They allow you to use DNS to force
>> which protocol to use. Later this evening, after it's been announced
>> on .announce, the standard records like "carbon.redbrick.dcu.ie"
>> and "www.redbrick.dcu.ie" will all get IPv6 address aswell, this means
>> peoples own machines will decide which protocol to use automatically.
>>
>> That's it, I think :) People should now come up with cool use of
>> addresses, we have several billion now.
>>
>> I realise a lot of that will have been gobbledegook to people, but 
>> don't
>> worry, over the next few weeks, we'll be explaining more about Ipv6 
>> from
>> the basics up :)
>>
>> It's likely there may be some problems with the config of our 
>> services,
>> so if you have Ipv6, please try it out with RedBrick, and notify us
>> of all problems.
>>
>> -- 
>> colmmacc at redbrick.dcu.ie        PubKey: colmmacc+pgp at redbrick.dcu.ie
>> Web:                                 http://devnull.redbrick.dcu.ie/
>>
>> _______________________________________________
>> Redbrick-ipv6 mailing list
>> Redbrick-ipv6 at lists.redbrick.dcu.ie
>> http://lists.redbrick.dcu.ie/mailman/listinfo/redbrick-ipv6
>>
>
>
> _______________________________________________
> Redbrick-ipv6 mailing list
> Redbrick-ipv6 at lists.redbrick.dcu.ie
> http://lists.redbrick.dcu.ie/mailman/listinfo/redbrick-ipv6
>





More information about the Redbrick-ipv6 mailing list